Ticket to be used to hold the template dumps from the "legs" console command.

[wzdev-ci]

resolution_fixed type_patch (an actual patch, not a request for one) | by Buginator

---

If you run into "legs" in your multiplayer battles then enter legs into the console. (hit enter, type legs then hit enter again)

It will generate a few files for us to investigate what is going on.
The files will be in your config directory under logs/ and they will follow the following format:

template_0X-Sk-Rush_190850.txt <--- player X (where X is player number), map name, and time, for each human player. On a 8p map, with 8 people playing, you will have 8 files.

The other file will be of the format:
templateAI-Sk-Rush_190850.txt <---- AI template, map name, time.

---

Issue migrated from trac:1687 at 2022-04-15 21:13:25 -0700

[wzdev-ci]

Buginator commented

---

(In [10313]) Add template dumping code.

New console command, "legs"
When person enters this, it will recreate the csv files from the structures that the player(s) currently have, (1 file for each human player) and the AI list.

The file is created in your config logs/ directory.

refs #1686
refs #1687

[wzdev-ci]

Cyp uploaded file legs.txt (27.7 KiB)

Crash on sprintf(templateName, "%s", templatelist->pName);

[wzdev-ci]

Cyp commented

---

Above crashdump was tags/2.3_beta11a + commit [10313] + commit [10314].

Orange was just legs, hadn't seen cyborgs from other players. Assuming the players were in default position and colour, it's orange that caused the crash.

First game since starting program, so probably not a resetting-stuff issue.

logs/template_00-Sk-bagdad8-T1_232236.txt is 2617 bytes.
logs/template_01-Sk-bagdad8-T1_232236.txt is 0 bytes.
No other files generated.

