Nuclear Explosion Animation w/o ICBM

[NotSoGood]

Edit: The space before EFFECT shouldn't be there either. That appears to be caused by a problem when posting on this forum (I've had it happen before).

Use

 tags around them. Then you shouldn't have too many spaces. Somehow the forum adds white space. Below is a test, I haven't added any spaces there:
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

and the same in code tags:[CODE]aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

 

[General Tso]

That makes sense. Since it was only one line, I tried to save some time by not using

. Guess I won't do that in the future.

 

[Baldyr]

While we're on the subject, what does this function do?

CyPlot.nukeExplosion(iRange, pNukeUnit)

I obviously never tried using it myself, but would it just trigger a nuclear explosion without the mushroom cloud animation? What's that about a CyUnit instance (2nd arg), by the way?

 

[Afforess]

Yes, the animation effect and explosion are seperate entities. Calling the CyPlot function merely destroys the units, buildings, and adds fallouts. Modders can use whatever animation they feel like, the animation is not tied to the function.

The pNukeUnit is optional; and used for ICBM's and the such (to show the button icon of the unit that caused it), but you can just give it NULL if you want, and nothing bad happens.

 

[Baldyr]

The pNukeUnit is optional; and used for ICBM's and the such (to show the button icon of the unit that caused it), but you can just give it NULL if you want, and nothing bad happens.

Aha! What kind of setting is "null" by the way? I'm new to this so I realize it might sound like a stupid question.

I know about "None" but I'm not exactly sure when you can use that... Could you set any variable to "None" (or "null") and the rest of the code would be able to cope with it? (No errors for not being an integer value, a list or a string or whatever?) Can a Cy instance (like a unit or a city) be "none/null"? Is "-1" a valid "null" value for a indexed object? (Since those would be indexed zero and up.)

What gives?

 

[The_J]

NONE, null, NIL, etc. are just variables which do not really contain anything (this is simplified).
Not every function is able to use "nothing" as a variable, but i think, you can use instead of instance (not a defined variable type) "nothing". Is this makes sense is another thing.

But in genereal it often happens, that instances are NULL.
For example, if a unit dies, the instance is not removed from the game, instead it's set to NONE. If a unit upgrades...if a city is razed...etc, etc.

 

[Afforess]

A lot of variables are actually are references to a location in memory, not a simple variable. Here's an example:

int k = 5;

pNukeUnit = initUnit(...)

The k variable holds the value 5. The pNukeUnit is just a reference to the new unit, it isn't the unit, unlike k, which is 5.

Now, NULL is a special value, which can be assigned to references, which means there is no reference to the object.

Wikipedia - References.

 

[EmperorFool]

None is Python's special value (with type NoneType) that signifies a variable doesn't refer to an object. Technically, I believe it's an object itself, but you cannot call functions on it as you can a valid CyUnit reference. When you pass None through Civ4's Python API it becomes C++'s NULL value which is really just a preprocessor constant for the long value 0

#define NULL         0L

This is used to denote an invalid memory address and assigned to pointer type variables to say that they don't point to a valid object, just like None in Python.

 

[Baldyr]

Ok, thanks for the informed replies. I gather I still have a lot to learn, as the responses didn't make the issue much clearer for me. I'll just start with the link above.

 

[EmperorFool]

Every game- and engine-related object in Civ4--CyGame, CyPlayer, CyTeam, CyUnit, CyMap, CyPlot, CyInterface, CyEngine, CyMessageControl, and so on--lives in two worlds: in the SDK/DLL as C++ objects and in Python as, well, Python objects. All of the code in the .py files uses the Python API.

Whenever you interact with a Python object, it is only a proxy (stand-in) for the "real" C++ object. A CyUnit is used in Python to operate on a CvUnit in C++. Most of the functions in the Python API exist as-is in C++, but there are many C++ functions that you cannot call via Python.

Every call to a Python object goes through a translation layer between the Python and C++ worlds, and again when the function returns back to Python. If you pass in "None" to a Python function, this translation layer turns it into NULL when calling the equivalent C++ function. This is handled automatically by the translation layer embedded in the game, called Boost (Boost:ython in this case).

It is very similar to conversing with some in a foreign language via an interpreter. You say "book" to the interpreter, and they say "libro" to your conversation partner. Your partner says "verde", and the interpreter says "green."

 

[Baldyr]

EmperorFool, thanks for dumbing it down a notch or two for me, as the subject suddenly started to make a whole lot of sense.

And my apologies for hi-jacking this thread for my own questions.

 

[Baldyr]

A reference may be compared to a street address, such as "12 Main Street" or "three houses down the road on the left side". Going to the building with that address is analogous to dereferencing the reference. The name "Bob and Joe's Car Shop" might be a unique identifier for the same building, but cannot be compared to a data reference, because finding the building with that name requires a non-trivial search or a lookup in some directory. A reference stored in a data record can be compared to a sign on that shop saying "For tire service please go to 20 Cross Street". Passing a reference to a subroutine, instead of the data, is like giving your friends the address of that shop, instead of taking Bob and Joe and all their tools to your friend's home.

Talking about dumbing it down...

I'm not sure if I'm any wiser, but I guess I'm getting there, eventually.