Condition UnitType Problem

[Avaunt]

It seems that the UnitType check is not based on what a particular unit's current job is but on what he/she has TRAINING in.

My test scripts:

CheckFrequencyWeekEnd

LoopThroughAllUnits

Condition UnitType=UnitTypeSoldier

GeneralEffect CallEvent WTest_ME


***And now WTest_ME***

CheckFrequencyOnlyWhenCalled

AlwaysTrue

MessageTypeDossier

MessageText "Test"


Now, these scripts should give the effect that at the start of each week the dossier "Test" page will pop-up as long as there is a Soldier employed on the island. In reality the message will pop-up as long as someone on the island currently has Soldier training. To test this load the scripts to a new game. After the message pops up one time fire the Soldier.

The message will still continue to pop-up even after he moves to new employment. Now kill him with the muerte command. The messages stop.

This makes UnitType counts impossible to get accurately. So you will not be able to make events occur when a particular class of occupation reaches or falls below a certain level.

Any comments, corrections or verifications welcome.

Also, It seems that when you assign a UnitType to equal a certain unit type you can not set it again to a new UnitType class. Anyone able to have events and triggers within the same game effect/modify different UnitType classes?

Avaunt

[Mercator]

Whew, you had me quite scared there for a momento!  Don't do that!  

I'm really glad to see someone else testing things and bringing their observations to the rest of us.  Your input is highly needed and I thank you.

However, I did as you suggested and tested it myself.  I went even one step further and changed the W_TestME file message.  My file looked like this:

CheckFrequencyOnlyWhenCalled

AlwaysTrue

MessageTypeDossier

MessageText "[UNIT_NAME] is a soldier"


Now, when the message comes up, it tells you WHO are the soldiers.  My initial soldier (Name was Martinez) in my test came up the first week.  I fired him.  The second week, he came up again and I became very disappointed.  However, the third week, he didn't come up!  He was still alive and kicking as a farmer.  And what more, he was still trained in being a soldier!  I ran the game another year, hiring another soldier to make sure the event was still firing every week.  It was.

So I think that the reason Martinez came up the second week when he wasn't a soldier is either because the event still labeled him as one somewhere in that week, or as an unemployed citizen, the event will call upon the last known job, which in Martinez case was a soldier.

I looked through the Conditions to see if we can make the event only hit employed, soldiers.  There are to conditions called UnitIsJobless and UnitIsUnemployed.  NOw to me, these two conditions are the same!  Did PopTop mean to type UNitIsEmployed instead?  I can't think of a work-around off hand.  Anyone else got a clue on how to make it hit employed soldiers only?

[Avaunt]

Thanks for the clarification Merc. I think your right on -it's just a matter of Tropico taking several weeks to finalize all the status flags associated with a Unit regarding employment and probably other characteristics as well, however death is instant.

I would appreciate your ideas on solving this problem: Let's say you want a victory conditon to be you must have 20 cabaret dancers employed on the island. Now we can loop all units and check if there is at least one member of the UnitType, but how can we use Boolean logic terms like <, >, = with unit specific checks? I have tried adding > 1, = 1 suffixes to the Condition UnitType check. No Dice. Any ideas?


Avaunt

[Mercator]

Yeah, you can't use numbers with unit types, but there is a work around for it.  You need to use groupvariables and eventvariables I think. Try something like this:

LoopThoughAllUnits
Condition UnitType=UnitTypeDancer
GeneralEffect AddTo GroupVariable1 1



Then, in another event refer to GroupVariable1, like this:

Condition GroupVariable1 >= 20
Generaleffect GameWin (or whatever that effect is)


I'm still messing around with Groupvariables and Eventvariables myself.  I'm not sure, but I think Eventvariables are used to refer to itself ONLY within that event, while groupvariables refer to themselves within a folder of events.  This true?

If so, it really makes a differnence what events you put in which folders!  I tell ya, that could get mind boggling!

[Avaunt]

Merc:

Ok, here is a single script I think stays true to your above advice:

CheckFrequencyWeekEnd

LoopThroughAllUnits

Condition UnitType=UnitTypeSoldier

GeneralEffect AddTo GroupVariable1 1

MessageTypeDossier

MessageText "Group Variable count is now [Trigger_Group_Variable_1]"


What this does is check to see if any Soldiers exist and if one does (i.e. Soldiers >=1) then +1 is added to group variable 1. So in essence you get a counter not based on the number of soldiers but on the number of times this event is called.

