Using CSPL to Create an Event File For ToT

[Alex Woehr]

How about an event that would redirect the transportation of a unit to another location? The event would transport the unit to a set number of locations (if one is blocked it would go to the next location) and would look something like this:

RedirectTransport
TransportertType=
TranporterLocation=(x,y,z)
locations
randomize (optional)
(x1,y1,z1)
(x2,y2,z2)
...
(xn,yn,zn)
endlocations

Btw, you might want to keep the conventions that the ToT events file use now, such as using building number ID's rather than names.

[Harry Tuttle]

I would prefer IDs. Writing Leonardo's Workshop tens time over would be a pain. I'd rather write "15"

[Kull]

OK Guys, maybe I wasn't clear in my earlier commentary, so I'm going to repeat it - YOUR REQUESTS HAVE TO BE CRYSTAL CLEAR AND GENERIC. Let's review the issue:

What I keep hearing is that CSPL is too complicated and nobody wants to get into the business of coding events and then compiling them into executables. No problem - that's exactly why nobody has used this program in a scenario. The only alternative is a program with some kind of graphical interface that allows designers to select an event type and then enter the desired parameters - probably something like the CivDip PBEM utility. HOWEVER!!! Unlike the fairly limited number of actions you can perform in Civ2 Diplomacy (which is all CivDip deals with), CSPL touches EVERY PART of the game. So. Creating an interface program that a) allows designers to do anything they want and b) is simple to use IS NOT POSSIBLE (or at least highly unlikely).

Which brings me back to my original suggestion. ToT scenario designers should come up with a relatively small group of generic events which are not currently possible to achieve and then let's find a programmer who can create an easy to manipulate interface which hides Angelo's code behind the scenes, and whose output is an executable containing the desired CSPL events.

If I seem a little uptight here, it's because I spent a great deal of time laying out the mechanics of CSPL and identifying the kinds of information it needs in order to process an event and yet it looks as if nobody bothered to read it. To wit:

1) Boco's detailed request for an event was "Artillery". No offense bud, but imagine the look on the face of the programmer who gets this request.

2) Tecumseh wants "control of Trade goods". Well, what does that mean? Is it generic (i.e. the program ensures that every city is requesting the same three items?) Does it mean all caravans are generated carrying the same good? Does it apply only to caravans generated by normal ToT events? Is it a request for a new Caravan generating CSPL event?

3) Alex wants a transport redirect event, however the request is made in the form of Tot Event language. CSPL doesn't use this - it is C++ code that goes directly into the game and makes changes there. So there's no such thing as randomizing. That said, this could probably be a good generic CSPL event, but you'll need to be more specific about the parameters. For example. Will this apply to every unit, or only a certain type? Are there multiple start points or only a single tile? How many redirect points do you want? What would this be used for?

4) Alex and Harry would prefer IDs instead of names. First of all, Angelo created these functions and named them instead of numbering them. Changing this means creating or renaming these things in CSPL. However, since we're talking about customizing the interface, what difference does it make? In fact, why would we even want to type in things like unit IDs or the names of Wonders? Isn't it far simpler to make them selectable via drop down box? But we're getting wayyyyy ahead of ourselves here. DO NOT FOCUS ON MINUTIAE.

Please. Go back and look at what I've written about CSPL. Concentrate on the kinds of things it does and the information it needs to process those events. Then think about some of your greatest frustrations as a scenario designer and consider whether those issues could have been addressed by CSPL, and HOW it would do so. And then write down your request using language that is clearly understandable and not open to multiple interpretations.

Thank You!

[techumseh]

Sorry if I seem a bit vague, Kull. I'm not sure what some of the functions actually mean, eg. "WriteUnit" or "ReadNextUnit".

I guess it's the "ReplaceUnit" function I'm after. In making Roman Civil War, I wanted to simulate the role that slavery played in ancient warfare. So every time a city was captured, the active player recieved a slave unit which was a freight unit renamed. Caravan units could be built normally, but slaves only appeared by events.

The first problem was that all trade units appearing via events are "hides" by default. So I renamed that as "slaves". But few cities wanted slaves, so I used CivCity to make every city need slaves. But then after a few turns, the AI began changing the goods the cities wanted, leaving only a handful of barbarian cities that wanted slaves.

