Editing .evt files

[El_Coronel]

It appears tabs are a no-no.  I was using them to format my file more nicely, but they seem not to equate to spaces in the parser so anything after a tab is ignored (at least in a CallEffect type line).

Also, file names cannot exceed the DOS limits of 8 character in the CallEffect type line.

[Che_Miguel]

To be on the save side, make sure that all names of your events are not longer than 8 characters. Otherwise an event might not fire at all.

And yes, tabs are *read* as a character and lead to errors in all events.

[El_Coronel]

More little quirks (discovered after much hairpulling overnight):

Though GeneralEffect statements sequence as entered, Condition and Message statements do not.

The Condition statement (or AlwaysTrue, which overrides the Condition) appears to execute first always, no matter where placed.  Forgetting this can lead to some very screwy results.

Also, complicated conditions tend to not perform as expected, so it's often better to set up comparision variables in separate statements, then compare them in a shorter condition statement, which complicates things further.  You then have to pass those variables in very limited groupvariable resources to a CallEvent.

The Message Statement appears to always execute last, despite its position.  This can lead to some non-intuitive results if using a CallEvent with another Message statement inside it if the Message statement in the calling script is located before the CallEvent (the one in the CallEvent will always go off first since that, by definition, ends before control is returned to the calling script).

You can use multiple CallEvents within one outer script and they function as expected (as subroutines).  Thus you can nest Conditions slightly better by using nested CallEvents and careful logic.  Nothing after a failed Condition statement is executed, so it's useful to have that happen in a separate CallEvent at times. (assuming you have the groupvariable resources to handle everything)


This "language" is more counterintuitive than FORTH!

[El_Coronel]

One nasty gotcha.

Just relloading the event files, or restating the scenario, without exiting the game, is dangerous when debugging.  i just spent an hour trying to figure out why something wasn't working because the syntax error was not displaying.  Once I completely exited the game and reran it, suddenly the error was there.

So, the timesaving "shortcuts" can actualluy cost time.

[CafeDave]

You are right El_Coronel.  One of those errors is the divide by zero error that can occur if you have a condition or effect in an event that divides by anything (not necessarily zero).  But this occurs only on the first execution after starting the game and not later so there must be internal variables that get set once.

I do find it useful to debug events for the first time in the events folder for spelling erros that affect syntax or other incorrect syntax.  The errors are flagged right when Tropico starts so you don't have to open up a game save or scenario file.  Just cancel and make corrections and start Tropico again.  It is also useful for checking a new event you are not sure will work without the work of adding events and editing repeatedly.  But it is best to test the overall effect in an actual scenario mode to avoid problems.

[El_Coronel]

I am organizing better now.  Once I get  a set of events done and debugged, I sweep that folder to a holding zone so I can concentrate on the next.  

It's hard to interlink many events anyway, since we have so few variables resources, and no globals.  I keep eyeing the money variable, but too many factors affect that to allow even a quick passing of info through that avenue  

Found out even folder names MUST be 8 characters or less.  I renamed one without thinking and made a couple of previously working scripts start acting buggy.  Only some of them.  Took me another hour t
o figure it out then a simple renaming fixed it all.  If a long name flat stopped everything it would be a minor issue, but this sporadic effect is a bear.

Well, almost to the stage where actual balancing of the effects begins.  I'll get sick of the scenario testing it.  haven't even gotten to play it yet though.  

GSTreeCoverage is a 1 to 100 ration, by the way.  To be useful it has to be multiplied by 100.  And for some reason it then ends up showing 1 higher than the line in the standard report constantly.  No big deal, but curious.  Sounds like inconsistency in rounding.  One truncates, the other rounds up always?

Now to come up with a way to meaningfully measure rate of change in coverage without buring a group variable...

Heh, modern gear and languages have us spoiled.  Trying to write interesting scripts in this is like trying to write device drivers in 2k of memory.

[El_Coronel]

Hmm, seems I misunderstood how placement of events in folders works.  I thought separate folders were separate 'zones' and the events would not interact.  I was wrong.

