Blueprint Sandboxes


Temporary Editor-lite permissions in Lab-like environments for designing and experimenting.

Content
17 days ago
1.1
37.6K
Blueprints

b [WIP] Unusable entities if player has changed force

3 months ago
(updated 3 months ago)

I think I've found a bug: Suppose a player has entered and returned from a sandbox, then switched to another force. When the player enters the sandbox again, all entities that already exist on that surface will still belong to the old force created for the player. These entities can only be used once the player has changed back to the original force.

How to reproduce:

  • Start a new game.
  • Run /c p = game.player; orig_force = p.force; game.print(orig_force.name)
  • Enter the sandbox.
  • Hover the cursor over the electric pole that was automatically created, then run /c game.print(p.selected.force.name).
  • Note that player force and electric-pole force are the same.
  • Leave the sandbox.
  • Change forces using /c p.force = "enemy"
  • Enter the sandbox again.
  • Run /c game.print(p.force.name)
  • Hover the cursor over the electric pole and run /c game.print(p.selected.force.name)
  • Note that player and electric pole belong to different forces.

I think you should listen to defines.events.on_player_changed_force and change the force of all entities found on the player's surface (if it exists) unless the player's force was changed by your own mod. This may take a while if there are many entities, but players don't change their force too often, so I guess the impact on performance is mostly negligible.

Nevertheless: I wish you a happy new year! :-)

3 months ago

Happy new year! Indeed this is a "bug" in that I have left a to-do by simply printing to the player "Your Force changed, so you might have to Reset your Lab." In the situation you described, it would certainly be a better UX to update the force of every entity in their own lab. I didn't do that for two reasons: to see if it was "good enough" (i.e. that this post would not appear) and to avoid potential complications with other mods that alter forces.

On that last point, I'm not sure if the complications are actually bad, or just "more often force changes." Right now, it requires a manual reset (you could copy everything beforehand to prevent loss), and with an automatic "refresh" I think that worst-case it might only be the old manual reset anyway. I'll attempt this!

3 months ago

OK, I've pushed an update that should address this. Let me know how it goes for you!

3 months ago

Thank you, this seems to work! The force of entities was even updated when I changed to another force while I was in a sandbox.

A minor thing: I inspected your mod's data with gvv and noticed that you keep data of forces after the last player has changed to another force. That shouldn't do any actual damage, but will bloat saved games with obsolete data, so cleaning up may still be a good idea.

In Autodrive and GCKI, I've added support for BPS by turning off GUI and shortcuts of players who change to one of your forces. As players are expected to return from the sandbox, the change is only temporarily, so I add the player to global.force_data[old_force_name].suspended_players.

When there is no player left at the old force, I disable the handlers for GUI and shortcut events unless next(force.connected_players) is true for any of the other forces stored in global.force_data. I also remove the force_data stored for forces where both not next(force.players) and not (force_data.suspended_players and next(force_data.suspended_players)) are true. The force data will be rebuilt when needed, i.e. if a player joins the game or changes to another force.

3 months ago

That's certainly another good idea that for me has simply fallen into the category of "good enough." The same applies to surfaces (if you were meaning specifically the global data) which probably incur more costs than just data size. Since the "cleanup" actions involve destroying things, I am also weary about then "accidentally" destroying things in the cases of bugs of mod conflicts. All that said, I can do some poking/debugging for some easy wins!

New response