So I'd like to have two functions that are trade related. The first one is to change the commodity of a specific type of trade unit to a specified type, based on a variety of triggers, including the creation of the unit by events. So in other words, as soon as a freight (but not a caravan) unit is created by events, it's commodity is changed, eg. hides -> uranium.

The second is to have the ability to change the type of goods demanded by a city based on some trigger, or to simply be able to refresh the goods demanded every turn, to prevent the AI from changing it as the game progresses.

An example might be to combine this with your #2: city improvement that must exist in order for a particular unit to be constructed. I've used superhighways to represent slave markets. So, if a city contains a slave market, then every turn the city contains that improvement, the #3 demanded commodity is changed to slaves.

I hope this is specific enough, if not, I'll be happy to try again.

[techumseh]

DP

[Mercator]

Originally posted by techumseh
Sorry if I seem a bit vague, Kull. I'm not sure what some of the functions actually mean, eg. "WriteUnit" or "ReadNextUnit".

CSPL continuously checks the Unit section in memory. It looks the same as in a savegame. It basically continuously loops through the unit list over and over. For every unit, it calls the UnitCheck function. All the unit related stuff goes in that function.

So, WriteUnit, will replace the unit it's currently reading with the unit you provided in the function's argument.

As the CSPL manual says (you'd have better read that, or at least have it handy, even if you only understand half of it ), you shouldn't really use ReadNextUnit. It's the function CSPL uses for doing that loop I just described.

The first one is to change the commodity of a specific type of trade unit to a specified type, based on a variety of triggers, including the creation of the unit by events. So in other words, as soon as a freight (but not a caravan) unit is created by events, it's commodity is changed, eg. hides -> uranium.

Not possible. CSPL doesn't know about events, so it won't know which unit has been created by events or not. You're going to have to do everything in CSPL. That is, you'll have to create the unit with CSPL, using whatever conditions (which are also coded in CSPL). CSPL's unit structure already contains the commodiy info, so that's nothing special when creating a unit. Well, just saying that it's possible anyway, nothing about how to make that easier to do. Still, that's only the action part, so to speak, the trigger also needs to be in CSPL, so what would you want for that?

(*cough* and no, there's no way I'll be working with CSPL, or programming any of this. I'm just doing what I'm good at; ranting on forums )

The second is to have the ability to change the type of goods demanded by a city based on some trigger, or to simply be able to refresh the goods demanded every turn, to prevent the AI from changing it as the game progresses.

Still only an "action", but yes, this is doable. The Cities "thread" works the same as the units "thread". CSPL continually scans all cities. The commodities are in the city structure, so CSPL could reset the commodities to your preferred values every time it passes through, say.

An example might be to combine this with your #2: city improvement that must exist in order for a particular unit to be constructed. I've used superhighways to represent slave markets. So, if a city contains a slave market, then every turn the city contains that improvement, the #3 demanded commodity is changed to slaves.

Hmmm, it kinda looks that would be the simplest approach. Create a bunch of Boolean functions for the triggers that return true or false. These could be OR'ed or AND'ed together. And then a bunch of functions that perform some simple write. For a lot of cases, the CSPL script could then be reduced to a bunch of if-then statements.

So, then a trigger could be:
City improvement X exists in city Y (true or false)

And an action could be:
Change demanded commodities in city A to X,Y,Z.

[techumseh]

OK, if CSLP can't detect an event, then it should be able, every turn, to convert every "hides" frieght on the map to "uranium". Yes?

[Mercator]

Yes it could.

[Boco]

I cryptically mentioned artillery, because I thought it was a clear example in the readme at one point. The assumption in your reply was dead on, from my point of view. So I succeeded in jarring your memory of that example!

Input Variables for artillery routine:

• Civ (I'd be happy with using the same civ for spawner and spawnee)
• Spawning unit
• Spawned unit
• Damage per invocation

Since you got me in i/o mode, here's another idea. Supply! If a unit ends its turn on a certain kind of terrain, it loses (or gains) strength.
Input Variables for this routine:

• Civ
• Affected unit type
• Terrain type in which this occurs
• Change per turn (damage or healing)

I vote that Mercator learns CSPL inside and out, and writes the interface!

@Tech: that should fly. I think...

[Kull]

Originally posted by techumseh
Sorry if I seem a bit vague, Kull. I'm not sure what some of the functions actually mean, eg. "WriteUnit" or "ReadNextUnit".

I don't expect that you guys should specify which functions need to be called - or even know exactly what they do. After all, that's what the programmer will do when the Event is coded. The key is to specify exactly what you want to occur in the game and to indicate HOW it would happen.

Your last request is a perfect example of this, and it's even clearer as phrased by Mercator.

[Kull]

Originally posted by Boco
I cryptically mentioned artillery, because I thought it was a clear example in the readme at one point. The assumption in your reply was dead on, from my point of view. So I succeeded in jarring your memory of that example!

Even though I had a prety good idea what you wanted, I was about to beat up a few other folks for lack of clarity, and just couldn't give you a pass. Sorry!

Input Variables for artillery routine:

• Civ (I'd be happy with using the same civ for spawner and spawnee)
• Spawning unit
• Spawned unit
• Damage per invocation

This is better, but is it a keypress event or turn based or location based? Again, I'm pretty sure I know the answer, but......

While we're thinking of artillery, why not eliminate the keypress issue altogether? After all, that prevents the AI from being able to use this feature. So here's an idea for a similar event:

Name: Artillery Shell Generation
Purpose: To generate artillery shells every turn and place them in the same tile as an artillery piece.
Spawning Unit: Name of unit that generates the artillery shell
New Unit: Artillery Shell
Where located: In the same tile as the artillery piece
Other factors:
1) Cause 1/3 damage to the artillery piece for every shell generated.
2) Artillery pieces with Health at 1/3 or less do not generate shells.
3) Count Artillery pieces and Shells and do not generate new ones once the ratio of shells to artillery exceeds 3-to-1 (prevents stockpiling and excess unit problems)