So far every combination of burying events that call each other in and out of folders appears to work identically.  Folders are then nothing more than a tool to organize things, at least at this calling of sub-events level.

Now to retest the effects on event and general variables.

[El_Coronel]

To test variables' behavior I set up in the events folder with 1st level folders s and b and within those aa and bb, respectively.

I have a dumpvars event that prints all variables to a dossier, and one that initializes variables to set values.

1) When both reside in the top layer, in the events folder itseld, I get the "Affecting a group variable for an event that is not in a group" when init fires in the events folder.  It does set the variables to the designated numbers.  This is an error that goes covert.  It won't reappear on successive tests with just game loading.  To see it again you have to exit the game and re-enter (nasty debugging problem).

2) With both in the same folder (a) the group variables show the initialized values as expected, the event variables are 0, so the domain of event variable is the event that uses them only, as the documents say.

3) With init in a and dumpvars in events, no errors, but dumpvars does not know groupvars values init sets.  Apparently it's setting variables that upsets the program, not reading them (though that may well be failing too).

4) With init in a and dumpvars in b, the group variables are not transferred.

5) With init in a and dumpvars in aa, the group variables do not transfer.

6) With both in aa the group variables do transfer.


So, group variable DO work as I understood.  I was just confused on how calling of other events happens.

For group variables to be transferred, the events transferring them must reside in the same folder.  Thus the domain of group variables is a single folder.

[El_Coronel]

Another tip:

Don't try to make more than one Condition per event.  Debugging it is nigh impossible as if one event is false the event tends to stop in its tracks before even statements needed before the Condition is evaluated are not processed reliably. (whew, that is bad! let me try again)

Condtions seem to be evaluated before anything else happens in an event in some cases.  I know they are before Message Statements, and believe they are before ANY CallEvent is processed also.  So we can't use CallEvent to set up for a Condition in the calling event. (that better?)

The key is to set up the variables needed in one event, then use CallEvent to test the negative and do any processing if the Condition is false (maintaining the test variables and maybe calling additional events), then following that with a second positive case CallEvent from the main event to handle the positive condition.  After that any states can be saved.  

It's all rather creative of migraines, but an interesting challenge.


That said...

I almost have a World Bank loan system up and running  .

I am issuing 10-year loans (up to 5) with a dialog (fired based on year or some external events), computing interest based on other conditions and payment record to date, automatically deducting annual interest payments and handling payment defaults if there isn't enough money when they come due (adding the interest to the principal).  Next I tackle the principal payback and maybe rollovers if your credit record is good enough.

It should all be a drop in module (with the caveat that unless you want the offers of loans to happen every 5th year or something you will have to add some links to make the loan offers fire), though tweaking the settings will not be for the faint of heart.  I use a lot of comments in my code, but the logic is convoluted, to put it mildly.

Oh, it also links to an event that decreases or increases respect for El Presidente based on his actions with international loans (turn them down= small boost, accept them and pay them off= small boost, miss payment=moderate drop, default on principal=bad juju).

This should let us make some very tight money scenarios.
Loans may be really helpful, but they should have attendant risk.  

[El_Coronel]

And a preview of the delinquency notice...

[el_malo]

El Coronel, I find your research and development... very interesting.   It is a shame that fans are forced to Pot-top's job for them.

Hey, would it be possible to script a drop-in event that would activate a hunt for rebels.   I was figuring something along the lines of:

1.  When the Conscription edict is enacted... one-third of the Army would seek to eliminate rebels.

2.  If the Martial Law Edict is used... two-thirds of the Army would seek to eliminate Rebels.

[El_Coronel]

Don't think so.  We don't have direct control over units to that degree.  We can fire them, kill them, make them sick, but can't say, 'Go hunt rebels,' or even 'Take a job as a soldier.'

We can't even make units braver or smarter.  We can make them more respectful of their leader, and happier, less hungry, less in need of medical care or rest, all of which would have indirect bearing on their decision to fight, but we can't make them go fight.

[el_malo]

