Factorio Forums

Hello,

Currently, I believe the only way to change the starting player's inventory is to handle the on_player_created event, and then use methods such as clear_items_inside() and insert() to modify it.

At a basic level this works, but it appears the game or at least the UI will act upon the new equipment before the event fires. The player experiences this by seeing the inventory stacks flash, as if items have been added, even when they are made empty by a mod.

There are other bug possibilities with this approach. If one mod sees the player inventory before a further mod changes it, then it might act upon the inventory in a way that causes problems for the other mod. Given that the event handler ordering is (as far as I know) still alphabetical rather than dependency ordered, it is difficult for mods to coordinate their starting inventory changes to prevent these issues. A good example would be a mod that forcibly remove all things from the player so they have to gather and craft everything. It would not be able to ensure it does its job if any other mod adds starting items. It'd be much cleaner if we could modify the starting items before they are added and act in mod dependency order.

My thinking is, that having a prototype for the starting inventory would solve all these problems. I mean I wouldn't be surprised if it already exists but I couldn't find it? A further benefit, I imagine many modders are more comfortable with data.lua than control.lua, it can be used by designers as well as programmers. The current approach would still be available for mods that really need a programmatic way to manipulate inventory, e.g. different players get different items.

Regards
H8UL

100% agreed. I still remember the time where some other mod did numerical quickbar filling, so it randomly overwrote starting items that happend to be in the quickbar, including the stuff my own mod added. The only way to fix it was adding my own stuff to the main inventory. So adding the ability to add starting items would be awesome.

There's still a problem though. Inexperienced modders often do: i.e. they overwrite a whole table instead of using table.insert() to add parameters. For a shared property like starting_items this would be problematic unless starting_items is implemented as a type of prototype, where all instances are merged on game start. I.e.

How about tutorials and scenarios, where starting inventory must be empty or just another?

Making it a prototype property wouldn't bypass the inventory-changed highlight logic. The logic detects any inventory change and shows the player the slot changed - as intended.

If you want to add things to the players starting inventory you do it just how the freeplay scenario works: on_player_created player.insert(...).

Rseding91 wrote: ↑Sat Oct 27, 2018 3:57 pm If you want to add things to the players starting inventory you do it just how the freeplay scenario works: on_player_created player.insert(...).

It's not quite that trivial.

• When you want to add an item preferably to the quickbar, but to main when quickbar is full, then you have to compensate for different controller types at the very least. (Not every starting item has a "goes-to-quickbar" flag.)
• If you want to add more than one stack you either have to have an extra .insert() for each stack or check back on the actually inserted count. Otherwise you might miss a stack when the quickbar is full after the first stack.
• Bad mods overwrite the quickbar. (Well ok, can't really fix that. But if there was an easy way then hopefully sprouting modders would use that instead of trying to script it.)
• You might want to give items to players even if the mod is added to an old map.
• etcpp.

There's quite a few caveats for such a seamingly simple thing as giving a player starting items.

Rseding91 wrote: ↑Sat Oct 27, 2018 3:57 pm Making it a prototype property wouldn't bypass the inventory-changed highlight logic. The logic detects any inventory change and shows the player the slot changed - as intended.

If you want to add things to the players starting inventory you do it just how the freeplay scenario works: on_player_created player.insert(...).

I don't want to bypass the highlight, I want it to highlight the actual starting equipment. Right now, I have to modify the starting equipment after the fact, so the highlighting gets confused. It highlights what the core game (on behalf of the base mod) adds even though my mod removes it. Whereas if I modify a prototype then the base mod starting equipment never exists.

By comparison: when I modify a recipe in data.lua I don't "change" the recipe during the game. It is on startup, before a game is loaded. The game recipe is what my mod specifies.

I like the highlighting. But I want to say during factorio startup: "this is the starting inventory when you add a player". Said inventory will be highlighted correctly. Nothing bypassed.

I should emphasize I'm working on an overhaul mod, adding is not enough, I need to edit the start. It is not meaningful in my mod to begin with a stone furnace because they literally won't exist. Any total conversion mod is going to need to replace rather than add, and my mod isn't even total conversion.

Put it another way: why is the starting equipment tied to a stone furnace and burner drill in the core game when they aren't even defined until the base mod? Sounds screwy.

H8UL wrote: ↑Sun Oct 28, 2018 11:33 pm Put it another way: why is the starting equipment tied to a stone furnace and burner drill in the core game when they aren't even defined until the base mod? Sounds screwy.

The scenario is included with base mod, not core.

I will add some remote.calls you can make to adjust the inventories given to the player on spawn and respawn,
That should resolve the problem you are having

Makes sense, thanks!