Forcing random events

[TeamStar]

Is it possible to create an event on a scenario, that forces one of the events from the random events list, to happen? Like, forcing a marine strike to take place in a specific date...

[artemais]

The only truly scriptable random event is the redtide.  To use it, you would have to like the following:

checkfrequencymonthend
condition gsaveragehappiness>=60
condition year<1970
generaleffect redtide


Of course, the conditions can be anything you want, but redtide is the only random event you can call  through script.

[TeamStar]

redtide is the only random event you can call  through script.

Why? Is there a plausible reason for it?

[TeamStar]

I would imprison the people at PopTop, so they would gain some RESPECT for us and start working on a new patch.

[artemais]

Why? Is there a plausible reason for it?

Yeah, no kidding.  I would love to be able to call the maritime strike in a script.  That by far is my favorite of the random events, but it would be really nice to beable to call hurricanes and epidemics too.

[rickrick]

Just a thought, but couldnt you simulate a Maritime strike by simply going thru and firing all the dockworkers? Hmm...not seeing a firing command in the scripts list, however there is a UnitIsJobless query ... I wonder if you can set that to False to force a fire?

Ah! Here it is "BldgFireWorkers". So Simply do

CheckFrequencyDayEnd

LoopThruAllBuildings
Condition ((BldgType=BldgTypePortEast)or(BldgType=BldgTypePortWest)or(BldgType=BldgTypePortNorth)or(BldgType=BldgTypePortSouth))
Condition GroupVariable1=1  ;"Maritime Strike" is True

GeneralEffect BldgFireWorkers

Course, I'd actually set that up as a "WhenCalled" frequency, but I think it will work the same. Your docks will shut down during the strike and new workers will be fired each day. You might have to test it a bit and see if the fired dockworkers who try to join over and over get upset for being fired each day during the duration of the event. If so simply add in some kind of modifier to counter-act that. But all in all no more boats will come.

[artemais]

Um, yeah, but the problem is not firing the workers.  We can fire workers all we want, and then el presidente hires new people and everything is okay.  The maritime strike event actually causes all incoming ships to stop for a period of time, which I love because there is nothing that can be done to counteract it.

[rickrick]

I think you misunderstand what I'm suggesting. If the dock workers are fired then no ships will dock. Just keep the event running for however long you want it to - which gives you even MORE power than the internal Maritine Strike because YOU can set the terms in which the strike ends rather than a simple passage of time.

Maybe they want a pay raise, maybe you need to build a police station to stop crime so docks can open, whatever your scenerio calls for. With the script running on a daily basis then no matter how many times the player tries to get people to work there or how many times the people take a dock job it will fire them at days end - pretty much acting like the random Maritime strike.

To help keep people from hiring on you can also force the payrate of the dockworkers to 0 each day, maybe stagger the event so days end fires the workers and day begin sets pay to 0. This should keep the docks empty enough that a ship wont dock and the player wont be able to entice workers in. At least, I *THINK* you can alter payscale with a script? Dont have the help file open to verify that.

[artemais]

You can't alter the payscale through script.

Having the event firing every day would be a killer on the processor since it has to loop through all units.  I actually don't even think you could have the event fire in a day since it would be doing some pretty good looping.  That's the problem....one probably can't fire the script fast enough to keep the dock unemployed.

[rickrick]

I'm not sure what kind of system you have, but I've tried these scripts on both my computer and my wifes (2.66 ghz and 600 Mhz respectively) with no noticeable slowdown.

Once the script became active the dockworkers where fired and no new boats entered the area. Any boats awaiting to be docked stayed anchored until after the strike was over and there were dockworkers. If it happened when a boat was already docked then that boat did not leave until dockworkers went back to work.

I raised the payscale to the maximum amount and kept firing males off of other jobs to get them to work there. If they would pop in it would only be for an instant (depending on how fast you have time going) and were then fired. At no time during that small amount of time when there was a dockworker did any ship begin docking or leave the dock if already there.

Soon as the time period passed I was able to hire dockworkers normally and the boats returned as normal. Here's the script. Easiest thing to do is simply throw it in your Tropico Event directory and run any game/scenerio. I tested with default settings on a game.

The "maritime strike" begins at the very last day of 1950 and ends on the beginning of the last day in 1951.

Strike.evt
CheckFrequencyDayBegin

Condition ((Year>1950) and (Year<1952))

LoopThroughAllBuildings
Condition ((BldgType=BldgTypePortEast) or (BldgType=BldgTypePortWest) or (BldgType=BldgTypePortNorth) or (BldgType=BldgTypePortSouth))

GeneralEffect SetTo BldgFireWorkers 1
GeneralEffect CallEvent Strike2
GeneralEffect CallEvent STrike3

Strike2.evt
CheckFrequencyOnlyWhenCalled

