Event Signs

[Dresden]

Later on this evening I'm going to commit a new feature; I want to lower the verbosity on my debug text and clean up a minor thing I saw when making the screenshots first. I've finally gotten around to despoilerizing and BUGifying my EventSigns modcomp. What this does is add map signs to plots that have their yields changed by random events (like the Truffles or Sour Crude events). I always thought this was a useful idea because it's hard to remember (or discover) where these extra-bountiful tiles are later on if you have to rely on the plot hover info; it adds a little extra impact to the events themselves too.

The original non-BUG version was a spoiler problem because signs are still visible if they are placed on unrevealed plots so this version saves the sign data using sdtoolkit and only places the sign on the map after the plot is revealed to you. Here's an example of the Truffles event triggering on an unseen Spanish plot. First screen is just after the event triggers and second is after I reveal the plot.

Note that the sign captions are all XML-based and are loosely translated using the original Firaxian event translations and Babelfish; so I won't be surprised if some improvements can be made there.

It has an option to enable/disable on the first tab under the Miscellaneous part of the Main Interface section because I had no idea where else to put it. The default is to enable them. The enabling/disabling actually only controls whether the signs will be placed from that point on; existing signs are unaffected. We might need to add some to the option hover text if that winds up being too confusing.

I wound up adding a surprisingly large amount of code to do the despoilerizing so this is going to need a good deal of testing to make sure it works ok. The two main things to look for:

• If such an event triggers in known territory (like your own), a sign should show as long as that plot doesn't already have one.
• You should never see signs on an unrevealed (fully black) tile.

One of the reasons I made this a separate thread rather than just putting it in the New Features topic is because I expect problems and want to have a dedicated place to report them. But if you have any other comments/suggestions on it, please share them here too.

 

[EmperorFool]

Wow, you read my mind. I noticed this modcomp in your sig again last night and figured I'd ask you this weekend if you had made any headway on the spoilage. Nice job.

So I'll ask the obvious question: How hard would it be to change the enable/disable option into hide/show so it tracks the events regardless and allows you to toggle the display of all signs it remembers?

I'd like the ability to hide/show the signs at will without deleting the old ones permanently, and this way SG players that don't want the signs won't interfere with their teammates that do want them.

 

[The Doc]

Is it possible to replace the "F", "P", and "C" letters with their corresponding icons? The codes are [ICON_FOOD], [ICON_PRODUCTION], and [ICON_COMMERCE]. I would test if it works myself but I currently have no save with such an event.

 

[Dresden]

@EF: Hmm. That's probably doable. Is there some kind of event or other notification that happens when the player changes the options?

@Doc: I tried something like that when I first made it, but I could never get anything but bare text in the sign captions; I'd either get unicode vs ascii errors or the markup would get directly displayed like "<font=2>whatever</font>" If somebody can figure out how to make it work, I'd happily use that instead of the F/P/C. Note that you can force events to happen via the Python console which is useful for testing. For example, when making the above screenshots, I used

gc.getPlayer(1).trigger(50)

in the Python console to force a truffles event for izzy.

 

[EmperorFool]

@EF: Hmm. That's probably doable. Is there some kind of event or other notification that happens when the player changes the options?

Use the <change> element inside the <option> definition to specify a function to call.

@Doc: I tried something like that when I first made it, but I could never get anything but bare text in the sign captions.

Given that the only way to create signs normally is to let the user type them in, I wouldn't be surprised if the function requires a plain ASCII string and doesn't render the sign as HTML.

 

[Dresden]

Use the <change> element inside the <option> definition to specify a function to call.

Nice. I should probably change the CDA to use that too instead of the kludge I'm currently using (caching the old values and checking for a change when the screen is opened.)

The remaining question then is how to handle sign conflicts. Currently, when an event triggers if the target plot already has a sign, nothing is done. While it is theoretically possible to remove the old sign and subsequently replace it with a new (possibly "merged" sign) there are timing issues that I couldn't resolve way back when. So I'm thinking that we should also skip placement if signs are turned on and a target plot has an existing sign.

Similarly, if the player chooses to hide the signs, I think we can compare the saved caption to the current caption of the sign and only remove it if they're the same.

 

[The Doc]

@EF: Hmm. That's probably doable. Is there some kind of event or other notification that happens when the player changes the options?

@Doc: I tried something like that when I first made it, but I could never get anything but bare text in the sign captions; I'd either get unicode vs ascii errors or the markup would get directly displayed like "<font=2>whatever</font>" If somebody can figure out how to make it work, I'd happily use that instead of the F/P/C. Note that you can force events to happen via the Python console which is useful for testing. For example, when making the above screenshots, I used

