Update
first link:
http://tropico.strategyplanet.gamespy.com/cafe/index.php?topic=5837.0
El_Coronel: I ... saw no definitive answer on how faction works for units. I think I am making progress in understanding it. ...
Methodology: I placed a single unit on a map to keep it simple. I dumped the 4 following scripts into the 'events' folder created in the main Tropico folder. Then I loaded my map. Opening the Lists, I checked the current display there for my one unit in the environmentalist faction, which is the one I was tinkering with.
Results: A single AddTo does not visibly move the faction obtained by checking UnitUIFactionSupportEnvironmentalist (18). After about 25, the x100 number moved 1 (from 1800 to 1801 in my case). This suggested the increments are smaller, so I added a x10000 line in my report. And retested.
This time at iteration 29 I saw the numbers toggle to the following:
iteration 29
(x1) 18
(x100) 1801
(x10000) 180100
The granularity of x100 was sufficient, it appears. (Prior experience with the logging numbers made be suspect this). Now the question is whether the effect is random, a chance based increment, or fixed on some interval. I will go on to see when the next several increments happen, and retest from start to see if the sequence stays consistent.
At iternation 57 I saw 1802 appear. It looks like the magic number is 28, which is the number of days in a month in the game, but another set should prove it. My starting day was probably the 2nd of January for the sequence, thus the slight blip.
At iteration 85 1803 popped up. That's 28 days later. The next should be at 113 then. And it was.
It appears that an AddTo of 1 each day for a month results in an increase of one percent of a point of faction. That means 2800 should move it 1 point. That will be next test.
A quick edit of testevnt.evt to change the 1 to 2800 and away I go.
My unit starts as a detractor, so in the space of 3 months it should move up to the maximum support category. The numbers should track progress.
Whoops. That's odd. Numbers are maxes at iteration 1. Yep, she's now a DieHard supporter! Either a bigger boost moves faction a LOT faster, or I have some sloppy code. Except if it were code, 1 point per day for all of January would not get it to 100. The former theory seems more likely. Must be some exponential equation involved.
I'll try with a boost of 2 instead and see if the numbers move more than twice as fast.
Hmm, at iteration 1 the number is 1900. And at 2. And all the way through the month. Aha! We can only boost faction for a given unit once per month? At 29 it's 1902. and at 57 it moves to 1904. Still unclear.
Does appear as if the 'one move per month' theory might be good. Not sure what happened last test though. Why did a boost of 2800 max faction? It should have moved to around 4500 (45.00) if it's linear as the other two tests suggest. Unless it's some sort of logarythmic scale. Let me try a boost of 10.
Hmm, at iteration 1 it's 2700. That is 1700+1000 (17+10), which is weird. But tracks with the other two tests of 1 and 2 increments. And by that logic, 1700+280000 would force maximum. But why is that first increment 100 times the others? Is that a designed intent to allow scenario designers to quickly move faction at the start of a scenario? In any case, at 29 interations the number moves to 2710.
If the first is a x100 effect, I should be able to hit 99 at iteration 1 by adding 99-17=82. Yes! And I should see 99.82 at 29 iterations... and I do (and the x1 number is rounded to 100 too, interesting.)
Tentative conclusion:
The first adjustment of a unit's faction adds whole points in the 0-100 faction range. So a unit with 50 starting faction can be changed to a 100 with:
GeneralEffect AddTo (faction) 50
After that, faction is moved in 1/100ths of a point with one event per month maximum. The above command would at one half a point, moving a faction of 50.00 to 50.50.
I'll test this further by setting a series of timed events, rather than daily loops, and see if it performs as expected.
I changed to a loop of Monthbegin and negative numbers and it performed exaclty as expected in my comclusions above.
Next is testing beyond one year. Hope my test unit doesn't emmigrate on me... no dock, maybe that will keep her close.
Anamolous behavior on the first of the year. Regular on the first of the other months out to past 3 years.
start 17.00
Feb 1 27.00
Mar 1 27.10
Apr 1 27.20
.
.
Nov 1 27.90
Dec 1 28.00
Jan 1 27.81 <--
Feb 1 27.91
Mar 1 28.01
.
.
Dec 1 28.91
Jan 1 28.73 <--
Feb 1 28.83
.
.
Dec 1 29.83
Jan 1 29.64 <--
Feb 1 29.74
It appears there is some normalization of faction on Jan 1 of each year. But is this to some base number (maybe 25 as the neutral point) or back to the starting number for the unit?
First year decrease is: 0.29
Second: 0.28
Third: 0.29
Hmm, doesn't seem to be 1 percent of total, quite, though close. I would expect the first to be a bit lower. Might be rounding.
Can't tell what the target is though. There may be other faction-modifying events in the game that we don't see too (beyond the newspaper/radio/TV ones we know about).
Whoops, made one assumption too soon. x10000 is necessary to see significant digits once a year is passed. (skip rest of
Reply #2)
Senor Ruina: Colonel: nice to see some work being done on this. I have not done as much detail as you, but I'll relate what I have done.
Taking the idea of multi-factions from an earlier post that I read here, I got the idea to make a scenario called
Bolsheviks. The idea is that your goal in the game is to create a faction of people both communist++ and militarist++. My scripts would look for that, then whenever they see a new bolshevik they would boost him or her to communist+++ and militarist+++ (and also it would drop religion by 25). This makes it the unit easy to find, and it also makes it easy to know which new units (which appear from time to time) have been "branded" as Bolsheviks and which ones have not. (So you can report new ones to the player.)
I had no problem detecting people who were ++ in the two factions. My scripts then set the people to level 99 in both factions, and this also worked. By means of testing, what you would see is that a new person appears with ++ in the two factions (typically just after leaving a military school), then at the month start when the event fires that person is noticed, the message for new bolshevik appears properly, and the person is now +++ in both factions.
Incidentally, the scripts all work in case any wants them. My playtesting with them convinced me that the overall idea is flawed. Culturing a bolshevik party is not, actually, very much fun. It is too straightforward. My other main idea in Bolsheviks, which is rewarding the player for getting his bolsheviks into particular jobs, also is not hugely fun. The problem here is job bumping, which just gets ridiculous and tedious.
(Then there are some comments on coding techniques)
El_Coronel: Here's my modified version which appears to work perfectly.
CheckFrequencyOnlyWhenCalled
;
; event: varsetrw (name each event to describe var set)
;
; variable x
;
; GV4 is rw flag (F/0 = read, T/1 = write)
; note: GV4 must be 1 or 0 only
; GV1, GV2, GV3 are passed variables
;
; EV1, EV2, EV3 are perm storage
; EV4 is working storage
; do GV1
GeneralEffect SetTo EventVariable4 (GroupVariable1 * GroupVariable4)
GeneralEffect AddTo EventVariable4 (EventVariable1 * (GroupVariable4 = 0))
GeneralEffect SetTo EventVariable1 EventVariable4
GeneralEffect SetTo GroupVariable1 EventVariable4
; do GV2
GeneralEffect SetTo EventVariable4 (GroupVariable2 * GroupVariable4)
GeneralEffect AddTo EventVariable4 (EventVariable2 * (GroupVariable4 = 0))
GeneralEffect SetTo EventVariable2 EventVariable4
GeneralEffect SetTo GroupVariable2 EventVariable4
; do GV3
GeneralEffect SetTo EventVariable4 (GroupVariable3 * GroupVariable4)
GeneralEffect AddTo EventVariable4 (EventVariable3 * (GroupVariable4 = 0))
GeneralEffect SetTo EventVariable3 EventVariable4
GeneralEffect SetTo GroupVariable3 EventVariable4
