I_TimerElapsed and Wait

[Withwnar]

Hi, I have a couple of questions.

1) I read somewhere that wait shouldn't be used inside a monitor. Is this correct? It might have been a RTW thread that I read that in.

2) I have seen some examples of I_TimerElapsed being used that goes something like this...

monitor_event {...}

  {...stuff...}
  
  restart_timer Campaign_Map_Timer

  while I_AdvisorVisible
    monitor_conditions I_TimerElapsed Campaign_Map_Timer > 10000
      ui_flash_start advisor_dismiss_button
      terminate_monitor
    end_monitor
  end_while  

end_monitor

(If advisor is showing and has been for 10+ seconds then flash its dismiss button.)

I'm wondering why the embedded monitor_conditions. Is it simply a more elegant way of doing the following? (i.e. Uses less lines of code and no extra counter.)

monitor_event {...}

  {...stuff...}
  
  restart_timer Campaign_Map_Timer

  set_event_counter dismiss_is_flashing 0
  while I_AdvisorVisible
    if I_EventCounter dismiss_is_flashing == 0
      and I_TimerElapsed Campaign_Map_Timer > 10000
      ui_flash_start advisor_dismiss_button
      set_event_counter dismiss_is_flashing 1
    end_if
  end_while  

end_monitor

Also, is it bad practice to have something like the following in campaign_script?

declare_timer my_timer

monitor_event {...}

  restart_timer my_timer
  
  set_event_counter test_if_timer_has_elapsed 1

end_monitor

monitor_conditions I_EventCounter test_if_timer_has_elapsed == 1
  and I_TimerElapsed my_timer > 5000
  
  set_event_counter test_if_timer_has_elapsed 0
  
  {...do something...}
  
end_monitor

This monitor_conditions never terminates but only does something when a flag is set. It seems like a bad idea to me because the monitor_conditions is being evaluated however-many-times-per-second even if its conditions don't evaluate to true, which would add CPU overhead for the lifetime of the campaign. Am I correct in that?

I tried it while watching Task Manager and it didn't seem to increase CPU usage, but I can't say for sure.

Any help is appreciated. Thanks.

[Germanicu5]

I'm not sure such script would make sense.
First of all show_me scripts substitute data streamed towards game's parser from campaign script with given show_me code. That means counter\timer-based code put inside campaign script won't execute (notably running show_me just shuts any non-show_me timer, that includes "wait" commands as well). It also means you'd need to add such advisor shutting code to each advice script. Given the fact advice is pretty useless and causes battle CTDs, I'd just recommend stripping advice files instead, as I did for SS and TATW.

Apart from that, 2nd version of code you presented is ok, it won't kill CPU or anything.

Wait commands can be put inside a monitor if you know what you're doing - you need to consider "what if conditions met when 10s timer started aren't met 10s later", a way to avoid related issues is doing something like this:

monitor_conditions\monitor_event XXX XXX
and I_CompareCounter YYY = 1
and condition zzz or something

wait 10
if I_CompareCounter YYY = 1
and condition zzz or something
[code]
end_if
end_monitor

I_TimerElapsed isn't bad, but it makes a total junk out of log file and it needs more monitors to be set up, so it's more resource-consuming.

Regards

[Withwnar]

Thanks for that G5.

I'm not trying to do anything with the advisor myself - this was just some code I found in another thread, as an example. It was more a general question about using an embedded monitor_conditions as opposed to counters and ifs. But thanks for the info, that's good to know.

And I take your point about conditions not necessarily still being true after the wait.