Open Arena Expanded Beta 50

[Gig]

Excuse me Sago, one more thing:
I have just done a few player spawning tests... and there is something strange about "nobots" and "nohumans" keys, which should be spawnpoint-specific keys (not meant for uses diffent than character spawn points, if I understood correctly).

I tried using them on an info_player_deathmatch, and it looks like they are capable of completely crashing the game (not shutting down with "couldn't find a spawn point", but really making the game completely freeze). I did a few tests, and things seems to vary...

A) It looks like the game crashes when it tries tries to make the player/bot spawn there (apparently, no problem for the spectator). It happens even if there is another info_player_deathmatch without any kind of limitation available in the map. So, it may not be at the first spawn, sometimes it may happen at a later spawn.
It almost seems like the spawn procedure does not ignore the spawn point as it should and picks it up anyway, but then it is unable to actually use it and hangs. But these are just my impressions, one should look at the code/debug to be sure what's happening.

B) In a few sceneries I had the impression it just ignored the key and used the spawn point (without crashing) although it should have ignored it^[1].


Notes:
- "nobots" should not be confused with "notbot", which instead is meant for (pick-up-able) items, to make bots not be attracted by them.
- This seems to happen also in both current OAX and 0.8.8, so it has not been introduced when you did the recent 0,0,0 trick to prevent server shutdown, but it is older.
- Tried in the original Q3A game (without bots): problem A) [the worst one!] does not seem to happen there (it always spawns at the "right" info_player_deathmatch, the one without limitations, without crashing). Problem B) seem to happen also there (playing as blue in CTF without the dedicated "blue" spawn points, it always spawns at the deathmatch spawn point which has "nohumans/1", while in theory it should use the other one).
-- So, there may theoretically be some maps made for Q3A which work in Q3A but freeze OpenArena.
- Being a gamecode thing, even if you fix it for OA3 it would still affect older versions of the game, so maybe we should place some advice to avoid using such keys?
- I have tried using them only on info_player_deathmatch, NOT on any other kind of player spawn point.
- I have no info_player_intermission in the test map

[1] Scenery of this test: I do have 1 team_ctf_redplayer, 1 team_ctf_redspawn, 1 info_player_deathmatch (spawnflags 1) without any restriction and 1 info_player_deathmatch (spawnflags 1) with "nohumans/1". In g_gametype 4, as red player I spawn where expected (team_ctf_redplayer first time, then team_ctf_redspawn), while as blue player it ALWAYS spawns at the info_player_deathmatch with "nohumans/1" (while it never uses the one without "nohumans"). Of course, using deatchmatch spawn points in CTF is already a "fallback", however this is still strange.

[sago007]

I have not done anything about 0,0,0 and devmap, it was just an idea.

The inactive warmup in Elimination gives some time for rockets and mines to be cleared. It also just feels better that the next round warmup does not start in the same moment the previous round is won. It gives a "spawned dead" effect.

I am a bit surprised about the nobots and nohumans bug. I knew that the freeze thing could happen (it happened for me in intooa) but I thought the bug had always existed. I created a small workaround to make intooa not freeze.

[sago007]

I am very surprised that you got it working in VQ3 because the original VQ3 source defiantly has the nohumans bug.

It was fixed in ioquake3 2009-11-03: https://github.com/ioquake/ioq3/commit/f5d79ea066c1f742ff8c98dd5d9c484b9db122e3

[Gig]

I have not done anything about 0,0,0 and devmap, it was just an idea.

It sounds like a good idea to me (for both "devmap" and "devspmap", of course).

The inactive warmup in Elimination gives some time for rockets and mines to be cleared. It also just feels better that the next round warmup does not start in the same moment the previous round is won. It gives a "spawned dead" effect.

The "spawned dead" thing is a bug, not a feature, isn't it? IIRC, it affects only half of the players...
WAIT, let me make a couple of tests...

Oh, now I finally got it! You are not telling about the problem which happens in some maps at the very first spawn...
I finally understood what's the difference between between "inactive" warmup and "active" one: during inactive warmup, players who died in the previous round are simply not yet revived! So, if you survived the match, you do not notice differences between inactive and active warmup behavior (unless the gap between the two warmups is enough that you can notice there are no enemies around).... but if you did not survive the previous round, you just continue spectating until the "active" part begins, and this is not a bug. Okay!