ExecuteOnlyOnce

MessageTypeDossier
MessageText "Presedente!\n\nThe Dockworkers have gone on STrike!"

Strike3.evt
CheckFrequencyOnlyWhenCalled

ExecuteOnlyOnce

Condition Year = 1951
Condition MOnth = 12
Condition Day = 28

MessageTypeDossier
MessageText "Presedente!\n\nThe Dockworkers have gone back to work!"

 

[Railnut]

I only have about a million other things to be doing this morning, so I ran this strike event instead.

My system is P4, 2.8GHz, 512MB RAM. I had no noticable slowdown even at Very Fast game speed.

Results:
Strike worked. I fired all males and closed all jobs. Eighteen to twenty unemployed men. Very few job takers during strike even with pay at $50. All stayed less than a second. On the Pay list in the almanac there were as many as seven at $0 pay wearing dockworker's uniform. One boat waiting to dock moved in as soon as strike ended.  One former farmer hired on in May. Three immigrant dockworkers were on that boat. One more rehire later.


Changed to Weekly check. Boat in dock at start. Some takers during first few months, about two second tenure, never made it near the dock. Up to 14 at $0 pay in uniform. Never saw the message at end. One new hire in May and boat left immediately. Another hire in July. Two immigrants in Feb '52.


Changed to Monthly check. One boat in line to dock. Some takers in Feb, stayed seven seconds at Very Fast. Never made it to the dock and boat never moved. Another boat joined the waiting line. More hires and boat docked in May. Two hires and three immigrants in July, boat left. One hire in August. Up to 16 at $0 pay in uniform. Again, never saw end message. With pay still at $50, one hire in Jan '52. Boat didn't move until March. Three immigrants and one more hire in April. Then I opened all other jobs and they filled immediately at $5.


Conclusions:
Daily check was no problem for me. Weekly worked well enough to keep the dock empty. Monthly wasn't 100% effective, but I don't know if any worker would have had time to load any loads. I doubt it.
Now I just need to figure out why I didn't see the end notice on the weekly and monthly tests.

And one unrelated question:
Is that frame rate counter always there on the bottom right, or did I somehow accidentally turn it on? I don't really remember ever noticing it before and now it's annoying me.

[TeamStar]

What about bulldozing, through script, the existing dock(s) and all other future docks, eventually built by player? Would this work?

[TeamStar]

... or trigger through script the No One Gets Out Alive set on immigration, supposing there is an Immigration Office on the island?...

[Brf]

Perhaps a full-blown strike of the Teamsters

My scenerio Return to Glory has a type of Teamster strike. If you do not pay the Teamsters enough, they go home and rest until you give them raises.

[artemais]

My system is P4, 2.8GHz, 512MB RAM. I had no noticable slowdown even at Very Fast game speed.

Ah, well I'm only running on 64mb of RAM as it is, I don't even remember what my processor speed is, but my computer just turned 7 and I have never upgraded.....

My scenerio Return to Glory has a type of Teamster strike. If you do not pay the Teamsters enough, they go home and rest until you give them raises.

I'm pretty sure CafeDave has a similar event in his Wooden Limbs scenario.

My conclusion:  yes, the strike is feasible, and maybe its just my system, but it would take some processor speed away.  A better test to run woule be to have the strike start in 2000 when the entire island is a parking lot rather than in 1950 with the starting buildings.

[Railnut]

Thanks Ck. I never fear random input to do something, but always fear random input when trying to undo what I accidentally did. I bet I tried to use the cheat FIVEYEARS and hit the shift instead of ctrl. I take this episode as minor proof of at least some sanity on my part since I was sure that that ever-changing yellow number hadn't been there all along.

CafeDave's Wooden Limbs and Aching Backs has teamster and dockworker strikes. And just to be sure they stay off awhile, they destroy the buildings on their way out. I never did finish that one. Maybe I'll try it next.

Good point, artemais, on trying the strike on an already busy map. I'll add it to a saved, finished game and see what happens. That may have to wait until next weekend though.

[rickrick]

A really nice break-through on how to script a "strike" for all of a "class" of workers through their "employment" building(s).

I dont know about it being a break thru  but thought that it was quite possible to at least simulate some of the games other random events. While not exactly the same, at least close enough to fit within the parameters of a scenerio. And as pointed out, stuff like this has probably already been done by others and probably just forgotten about.

I only have about a million other things to be doing this morning, so I ran this strike event instead.

Thanks for running that Railnut, you thought up some things that I hadn't considered. It looks like anyone concerned about the processor hit could go with the weekly check quite easily, and the monthly even looks feasable with the possibility of a boat slipping thru on a rare occasion.

The reason the ending didnt fire when you changed from Daily to weekly and monthly was that the script was written to end on Dec 28,1951. Changing to weekly/monthly means that the check was never performed on that date, but after so it could never be found true. A simple modification for checking AFTER that specific date would fix that.

