Introducing: PyScenario - easy-to-use scenario event scripting for RFC

Spoiler :
So, in other words, you want Triggers "A" and "B" to only fire once? But once Trigger "C" fires you need to basically reload Trigger "A" so that it doesn't register a fired any more?

Other than that, due to the ad hoc nature of the fired() Condition you wouldn't be able to make a reference to the second Trigger in the first one. Because when the first Trigger is initialized it won't recognize the label of the second one.

Also, the second Trigger is referencing itself - it might fail on the same principle as the first one.

If something like what you propose was to work I might have to rewrite the whole code for Trigger binding, I'm afraid. I'm not sure if I have the time for all the testing and debugging involved. Stuff like move the initialized Trigger objects into a dictionary from the current list setup. That should fix the indexing once-and-for-all - as long as two Triggers don't have the same label.
Is this still a priority of any sorts?
 
Ok, so I've compiled a to-do list of sorts.

It seems that there are some custom methods floating around since the last release. These seem to be an augmented units() method which will spawn units in the capital city of the Target Player if no Map Target is specified within the Trigger. I believe that this functionality needs to be added to other methods also. Which ones? Or do we add a new capital() method instead?

There is also a modified tech() method which can be restricted with a bFirst parameter. Did anyone ever test that one?

And finally we have a brand new rebirth() method that grants Golden Ages. Has it been tested?

Does the current version of PyScenario work properly with the latest version of RFC Epic/Marathon? I don't believe I ever tested it myself...

There seem to be a couple of bugs reported: The buildings() method needs to check for a valid city before spawning any buildings. And the built() method needs to also work if there is no Target Player for the Trigger. Anything else?

New additions on my agenda right now is dynamic mod folder detection that allow mod-modders to use a non-standard mod folder, a civilization() method making it possible to change the Civilization attribute of players, signs/landmarks for map tiles, and some sort of killer parameter to the captured() method. Possibly the iX and iY parameters of city() will be optional, but I'm not sure about this yet.
 
Nope, the original suggestion was that capital() would set the Target Tile to the Target Player's capital. I'm not so sure however; I think that simply omitting a Target Tile while supplying a Target Player should always set the Target Tile to the capital. The question is what methods other than units() would benefit from this setup?

You can change the capital by building a Palace on a city with buildings(). Come to think of it, national wonders (like Palace) should probably not be replicated in several cities, so the original instance should be erased first. I'm taking a note of this.
 
I'm updating PyScenario as we speak and will hopefully be through with all the testing and debugging this weekend.

Since I'm restricting spawning wonders (national and world) that have already been built by the target player, I've introduced a capital() method for moving the Palace. It of course removes the old instance, so that you don't end up with multiple palaces. :rolleyes:

I just realized that I probably need to restrict wonders globally, so that you can't spawn multiple world wonders in the game. Thoughts? Or should world wonders be moved to a new location by default? Or should we replace the capital() method with a generic move() method that allows you to move wonders (like the Palace)?
 
Ok, looking at this stuff again makes me think that I will never be able to add the civilization() method into the application properly, since the dynamic Civ names are, still, hard-coded into the DLL. :p
 
The documentation on the first page has been updated to reflect the new (final?) version, which is now up. I'd appreciate if the community could test things throughly within the next week or so, because after that it will be difficult for me to fix any issues. :p
 
I'm fairly confident that you can still add a method to change civ names because the DLL names will get overwritten by the python.

I may be wrong though.
 
Unless embryodead changed something in the last release, the names are automatically reverted on a turn-to-turn basis. In the testing I did for the civilization() method I couldn't affect the Civ name nor the flag. This isn't the same that it isn't possible to do with Python. I only know that it wasn't possible before, and I simply gave up this time around. :p
 
Yeah, I have no idea what was going on there. I did manage to change the flag before... Well, I simply gave up on this idea.
 
If you like, I could easily compile a DLL for you that has the dynamic naming disabled.
 
Thanks, man. But the application is called "PyScenario" and it will never ship with a custom DLL file. Because its a pure Python thing.

If embryodead releases a new version of RFC:E/M with the changes in place, then I might include it in a (hypothetical) future release.
 
I thought you might say that :D

On the other hand, wouldn't it be possible to store the current user-specified (i.e. Python controlled) civ name somewhere and update immediately after the DLL updates? It's some overhead but might be worthwhile because I imagine this is an aspect many people might like to influence.
 
I honestly don't know, at this point. :dunno:

And yes, it would have been a nice touch to end development with this functionality in place.
 
Trigger("findgordion").find("Gordion").found().message("The Phrygian capital of Gordion has been built!").once()
Trigger().fired("findgordion",False).valid((71,43)).target(73,43).owned().culture(-100)

Why might this be failing? The text message is just to provide in-game confirmation that the trigger is firing.
 
Top Bottom