[Idea] Possession gametype

[Neon_Knight]

The UI currently just selects all ffa maps. I am not happy about adding more to the arenas.txt file. I might look for an alternative solution.

Arenas2.txt maybe? To be used with Arenas.txt in an additive way... Just an idea. Could have some backfiring, but maybe...

Perhaps the Nexuiz/Xonotic way with .mapinfo files?

OA3 will have a lot of fat trimmed out of it, so size, at least for several releases, won't be a problem.

[Gig]

Things that I have not gotten around to:
No bot support. The bots play as if it was deathmatch.

However, I see them running around with the flag. Maybe you mean they could give higher priority to fragging flag holder over other enemies and collecting the flag over other items? Or that they should try to avoid combat a bit when they have the flag (however, possibly without camping too much, it may be boring)?

More on this topic:
* Flag radar/distance meter, if implemented, could be a good counter against camping.
* Just questioning. Do or should bots "cheat" about knowing where the flag carrier is? How do they do in other gametypes?
** Just questioning. In case they should not know about where the flag is exactly unless they see it... should they consider the radar, if implementrd?

... and Possession is one of the simpler gametypes we could think about...

[Gig]

[...]
Pick the first entity in the game

Uh? This sounds a bit dangerous, if taken literally... what would happen in case the first entity is worldspawn or something like a target_speaker or info_null or just something which requires less room than a flag (like an armor shard) and thus could be in some small place? However, I understand this was a last-resort manouvre... what about picking up a random red or blue team ctf spawn point before this? Just asking...

[Partially OT] Hey Sago, now that I think about it... as a possible "idea"* to be made after Possession (and its flag spawn point choose algorithm) is 100% complete, if you wish: what would you think about making DOM and DD modes compatible with (almost) any map by automatically choosing DOM/DD points, in case the map does not include the required flags/dom points?
About "how many" DOM points, it may be either a fixed number (e.g. 3), or may be random/calculated depending from "something" map-related (e.g. if there are more than X weapons and more than Y player spawn points, this may be a large map, so you can place 5 or 6 DOM points).
We could continue to list in arenas.txt only the maps which actually have dedicated (and fixed) spawn points for them, but the modes would work with any map. Oh, well, ALMOST any map... maps which do have ONLY ONE ffa spawn point (like oa_ctf4ish, test it with Possession), would still be a problem. Wait! Such maps would probably have many team spawn points, so one may use them in that case... Hey, maybe even before searching for FFA spawn points: that may assure half Dom points to be placed far each other.
This may be worth of a dedicated thread. Sago, just tell if you are interested into this stuff, then we could open an apposite thread about it (or just use OAX thread) after Possession is completed.[/OT]

PS:

[...]
So I ask, has the OAX gamecode been changed so, instead of closing the server with "couldn't find a spawn point" error, launches the map making everyone spawn at 0, 0, 0 coordinates, in the hope those coordinates are inside the map and not inside solid brushes?

Excuse me Sago, could you please confirm this? Also the possession flag seems to spawn there in this case (just try Possession in current am_galmevish2, after you are telefragged by a bot you can notice the flag fallen on the bottom of the pit), right?

* Yes, I know "ideas are cheap".  

[sago007]

[...]
Pick the first entity in the game

Uh? This sounds a bit dangerous, if taken literally... what would happen in case the first entity is worldspawn or something like a target_speaker or info_null or just something which requires less room than a flag (like an armor shard) and thus could be in some small place? However, I understand this was a last-resort manouvre... what about picking up a random red or blue team ctf spawn point before this? Just asking...

I'll change the picker to use a human spawn point as the last resort. If the map does not have a such then the map is unplayable anyway.

[Partially OT] Hey Sago, now that I think about it... as a possible "idea"* to be made after Possession (and its flag spawn point choose algorithm) is 100% complete, if you wish: what would you think about making DOM and DD modes compatible with (almost) any map by automatically choosing DOM/DD points, in case the map does not include the required flags/dom points?

I have some other priorities. Unless it turns out to be very simple. I think I would just choose two pick able entities semi-randomly and replace them. By semi-randomly I mean that I would choose the same two every time the same map is loaded.

[...]
So I ask, has the OAX gamecode been changed so, instead of closing the server with "couldn't find a spawn point" error, launches the map making everyone spawn at 0, 0, 0 coordinates, in the hope those coordinates are inside the map and not inside solid brushes?

Excuse me Sago, could you please confirm this? Also the possession flag seems to spawn there in this case (just try Possession in current am_galmevish2, after you are telefragged by a bot you can notice the flag fallen on the bottom of the pit), right?

