Hello Sago, any news about this stuff? Where did we left?
I try to sum up things previously mentioned, adding some thoughts in the meanwhile.
1) You encountered some problem finding out where the white flag is, to allow the distance meter to be of use also when nobody has it. If I understood correctly, the problem is something like that in that case clients do not know where the "item" is, but only where the "model" is, right?
In case they
always know that, even if it's far and even behind an areaportal, I suppose it may be okay even to locate the model (although maps containing more white flags, e.g. for decorations, would theoretically mess up the radar... do you think there are such maps out there? But in case of "decorations", I thought the model was baked into the bsp... would it still be a problem?).
Alternatively, I suppose the server should know where the "item" is at any moment, isn't it? Couldn't the server read this info and spread it to all clients as a new variable, at the price of a little more bandwidth use?
2) Not sure about what to suggest you about the yellow flag thing. I think I more or less understood the problem now (if a map contains both your "new" entity and the "neutral flag" entity without gametype limitation, and both use the same model -white flag-, you cannot hide only one of the two), but I'm unsure what's the best thing to do.
One may think that, if there is a Possession-specific entity, that would be used for first, while you have to use it as second choice instead, to avoid the risk of double flags in case there is already a neutral flag, right?
The reason for foreseeing a possession-specific entity was in case mappers wanted to set "notfree" or "gametype/oneflag" for neutral flag, right?
Unlike red and blue flags which are "manually driven" (by default, shown also in gamemodes where they are useless.... except for Possession and a few other modes such as Elimination where you automatically hide them),
the white flag is only shown in modes which support it (other modes do hide it automatically, without the need to use "gametype" or "not*" keys). Do you think that mappers may however set "notfree" or "gametype/oneflag" to neutral flag anyway, "to be sure", even if that's not really necessary? They may be unaware of that...
3) To add some more headache, one should also think about what to do about team_neutralobelisk (as optional "basement" for white flag) in Possession. The worst scenario would be the case of it spawning in a different place than the white flag, something we should try to avoid. Currently, it does simply not spawn at all in Possession mode:
surely it's the simpler and more headache-free solution, although it may have been nice to have the flag base shown, to know where the flag will re-appear (
a possible way to achieve that may be to hide its standard model and automatically spawn -like A and B DD points- an alternate copy of it -something like the yellow flag idea you mentioned above-, which may be dropped to the ground just like the flag is -unlike flags, obelisks are NOT dropped to the ground-. Although this would mean making the entity work in a very different way in Possession than in other gamemodes, theoretically giving some further perplexity to mappers. Also, there is still the -remote?- possibility that mappers placed something different than the neutralobelisk where the oneflag white flag is, to act as basement.).
4) We will need the necessary to callvote for the new mode, from both console and GUI (including updating default "g_votegametypes" value).
5) After you die, the score board requires you to push TAB key to be updated (e.g. to show you lost the flag).
Making a few more tests, it looks like that the score table not auto-updating is a more general "issue" which affects other gametypes, too... even when you are alive and hold TAB button to show scores, you have to release and push it again to see scores updated (I don't know if this last mentioned behavior is intended... are scores only sent to a client when it asks for them? In other words, does updating the score table consume more bandwidth?). I don't know the reason why, when you die in CTF or Oneflag mode, in the score table the fact you lost the flag is updated after less than a second, while players' scores are not updated unless you press TAB. Maybe not auto-updating is a choice "by design" to save bandwidth, but maybe Possession may work like CTF mode and automatically update flag holder info only...
6) Making bots somewhow more objective-aware (care for the flag a bit more than for opponents)?
7) Trying some other improvement to the radar (e.g. using different colors is you are going in the right direction, in the wrong one or you are at the same distance from the flag)?
8) Lowering default Possession fraglimit in GUI, 300 being too high? We are sure about using fraglimit instead of capturelimit, right?
9) Some tweak to console (e.g. writing who has grabbed the flag),
at the end of work?
10) Something more I forgot?
PS (really OT, but comes in mind while looking into entities keys stuff): when we will make updated Radiant entity definitions, we should make an apposite thread and review them extensively first. For example, at least in the version I have, it is not mentioned that flags entities do support "notfree,notteam,notsigle" keys.... and also for other kinds of itmes, "!gametype" existence is not mentioned, "notfree" refers to "free for all" and "tournament" only... description of team_neutralobelisk says "harvester only", while it can also be used as optional basement in oneflag mode... "light" entity mentions "color" key while I fear it's "_color" instead... etc.PPS: Seeing how much complicated and fragile is the item spawn procedure thing... I removed from "
DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Wishlist]Wishlist" wiki page my request to make the game automatically choose DD and Dom locations to play such modes in maps not thought for them. I fear the risk of making the items spawn in unreachable points (even in Possession, we use player spawn points for white flag really as last resort... I would even try using a red or blue flag place before going that far) may make it not worth. I did not move the wish to the "
DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Wishlist/Rejected]Wishlist/Rejected" page, because you didn't actually reject it and theoretically may decide to do it anyway, or someone may ask for that in the future... Simply, right now I'm not asking you that anymore.