Oh shucks, thanks for the info... anyway.   I was hoping that the issue of the previously mentioned edicts could kick-in a modified version of either the Capture or Eliminate Edicts... if not both.   Instead of Eliminating "Joe Blow", soldiers would seek out anyone who is a Rebel.

[Senor Ruina]

Malo, I believe someone already has scripted a "kill rebels" script that uses the UnitDieFromSickness command to kill off rebels without actually having to have a shootout when they attack one of your buildings.  

But we cannot alter most things about how the game works.  For instance edicts.  The only thing we can do with edicts is detect when they are on.

[el_malo]

Yes, Che did something along those lines, but it still does not adequately represent a counter-insurgancy mission for the Army.

[Senor Ruina]

Colonel: my understanding of conditions is that they are always the first things executed in every event.  But you can have as many as you like, and that works.  If you want to do things, then test conditions, then do other things, you have to write multiple events.

For instance, say you want to do this:

event0:
GeneralEffect CallEvent event1
condition (GV1 = something)
condition (GV2 = somethingelse)
GeneralEffect CallEvent event2

... that won't work, since the two conditions will be evaluated before event1 is called.  You should do this instead:

event0a:
GeneralEffect CallEvent event1
GeneralEffect CallEvent event0b

event0b:
condition (GV1 = something)
condition (GV2 = somethingelse)
GeneralEffect CallEvent event2

It is generally speaking a pain in the ass to code events, because you end up using lots of events to implement simple things.  But such are the travails of primitive languages.  (I have thought about the idea of writing a compiler to allow a higher level language to be compiled into event code.  It is a nice thought experiment, anyway.)

[Raul]

 
My question is.... how did you get the underlined and red text in your messages?

[Senor Ruina]

Raul - see
http://dynamic3.gamespy.com/~tropico/cafe/index.php?board=7;action=display;threadid=1061

[Raul]

Thanks, Senor Ruina.

[El_Coronel]

Sure, Coconut Kid.

But I prefer to feel I have some control over what happens in my games.  The idea with the World Bank is to give the player some control over finances, but with trade offs.  A scripted loan shark _could_ do the same, but doesn't sound like that's how you mean for yours to work.  Having random withdrawals, or even pre-planned ones, is not my idea of empowering the player by giving them the feeling they can choose, and in so choosing they determine their success or failure.

I suppose it's the difference between a puzzle and a game.  Some prefer the former, others the latter.  I prefer the latter.  Many scenarios to date tend more to the puzzle end.  The open ended ones with multiple paths to successful conclusions are more "game-ish."

Events can either just add flavor, or they can change the dynamics of the game.  The former grow old fast, though they are oftern quite fun the first couple of times if the event scripter is imaginative.  The latter, done well, make the game deeper and more challenging for a long time.  They give it even more 'legs.'

Heh, don't get me started on game design!  

Sid Meier is #1 to me.  He best understands what makes a game a game.  The guys at PopTop learned well from his games. Hope they keep it up.  RRT2 was a nice sequel to RRT.  Tropico is a very well done game (editor aside).

[Coconut Kid]

... Hey, would it be possible to script a drop-in event that would activate a hunt for rebels.   I was figuring something along the lines of:
1.  When the Conscription edict is enacted... one-third of the Army would seek to eliminate rebels.
2.  If the Martial Law Edict is used... two-thirds of the Army would seek to eliminate Rebels.

LOL -- You are persistent if nothing else.  I think some posts in this thread indicate that a "work-around" script could eliminate Rebels upon your conditions -- BUT you would not have the pleasure of watching your army do the work. They would just fall dead.

Perhaps I should take the side of the Rebels to suggest counter measures? Humm!

 

[el_malo]

Perhaps I should take the side of the Rebels to suggest counter measures? Humm!

An excellent idea.

We do not want the Rebels to be cream-puffs 

[Coconut Kid]

Raul - see
http://dynamic3.gamespy.com/~tropico/cafe/index.php?board=7;action=display;threadid=1061

Updated link:
http://www.the-nextlevel.com/tropico/cafe/index.php?topic=1061.0