am_galmevish2 is too aggressive with its "gametype"-flag on the spawn points. Therefore it is unplayable in any mode that it does not specifically support. A map must ALWAYS contain 8 info_player_deathmatch points without any restrictions.

[Neon_Knight]

am_galmevish2 is too aggressive with its "gametype"-flag on the spawn points. Therefore it is unplayable in any mode that it does not specifically support. A map must ALWAYS contain 8 info_player_deathmatch points without any restrictions.

I would like to know of the problem still arises with the OA3 version:

http://openarena.ws/board/index.php?topic=4801.0

[Gig]

am_galmevish2 is too aggressive with its "gametype"-flag on the spawn points. Therefore it is unplayable in any mode that it does not specifically support. A map must ALWAYS contain 8 info_player_deathmatch points without any restrictions.

I would like to know of the problem still arises with the OA3 version:

http://openarena.ws/board/index.php?topic=4801.0

At a first test, am_oa3dm1 seemed to work correctly with possession. But in a second and in a third try... I have not been able to locate where the flag spawned.   (Possession bug? Me being an idiot?)

Also, Possession bugs noticed:
- If I kick all bots, I score a point for some unknwn reason. I have not checked if this is is related with how many bots were in the map, or if it happens also with individual kick.
- Once I saw "you killed X. You are tied for the first place with Y" message (I had the impression that Y was the number of frags, not the actual Possession score... I think I was way behind the score of the leader at that moment).
- "You lost the lead" sound is played twice, maybe?
- Not a bug: maybe 300 is too high as goal (one player keeping the flag for 5 minutes)? 200 or 250 maybe? Just asking.

[Gig]

At a first test, am_oa3dm1 seemed to work correctly with possession. But in a second and in a third try... I have not been able to locate where the flag spawned.   (Possession bug? Me being an idiot?)

Made a few more tests today, and found it these times. Maybe there is one "problematic" spawn point in that map and yesterday it ended up there? I have no idea.  

If I kick all bots, I score a point for some unknwn reason. I have not checked if this is is related with how many bots were in the map, or if it happens also with individual kick.

Strange, I have not been able to reproduce this, today...  

However, I noticed that "bot_minplayers" does NOT work with this mode (yet).

Sago, I don't know if you noticed you made a small typo in in this diff (a "fint" instead of "find"). I wrote that in another thread a few days ago, but this is the thread it should go, so I write it also here for completeness.

PS: See at the attached screenshot... playing in oasago1 map, I noticed this place where those "1" were floating (I had the flag). It's not the same place where the flag spawned.

[sago007]

However, I noticed that "bot_minplayers" does NOT work with this mode (yet).

Sago, I don't know if you noticed you made a small typo in in this diff (a "fint" instead of "find"). I wrote that in another thread a few days ago, but this is the thread it should go, so I write it also here for completeness.

PS: See at the attached screenshot... playing in oasago1 map, I noticed this place where those "1" were floating (I had the flag). It's not the same place where the flag spawned.

I forgot about the bot_minplayers. I noticed it back then I was launching from the console but forgot after I started launching from the menu.

I'll fix the spelling mistake.

The "1" should not spawn at the flag carrier. I can only see them then I am holding the flag though. Fixed in: https://github.com/OpenArena/gamecode/commit/48b6227682868b49905e2c9527683bbca66fccf3

"You have lost the lead" playing twice was fixed in: https://github.com/OpenArena/gamecode/commit/5da298cdfe0e834bf20877f9b351772658b20d64

Not all changes may have made it into the nightly build yet.

[Gig]

About your comment to this diff (g_mappools variable being very long and hard to maintain), maybe a solution could be move that list to a text file, discard the current variable and use a new one (e.g. g_mappoolslist) to keep the name of the file to read?
Just an idea...

[sago007]

About your comment to this diff (g_mappools variable being very long and hard to maintain), maybe a solution could be move that list to a text file, discard the currently variable and use a new one (e.g. g_mappoolslist) to keep the name of the file to read?
Just an idea...

I think more about creating individual CVARS:

Code:

g_mappool_dm
g_mappool_toruney
g_mappool_ctf
etc.

That also makes it easier to change it from the command line because you can just set:

Code:

/g_mappool_0 dm_maps2.cfg

or

Code:

/g_mappool_0 dm_maps3.cfg

If you want to have multiple mappools and change between them.

I don't remember why I thought placing them in one cvar would be a good idea.

[Gig]

That could be a good solution, too.
Only, can a lot new cvars (except those of "sets") be created without problems, or should new cvars be created only if really necessary?

