Chain-linking functions
- Thread starter Baldyr
- Start date
Could you exemplify more explicitly?
EmperorFool
Deity
Where you have
instead type
You can read about "new style" classes in Python (it's technical).
Code:
class Context:instead type
Code:
class Context(object):You can read about "new style" classes in Python (it's technical).
Success! 
I actually understand how this works (in practice only, not in theory) but looking at the Python documentation at large makes me realize how much there is to learn... Its an entire science, hence computer science, I guess...
I actually understand how this works (in practice only, not in theory) but looking at the Python documentation at large makes me realize how much there is to learn... Its an entire science, hence computer science, I guess...
EmperorFool
Deity
I like to remind new coders that computer science has evolved quite a bit since the beginning. People like me who got to start with simple procedural programming before moving on to object-oriented programming got to learn all this gradually over time. Of course, many of us have learned and practiced some pretty bad habits we need to unlearn from time to time. 
EmperorFool
Deity
Python is relatively new compared to other languages such as C and C++. While all variables have always been "objects" in the language implementation, the language itself didn't have OO features until recently. I wasn't around then and haven't looked it up, but I believe the "old style" classes were added after the language was created.
Another progress report:
I've been ill this holiday so instead of all the work I was scheduled for I've been coding more or less around the clock.
I'm still not anywhere recovered so I'll get some good hours in yet.
I'm basically done with the scenario maker itself, since more or less everything I did in my previous project is now incorporated in this new and improved version. I've also been able to integrate other calls from the Event Handler than just onGameTurn (or whatever) and it all works nicely. This is what the API looks like this far, by the way:
There is of course room for more and I plan on expanding the library over time. The first method ("target") is for defining either a tile or a map area - it works for both purposes. Otherwise the target tile can just as well be defined with any of the methods taking coordinates as arguments. (Like the city() method as featured below.)
An example of a complete trigger, then:
The trigger spawns the size 2 city of "Metropolis" on game turn 99 at the specified coordinates. The class invocation actually takes the player index value (3 in this case) as an argument. Besides the turn condition there is check() that (using the default settings) denies any spawn for the human player or for a dead player, and there is valid() that makes sure there are no cities or enemy units or bad terrain blocking the spawn, and that the tile isn't foreign. (The optional settings could have been used to override some of these built-in conditions.) If the city spawn is successful there will also be preset buildings and a religion to boot. Moreover, there will also be a couple of level 2 units (of the drafted sort) with preset promotions that are automatically picked by a script.
A simpler version of the same trigger, doing practically the same thing (but without some of the bells and whistles - and with only one conditions):
The longer version is an example of a fairly complex - albeit very straight forward - spawn. Only a fraction of the available settings were used as the default values do just fine. Since the code fills in some gaps on its own, some methods could be skipped altogether (like the promotions() one).
As it stands now, all the triggers are defined on initialization in a tuple and that is then stored in an Setup instance at startup for future calls from the Event Handler. I might change it into a list eventually, if I want to be able to delete entries as they are triggered and expired. Also, there is some sort of glitch that makes the Setup instance in the Event Handler expire in some cases, but it could just be my debugging that does that...
The main thing, however, remains that only the conditions are cycled through on each call from the Event Handler, and triggers that don't apply are skipped in a timely fashion. But I bet there would be even more efficient ways of achieving this.
Well, next on the agenda might be expanding the library into new areas like Techs (for both conditions and actions) and for changing terrain. Then it might be easy-to-use ways of handling in-game messages and pop-ups. So I guess I'll have my hands full for some time to come, then. Especially since I will be going back to work in a all-too near future - and once I'm fully recovered there will be double the work-load at the old day job.
Oh, well...
ps I was thinking of a name for the finished thing, and "PyScenario" came to mind. Good? It could be noted that I'm not at all clear about all these prefixes used in this genre (like Py, Cy and Cv). Is there a good explanation available, somewhere?
pps And this is a snippet of the code for the Trigger class, in case anyone is following my progress.
It features some of the solutions discussed earlier in this thread.
I've been ill this holiday so instead of all the work I was scheduled for I've been coding more or less around the clock.
I'm still not anywhere recovered so I'll get some good hours in yet. I'm basically done with the scenario maker itself, since more or less everything I did in my previous project is now incorporated in this new and improved version. I've also been able to integrate other calls from the Event Handler than just onGameTurn (or whatever) and it all works nicely. This is what the API looks like this far, by the way:
Spoiler :
An example of a complete trigger, then:
Code:
Trigger(3).check().turn(99).city(34, 56, "Metropolis").valid().buildings(3, 5).religions(1).garrison().XP(2)A simpler version of the same trigger, doing practically the same thing (but without some of the bells and whistles - and with only one conditions):
Code:
Trigger(3).turn(99).city(34, 56).garrison()The longer version is an example of a fairly complex - albeit very straight forward - spawn. Only a fraction of the available settings were used as the default values do just fine. Since the code fills in some gaps on its own, some methods could be skipped altogether (like the promotions() one).
As it stands now, all the triggers are defined on initialization in a tuple and that is then stored in an Setup instance at startup for future calls from the Event Handler. I might change it into a list eventually, if I want to be able to delete entries as they are triggered and expired. Also, there is some sort of glitch that makes the Setup instance in the Event Handler expire in some cases, but it could just be my debugging that does that...
The main thing, however, remains that only the conditions are cycled through on each call from the Event Handler, and triggers that don't apply are skipped in a timely fashion. But I bet there would be even more efficient ways of achieving this.
Well, next on the agenda might be expanding the library into new areas like Techs (for both conditions and actions) and for changing terrain. Then it might be easy-to-use ways of handling in-game messages and pop-ups. So I guess I'll have my hands full for some time to come, then. Especially since I will be going back to work in a all-too near future - and once I'm fully recovered there will be double the work-load at the old day job.
Oh, well...
ps I was thinking of a name for the finished thing, and "PyScenario" came to mind. Good? It could be noted that I'm not at all clear about all these prefixes used in this genre (like Py, Cy and Cv). Is there a good explanation available, somewhere?
pps And this is a snippet of the code for the Trigger class, in case anyone is following my progress.
It features some of the solutions discussed earlier in this thread.Spoiler :
