script madness

[Byg]

I have come across yet another maddening bug in the scripting language. If anyone has had a similar problem and a resolution then please let me know.

On the first few turns my code works. If I carry on a few more turns it stops working, however, if after it fails I save the game and reload it then it works instantly, meaning when it loads it is fixed as if it took a reload to unstick it.

I am dealing with while loops and am wondering if it is possible that after a few turns of running these that somehow the game gets temperamental about them and if so then what is the act of saving then loading doing to make the code appear properly.

In more detail then:

The code runs at start turn (it alters the value of a counter) and then during the turn I can summon a historic event to tell me the value of the counter that has just been processed by my while loop. After a failure the historic event shows that the value is unchanged by the code.

The problem is definitely not with the historic event not correctly showing the counter value BTW.

So now I save and then load that save. Again I summon the historic event which now shows the counter value has changed correctly (not just the historic event showing differently - the counter has actually altered value) - yet no code has run since the save and reload. Could the game's intention of running the while loop at FactionTurnStart really be held in memory, stored in a save and then reloaded and triggered to run mid turn like this?

I cannot get my head around how this is possible.

Small simplified sample script transfering the value of c into b (and also into other counters in further sections of the bold script) :

monitor_event FactionTurnStart FactionIsLocal
set_event_counter c 100
end_monitor


monitor_event FactionTurnStart FactionIsLocal
and I_EventCounter c > 0;---- problem happens with or without this line

while I_EventCounter c > 0

if I_EventCounter o = 1
and I_EventCounter c > 0
inc_event_counter c -1
if I_EventCounter b1 < 90
inc_event_counter b1 1
end_if
end_if
similar code repeated for b2, b3, b4 etc (until c is spread amongst all these counters. NOTE: There is no danger that c will run out of counters to go into and thus prevent the loop ending)

end_while
end_monitor

Remember that there are no errors in the code. What I am hoping to find is a reason why it should sometimes stick and only run when reloaded mid-turn. Ideally I need a way to unstick it in code rather than saving and loading.

[Bungo Baggins]

Interesting...

Could you please post the whole script and tell what it is about?

- After how many turns does the bug happen (constant?)

- What happens to the value some turns after the first frozen value occured?
--> Is it still unchanged for the historic event?
--> Does the savegame still give the correct value?

The extra conditional line "and I_EventCounter c > 0" is superfluous as the same counter is required to start the while loop at all, but you surely know this.

[Byg]

Interesting...

Could you please post the whole script and tell what it is about?

No sorry, it would only upset people. And it's too long and complicated to explain.

- After how many turns does the bug happen (constant?)

I'm not sure if it is relevant, but it is in a 12 turns a year script. It runs ok on month 2 and on month 4 (the script links it to running in these months) in the first year, but next year on the same months it does not work. Not tried other months, but no reason to as the months are working ok and the months are set prefactionturnstart so they exist before my code depends upon them. There is no code referencing the year so this should not be a factor. So to answer the question, it is known to work (without saving and loading) at least in turn 2 and 4, but not later in turn 14 and 16.
Despite this I think I'll try triggering it at turn 11 or 12 too just to be sure it isn't linked to some 12 tpy madness.

- What happens to the value some turns after the first frozen value occured?
--> Is it still unchanged for the historic event?

yes. BTW it is not a complex event, it's simply something like if b1 = 1 then display the scroll with "1" on it and so on.

--> Does the savegame still give the correct value?

yes, if I save then load at any point after the problem the loaded game sees the correct values, same turn or later turn. When for example it fails for both the counter increments of turn 14 and turn 16, if I then save and reload it effects the code changes as they would have been done by turn 14 and turn 16.

For example, suppose the initial value was 1, turn 14 adds 1, turn 16 adds 1. With the problem the counter has its original value of 1 at turn 17. So save and reload on turn 17 then the value becomes 3.

The extra conditional line "and I_EventCounter c > 0" is superfluous as the same counter is required to start the while loop at all, but you surely know this.

Yes it was just one of the many things i tried after i encountered the problem. Having exhausted the likely i turned to the unlikely. I even tried whistling "Dixie" whilst the game ran, but to no avail.

[Bungo Baggins]

Quote:
- What happens to the value some turns after the first frozen value occured?
--> Is it still unchanged for the historic event?

yes
Quote:
--> Does the savegame still give the correct value?

yes, if I save then load at any point after the problem the loaded game sees the correct values.

That's one of the strangest bugs i have encountered so far...