IIRC, I encountered some "too many cvars" errors while playing some old mod, in the past...

[sago007]

IIRC, I encountered some "too many cvars" errors while playing some old mod, in the past...

Newer versions of ioqauke3 deletes a lot of cvars when changing mod to prevent old mods with a small cvar table from overflowing.
Hopefully this should fix a lot of problems.

[Gig]

I do wonder how they may know which variables could be deleted safely... maybe they check for variables which are not defined in the binaries and do not appear at all in mods qvm code. Figuring out variables useless for engine sounds harder. And I wonder what would happen to user-generated variables (as those of rotation scripts). But this is not the right place for this.

[Off topic]
Could you please tell me what those green checks mean in gihtub changes history page?
[/OT]


PS: I have not yet understood if OA3 homepath will be named OpenArena or OpenArena3. In the second case, for version 3.0.0 , 0.8.8 values of cvars should not be a problem.

[sago007]

I do wonder how they may know which variables could be deleted safely... maybe they check for variables which are not defined in he binaries and do not appear at all in mods qvm code. Figuring out variables useless for engine sounds harder. And I wonder what would happen to user-generated variables (as those of rotation scripts). But this is not the right place for this.

They are deleting the unregistered CVARs. This is sometimes a bit too harsh in my experience.

[Off topic]
Could you please tell me what those green checks mean in gihtub changes history page?
[/OT]

A green check mark means that Travis CI could confirm that the branch still compiles after that commit.
A red X means that it cannot be confirmed.
If there are no icon then Travis did not test it. (If you push multiple commits at a time Travis will only test the last one per branch)

Github can do more tests than just Travis build test but for OpenArena that is the only relevant one.

It is possible to have Github validate that everything checks before committing to a specific branch (like master) to ensure that the master branch compiles at any time.

0.8.8 branch does not have Travis support (it was released before I setup Travis) and therefore it has a permanent red cross. https://travis-ci.org/OpenArena/gamecode/branches

[sago007]

The current nightly build contains a lot of the changes: http://files.poulsander.com/~poul19/public_files/oa/dev088/gamecode_nightly/openarena_gamecode_2016-07-30_a351b8da0ad753b8fc75e525b9254144fa0e53fd.zip

bot_minplayers now works.
The chooser now only chooses player spawnpoints. Domination points was not always suitable. For instance in plxfan one of the domination points was unreachable.
There is now a radar. It does not seem as useful as I had hoped. It is useless against the bots but it may help against human campers.

[Gig]

I cannot test before Monday.

However, are you sure about skipping Dom points? If one of them is not reachable, then that's a bug of that specific map (mapping error), isn't it?

In theory, all Dom points should be reachable by players, while for player spawn points this is not a requirement (you may place a spawn point on the top of a roof where there is no way to return after you jump down). Do you remember the screenshot I attached to that post?
http://openarena.ws/board/index.php?topic=3995.msg53964#msg53964

Another thing... considering you said the bots do consider "the obelisk" where the flag spawned the first time, we should do some test in case of strange spawn points like placed very high in the sky, or inside water, or above water...

PS: I suppose plxfan map could be fixed before OA3 is released.

[sago007]

I'll add an option so that it can be marked if domination_points are valid for generic cases. In pxlfan's case the area the domination points is in is blocked for all other gametypes but Domination. If the domination_point was blocked for all other game types too it would not have been a problem.

Once the arena-file problem has been solved it should be ok.

[Gig]

I'm sorry, I got lost. Could you please reword?

What do you mean with "blocked"?  If there was "gametype" key in one dom point only, it should have used the others. If there was "gametype" key on all dom points, it should have used a player spawn point, isn't it?

Wait... AREA blocked? Zones of the map should not be closed/opened by gametype keys... bots do not recognize such changes (conditional walls)!

And what's the relationship with .arena file?

[Neon_Knight]

What if, instead of supporting all of the maps, Possession support is left to all of those who want to implement it? The white flag needs to be carefully positioned by mappers, instead of it spawning in a non-permanent place.

[fromhell]

I haven't tried possession yet, but I will once I finish working on a leixperimental merge by hand.

EDIT: did that, tried it

and on second thought maybe chicken mode could be a second setting on the same gametype, and maybe a quad damage too

[sago007]

However, are you sure about skipping Dom points? If one of them is not reachable, then that's a bug of that specific map (mapping error), isn't it?

You are right, I'll add it.

What if, instead of supporting all of the maps, Possession support is left to all of those who want to implement it? The white flag needs to be carefully positioned by mappers, instead of it spawning in a non-permanent place.

