search

Patashu / Baba-Is-You-Patashu-s-Mods

A mod for Baba Is You that adds new rules.
3 stars 0 forks source link

Faster hash function for MAYBE desired (updated) #1

Closed Patashu closed 5 years ago

Patashu commented 5 years ago

nothing in vanilla needs to supply x, y to prefix conditions for empty, so they're nil, but MAYBE needs them, so it throws an error.

Patashu commented 5 years ago

it's also really laggy. if the lag is because it's redundantly rerolling the same RNG over and over, we can have a global table of seeds -> random() results, and change saccade to use that random() result, so it's as cached as possible. if it's for some other algorithmic reason, investigation will be required.

Patashu commented 5 years ago

Another possible performance improvement: using generaldata.strings[CURRLEVEL] to retrieve the current level's string

Patashu commented 5 years ago

Another thing that would be nice for MAYBE to have is to have independent probabilities for each rule affecting the same name/x/y/turn. We could have the entire rule text be part of the seed - if it is accessible to us. And if it is, what other distinguishing quality could be? (We can't just count how many times a particular seed has been used this turn, because it might be the same rule checking multiple times that turn.)

Patashu commented 5 years ago

cg5 has a great idea:

4:38 PM] cg5: For THOSE I modified conditions to include the ID of the condition word so that testcond knows it. You could add the coords of the MAYBE to the seed. This also has the (desirable?) property that if you use the same MAYBE vertically and horizontally then those two MAYBEs are correlated. [4:38 PM] Patashu: huh... that's an interesting side effect lmao. I might actually want that. the side effect has a side effect that if you push the MAYBE around then you get different results but that might be an okay tradeoff 4:40 PM] cg5: The alternative is matching the entire text of the rule? So if you have MAYBE KEKE IS MOVE and somewhere further down MAYBE KEKE IS MOVE again, then those two MAYBEs are correlated and Keke either moves 0 times or twice.

->

[4:47 PM] not baba: first ones def cooler [4:54 PM] Patashu: yeah I like it a lot actually [4:54 PM] Patashu: because like, it's not even limited to 2 rules [4:54 PM] Patashu: (thanks to stacking) [4:54 PM] Patashu: so it would let you correlate as many rules as you like, and conversely you can have the same rule many times uncorrelated

Patashu commented 5 years ago

What I need to do is have information about the MAYBE (or RARELY etc) condition in testcond. I can do this by storing its unitid rules.lua in conds array, because that information is already passed around then I'm guaranteed to receive it. It'll be a 'hack' in the sense that it's not generic, but it will be more than enough for my purposes.

https://www.diffchecker.com/8elPs3LN This is cg5's diff to do something similar. Ignore the state machine changes as they're unrelated. Add this to my shelf, confirm that the unitid is for the maybe or whatever, then I can make it part of the seed.

Patashu commented 5 years ago

Status update:

1) We now have reason/reason_x/reason_y in the seed! So we can have correlated and uncorrelated RNGs. 2) Caching is in! 3) Sadly it's still kind of slow (1.5 seconds to paint a map's EMPTY with 5 rules). I would like to find a faster way of generating seeds for math.randomseed than CRC32, but since lua lacks bitwise arithmetic out of the box most fast hash functions (like https://github.com/szensk/luaxxhash/blob/master/luaxxhash.lua ) require access to libraries that I can't add (I think) to Baba Is You. So I am not sure what to try.

Patashu commented 5 years ago

random thoughts: we distinguish units by name, x and y but if there's multiple on the same tile they'll all experience the same RNG. do we want this, or should we further distinguish both the MAYBE and the unit by its index in its tile map? I am not sure. alternatively, we could use unit id instead of name/x/y (the initial reason I did this is because it wasn't stable under restarts, but that's fine if we're doing away with determinism between restarts) - but I'm not certain this is deterministic over undoing/redoing creating objects.

Patashu commented 5 years ago

Since we're caching anyway, here's a way to get even faster RNG - just don't use randomseed at all! call random() once, declare that to be the cached number, and move on with your life. We only need randomseed if we need deterministic results between different playthroughs - that is, we're using the level name as part of the seed - so we can leave that extra functionality alone unless we actually want it.