Jump to content

Route Logic with random value


Recommended Posts

Hi guys

 

Can you explain how a logic ever can be true if the number is 100.

 

I'm working with routes where the tank can choose one of 3 routes. 

 

Route 1 logic:    0<= Random Variable NEW < 45

Route 1 logic:    45<= Random Variable NEW < 90

Route 1 logic:    90<= Random Variable NEW < 100

 

But then at times Random Variable hits 100, and the logic falls apart as it only pics values under 100. There is a missing = or a way to hit a max value.

 

Any good ideas as i have a LOT of routes to alter to fix this

Link to post
Share on other sites

Hi Mav,

 

As you can see if the logic is:  ?<= NEW < 100 that means that the right number will NEVER be reached, e.g. 99.99 !

I only use X1 instead of NEW. And it works.

Link to post
Share on other sites

Abraxas is right. The values range from 0.00 to 0.99

It's 100 discrete values so we're not robbing you of a percentage point, we're just start counting from zero.

Don't be ashamed; in programming, "off by one" counting is among the top five errors that programmers make.

Link to post
Share on other sites

Also, using the "new" variable to pick random routes from a waypoint won't work as you might expect as it rolls a fresh "new" random number each time it checks instead of comparing one roll against each condition until it finds one that matches.

Edited by Rotareneg
Link to post
Share on other sites

Thanks guys - changed the stuff now and it works. Not top notch, but enough for "replayability"

Basicaly i just added a very short Route 4 with no conditions in a loopback to the waypoint. In case no conditions are met it picks this one and go for a recheck..... "Drivebycoding" 

Link to post
Share on other sites

as long as the waypoint on which the unit arrives has NO waypoint tactic assigned, the unit will, on arrival, check all routes leading away from this waypoint. It will test all routes with embark conditions first, and if no embark condition is met, take the ("first") unconditioned route.

(...and since you have no way of knowing which of the unconditioned routes is the first one, make sure that there's only ONE unconditioned route and you're golden.)

Link to post
Share on other sites
5 hours ago, Mav said:

Thanks guys - changed the stuff now and it works. Not top notch, but enough for "replayability"

Basicaly i just added a very short Route 4 with no conditions in a loopback to the waypoint. In case no conditions are met it picks this one and go for a recheck..... "Drivebycoding" 

 

As Ssnake said, always make no tactics at the waypoint, and one UNconditioned route, then add other random routes.

 

So you can change your loopback rotue into one of the options you want.

 

12 hours ago, Mav said:

Route 1 logic:    0<= Random Variable NEW < 45

Route 1 logic:    45<= Random Variable NEW < 90

Route 1 logic:    90<= Random Variable NEW < 100

 

NEW is a different NEW value in all those 3 cases!   So, just use 0 < NEW 45 for both route 1 and route 2. (faster to setup too as you can select both routes and add hte embark if just once)

Route 3 can be unconditioned and it will have a 10% chance to be used.

Link to post
Share on other sites

Here is another option:-

 

From a waypoint have 2 routes. One is just a short (say 10m route) which ends in a no tactic waypoint.

 

Short route Logic:- 0<= Random Variable New <90

Longer route no logic.

 

From the end of the short route 2 routes:-

route 1 logic:- 0<= Random Variable NEW < 50

route 2 No logic.

Link to post
Share on other sites

A tree-way fork with 45% likelihood each with variable "New" for two of the routes will result in a 30.25% likelihood that neither of them will be taken. This may be non-intuitive but the chance of the first to not be taken is 55%, same for the second, and .55 x .55 = .3025 which is then the chance for the third (unconditioned) route. It's better to use the same random variable in such a case (X30, say) rather than the independent random variable, or to use the concatenated approach as suggested by DarkAngel.

Link to post
Share on other sites
2 hours ago, Ssnake said:

A tree-way fork with 45% likelihood each with variable "New" for two of the routes will result in a 30.25% likelihood that neither of them will be taken. This may be non-intuitive but the chance of the first to not be taken is 55%, same for the second, and .55 x .55 = .3025 which is then the chance for the third (unconditioned) route. It's better to use the same random variable in such a case (X30, say) rather than the independent random variable, or to use the concatenated approach as suggested by DarkAngel.


You’re right, in this case 68% for the 2 routes would leave approx the 10% on the default route that he wanted in that example.

 

To be exactly equal you would need to concatenate the routes as Dark sugested.

Edited by ben
Link to post
Share on other sites

Well, use 0<X15<45, 45<X15<90, and you get a 45-45-10% distribution as intended. The key is not to use "New" as the random variable unless it's a strictly binary choice.