(Will attach _00, but probably doesn't show anything useful.)

[wzdev-ci]

Cyp uploaded file template_00-Sk-bagdad8-T1_232236.txt (2.6 KiB)

Templates from a player that probably had normal cyborgs.

[wzdev-ci]

Buginator commented

---

(In [10334]) Fix crash in "legs" routine. sprintf() doesn't handle NULLs very well in non windows version it seems.

refs #1687

[wzdev-ci]

Cyp commented

---

Hmmm...

#include <cstdio>

int main()
{
    char test[100];
    std::sprintf(test, "%s %s!\n", "sprintf", NULL);
    std::printf("Hello world! %s and %s\n", NULL, test);
}

prints “Hello world! (null) and sprintf (null)!” on my linux machine. Without crashing.

[wzdev-ci]

Cyp commented

---

Steps to reproduce:

Use a profile build, or at least disable asserts.

Client A hosts Sk-Rush. (Does not click ready.)
Client B connects, moves from position 1 to position 3 and clicks ready.
Client C connects (lands in position 2) and clicks ready.
Client D connects (lands in position 1) and clicks ready.
Client B disconnects, and then closes the client.
Client A removes the AI from position 1 (and wonders why position 3 is completely missing), sets the bases to Advanced Bases (so that it's possible to build cyborgs), and clicks ready.

Game starts.

Client A controls bases in positions 0 and 3.
Client B is drinking a cup of tea.
Client C controls the base in position 2.
Client D controls no bases, and is soon told that it lost the game, and quits in frustration.

Client A seems to have normal cyborgs, and sees Client C's cyborgs normally, but types "legs" anyway, just for fun. All dumped human templates are completely identical to template_00-Sk-bagdad8-T1_232236.txt.
Client C wonders why it seems to have only legs, and types "legs". All dumped human templates are completely identical to template_00-Sk-bagdad8-T1_232236.txt.

Client A and C don't actually play, and are therefore destroyed a while later by the disabled AI in position 1.

I'm guessing the previous crash on "legs" earlier was "just" random corruption.

The steps to reproduce involve clients being in nonsensical positions. I don't know if there's a way to reproduce without that (but if there isn't, then I already fixed the bug...).

[wzdev-ci]

Buginator commented

---

Replying to Warzone2100/old-trac-import#1687 (comment:4):

Hmmm...

#include <cstdio>

int main()
{
    char test[100];
    std::sprintf(test, "%s %s!\n", "sprintf", NULL);
    std::printf("Hello world! %s and %s\n", NULL, test);
}

prints “Hello world! (null) and sprintf (null)!” on my linux machine. Without crashing.

ermm... that isn't the same thing.

// gcc -g test2.c -o test2 
#include <stdio.h>

int main()
{
    char test[100];
    sprintf(test, "%s", NULL);
    printf("Hello world! %s and %s\n", NULL, test);
}

will crash every time I tried it.

// g++ -g test3.cpp -o test3
#include <cstdio>

int main()
{
    char test[100];
    std::sprintf(test, "%s", NULL);
    std::printf("Hello world! %s and %s\n", NULL, test);
}

will NOT crash, it does (null) correctly.

[wzdev-ci]

Buginator commented

---

Anyway, for the "legs" bug, (big thanks for the info on how to reproduce!), what happens is, we don't load the stats for the weapons. It looks like, when a player leaves the lobby, something gets reset that shouldn't.

player 0 is host.
player 1 dropped, then AI disabled.
player 2 is client.
player 3 was disabled

### this is host
info    |10:00:54: [loadDroidTemplates] player 0
info    |10:00:54: [addTemplateToList] psTempl 3867e48, id 325, storeCount:0, asWeaps0(0), asweaps:3867f84

### this is us
info    |10:00:54: [loadDroidTemplates] player 2
info    |10:00:54: [addTemplateToList] psTempl 38681e0, id 325, storeCount:0, asWeaps0(0), asweaps:386831c

### this is AI
info    |10:00:54: [addTemplateToList] psTempl 3868498, id 325, storeCount:0, asWeaps0(0), asweaps:38685d4

### the host's templates are getting loaded with the data
info    |10:00:54: [getTemplateFromUniqueName] I am 2 we are using 0 [is human is 1], template: 3867e48
info    |10:00:54: [loadDroidWeapons] pTemplate 3867e48, id 325, storeCount:0, asWeaps75(4b), asweaps:3867f84

### the AI's templates are getting loaded with data
info    |10:00:54: [getTemplateFromUniqueName] I am 2 we are using 1 [is human is 0], template: 3868498
info    |10:00:54: [loadDroidWeapons] pTemplate 3868498, id 325, storeCount:0, asWeaps75(4b), asweaps:38685d4

=== we are using our template list (which is 100% correct, but the data didn't load (loadDroidWeapons(), so asWeaps[0] is NULL, and since that is NULL, it will *NOT* show the other parts of the droid.===

info    |10:01:02: [fillTemplateList] I am 2 we are using 2 for factory list
info    |10:01:02: [droidSetBits] psTempl 38681e0, id 325, storeCount:0, asWeaps0(0), asweaps:386831c

loadDroidWeapons() should be called for every player, and it is doing that for player 0 (host), the AI, but 'not for player 2, which is us. (38681e0)

Why isn't it loading it for player 2 (us)? Dunno yet, didn't have time to find out, but I am inputting what is going on here, so perhaps someone else can fix it before I get back. :)

[wzdev-ci]

Per uploaded file fixlegs.diff (0.9 KiB)

Could this be the solution to the problem?

[wzdev-ci]

Cyp changed type from to-do to patch

[wzdev-ci]

Cyp commented

---

After applying fixlegs.diff, but forgetting to compile:

             _L
  /\         /\ <-- Repair cyborg.
         /\
/\
     /\       /\ <-- Regular cyborg.

After applying fixlegs.diff and compiling:

  _L         _L
  /\     _L  /\ <-- Repair cyborg.
_L       /\
/\   _L       _L
     /\       /\ <-- Regular cyborg.

I think that's a good sign.

[wzdev-ci]

Per commented

---

(In [10351]) Make sure all templates get all weapons. This hopefully fixes #1687 ie the cyborg leg issue.

[wzdev-ci]

Per changed status from new to closed

[wzdev-ci]

Per set resolution to fixed