Closed boot2big closed 6 months ago
To clarify: This variable's intended behavior is to be 0 on one tick, then 1 on the next. That's it. I could not think of a much better way to do it besides tying it to the variables behind tick
, but doing that made the variable always 0 whenever a vehicle first spawned which made one of the intended usages of this variable completely useless.
what would be possible with this variable? like what demonic uses do you think of?
Is there a reason you can't just use the random variable? I'm confused here...
For one it's separate between the server and each client (which granted, this one might still be actually?) so that prolly don't work too well with CDP. Second is that, well, it's a granular variable. It spends most of its time not being a solid 0 or 1, instead basically being a zero-point with a bajillion different decimals, which means it doesn't work too well with something expecting... a 0 or 1. Ergo this variable essentially gives you a coin-flip variable that's active one tick, then inactive the next; a coinflip variable.
Ah, given this, is there a reason you'd need it to be the same on servers and clients? If this is for choosing default parts, then you don't need to worry about client-server differences. All parts are added on the server, and these parts are then sent to the client in packets. So you only need to have the random be on the server. If you are using this variable for the default part choices, you don't need to tie it to the tick time. You can just use a Math.random() >= 0.5 and that should do it. Though it might be Math.random > 0.5. I can't remember if the random goes from 0 inclusive to 1 exclusive, or 0 exclusive to 1 inclusive.
Hmm.. noted! I'll have to mess with it later, but I'll see if I can use that instead; regardless of which one it does I'll be happy enough to have a 50/50 chance variable.
One smaaaaall catch is that this doesn't seem to be exclamation-invertible, which is simply means one can use "defaultPart" for the inverse operation instead, for when they don't get lucky with the lucky box.
Huta what nows? I coulda swore that you could use a ! in all those areas?
You can yeah, just not with this apparently. But again, one can do basically the same thing by using just one CDP with this variable, while having a regular defaultPart defined as well. Or you don't get a part if no non-conditional DP is defined.
Looking at the variable, I think what you want is return Math.random() < 0.5 ? 0 : 1;
? That way you'll get a 1 if the random variable is greater than or equal to 0.5, and 0 otherwise. And since the random function goes from 0 inclusive to 1 exclusive, that should work? This way you don't need to do a multiply or a floor operation, just check for size.
... Neeeegh! That seems a lot simpler. Lemme test that out and re-commit that soon.
Make sure to update the wiki!
Unfortunately means this variable freezes up when the
doDaylightCycle
gamerule is set to false, but I'd generally assume that shouldn't be an issue as the worst case scenario involves getting the same result each time.Useful for defining a random chance between one set of conditionalDefaultParts or the other. Examples: setting a normal defaultPart along with one CDP to switch between the two, or not having a DP defined for a 50/50 chance of getting that part or not.