Since you got me in i/o mode, here's another idea. Supply! If a unit ends its turn on a certain kind of terrain, it loses (or gains) strength.
Input Variables for this routine:

• Civ
• Affected unit type
• Terrain type in which this occurs
• Change per turn (damage or healing)

Looks OK

[techumseh]

The artillery shell idea is a bit problematic, since once generated they can't be transported if the artillery piece moves. And they can be moved as independent units, stored in cities, and used as recon units. Could we deal with this more abstractly, eg. artillery which attacks (only) doesn't suffer any hits, whether or not it's target is destroyed? It's limited to a range of 1, but simple is better usually.

[Boco]

I like that idea!

[Kull]

Originally posted by techumseh
The artillery shell idea is a bit problematic, since once generated they can't be transported if the artillery piece moves. And they can be moved as independent units, stored in cities, and used as recon units.

There is an easy solution to all three of those issues. At the start (or end) of every turn, CSPL scans all units (which it does anyway) and simply eliminates any shell units that are not on a tile containing an artillery unit.

Could we deal with this more abstractly, eg. artillery which attacks (only) doesn't suffer any hits, whether or not it's target is destroyed? It's limited to a range of 1, but simple is better usually.

As noted above, the attack thread does all the legwork for this already. All you'd need is code which states, "If unit type "x" is attacker and is not winner, place a unit type "x" in the tile it occupied." And some other code that says if it is winner, set health to max.

Personally I prefer the first solution, but the second set of code might have other, non-artillery uses. You could even have both sets of code available in the tool.

[Kull]

Another thought on units: One of the basic features of Civ2 - and it's so fundamental we don't even think about it - is that every combat between units is a black/white outcome. One unit survives, the other is completely destroyed. Of course historically, that hardly ever happens. Well, CSPL could change that for EVERY UNIT in the game. Here's just one way to skin that cat:

1) Unit "X" is attacker (health=100%), Unit "Y" is defender (health=100%)

2) Unit "X" is winner (health=90%), Unit "Y" is loser (health=0%)

CSPL Code does the following:

1) Before attack begins, capture health status of each unit.

2) After attack, replace losing unit on map, set health at 50% of former status.

3) Examine winning unit and increase health by 50% of former status.

4) If losing unit health was 30% or lower at start of combat, do not replace unit.

The key point here is not the rules themselves, because those can be almost anything we like. The real takeaway is that Civ2 can be changed in ways that were hitherto inconceivable.

Caveat: We still have the sticky problem of stacks - since the CSPL attack code only looks at the stats of the defending unit, it can't replace the others since it doesn't even know they were destroyed. Which suggests another possible CSPL event - some way to ensure that every tile on the map has the "fortification" feature, and that even if pillaged it gets regenerated.