Link to post
Share on other sites
8 minutes ago, Ssnake said:

Well, use 0<X15<45, 45<X15<90, and you get a 45-45-10% distribution as intended. The key is not to use "New" as the random variable unless it's a strictly binary choice.

 

By the way... Is there any way to know in what order the conditional routes will be evaluated?  Is it based on order of creation?

Link to post
Share on other sites
5 hours ago, ben said:

 

By the way... Is there any way to know in what order the conditional routes will be evaluated?  Is it based on order of creation?

This is why the best way is to only have 1 conditioned and 1 non conditioned route.

Link to post
Share on other sites
6 hours ago, ben said:

Is there any way to know in what order the conditional routes will be evaluated?

No. If you want perfect determinism, use only binary forks in the road. But IMO this is more of a theoretical problem. If two or more conditions are all true at the same time, who's to say that whichever choice the unit made is "wrong"?

I'd be a lot more careful if we were talking about heavily parallelized code with then essentially non-deterministic outcome. But at the end of the day we're talking about tactical decisions of units and if you design the decision problem vague enough that multiple answers are true at the same time, I suppose you could live with whatever answer the unit gives when choosing the path.

If only one condition is true, there is no problem.

If no condition is true, wait (if waypoint tactic is given) until the situation changes, or take the (one) unconditioned route.

Link to post
Share on other sites
2 hours ago, Ssnake said:

No. If you want perfect determinism, use only binary forks in the road. But IMO this is more of a theoretical problem. If two or more conditions are all true at the same time, who's to say that whichever choice the unit made is "wrong"?

I'd be a lot more careful if we were talking about heavily parallelized code with then essentially non-deterministic outcome. But at the end of the day we're talking about tactical decisions of units and if you design the decision problem vague enough that multiple answers are true at the same time, I suppose you could live with whatever answer the unit gives when choosing the path.

If only one condition is true, there is no problem.

If no condition is true, wait (if waypoint tactic is given) until the situation changes, or take the (one) unconditioned route.


Thanks for the full explanation, it makes sense; it is up to the scenario designer to avoid or accept ambiguity of route conditions.
 

I would really appreciate a feature in Steel Beasts where I could add several normal unconditioned routes from a waypoint, and one of them would be chosen with a balanced random choice automatically, for each unit who reaches the waypoint.

 

Im not aware of the technical challenges and side effects, but just a thought, it would be very efficient and intuitive for scenario design.

Link to post
Share on other sites
11 hours ago, ben said:

 

By the way... Is there any way to know in what order the conditional routes will be evaluated?  Is it based on order of creation?

 

I did some testing in editor to answer my question;  it appears that the latest created routes always take precidence.

 

So; conditioned routes are evaluated in order of "youngest" to "oldest".

Link to post
Share on other sites
3 minutes ago, ben said:

 

I did some testing in editor to answer my question;  it appears that the latest created routes always take precidence.

 

So; conditioned routes are evaluated in order of "youngest" to "oldest".

this can go out the window if you paste them.

 

Link to post
Share on other sites
10 hours ago, ben said:

I would really appreciate a feature in Steel Beasts where I could add several normal unconditioned routes from a waypoint, and one of them would be chosen with a balanced random choice automatically, for each unit who reaches the waypoint.

Fair point, currently it requires a few more clicks ... but not THAT many.

Like, you can create prototype "route-lets" outside of the mapped area - say, an unconnected waypoint 1 leading a short leg to WP2, then a fork to WP3/4/5. You mark the routes 2-3, 2-4, and 2-5 and set the embark condition to 0<X30<35. Then you enter the dialog again for JUST route 2-4 and change it to 35<X30<70, and change route 2-5 to 70<X30<100.

 

Later, whenever you want a fork, you right-click route 1-2 and "copy route chain", then paste it to your current waypoint, and you have immediately a three-way split. Create a handful of such "Lego bricks" for oyur scripting and you can use them over and over again. Maybe you do the fancy thing and when you paste the fork, you edit the random variable from X30 to X29, X31, ... so that the random choices aren't all dependent on the same variable.

Link to post
Share on other sites
2 minutes ago, Ssnake said:

Fair point, currently it requires a few more clicks ... but not THAT many.

Like, you can create prototype "route-lets" outside of the mapped area - say, an unconnected waypoint 1 leading a short leg to WP2, then a fork to WP3/4/5. You mark the routes 2-3, 2-4, and 2-5 and set the embark condition to 0<X30<35. Then you enter the dialog again for JUST route 2-4 and change it to 35<X30<70, and change route 2-5 to 70<X30<100.

 