It should be possible for mappers to explicit support Possession. However there are infinity many gametypes not yet developed and maps should not prevent those from working. Too specific requirements to maps makes modding too difficult. If I had not added the possibility to play on all maps then no one would have been able to test it yet.


I'll wait a bit before pushing more changes to the master branch. fromhell is currently doing a large merge.

[Gig]

Quickly tried oax 2016-07-30 build (side note: for some reason, that day it made two nighly builds)

The "1" should not spawn at the flag carrier. I can only see them then I am holding the flag though. Fixed in: https://github.com/OpenArena/gamecode/commit/48b6227682868b49905e2c9527683bbca66fccf3

Now, when I have the flag, I see them appearing behind me.

For the rest, I like the "survive for" counter... but isn't it possible to have the distance meter shown also when nobody has the flag?

[Gig]

Sago, I tried Possession from 2016-07-01 nightly build with this version of WIP am_gamelvish-oa3, and I noticed:

1) There is some problem with flag spawning algorithm. It first spawns in the middle of the map, you grab it, and then you see it having spawned AGAIN, in another location! So you can grab it twice... This is a bug.

2) Red and blue flags (if placed without gametype restriction, I suppose) appear in the gametype, but they are useless here.

3) With the flag in the middle of the map (in the place of 1fctf white flag), it happens that some powerup spawns at the same exact place. This is due to being natural to place some item in the middle of the map, probably people would set the powerup with "!gametype" to prevent those items from spawning in 1fctf... but they would spawn in possession. That's not a major problem, it's just a little bad looking. I don't see a way to automatically fix this (unless you think that automatically detecting if other items spawn at the the same place of the flag and in that case prevent those items from spawning -or making the flag spawn elsewhere-, is a feasible thing)... I suppose for OA3 we will have to check all maps to update their "!gametype" key for items positioned in the same place as the white flag, to prevent them from spawning also in Possession mode.

More Possession thoughts I wanted to tell you since yesterday:

4) You said that the distance meter is not very useful against bots. Maybe because it requires too much attention? Just an idea (maybe it's stupid, but I tell anyway): maybe integrating it with text (or icon) which changes three colors depending from the distance between you and the flag is the same, is bigger or smaller than previous value (or than previous server frame?), may help player understanding if he's going in the right direction or not without requiring so much attention reading actual distance?

5) If it has not been done yet, a reminder to make it when you will have time: making a keyword for gametype/!gametype keys for Possession. ("Pos"? "Poss"? "Possession"?). Yes, I know now this is implied from what I said in point 3), but I thought about this since yesterday...
Note: I don't remember exactly... maybe once someone said that those checks do search for part of the string instead of the whole string, so there was some problem limiting items only for "ctfelimination" due to the shared parts of the key value with "ctf" and "elimination" modes (or was it vice-versa?)? This may be taken in account while choosing the name of a new "gametype/!gametype" value.

6) Related to the above: I have never checked if "notfree" and "notteam" keys do actually apply only to the original Q3A gametypes (those that are mentioned in the in-editor descriptions of items), or if those keys have been updated and so they do apply to all OpenArena gametypes. In that case, "notfree" should apply to Possession, too.
PS: I read somewhere they do exist also "notq3a", "notta" keys, but I have never tried them and I don't know how they work exactly. This gametype does not come from either q3a or ta, however.

Update: Sago, could you please take a look to this and the following replies? Thank you.

[sago007]

Thanks Gig.

1. Fixed. I now check if the map already contains a flag before adding one.

2. Fixed. They have been removed.

3. The place where you can use "notteam" and "notfree" is for items in the same location. They are guarantied to never be true simultaneously. The same reason I added the "!gametype"-flag: You can say, if this gametype then use this item, if this gametype use that item else use a third item.

4. Perhaps.

5. It is called "pos".

6. If an entity has "notfree" on it then it should not spawn in possession. If it has "notteam" it may spawn. Yes, it causes a problem for the white flag in possession because "notfree" entities will not spawn.

Do not use the "notq3a" and "notta". Technically they are still working but not very useful. They are depending on you are using the missionpack qvm or not. This makes no sense for OA as you always get the full package. I don't think any mappers has successfully created a balanced map using these flags. These are the ones I might have referred to as "deprecated" at one point.

EDIT:
When I say "fixed", I mean "committed". It may or may not have been compiled yet.

[Neon_Knight]

I'm giving Possession support to some of the OA default maps, at least those with a chance to make the cut for OA3.

Unrelated to the above statement, what would be the keyword for the .arena file? Also "pos"?