I'm not sure if it is relevant, but it is in a 12 turns a year script. It runs ok on month 2 and on month 4 (the script links it to running in these months) in the first year, but next year on the same months it does not work. Not tried other months, but no reason to as the months are working ok and the months are set prefactionturnstart so they exist before my code depends upon them. There is no code referencing the year so this should not be a factor. So to answer the question, it is known to work at least in turn 2 and 4, but not later in turn 14 and 16.

It could have to do with the changing of the year then, though this does not explain the earlier issue completely.

- Does the error occur as well for turn 14 if you reloaded in turn 12?

- Could you post the script for the 12 turns/month year (probably not?...)

[Byg]

I'll try some stuff to rule out the 12 tpy plus your suggestion. As said, the only scripted link my code has to 12tpy is the month number, which i know is correct so the code itself wont help. Also we know that the code did in fact run (albeit in another dimension) because the correct value is there after a reload.

[Germanicu5]

100% confirmed way of such bug occuring is having advice (aka "show_me script) active in background - so my guess is that either some advice launched and never shut correctly or you're using such scripts for testing... or it's used for 12tpy season information (taking a wild guess).

Show_me scripts interfere with counter-based code as they somehow intercept counter stack information leaving campaign script code crippled.

It's always fixed by reloading as show_me script gets shut then and counter values are stored.

Regards

P.S. If I happen not to answer any questions within a month don't be disturbed.

[Byg]

100% confirmed way of such bug occuring is having advice (aka "show_me script) active in background - so my guess is that either some advice launched and never shut correctly or you're using such scripts for testing... or it's used for 12tpy season information (taking a wild guess).

Show_me scripts interfere with counter-based code as they somehow intercept counter stack information leaving campaign script code crippled.

It's always fixed by reloading as show_me script gets shut then and counter values are stored.

Regards

P.S. If I happen not to answer any questions within a month don't be disturbed.

This turned out to be the problem, ironically it was Germanicu5 own battle script that was wiping my script out. I removed the script part of his mod and my script proceeded properly every time. Sod's law dictated that this script was the only one I had not removed prior to adding my own thinking it could not possibly interfere.

The battles initiated by the ai against me between turns 4 and 14 were why my script did not function for turns 14 and 16, but did for turns 2 and 4.

I now wish I had not spent the last few months rewriting code that was obviously never at fault.

Thanks everyone for trying to help.

[Withwnar]

There is no danger that c will run out of counters to go into and thus prevent the loop ending

This was my immediate suspicion, that the loop isn't ending. Are you positive that "I_EventCounter o = 1" will never be false? I realise that this is a simplified example, so more generally, is it possible that "inc_event_counter c -1" will never be reached in some circumstance(s)?

[Byg]

I think your battle script is active germanicus, though at one point I believe I tested with it removed. Worth trying that again I guess as this is not the only strange reload effect I have seen. My last post here was in fact about another part of my script only working properly if it was not reloaded. if we don't hear from you again after a month we will assume foul play and alert the authorities.

One other thing I could mention is that the while loop is able to break out of the event that supposedly restrains it. In this case the while is triggered by start turn, but if I place another start turn after this which sets c to zero, then this prevents distribution of c to the other counters. This happens when the code is normally working and shows that the script is multi tasking in that it does not wait for the while loop to end but runs ahead to other events, in this case actually being stopped by one before it has even started.

This was my immediate suspicion, that the loop isn't ending. Are you positive that "I_EventCounter o = 1" will never be false? I realise that this is a simplified example, so more generally, is it possible that "inc_event_counter c -1" will never be reached in some circumstance(s)?

o can be zero, and often is and this should not affect the code adversely.
Yes, remember that the reload enables it to show the correct value, so it must have run correctly. Also c is only decremented by one if it is over zero.

[Withwnar]

o can be zero, and often is and this should not affect the code adversely.

Maybe I'm not seeing the whole picture here but if o = 0 then surely this while loop will not end...

while I_EventCounter c > 0
  if I_EventCounter o = 1
    
    inc_event_counter c -1
 
  ...
  end_if
...
end_while

"inc_event_counter c -1" will not be reached so c will always be > 0.

[Byg]

I just came back to edit my post, but you beat me to it. Here is what I was going to add:

That's a simplified script I showed so as not to confuse the issue. Yes if the value of o = 0 then it could go wrong. In fact for each block of code shown as bold text previouisly there is a different counter, o1,o2,o3 etc. The value of most should be 0, but some should always either be 1, 2 or 3 (I also did not show the code that involved values 2 and 3). The only way all of the o counters could be zero is if my other code that calculates the value for 01 etc at settlementturnstart, not shown here, failed to work or failed to work before its value was required by the above code. I'm sure all o counters are not 0. If however all o counters were not changed in time for the above code (i.e. left as zero) then that would mean settlementturnstart could be preceded by factionturnstart, which would be even more weird.

[Withwnar]

I'm sure all o counters are not 0

Sounds like it isn't that then. You could put a "log" call after the "end_while" just to verify that the loops are ending.

e.g.
end_while
log always loop ended

Or just a historic_event.

[Squid]

monitor_event FactionTurnStart FactionIsLocal
    set_event_counter c 100
end_monitor


monitor_event FactionTurnStart FactionIsLocal
    and I_EventCounter c > 0;---- problem happens with or without this line

    while I_EventCounter c > 0

     if I_EventCounter o = 1
         ;line below is redudant as the while loop guarantees c > 0
         ;and I_EventCounter c > 0
         inc_event_counter c -1
         if I_EventCounter b1 < 90
                  inc_event_counter b1 1
         end_if
    end_if
    ;mental sanity if to make sure loop exists
    if I_EventCounter o = 0
        set_event_counter c 0
    end_if
    
similar code repeated  for b2, b3, b4 etc (until c is spread amongst all these counters. NOTE: There is no danger that c will run out of counters to go into and thus prevent the loop ending)

end_while
end_monitor

I've suggested a couple of fixes that would hopefully help sort things out. When posting code please include it in code tags so that indentation is maintained.

[Byg]

Yes. I know some lines are redundant - they don't actually exist in that form in the actual script. I shortened the original script by a few thousand lines to show it simply.

As I mentioned further up the page the "o" counter in the actual script is o1,o2,o3, etc and many of those will be zero value so the "mental sanity if" cannot be applied.

The suggestion in the previous post to add a historic event to check the loop has been done already effectively by putting an historic event in a following FactionTurnStart, but I will try it where suggested too, just in case it makes some difference.

[Germanicu5]

[post edited a bit]

Now I possibly need some feedback on conditions in which you run my scripting - the best would be if you attached my code in .txt file.

You weren't running some version that worked via advisor, were you? There's also a chance you missed a required counter which caused advisor meant for custom battles launch during campaign.

Some additional info would also be appreciated, you can PM me with details as well.

Generally I strongly advise that my code is put below all other (we'll need to change it in SS) - try doing this with the code you had in cs and please report back if it helped (it'd be much appreciated).

I'll be a bit technical, but there are some cases in which a monitor doesn't shut if a battle is finished during its execution and it carries over to next battle, which might possibly "lock" some monitors, hopefully only below it.
I took ~all reasonable measures to prevent it, but it might happen if you quit battle instantly after starting it, generally it's mostly attributed to wait commands.
[edit: retested, it doesn't lock execution of other monitors, incl. counter-based].


Regards

P.S. I made major changes to scripting back in May, so I strongly recommend using latest version.

[Byg]

I doubt you need to worry as my latest version was begun years ago and as such was installed into an old rrrc compilation version for ss. Your script was indeed at the end of the custom script. The battles were not fought, but we're auto resolved. I had already tried my code before and after yours and it made no difference. Your script summoned the advisor. It also appeared to summon the advisor with the campaign script part removed.

;##########ReallyBadAI BAttle System launching code #######

;set_event_counter show_me_how 1

;monitor_event GameReloaded TrueCondition

;set_event_counter show_me_how 1
;end_monitor

;monitor_event PreBattlePanelOpen TrueCondition
;and I_EventCounter show_me_how = 1

;console_command clear_messages
;advance_advice_thread G5Script_Thread
;wait 1
;select_ui_element advisor_portrait_button
;simulate_mouse_click lclick_down
;simulate_mouse_click lclick_up

;wait 2
;select_ui_element advisor_show_me_button
;simulate_mouse_click lclick_down
;simulate_mouse_click lclick_up

;select_ui_element advisor_dismiss_button

;simulate_mouse_click lclick_down
;simulate_mouse_click lclick_up

;set_event_counter show_me_how 2
;end_monitor

[Germanicu5]

Ok, thanks. That's a version I used for a short period of time before gracul and me realised it was killing counter-based campaign script code.

You definitely need updated AI.

Regards

[Byg]

...

You definitely need updated AI.

Regards

New? No way, retro mods are in.