Unify controller type access.

[eradicator]

What?
Free mod(der)s of the burden of having to care too much about controller types for standard tasks.

Details
With the advent of defines.controllers.editor(?) in 0.17 and the possibility for any player to switch at a moments notice, i was wondering what this implies for mods. Does an editor still have an inventory? A character? Character bonusses? How many additional checks do i have to add just to not cause an error the second a player switches to being an editor?

Most mods are already written for freeplay, and it is quite easy to create bugs when missing some speciality of the god controller. The most common examples are probably character_x_y_bonus, which will instantly error. Other things like god.get_inventory(defines.inventory.player_quickbar) fail more subtly, as you still get an inventory back, just not the right one. The lack of character_x_y_bonus on the god controller also means that many mods simply can not work at all when force-wide bonuses would be inappropriate.

I know freeplay is the "recommended" mode of play, but i'd still like my mods to work in all modes without needing 4-way case-switches everywhere.

[Bilka]

How do you want this to be implemented?

[eradicator]

(Most important bits bold, sorry for wall of text.)

I don't have any strong opinion about the "how", but i have some ideas. I'd also be happy and grateful if at least some of these things were changed, even if some others are too difficult.

_____
for get_inventory() it would be nice if the differences between controllers simply vanished i.e. all controllers use player_main, player_quickbar, etc.

• defines.inventory.player_quickbar → same for every controller
• defines.inventory.player_main → same for every controller
• defines.inventory.player_vehicle → same for every controller (gods can already use vehicles but this returns nil in that case)
• defines.inventory.player_guns → inventory of size zero (like player_trash already does before it is researched)
• defines.inventory.player_ammo → inventory of size zero
• defines.inventory.player_armor → inventory of size zero
• defines.inventory.player_trash → inventory of size zero
• defines.inventory.player_tools
• defines.inventory.god_quickbar → removed because obsolete (or could simply return the same number as player_quickbar for backwards compatibility)
• defines.inventory.god_main → (see god_quickbar)

So what about inventories that a controller doesn't have? Why not nil? Becaues nil is an unspected outcome to the "naive" mod. A defines.controllers.character always has _ammo,_armor,_trash inventories. Whereas calling .insert('something') onto a size 0 inventory fails gracefully - the same way as if the inventory was non-zero but already full. It would also prevent bugs when a mod has bad timing and tries to access a player while they're waiting for respawn (i.e. when they're controller.ghost).

_____
for ghost controllers player.cursor_stack currently returns nil. i.e. even trying valid_for_read is an error. i'd suggest a dummy LuaItemStack that can be interacted with normally, but that's never used anywhere and is deleted when the player changes controller type (i.e. respawns).

_____
character_x_y_bonus. This is a bit difficult. I prefer Solution D, but i'll leave the others here.

Solution A)
Make them actually work. Gods with double quickbars and extra inventory without applying the bonus to the whole force would be nice. _distance_ type values would simply be very large.(replaced by Solution D)

Solution B)
Move character related values to the characters LuaEntity instead of keeping them on the LuaPlayer. These values are already volatile, and die with the character, etc. It'd be a simple matter of s/character_build_distance_bonus/character.build_distance_bonus/ to upgrade any mod. And checking for a character is an easy straight forward single point of failure.

Solution C)
Associate an invisible and intangible fake character with every controller. Syntax would stay the same, any changes would simply be lost when changing controller types. God controllers would be able to have capsule-robots follow them (they currently don't). Could be combined with Solution B or not.

Solution D)
Make them work as player_x_y_bonus (actually renaming the variables would be optional). The bonus is no longer bound to an entity, and simply always applied to that individual player. Imho this is what most modders expect it to work like, before they notice it doesn't. RPG type mods wouldn't have to bother guessing the right bonus after death+respawn anymore. Mods that apply a bonus while a player is respawning (ghost) would still get the expected result. Things that are actually character related like health_bonus and logistic_slot etc would simply not do anything while the player has no character, but would be applied as soon as they have one again.

• character_build_distance_bonus
• character_item_drop_distance_bonus
• character_reach_distance_bonus
• character_resource_reach_distance_bonus
• character_item_pickup_distance_bonus
• character_loot_pickup_distance_bonus
• quickbar_count_bonus
• character_inventory_slots_bonus
• character_logistic_slot_count_bonus
• character_trash_slot_count_bonus
• character_maximum_following_robot_count_bonus
• character_health_bonus

[Rseding91]

There's also the spectator controller in 0.17.

Simply put: you'll always have to check what controller type you're interacting with if you want to be correct. That's just how modding in Factorio works: like complaining that you have to care about surfaces when those where introduced.

[eradicator]

There's also the spectator controller in 0.17.

Simply put: you'll always have to check what controller type you're interacting with if you want to be correct. That's just how modding in Factorio works: like complaining that you have to care about surfaces when those where introduced.

Surfaces do not randomly turn to nil. And handling them is well implemented. I don't have to take special care about which surface something is on, i just say this.teleport(that.position,that.surface). But for controllers i can't just say get_inventory(inventory_type,controller_type) i have to do a lengthy case switch if player == god then dothis() elseif player == spectator then dothat() etcpp.. They also frequently change mid-game. Most mod authors are probably not even aware of the problem and will crash in anything but freeplay.

I'm not complaining that i "have to care about controllers", i'm complaining that caring about them is not comfortable enough.

But as this has already been moved to "won't implement" i guess i'll have to write a wrapper around all inventory manegement, and give up hopes of mods ever becoming inheritely sandbox-compatible.

[Rseding91]

There's https://lua-api.factorio.com/latest/Lua ... t_quickbar and https://lua-api.factorio.com/latest/Lua ... _inventory

Also surfaces can turn to nil via delete_surface.

[eradicator]

There's https://lua-api.factorio.com/latest/Lua ... t_quickbar and https://lua-api.factorio.com/latest/Lua ... _inventory

True. Does it return nil for editor/spectator/etc? Still weird with god-steered vehicles. And the documentation should definetly mention that using get_inventory() with a defines value from the wrong controller class won't fail but give you the wrong inventory instead. And it should recommend using the above two functions where applicable. (I.e. it looks like there's no good reason not to use get_main/quickbar() except for legacy code?)

Also surfaces can turn to nil via delete_surface.

I can ask a reference to a surface if it is .valid even after deleting the surface, but i forgot where that argument was supposed to go .

Are .god and .character the only two controller types that have any inventory at all?