I am a bit surprised about the nobots and nohumans bug. I knew that the freeze thing could happen (it happened for me in intooa) but I thought the bug had always existed. I created a small workaround to make intooa not freeze.

I had to do a search to find out what "intooa" was: it is a version of yours of an introduction/tutorial map, right? http://openarena.ws/board/index.php?topic=3999.msg36421#msg36421

I have no idea about the reason why the tutorial maps from Neon Knight (the first one being in this thread, and the one thought for OA3 in this other one) do not freeze. Maybe the presence of one spawn point with "nobots/1" is not alone enough to trigger the bug, but there must be some other thing interacting (e.g. that spawn point being the one the game chooses as "default" one for that gametype? I don't know)? Or maybe the fact that NK also placed other keys ("gametype/single" and "target/target_give1") to that entity somehow prevented the bug from happening? I have no idea.

Also, is your fix meant to only fix the crash (problem "A" in that previous post), or also problem "B" (not fatal, but existing)?

I am very surprised that you got it working in VQ3 because the original VQ3 source defiantly has the nohumans bug.

I really don't know what to think.
Attached, you can find a "testbox" map pk3, so you can try with your own copies of OA, Q3A and ioquake3 if you wish. It's a small box, with some absolutely unrelated things as it's just a box where I do tests.. don't care for them. Just try (re)spawning. Source .map included.
It should be the scenery described in the note "^[1]" of the previous post, so it should be good also to test problem "B" if you wish. However, about problem "A", if you launch the map in g_gametype 0, at first you spawn in the correct place (the deathmatch spawn point on the left -on "north" side in the editor-, which has NOT the "nohumans/1" key), but if you suicide yourself (/kill), the game hangs.

I tried this map in OpenArena, and it CRASHES (at second spawn in ffa) in both 0.8.8 and recent oax. I also tried it with the old "DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/ModCompat/Alternate_Fire]Alternate Fire" Q3A mod, and it does NOT crash there.
Then I tried it in Q3A 1.32c (I haven't tried it with ioquake3): it does NOT crash in baseq3 and does NOT crash in alternate fire mod. My Q3A install is somewhat a mess, but however I don't know how's possible it works there without crashing, if you say Q3A had the bug. Maybe something changed between Q3A and OA and thus the bug happens under different circumstances? I haven't tried NK OA3 tutorial map in Q3A yet...

It was fixed in ioquake3 2009-11-03: https://github.com/ioquake/ioq3/commit/f5d79ea066c1f742ff8c98dd5d9c484b9db122e3

I don't know that to think...
Does ioquake3 also do changes to gamecode, other than engine? How's possible that bugfixes made in ioquake3 have not been ported to OpenArena? Do you think that there may be many more of them?
Are you sure that the bug was there since Q3A and it wasn't introduced by ioquake3 instead, with OpenArena inheriting it from ioquake3? I don't know how a such thing may have happened, but that would explain why my testbox map crashes in OpenArena, but not in Q3A...

[Gig]

Hello Sago, how are you?
Did you discover something about the things we were discussing before, e.g. which are the Q3A/ioq3/OA versions which may freeze if "nobots" and "nohumans" are used in player spawn points?

Also:
- Do you think everything should work fine, with latest nightly builds, or some bugs are still there (IIRC under some of the previous tests, the game did not freeze but those spawn points were used even if in theory they should have been ignored)?
- Also, are those keys working for all kinds of player spawn points or only for some of them?

Different topics:
- I see in this diff that you added a dmflags (4096) to move much faster underwater... I haven't tested it yet, but I see there is also another "new" dmflag (DF_PLAYER_OVERLAY, 2048): what's that?

- I have tested g_respawntime (a 0.8.8 cvar), and I have written about it DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Special_game_options#Respawning_in_waves]on the wiki based on my own tests (DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/index.php?title=Special_game_options&diff=17694&oldid=17679]diff). Could you please confirm I correctly understood its behavior? I tested it all alone, without other players or bots...

[sago007]

Hello Sago, how are you?
Did you discover something about the things we were discussing before, e.g. which are the Q3A/ioq3/OA versions which may freeze if "nobots" and "nohumans" are used in player spawn points?

I think the reason that it worked in VQ3 was due to another bug that canceled it out.

Also:
- Do you think everything should work fine, with latest nightly builds, or some bugs are still there (IIRC under some of the previous tests, the game did not freeze but those spawn points were used even if in theory they should have been ignored)?
- Also, are those keys working for all kinds of player spawn points or only for some of them?

They only work for deathmatch spawnpoints, all freezing should be fixed and it should not allow the engine to use illegal spawnpoints.

Different topics:
- I see in this diff that you added a dmflags (4096) to move much faster underwater... I haven't tested it yet, but I see there is also another "new" dmflag (DF_PLAYER_OVERLAY, 2048): what's that?

DF_PLAYER_OVERLAY does not work. It required shaders that are not included. You may be able to find them in old OAX releases.
The underwater thing does not work that well either. It should allow much faster movement underwater but it only makes it twice as fast as before at the moment.
Both if them are mainly meant to test ideas for mods.

- I have tested g_respawntime (a 0.8.8 cvar), and I have written about it DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Special_game_options#Respawning_in_waves]on the wiki based on my own tests (DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/index.php?title=Special_game_options&diff=17694&oldid=17679]diff). Could you please confirm I correctly understood its behavior? I tested it all alone, without other players or bots...

It is supposed to work like you described it.

[Gig]

They only work for deathmatch spawnpoints, all freezing should be fixed and it should not allow the engine to use illegal spawnpoints.

Are you sure? I have just done a test with oax nightly "2016-10-11", and while it did not crash (good), it still happened that it picked the "wrong" spawn point in that (odd) test of mine described here:

[...]
B) In a few sceneries I had the impression it just ignored the key and used the spawn point (without crashing) although it should have ignored it.
[...]
Scenery of this test: I do have 1 team_ctf_redplayer, 1 team_ctf_redspawn, 1 info_player_deathmatch (spawnflags 1) without any restriction and 1 info_player_deathmatch (spawnflags 1) with "nohumans/1". In g_gametype 4, as red player I spawn where expected (team_ctf_redplayer first time, then team_ctf_redspawn), while as blue player it ALWAYS spawns at the info_player_deathmatch with "nohumans/1" (while it never uses the one without "nohumans"). Of course, using deatchmatch spawn points in CTF is already a "fallback", however this is still strange.

You can simply test it using my "testbox" map I attached to this previous post, joining the blue team in CTF mode: I do still spawn at the info_player_deathmatch which has got "nohumans/1", while I would have expected the other one. I know the one of the example is a very odd case, but I don't know if that may affect more cases.

DF_PLAYER_OVERLAY does not work. It required shaders that are not included. You may be able to find them in old OAX releases.

Could you please provide some more infos? Does it "not work" only due to missing shaders or also for other reasons? What's that supposed do to?

The underwater thing does not work that well either. It should allow much faster movement underwater but it only makes it twice as fast as before at the moment.

I did a quick try, it looks to me it allows to swim in water at the same speed of standard "running" on the ground (without strafejumping... about 320ups), right? In that case, it looks to me a good speed, if one wants to actually use the feature because finds the standard swimming speed annoying.

Of course, a mod author could re-use that code as base for a "sea being" class of character which would swim faster than run... probably he would not use the dmflag itself, but would adapt it for the class-based thing, and then may use a new "multiplier" constant with an higher value than the one of the dmflag, to obtain higher speeds... isn't it?

[sago007]

You can simply test it using my "testbox" map I attached to this previous post, joining the blue team in CTF mode: I do still spawn at the info_player_deathmatch which has got "nohumans/1", while I would have expected the other one. I know the one of the example is a very odd case, but I don't know if that may affect more cases.

There should be no check for nohumans/nobots while doing fallback.

Could you please provide some more infos? Does it "not work" only due to missing shaders or also for other reasons? What's that supposed do to?

I don't remember. It was used to create this screen shot:
http://openarena.ws/board/index.php?topic=4324.msg40500#msg40500
As far as I remember it was just the hazard suit shader with blue and red colors.

but would adapt to it for the class-based thing

Exactly!

[fromhell]

oh so like an oaverw*tch?

[Gig]

You can simply test it using my "testbox" map I attached to this previous post, joining the blue team in CTF mode: I do still spawn at the info_player_deathmatch which has got "nohumans/1", while I would have expected the other one. I know the one of the example is a very odd case, but I don't know if that may affect more cases.

There should be no check for nohumans/nobots while doing fallback.

If that's intended, then okay.  :)

Could you please provide some more infos? Does it "not work" only due to missing shaders or also for other reasons? What's that supposed do to?

I don't remember. It was used to create this screen shot:
http://openarena.ws/board/index.php?topic=4324.msg40500#msg40500
As far as I remember it was just the hazard suit shader with blue and red colors.

"Brightskins"-like shaders, eh? May be an interesting thing which may be worth looking into. A few considerations:
- At the time, Fromhell said she wanted "pro" stuff (which she does not like) in a separate "pro" folder; I think she was referring to a sort of "stock-included" mod (like the "Missionpack"), but I'm not sure. Personally, I have no problem in having them in baseoa, as long as they are a server-allowed thing disabled by default. What's her current opinion about that?
- A few of the OA 0.8.x player models do not work very well with the powerup shaders (e.g. battle suit shader), which you said were the base for your test. I hope all OA3 models will work well with those shaders.
- In case the idea is totally discarded, the dmflag 2048 may be reused for something different, to do not left an "empty space" in its allowed values. In case the idea is applied, this would be a feature so wanted by playerbase that it may even be worth of having a proper cvar to enable it, instead of just a dmflags value (just thoughts).
- I see that post is from 2011... does it mean that code is in 0.8.8, and if one places the right shaders in the right folder, it would be more or less working with 0.8.8?
- Just for completeness, I'm not a great "proskins" fan myself, although I used something of that kind (cg_enemymodel keel/green in the OSP mod, IIRC) in the old times I was in a Clan Arena OSP Q3 clan, something like 15 years ago...

oh so like an oaverw*tch?

What? :-/

[sago007]

oh so like an oaverw*tch?

More like: Oaver Fortress Arena IV

- Just for completeness, I'm not a great "proskins" fan myself, although I used something of that kind (cg_enemymodel keel/green in the OSP mod, IIRC) in the old times I was in a Clan Arena OSP Q3 clan, something like 15 years ago...

Me neither but I must admit that even I had some problems with the lightning on the maps and being unable to see all player models clearly. This can be blamed on the maps but I did not consider it realistic to fix them, so I suggested an alternative solution.
At least the overlay solution still kept some of the charm of a large roaster.

The shaders needed are:
playeroverlays/playerSuit1_Neutral
playeroverlays/playerSuit1_Red
playeroverlays/playerSuit1_Blue

I found the shader and have attached it. In case someone wants to try it.

[Neon_Knight]

In all reality I fully agree that brightskins are just a workaround for the visibility problem found in maps. And we have already an example of a game which never needed brightskins and had a full-blown competitive scene: the first Unreal Tournament.

[Gig]

Tried it. Is looks like it works quite well.  
Attached to this post, you can find z_playeroverlays_test.pk3, which contains the same shader file from Sago's post above, but packaged to be tested more easily. Just place it into your baseoa folder, start OpenArena (you don't even need OAX, since OA 0.8.8 already contains the required gamecode), set dmflags 2048 and play.