gc.getPlayer(1).trigger(50)

in the Python console to force a truffles event for izzy.

I triggered the event (thanks for the tip ) and waited for the sign to display but it didn't show up. So, I thought it's maybe caused by the icons and reverted that in the XML but after I triggered it again it doesn't work either.
Is there something I'm missing?

 

[Dresden]

Hmm. Are the signs are enabled on the options screen? Are you triggering for yourself or an opponent? When the event triggered, did one of the little yellow "!" icons show up?

 

[Del69]

@EF: Hmm. That's probably doable. Is there some kind of event or other notification that happens when the player changes the options?

@Doc: I tried something like that when I first made it, but I could never get anything but bare text in the sign captions; I'd either get unicode vs ascii errors or the markup would get directly displayed like "<font=2>whatever</font>" If somebody can figure out how to make it work, I'd happily use that instead of the F/P/C. Note that you can force events to happen via the Python console which is useful for testing. For example, when making the above screenshots, I used

gc.getPlayer(1).trigger(50)

in the Python console to force a truffles event for izzy.

Everything I tried for making font icons work with signs ended up with the same result as you. All the sign or landmark function calls expect just plain ASCII strings and no markup of any sort seems to work with them either.

 

[The Doc]

Hmm. Are the signs are enabled on the options screen? Are you triggering for yourself or an opponent? When the event triggered, did one of the little yellow "!" icons show up?

Yes, they are enabled as far as I can tell from the options screen.
I triggered it for myself several times.
Yes, the yellow "!" appeared instantly.

I started a whole new game to test it but no signs showed up, neither with font icons nor with plain ASCII strings in the appropriate XML.

 

[Dresden]

well then make sure the XML matches the current svn and post your pythonerr.log and pythondbg.log after triggering an event.

 

[The Doc]

well then make sure the XML matches the current svn and post your pythonerr.log and pythondbg.log after triggering an event.

Here's what's in pythonerr.log regardless of which XML I use (either SVN or modified, it's always a unicode error):

Traceback (most recent call last):

File "CvRandomEventInterface", line 4236, in applyLandmarkFromEvent

File "CvRandomEventInterface", line 4214, in placeLandmark

UnicodeEncodeError: 'ascii' codec can't encode character u'\xfc' in position 14: ordinal not in range(128)
ERR: Python function applyLandmarkFromEvent failed, module CvRandomEventInterface

 

[Dresden]

Alright. Which event(s) were you trying?

 

[The Doc]

Only the one with the truffles you mentioned above.

 

[Dresden]

OK, I see the problem. It hates the umlaut. Oddly enough, I can type "ü" into the sign dialog and have it display properly, but when I read it from the XML, it fails.

For now, test with one of the events which don't have any accented characters in the german text. The tin event (52) I think only needs a mine. Also depending on terrain, the 40 thieves event (101), waters of life event (103), parrots (44), or horticulture (21) will probably work.

 

[Dresden]

Yeesh. I finally can get it to recognize accented characters by doing the following:

engine.addSign(pPlot, ePlayer, szCaption.encode('latin_1'))

Sometime later today or tomorrow I'll commit a new version that not only does that but uses a hide/show option rather than enable/disable.

 

[Cammagno]

OK, I see the problem. It hates the umlaut. Oddly enough, I can type "ü" into the sign dialog and have it display properly, but when I read it from the XML, it fails.

You can try to change the charset declaration in the XML...

 

[Dresden]

Nice idea, but that XML file is already set to latin_1 encoding. But after running it through the translator, the resulting string is unicode (which is either my fault for adding a unicode space or just how the translator works). And the damned engine sign functions don't accept unicode arguments so we have to change it back to latin_1. However I'm fairly confident the next version will be fixed; good thing there's no Russin BUG translation though because Cyrillic isn't gonna happen.

 

[Del69]

Pretty sure its the translator changing text to unicode. I was having problems bringing anything from XML to a sign as well.

 

[Dresden]

@Del: Congrats on the new addition! I bet the birthday smiley doesn't get used for this too often.

On topic, new version of EventSigns committed. Completely redid the internals and the BUG option will now mass show/hide the signs. Signs from the previous version won't be remembered because of the internal changes but I did add some extra stuff so they at least don't cause an error on loading.... The new version also handles the accented text from XML properly. So, keep hammering away please and let me know of any problems.