What about bulldozing, through script, the existing dock(s) and all other future docks, eventually built by player? Would this work?

I think that could certainly work, but you are still going to have to make some checks to ensure that another dock isnt built if your intent is to keep shipping closed down for a period of time. It will depend on what story you are weaving in your scenerio.

As for the processor speed issue, it seems to me that if you can run the script with no noticeable effect in 1951 then running it in Year 2000 with a huge Island economy in the works makes no difference. If you are going to have any slowdown from an older system then you are already going to have it by that point in the game anyway. Plus, its been put forward that a weekly check is just as effective as the daily, reducing any feared processor hit even more.

[artemais]

As for the processor speed issue, it seems to me that if you can run the script with no noticeable effect in 1951 then running it in Year 2000 with a huge Island economy in the works makes no difference.

Actually since the script would have to loopthroughall buildings to continually fire the dockworkers, it would make a huge difference, especially if you have developed your island with a ton a of small buildings.  Anytime the script loops through buildings or units, the more it has to loppthrough is the more it has to check against the conditions, making it take longer to fire.

And just to be sure they stay off awhile, they destroy the buildings on their way out.

  Yeah, that's certainly AN option.....actually, even though you cannot script a pay change to $0 at the dock, you can force el presidente into changing the pay to $0 or suffer the ill-effects--sooner or later after all your buildings start to collapse one would want to change the pay.  Changing the pay to $0 would discourage most people from taking the job, making a monthly check more feasible.

And to get back on the original topic now, this is still just a quick fix to not being able to script the maritime strike.  There would be other quick fixes to simulate hurricanes and epidemics too, but the original post was which of the random events can truuly be scripted, and the answer to that is only the redtide.

[rickrick]

I have a theory and to test it I created this looping scenerio. I also watched the FPS counter with the Shift-F in place (thanks for mentioning that Railnut!)

This scenerio runs daily. For comparison I first ran my computer without the scenerio in place and watch the FPS counter on both my computers.

System     Low FPS      Avg FPS        High FPS
2.66 Ghz    34ish          45-55           60ish
400  Mhz      2ish             5                 7

*A note on the 400, I miscalled my wifes system as a 600, it is actually a 400. I have a 600, but we put that in the kids room for school. I had mixed that up, sorry.

Once I ran the scenerio I found the numbers for framerate changed very little and actually increased if anything. The 2.66 hovered more between 50 and 55 and my wifes averaged around 7. There was no discernable change in the movement speeds between the script and non script run.

I also had the script set up to not run the first year, run for all of 1951, then shut off in 1952. I used Ctrl-ONEYEAR to force this issue after running for a few months and also ran with extremly fast time speed. There was no alteration in movement speed on either computer. The FPS didnt make any noticeable change in average speed.

One thing I noticed was that on my computer, even tho the loop is setup to run 1000 times per call, it only ran 30 times. On my wifes computer it only ran 28 times per. This leads me to believe that there is an internal limit of how many times it can run dependant on some factor.

LagIt.evt
CheckFrequencyDayBegin
Condition Year=1951
GeneralEffect SetTo GroupVariable1 1000
GeneralEffect CallEvent Lagit1
GeneralEffect AddTo GroupVariable2 1
MessageTypeBottomRight
MessageText "This test has run [Trigger_Group_Variable_2] times for [Trigger_Group_Variable_3] Loops."

Lagit1.evt
CheckFrequencyOnlyWhenCalled
Condition GroupVariable1 > 0
GeneralEffect CallEvent Lagit2
GeneralEffect CallEvent Lagit1 :**<---Had originally forgot this line, sorry 

Lagit2.evt
CheckFrequencyOnlyWhenCalled
LoopThroughAllBuildings
Condition Money != 1000000
GeneralEffect AddTo GroupVariable1 -1 ;Decrease Count
GeneralEffect Addto GroupVariable3 1  ;Count Loops



Does anyone have a scenerio that can bog the system down? I'm assuming that has happened before because its been mentioned alot. Just trying to find the limits. Right now I'm starting to think :

1- The game limits loops internally to control bog down
2- The game Loops one time naturally and the script loop calls dont actually create a loop but make a call/s within that one loop
3- Simply dont eat up as much processor time as people think.

And to get back on the original topic now

We never lost the topic. The original question asked if there was a way to call the internal random events. While you cant simply call "MaritimeStrike" you can still manage to simulate pretty much exactly the same effect. A little more involved than a simple call, but still quite on topic.

The hurricane is quite doable, however I dont know about the increased cloud part. While there is a event called "CloudRate" I've tinkered with it with many numbers (small and large) and still have yet to make it make the number of clouds in the sky change. Still, declaring a hurricane and randomly knocking down buildings is quite doable. Just cant seem to get the pretty storm