As you can see, it currently adds a yellow/orange layer in non-team-based modes, and red or blue layer in team-based modes.
I also attach an image with the most "fragile" situation, having it and powerups at the same time. It is non-exhaustive, but still gives the idea. Maybe some kind of tweaking from someone who knows shaders may produce even better results.

I don't know how to calculate how much the feature may affect framerate...

[1pixel]

I don't know where exactly I could post these questions so I'll post it here...
Is this topic preferred way of discussing gamecode changes as there seems to be nothing on github issues page?

[sago007]

Is this topic preferred way of discussing gamecode changes as there seems to be nothing on github issues page?

You are welcome to open an issue on Github. I personally prefer it although I don't know how many people here have an account and follows the repository. I do.

[Gig]

I haven't a github account (at least, not yet). Not being a developer, I would not use it for anything else that posting issues.

On one hand, handling open/closed issues with a proper managing system would be more efficient than the current way of just using forum threads plus trying to somehow update the DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Bugs]Bugs wiki page (and the DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Wishlist]Wishlist one) as recap...

On the other hand, using the forums allows for some more visibility and potentially some more brainstorming about possible improvements...

[1pixel]

I haven't a github account (at least, not yet). Not being a developer, I would not use it for anything else that posting issues.

On one hand, handling open/closed issues with a proper managing system would be more efficient than the current way of just using forum threads plus trying to somehow update the DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Bugs]Bugs wiki page (and the DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Wishlist]Wishlist one) as recap...

