[4.4.2] Weapon slots initialized late with a mod

[m8f]

For some mods, weapon information is loaded after one tick in the game.

Steps to reproduce:
1. Download LILA-DOOM
2. Start the game with the following command line parameters:

Code: Select all

gzdoom -file LILA-DOOM.pk3 +map map01 +"wait 1; give all"

Expected result: all mod weapons are given by "give all" cheat. Printinv command outputs 50 entries.
Actual result: vanilla weapons are given. Printinv command outputs 43 entries.

Notes:
1. The expected result can be achieved by launching the game with the following command:

Code: Select all

gzdoom -file LILA-DOOM.pk3 +map map01 +"wait 2; give all"

(note wait 2)

2. The mod in question uses setslot command in keyconf, which is deprecated.

I'm not sure if this is a bug or just an engine quirk, in any case chances of encountering this bit of behavior in real situation are slim. One of my mods, however, attempted to get weapon slot information at the game start, and discovered wrong data. The workaround is to load weapon slot data when level.time == 1 instead of inside playerEntered event.

[Major Cooke]

What would one of your mods be? Debugging LILA-DOOM is going to be rough because it has wads inside zips which can cause side effects, since it may throw memory management out the window.

I ask for this because I have a weapon slot initialization system of my own. But then again I never start a map and immediately have all weapons given, yet this always executes flawlessly and has everything set up and ready to go the moment its all booted up without waiting.

[m8f]

My mod in question is new Weapon Menu version which is not released yet.

And to clear things up: the problem lies in WeaponSlots.LocateWeapon giving wrong information, and "give all" cheat behavior just allows to see this.

[Graf Zahl]

Still using KEYCONF? It has been deprecated for years because it doesn't work right. There's one important thing about it - it sends its changes across the network, and that's where your delay comes from.