Jump to content

Recommended Posts

Posted (edited)

I've demonstrated without any doubt that if a deactivated counter is incremented into its limit, it will NOT trigger immediately when it is later activated....crud!  This counter functionality is called out more that once in the manual, but frustratingly I cannot get it to work.  Sure there are workarounds, but dang, this would be a really convenient feature to have.  Am I alone in not having this work as documented?

Edited by AcidBath
Posted

Just to clarify, are you saying this:

 

Say the counter is set to 3. Without ever having been deativated, it gets two input pulses then you deactivate it.  While deactivated it may or may not receive inputs.  When reactivated, it requires more than the expected single (third) pulse to produce an output?

Posted (edited)

Thus spake IL-2 Sturmovik Mission Editor and Multiplayer Server Manual on page 279:

 

Quote

Usage Notes

If you deactivate the counter using a deactivate trigger (pg. 280), the current value is still incremented when an input triggers the counter. However, the counter does not fire when the value reaches the maximum, but it does fire when the counter is activated again using an activate trigger (pg. 274).

 

 

Fortunately, a decently clean workaround with the same functionality is to have the (not ever deactivated) counter's trigger pulse enable a switch which was previously disabled.

Edited by AcidBath
added my workaround
Posted (edited)

I tested it just now (see attached mission) and either that functionality has changed since late 2016 or the note in the manual was wrong from the start. Sorry for any confusion.

 

JimTM - Test Deactivate Counter.zip

Edited by JimTM
Posted
2 hours ago, AcidBath said:

Usage Notes

If you deactivate the counter using a deactivate trigger (pg. 280), the current value is still incremented when an input triggers the counter. However, the counter does not fire when the value reaches the maximum, but it does fire when the counter is activated again using an activate trigger (pg. 274).

 

A few years ago I noted that exact behaviour in RoF and considered it a bug.  From past experience I wasn't going to waste my digital breath reporting it, but it looks like it may have been fixed at least for this game.  Maybe I'll test it for myself.

Posted

Thanks JimTM for confirming this.  As a (now retired) software engineer, it's no surprise that software functionality can be a moving target from build to build.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...