Later, whenever you want a fork, you right-click route 1-2 and "copy route chain", then paste it to your current waypoint, and you have immediately a three-way split. Create a handful of such "Lego bricks" for oyur scripting and you can use them over and over again. Maybe you do the fancy thing and when you paste the fork, you edit the random variable from X30 to X29, X31, ... so that the random choices aren't all dependent on the same variable.


Yeah I use the copy paste method a lot now, also in the action phase. Very useful 👍

 

The thing that takes time and is error prone is to re-balance the values if I change from a 2 way to a 3 or 4 way choice later, especially if I cant remember how I initially set it up!

Link to post
Share on other sites

Well, for that you create prototypes with two, three, four, and five splits (anything beyond that is IMO just inviting error and confusion). Just like you have 2x2 Legos, 3x2, 4x2, etc.

 

Heck, I'd consider createing an empty scenario (no map) just with prototype routes, possibly beefed up with map graphics to denote which route-lets are for what purpose, then save it as "My default scenario.sce" that you open whenever you start a new project. Then you save it under the new project name, pick the map, place the units etc. so you'll always have the needed building blocks ready.

Link to post
Share on other sites
12 minutes ago, Ssnake said:

... set the embark condition to 0<X30<35.

The reason I chose X30 in this example is because it requires the most clicks to get there (left click increases the variable count, right-click decreases, shift modified the increase by 5 or 10, I no longer remember. So in your everyday scripting you will probably use X1 and X63 the most simply because they are no / one click away from the default setting. And if you're smart you'll try to be efficient and use as few clicks as possible, so the variables requiring the fewest mouse clicks will dominate regular random decisions. So, route-lets should probably give preferential use the the "hard to reach" number space since you can then, on later editing, still use the one left/right-click method to pick a different variable with minimal effort.

Link to post
Share on other sites

I understand, just it’s time consuming.

 

The reason I’m interested in some intuitive easy features is it takes me several tens of hours to make a decent scenario without too many bugs.

 

Any time saving tricks like that would allow me to create more scenarios in my given time, that’s all 😀

Link to post
Share on other sites

I just told you a great time-saving trick. Takes some prep time to set up, but afterwards will save you lots and lots of mouse clicks and error searching.

Link to post
Share on other sites
8 hours ago, Ssnake said:

Fair point, currently it requires a few more clicks ... but not THAT many.

Like, you can create prototype "route-lets" outside of the mapped area - say, an unconnected waypoint 1 leading a short leg to WP2, then a fork to WP3/4/5. You mark the routes 2-3, 2-4, and 2-5 and set the embark condition to 0<X30<35. Then you enter the dialog again for JUST route 2-4 and change it to 35<X30<70, and change route 2-5 to 70<X30<100.

 

Later, whenever you want a fork, you right-click route 1-2 and "copy route chain", then paste it to your current waypoint, and you have immediately a three-way split. Create a handful of such "Lego bricks" for oyur scripting and you can use them over and over again. Maybe you do the fancy thing and when you paste the fork, you edit the random variable from X30 to X29, X31, ... so that the random choices aren't all dependent on the same variable.

 

Brilliant as ever Ssnake....!!!!

Link to post
Share on other sites

I should emphasize one more time that if multiple conditions are true at the same time, you have no way of knowing which one a unit will take. This is a bit of a controversial topic in the team right now. I don't think it's a big problem (but I acknowledge that it is a problem - one that we have since Steel Beasts 0.8something (=forever) and apparently it was never raised as a big issue in 20+ years).

 

If you want to be able to predict with certaincy what will happen at every route fork, make sure to use conditions that are mutually exclusive - or learn to accept that in such a case one route (you won't know which one) might receive preferential treatment (which we might amend with a cointoss of last resort at the code level in a future update).

[I'm hesitant to throw developers at the problem because if the "fix" fucks this up, it fucks up pretty much every scenario there is, possibly in a subtle way that could conceal the new problem for a good while until unfucking the problem becomes problematic of its own.]

 

Also, my official recommendation is to avoid using the random variable New in anything but binary forks. Since New gets re-rolled for every possible route there is no dependency between routes, so the embark/jump condition could always be false or multiple routes could be true simultaneously. Both isn't good, but I maintain the position that it'd be entirely your fault. If you want predictability in your randomization, use random variables X1...X63; use New only when there's a choice to be made between a single random condition and a route without embark/jump condition at all.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...