Glory and Greatness, Development Thread

[Baldyr]

Ok, I'm not it.

 

[seasnake]

Cool then, I'll try what Asaf was talking about, see if I can get it to work.

 

[Baldyr]

Cool then, I'll try what Asaf was talking about, see if I can get it to work.

Eh, what was that? Because I think you just asked me to do the CyInterface.addMessage() thing he mentioned...

 

[seasnake]

So asaf, it would look like this?

CyInterface(eplayer).addMessage(spainGoodyMessage, (capitalName,))

I'll try it in the game, but if this is close just tell me.

 

[seasnake]

Oh, sorry Baldyr, hadn't refreshed this page. I though when you said "I'm not it" you were saying that we should try Asaf's approach to get the result we wanted. So I thought I'd give it a quick go based on what he posted earlier to see if I could fix it myself.

 

[seasnake]

hmm, well that just removes the message completely? What did I do wrong?

 

[Asaf]

You probably got an exception because you didn't call the functions with the right arguments.

CyInterface() creates an instance of the CyInterface class, which is exposed by the exe, which supplies several services such as displaying messages. It doesn't receive any parameters.

The prototype for addMessage is:

void addMessage(int /*PlayerTypes*/ ePlayer, bool bForce, int iLength, wstring szString, string szSound = NULL, int /*InterfaceMessageTypes*/ eType = MESSAGE_TYPE_INFO, string szIcon = NULL, ColorTypes eFlashColor = NO_COLOR, int iFlashX = -1, int iFlashY = -1, bool bShowOffScreenArrows = false, bool bShowOnScreenArrows = false)

(parameters with '= value' in them can be skipped, because they have default values)

But since I don't know the existing code and I don't know what Baldyr has planned for this - I suggest waiting for his opinion.

 

[Baldyr]

Haha!

I misspelled "I'm on it".

Don't bother with it yourself, that method took me like forever to decipher a year or so ago and I've also already wrapped it up in a addMessage() function for use with your mod. If you really wanna learn how to use that, then I can explain it for you. But firstly I might have to alter it slightly in order to be able to accommodate what you ordered.

Expect delivery during the coming week, or something. If there is a release date I would of course try to get it done before then.

 

[Baldyr]

Asaf: I don't believe that any parameters can be skipped in the Python version of that method, or any other for that matter. Am I incorrect?

 

[Baldyr]

Ok, since the subject clearly came up - here is what we're dealing with:

def addMessage(tag, tValues=(), ePlayer=None, eColor=eWhite, tCoords=(-1, -1)):
        """
        Adds the tag (string) message to the game in eColor. (The default color is eWhite
        and the other preset pointers to valid ColorTypes are eRed and eGreen.) If
        the tag argument requires other values to be inserted in the message, then these can
        be supplied with the optional tValues (tuple) argument. The ePlayer (integer)
        argument can be supplied to prevent the message from being transmitted if it
        references some other PlayerType than the human player's. The optional tCoords
        (tuple) argument is set to a pair of default -1 values that indicate that no arrow
        should accompany the text message. (Valid map tile coordinates will enable the arrow.)
        """
        pHumanCiv = getHuman()
        if ePlayer != None and instance(ePlayer) != pHumanCiv: return
        eHuman = pHumanCiv.get(playerID)
        message = Translator.getText(tag, tValues)
        bArrow = tCoords != (-1, -1)
        Interface.addMessage(eHuman, True, 20, message, "", eMinorEvent, "", eColor, tCoords[0], tCoords[1], bArrow, bArrow)

Three things to note:

1. the function takes 5 arguments, but only the first one is obligatory
2. the text following the definition line is the full documentation for the function
3. the last line is actually what Asaf has been talking about - or my implementation of it

So the whole function wraps up the CyInterface.addMessage() method into a format that is more convenient for me to work with.

Now I'm gonna take a look at all the Python code for your mod and see if the above function needs to be augmented in any way. For one thing, the eHuman variable should probably not be used for the PlayerType parameter, but as I said - I'm gonna take another look at the whole thing.

 

[Asaf]

Asaf: I don't believe that any parameters can be skipped in the Python version of that method, or any other for that matter. Am I incorrect?

Haven't tried it myself, but the prototype I gave is taken from the Python API, so I believe it does have default params.
Only one way to find out...

 

[Baldyr]

Ok, I thought I'd redeem myself by getting this done. So I did. I added the unit description names to the captured unit messages. But I also realized that it looks weird that firstly you get a message telling that a unit has been killed. And right afterwards that it has been enslaved. This only adds to the confusion - which one is it? Did the unit die or was it captured/enslaved?

I'll look around to see if I can't find a way to disable those death messages right before the capture message.

 

[Baldyr]

Haven't tried it myself, but the prototype I gave is taken from the Python API, so I believe it does have default params.
Only one way to find out...

Looking at the entry I realize that I never noticed those = characters before...

 

[Baldyr]

I couldn't find any way to disable those messages I mentioned earlier, so I guess they are done in the DLL then.

Below is the attached replacement GGPowers module - no changes necessary in GGUtils or any other module.

Note however that the mod settings at the top are the default ones I supplied you with originally. So don't just overwrite your own copy before transferring your own custom settings!

 

[seasnake]

awesome work, Baldyr!