Has Random variable "new" changed somehow? [RESOLVED, INVALID]

[Lumituisku]

Since 4.1, I have noticed that on many missions where previously were no problems units with "Random" routes now sometimes don't pick a route. 

 

For example classic TANKS missions. -  It seems that even when there is two different routes leaving from way-point with "embark If" commands. One with "0<=random variable NEW < 50"  and another with "50<=random variable NEW < 100"   AI unit sometimes doesn't pick either. 

So...  I wonder, if there has been a change in this that I have somehow missed to notice? 

 

[Toyguy]

That doesn’t seem like it would ever work as a new number is being requested each time, thus the condition could be false each time.  You’d want to request once, then act on it if less than 50 or else take the other route.  No need to request another value.

[Jartsev]

44 minutes ago, Lumituisku said:

For example classic TANKS missions. -  It seems that even when there is two different routes leaving from way-point with "embark If" commands. One with "0<=random variable NEW < 50"  and another with "50<=random variable NEW < 100"   AI unit sometimes doesn't pick either. 

It is rather  confusing, but '<' is treated as '<=',  so if  random variable new is '50', while 2 routes have embark logic  "0<=random variable NEW < 50"  and  "50<=random variable NEW < 100",   embarking conditions will conflict  each over. This means,  there should be  one unconditioned route,   and variables ranges for conditioned routes  need to be adjusted. 

See SBWiki article: http://www.steelbeasts.com/sbwiki/index.php?title=Random_Numbers_In_Control_Logic

[Lumituisku]

Interesting.  Thank you guys. This seems to have solved it very well indeed. Units keep now moving nicely around the map once again.    

 

So basically problem is (was), when random variable new gets same value that is on two or more conditions , AI wont be able to choose witch one to take and will instead stay where it is due to that conflict? 

[Jartsev]

Just now, Lumituisku said:

So basically problem is (was), when random variable new gets same value that is on two or more conditions , AI wont be able to choose witch one to take and will instead stay where it is due to that conflict? 

Exactly

[Rotareneg]

1 hour ago, Toyguy said:

That doesn’t seem like it would ever work as a new number is being requested each time, thus the condition could be false each time.  You’d want to request once, then act on it if less than 50 or else take the other route.  No need to request another value.

In 4.0 and older, it generated one "new" random number on arrival to a waypoint and checked it sequentially against each conditional route, which let you have a bunch of routes fan out from that waypoint. Now that it rerolls "new" with each check that won't work anymore, so scenarios that used it break. Either use fixed random variables (X03, etc.) that don't change or a series of 50/50 splits.

[DarkAngel]

3 hours ago, Rotareneg said:

In 4.0 and older, it generated one "new" random number on arrival to a waypoint and checked it sequentially against each conditional route, which let you have a bunch of routes fan out from that waypoint. Now that it rerolls "new" with each check that won't work anymore, so scenarios that used it break. Either use fixed random variables (X03, etc.) that don't change or a series of 50/50 splits.

 

[ben]

11 hours ago, Lumituisku said:

Since 4.1, I have noticed that on many missions where previously were no problems units with "Random" routes now sometimes don't pick a route. 

 

For example classic TANKS missions. -  It seems that even when there is two different routes leaving from way-point with "embark If" commands. One with "0<=random variable NEW < 50"  and another with "50<=random variable NEW < 100"   AI unit sometimes doesn't pick either. 

So...  I wonder, if there has been a change in this that I have somehow missed to notice? 

 

 

There has been a change that broke many of my scenarios which worked perfectly before.

[Ssnake]

While we rate it as invalid, we're still working on a fix, and I think it'll make it into the next patch.

[ben]

1 hour ago, Ssnake said:

While we rate it as invalid, we're still working on a fix, and I think it'll make it into the next patch.

 

If the multiple rolling of the dice was the original intended behaviour, why give the user  2 values to for the variable to be between?

ZERO  < NEW < UserValue 

would have been enough, but we have the current setup,

UserValue1 < NEW < UserValue2 

 

which implies to me it was designed for the behaviour I used to rely on  

[DarkAngel]

No because don't forget there are the Xn numbers which are covered by the same logic entry.

[ben]

12 minutes ago, DarkAngel said:

No because don't forget there are the Xn numbers which are covered by the same logic entry.

 

No, that’s different, X1 etc will be the same throughout the scenario.

 

NEW should be a new value each time a waypoint is reached.  The complaint is that now it is new again for each individual route leaving a waypoint.

Edited August 25, 2019 by ben

[Ssnake]

It's always been that XNew would be rolled new every time that it would be tested. A bug in that routine allowed you to apply it the way you did in past versions (it should have failed back then already). That bug was removed, which on the one hand makes the description of it as a "new bug" "invalid" but at the same time we acknowledge that leaving you with this the way it is now isn't exactly helpful either.