[Request] Ability to stop SimpleEntities from picking a random variation on build

[Deadlock989]

SimpleEntityWithOwner and SimpleEntityWithForce (and I'm assuming SimpleEntity as well) can have pictures or animations defined which are a stack of variations that are accessible to runtime scripting. This is extremely Nice To Have.

When a player selects an item from their inventory that builds a SEWO, the green/red tinted entity floating with their cursor is always variation index 1. When the entity is placed, however, the game suddenly picks randomly out of the pile of variations available.

This is not the case when the very same entities are revived from a ghost. If you ghost-build using an item from your inventory, the ghost entity always has variation 1 and the bots will always build variation 1. If the ghost came from a blueprint with some other pre-set variation, the bot faithfully builds that variation. The same is true if a player revives a ghost.

It's just players building them within reach that behaves completely randomly for some reason.

Scripting this away is surprisingly difficult. You'd think you could just listen for the 5 types of entity build event and set the graphics variation to 1 or to whatever you need it to be. But because you don't want to screw up ghost and blueprint building, and there aren't any/many good ways for you to detect whether that is what's happening, you always end up breaking something else.

Request: a flag in the SimpleEntity prototype and both of its inheritors, something along the lines of don't_pick_random_variations_out_of_a_hat_on_free_build or whatever a better name for it is. This would default to false for backwards compatibility.

It's even been suggested to me that this is a bug - but from memory, it's been this way forever - Earendel's Text Plates use SEWFs and you've always gotten random lettering if you spam them without using the provided gui.

[Deadlock989]

I came up with the following workaround, avert your eyes now:

- Leave robot build events alone completely, they work fine
- Use on_put_item and player.cursor_stack to detect whether one of your entities of interest is about to be built
- If there's a matching ghost in that location, abort, because it'll be revived as the right variation for that ghost and that's what you want
- If there isn't a matching ghost in that location, spawn one in the same place
- This tricks the build into reviving the ghost with variation 1 instead of picking one at random.

You can't do it in on_built_entity because there's no good way of knowing whether the player is reviving a ghost or not, and you can't just set the graphics variation directly in on_put_item because the entity doesn't exist yet. Short of passing a ton of messages around between events using global, this is the best workaround I could find.

[eradicator]

+1 Would use it if it existed.

So far the only entity i had this problem with is supposed to always revert to variation1 when constructed, so for me it works fine with on_built_entity.

[slippycheeze]

I'd personally think the reverse of this was the correct behaviour: if they are just visual variations, no functional changes, then they should select randomly *every* time they are created, not just in some cases.

Is there a specific reason why you want multiple animations, but only to use one? I assume it is some sort of desire to use the additional animations when some sort of internal state of the device that lives only in your mod changes, right?

Would that also be achievable if you simple set the desired (first) animation from your mod, if they were always randomly selected on build regardless of source?

[Bilka]

Okay, added random_variation_on_create bool to all simple entities.

[Deadlock989]

Nice one. Cheque's in the post.