This in itself is pretty useful if you wanted to create a warning message and if the player is warned, oh say three times ( groupvariable=3) without remedy of the trigger condition, then another event could be triggered, like lose the game.

However, this is a clumsy way to do it since event variables are specifically designed to work within one event script like mine above. I guess the true usefulness of group variables is if you had say 3 different scripts (in same subfolder) giving warnings and all adding +1 to group variable 1 and then another script set up just to monitor group variable 1's count and execute at a particular level.

But I still can't see a way to count unit types. Time for some more digging...


Avaunt

[Mercator]

Why not at the end of the week, resetting GroupVariable1 back to 0?  That way, every week, the number of soldiers gets checked, instead of being added to.  The next week, they get checked again.  If you want to save a particular week, then make GroupVariable2 = GroupVariable1.  We have upto 4 different GroupVariables to use.  What I would like to see added is another variable, like ScenerioVariable.  

This would let us keep track of certain numbers through each and every subfolder.  

[flagator_]

Remember, Avaunt and Mercator, that when you fire someone or they take a new job, their "skin" (uniform/clothing/appearance) doesn't always change right away. When I build my first Clinic and fire the college-educated soldier so he will become a doctor, I can click over to the Clinic and see him still wearing his fatigues. The UnitType must be what the game uses to track/decide what appearance the Tropican wears. So the UnitType will change when the skin does... not right away.

"I'm still a soldier, I'm just between things right now..."

[Mercator]

Yeah, that makes sense then.  I guess we just have to deal with it.  In my test, it only took one week (about 4 seconds on normal speed) for the soldier to change his UNitType.  So any event we set that deals with UnitType, we need to remember that one week delay.  In most cases, it shouldn't make a difference, thank the heavens.

[Avaunt]

Well what do you know? Read the editor .txt files and learn something in the process...

There is a command you can use to get an accurate count of several unit types. It is GSNumber... There are several versions (GSNumberSoldiers, GSNumberRebels, ect.)but not all units are represented and I still can't find a work around using the LoopThroughAllUnit functions.

Yeah, thanks Flagator for the reminder, but I was looking at some of the other indicatiors of employment changes like them being in their new employmer's building and the picture of their new place of work being on their unit stats screen. Even these are misleading as they seem to be updated before the person actually changes employment status.

The difference is pretty minor though, being at most a couple weeks before everything settles down correctly and I can't think of any event timings that really need to be that accurate anyways. It was just a good chance for me to start a thread out of ignorance and scare poor Merc, which is always a nice bonus  

Avaunt

[Coconut Kid]

Think Logically

..., when the message comes up, it tells you WHO are the soldiers.  My initial soldier (Name was Martinez) in my test came up the first week.  I fired him.  The second week, he came up again and I became very disappointed.  However, the third week, he didn't come up!  He was still alive and kicking as a farmer.  And what is more, he was still trained in being a soldier!  I ran the game another year, hiring another soldier to make sure the event was still firing every week.  It was.

[Speculation:] So I think that the reason Martinez came up the second week when he wasn't a soldier is either because the event still labeled him as one somewhere in that week; or as an unemployed citizen, the event will call upon the last known job, which in Martinez case was a soldier.

I looked through the Conditions to see if we can make the event hit only employed soldiers.  There are two conditions called UnitIsJobless and UnitIsUnemployed.  Now to me, these two conditions are the same!  ...

Remember, Avaunt and Mercator, that when you fire someone or they take a new job, their "skin" (uniform/ clothing/ appearance/ [avatar/ icon]) doesn't always change right away. When I build my first Clinic and fire the college-educated soldier so he will become a doctor, I can click over to the Clinic and see him still wearing his fatigues. The UnitType must be what the game uses to track/decide what appearance the Tropican wears. So the UnitType will change when the skin does - not right away.

"I'm still a soldier, I'm just between things right now..."

The unit has some things which are constant such as gender, but other things change - especially the avatar/ icon (skin). The game does not let the avatar change except in a building so the player will not get to see "Clark Kent turn into Superman" out in the open. So, there is a lapse between the time the unit changes occupations and the time it changes to a matching avatar. UnitType looks at the avatar, not the actual job; so Mercator's speculation about why Martinez came up a soldier after he was fired is wrong. And be warned -- it can take months for an avatar change in some cases.

Mercator was also wrong about UnitIsJobless and UnitIsUnemployed -- "Unemployed" is an avatar just like Mother and Farmer, so UnitIsUnemployed counts those wearing that avatar; UnitIsJobless counts all adult, employable units which do not have a job regardless of the avatar they are wearing.

Flagator got the point correctly.