ZDCMP2: Happy Doomsday Edition (RC2)

[edward850]

So here we need two fixes: the first is that showMessage needs a way to check if its activator is the local player or not

I can tell you already that you can't do that. "Local player" is not a thing to the playsim.

[Xaser]

I was never fully happy with that bit, since yeah, there's a lot of redundancy in the calls because of multiplayer future-proofing (and the fact I was in a rush when writing that ). A reliable way to get the current number of players would help in pretty much all cases.

Question on the internals: If Players 1-4 start a game, then Player 3 drops out, does Player 4's PlayerNumber() drop to 2 or remain at 3*?

[*For the confused, PlayerNumber() starts at zero, hence the seeming off-by-one here.]

[edward850]

The player count will drop, however the "order" stays the same. You are forever the player you start as. (Saved games seem to mess with that rule, but that's more of a bug.)
It is technically possible to be player 7 in a single player game, and ZDoom wouldn't give a damn.

In terms of code, the fastest, and most future proof way to iterate through the player count is:

Code: Select all • Expand view

int pcount = PlayerCount();
int atcount = 0;
for (int pnum = 0; atcount < pcount; pnum++)
{    // pnum is the physical player number, always increments for each player
    if(!PlayerInGame(pnum))
        continue;

    DoStuff(pnum);
    
    atcount++; // atcount only increments when the player is in the game
}

Automatically supports any player count, in any position.

Sidebar: One of my back burner ideas for expanding the player count is a way for ZDoom itself to quickly and efficiently iterate through each active player, without wasting time on dead slots. Depending on how I do that, this could be extended as a "NextPlayer" pointer in SetActivator (with the last player always being next to NULL). This is purely theory, however.

More sidebar:

I was never fully happy with that bit, since yeah, there's a lot of redundancy in the calls because of multiplayer future-proofing (and the fact I was in a rush when writing that ).

Just to note, determinism sanity aside, in its current state the playsim should be able to run effectively headless (i.e with no physical consoleplayer at all). It would be nice to keep things that way.

[zuzma]

Nice read, thanks for pointing out the real problem gez. Since I'm such a lazy ass I just set #define MAX_PLAYERS to 1. Doubtful I'd be playing it with anyone else. Really awesome map by the way. This is right up there with action doom in terms of being enjoyable to me. Some of the secrets are down right hilarious too

[Xaser]

@edward850: thanks there! I'll have to give the code a rewrite soon, since that solves it -- the real key is I had no idea PlayerInGame was a thing, so "just" the insertion of that in the code should eliminate the slowdown problem; the atcount bit will eliminate all the needless post-iterations too, so that helps a slight bit as well.

[Gez]

You can also use a GameType check to eliminate the loop entirely. So maybe in coop each datapad message will be spammed multiple times to the console log, but in single player it would no longer happen.

[edward850]

Well that would be pointless for two reasons:

• The for loop will already only count and run a single player in the first place, and thus only run the messages for a single player. Hence the point of pcount/atcount.
• Non-global messages are only logged by the instance that actually owns them.

[Gez]

Non-global messages are only logged by the instance that actually owns them.

I guess nobody got 64 messages per data pad in their console log while in single player then.

[edward850]

I sometimes wonder if you think I'm lying or something.
Take note of p_acs.cpp#L7739, which continues onto the logging in the same block, at p_acs.cpp#L7810. Non-global messages are only logged by the instance that actually owns them.

Xaser-minder: Toss me the message code when you have done editing it, and I'll sort out why the message ownership has gone bad. To note, it suggests that what's actually going on is you're printing all 64 messages to every player.

[Xaser]

Holy megabump, [SUPERHERO_NAME]!

Since some recent ini-related shenanigans were mentioned, I decided to crack the project open again and make some fixes. The ini-pollution is fixed now, as well as the 64-messages-in-singleplayer stuff mentioned in this thread (way-belated thanks to Edward850; that efficient player-iteration loop was just what the doctor ordered). Better hella-late than hella-never.

Here's a link to the patch: https://static.angryscience.net/pub/doo ... -08-20.pk3 -- load this over the top of zdcmp2.pk3 for now and you'll get the fixed ACS and KEYCONF/MENUDEF.

I suppose I should coordinate with Torm (or Gez? Whoever can canonically make stuff official) to plan a reupload at some point, but not juust yet. In case there's any other glaring-but-easily-fixable stuff still on the docket. Speaking of, are there any other outstanding issues/complains that anyone knows of? The old bugtracker subforum on R667 is gone, unfortunately.

[Gez]

Man this thread is four years old now.

[Princess Viscra Maelstrom]

hah, what a coincidence. i just so happened to be playing this earlier tonight, and found out that accessing the data logs just crashed the game. i'll be restarting the game with this fix then.

edit: actually, it still crashes the game when i open it on the latest stable GZDoom.

[Xaser]

Huh, sure enough -- same happens here. The latest GZDoom dev-builds and QZDoom 2.0.0 work fine, though, so hopefully the problem has already been fixed.

The objective/log displays are just Strife popups, anyway -- no funny business that i can see.

[Graf Zahl]

Thank you very much for taking care of this issue.

[Xaser]

You're welcome -- hopefully the situation is less of a headache now.

I'll try and give the wad another playthrough soon to check if there are any other rough spots, but I don't plan on making any tweaks unless something is outright broken. I did get one report that performance during the escape scene is rubbish, so I'll at least try and take a look at that.