Anyway, theres the script I tried. Anyone get different results? Btw, the money check in the script was only to have some query during the loop - wasnt sure how the loop would act without some condition check. Was worried if I checked for a specific building that it would only run the loop as many times as buildings there were.

[Brf]

the loop is setup to run 1000 times per call

I see nothing in your script that would make it run more than once per day.

[Coffeebean]

The hurricane is quite doable, however I dont know about the increased cloud part. While there is a event called "CloudRate" I've tinkered with it with many numbers (small and large) and still have yet to make it make the number of clouds in the sky change. Still, declaring a hurricane and randomly knocking down buildings is quite doable. Just cant seem to get the pretty storm

One thing missing is tree loss with a scripted hurricane event, which is a shame, if you're aiming for some realism.

[rickrick]

I see nothing in your script that would make it run more than once per day.

Too many late night hours and not enough sleep 

While debugging the script, running it on 2 different computers, and trying to stay awake with cheap "Dr. Thunder" rootbeer I somehow managed to not only copy/paste an early first workup of the script, but to run faulty testing with it while the correct script sat on my desktop, unsaved  Sorry.

I've gone up and updated the script in my previous message, but the culcprit was in Lagit1.evt where the call back to itself had not yet been put in place. The clue to me should have been that I was only get 28 or 30 counts - but I was just to tired to catch it.

Here is the correct Lagit1.evt for that script. The problem was that the first version didnt have the callback loop if condition was true.

Lagit1.evt
CheckFrequencyOnlyWhenCalled
Condition GroupVariable1 > 0
GeneralEffect CallEvent Lagit2
GeneralEffect CallEvent Lagit1

[rickrick]

2BldgTypeClinic is NOT listed in the editor documentation.

Look for BldgTypeHealthClinic, that thru me off for a bit till I happened to notice it while looking for something else.

[artemais]

I also had the script set up to not run the first year, run for all of 1951, then shut off in 1952. I used Ctrl-ONEYEAR to force this issue after running for a few months and also ran with extremly fast time speed. There was no alteration in movement speed

I think you've still missed the point.  The year does not matter.  The big factor is how many buildings you have to loop through.  If this is all you did without adding more buildings, then your test proved nothing.  The only reason the year makes any difference is if you have developed the island, naturally, over time.

[rickrick]

I think you've still missed the point.  The year does not matter.  The big factor is how many buildings you have to loop through.  If this is all you did without adding more buildings, then your test proved nothing.  The only reason the year makes any difference is if you have developed the island, naturally, over time.

Ok ... I took $1,000,000 with exacto, used rapido, paused the game and layed out a buttload of buildings (something like 20 bunkhouses, a dozen hotels, 6 tenaments, 2 churches, 3 clinics, a couple of mines, loggers, and ranches, police stations, an armory, power plant, 2 electric stations, dozen farms, 5 or 6 fishing shacks, etc. You get the point...also a few hotels, a bunch of bungalows, most of the entertainment buildings, and a couple docks. Colleges, Hospital, Cathedral, etc.

I changed the pay rates so that uneducated got 10, highschool was 20 and college was 30 - this was so that I would entice in immigrants. I went thru and paid for someone come work in each building. I set immigration to everyone was welcome.

I saved the game and reloaded to run with and without scripts. Quite a large influx of people when the first boats docked and I was up around a population of 80 fast (as an afterthought i should have just made the settings start with more people). More people came as ships docked but not as many as the first rush.

First I ran it without the scripts. On my computer there was a slight decrease in the FPS rate, but really no visible change in the peoples movement. On my wifes computer the Fps avg dropped from 7 to 5. This is without the script in the Event folder.

When I halted the games and put the script in the folder and re-ran both computers had the same FPS as without the script so framerate did not seem to be effected.

When the script ended on my wifes computer there was a ***SLIGHT*** increase in walk speed in her people (nothing noticeable on mine).

So I probably had about 100 buildings with a 1000 count loop on a daily basis (thats 100,000 checks per call each day) before there was any noticeable difference in speed that was pretty much insignificant in game play. I honestly think that unless you specifically go out of your way to write a script to bog down the processor its just not really going to happen under normal circumstances.

Is there a specific script or scenerio that has made everyone think that prosessor bog is easily caused? So far to me this looks like a rumor that has simply gone unchallenged and just accepted as fact.

Remember, I'm trying to do extreme loop scripting here to find the limits, how often does this happen in a normal script? Looping thru buildings and units a few times on a daily basis is simply going to have no effect on gameplay speed.

Artemais, your argument about development is a mute point. You are saying that more buildings means more bogging down because there are more things to count each loop. 100 buildings with 5 loops is the same as 5 buildings with 100 loops. In either case its 5 X 100 = 500 checks regardless.