I agree. Github should only be for bug tracking and people who work with code.

On the other hand, using the forums allows for some more visibility and potentially some more brainstorming about possible improvements...

We can also talk in realtime on discord for brainstorming ideas, etc. I could set up a #dev or #oax channel.

[Gig]

Back to "nobots/nohuman", I have noticed a curious thing:
I was searching in DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Changes]Changes wiki page trying to find out which OpenArena version added DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Spawn_protection]Spawn protection to baseoa (and I haven't been able to find it)... and so I noticed a line in the forum post about 0.8.5 changelog:

- Changed the way the game picks the spawn point to prevent maps with few spawnpoints that are marked with nobot or nohuman from hanging the game.

It looks like something went wrong back then...


PS: About the spawn protection, I found it, it's from OAX Beta 47: http://openarena.ws/board/index.php?topic=1908.msg33556#msg33556
That post is from July 2010, so it's a 0.8.8 feature (0.8.5 was from February 2010).

[Gig]

1pixel, are you the "Idrone" who is doing some test with a gamecode fork in these days?

Uhm... if some discussion is going to happen also on github, it looks like I will have to register also there...

Do you think you can run away from my boring posts?  

[1pixel]

1pixel, are you the "Idrone" who is doing some test with a gamecode fork in these days?

Uhm... if some discussion is going to happen also on github, it looks like I will have to register also there...

Do you think you can run away from my boring posts?  

I have to upload my "code suggestions" somewhere. 

But we can discuss the rest here. I'll try to follow both places.

[Gig]

It was just to be sure I was talking with the same person. 

Okay, now I'm "The-Gig" on github ("Gig" and "TheGig" were already taken by someone else). So you may find comments from mine on the "issues" there (e.g. I added a comment here and here).

[Gig]

Excuse me Sago... back to the fast swim dmflag, I wass giving another look to the source code... just for curiosity.

While for me the result of swimming at the same speed of running is ok, I do not understand how it works.
https://github.com/OpenArena/gamecode/commit/f06aa8b2628e53426599e53c1f4fec95da54311b
It looks to me that if the dmflag is active, you change a multiplier from 0.5 to 5.0... so I would have expected a result 10 times faster... why does this do not happen?
I don't think swimming five times faster than running is required at all, I was just curious...
I'm not accustomed to C, so I don't know what the "f" in 5.0f stands for, or what "->" does...

[fromhell]

f means float

[Gig]

Okay, I don't know why the variables initialized here https://github.com/ldrone/gamecode/commit/02d6b156553d746675e992c0c0829a9489718b9f do not seem to be marked as float despite having decimal parts...
But it looks like they are two different kinds of initalization (the code seems different)... maybe some are local and other are global variables, I don't know. It doesn't really matter, it's just that giving a quick look to the code changes, even if with a very limited understanding of it, seems interesting.

Back to school times, I used a little of Pascal and Clipper programming languages... not that I may be capable of writing something after all these years (at maximum I did some simple AutoIt scripts in the past years)... just to say that I had a few programming bases back then...

[sago007]

It looks to me that if the dmflag is active, you change a multiplier from 0.5 to 5.0... so I would have expected a result 10 times faster... why does this do not happen?

I guess that it is capped at some other place. I just haven't found it yet.

Regarding types:
5.0f -> single precision floating point (32 bit)
5 -> integer
5.0 -> double precision floating point (64 bit)
"5.0" -> string
"5" -> also a string

In games float is often preferred over double for storage but double is still often used in calculations.
The rules for converting between them can be weird in C.

CVARs are always strings on the disc.
Unlike C a floating point value in a CVAR is always a float. ( Example: "cg_some_cvar.value" is a float )
The two rules above means that declaring cg_kickScale as "1" (string on disc) and accessing them with "cg_kickScale.value" is perfectly valid.

I "->" in the code is a pointer dereference. It is short for following the pointer and then accessing its member. If p_pickScale is a pointer to a CVAR you would write: "p_kickScale->value"