Hiding brushes in certain gametypes

[Eraser]

I read that notfree and notteam can be used for item entities to hide them from certain gametype, but can this be used on func_groups (or other brush-entities) as well? It doesn't appear to work. And I want more specific control. I want a brush to appear only when the gametype is set to CTF. Is this possible without mods?

[dONKEY]

I *think* you can do that with func_static iirc

[themuffinman]

Code: Select all

gametype: used to set item to spawn in only selected gametype(s).
   ffa: Free for All
   tourney: Duel
   single: Single Player
   team: Team Deathmatch
   ca: Clan Arena (QL)
   ctf: Capture the Flag
   oneflag: One Flag CTF (TA/QL)
   overload: Overload (TA/QL)
   harvester: Harvester (TA/QL)
   ft: Freeze Tag (QL)

^ you use that to set an entity to appear in a specific gametype. Multiple gametypes can be specified, just seperated by a space (eg: "gametype = ffa team" would spawn the specific entity in those game-types only). To apply this to brushes you generally use func_static (as dONKEY pointed out).

In QL you can also use:

Code: Select all

not_gametype: used to set item to spawn in any gametype NOT specified.
   0: Free for All
   1: Duel
   2: Single Player
   3: Team Deathmatch
   4: Clan Arena
   5: Capture the Flag
   6: One Flag CTF
   7: Overload
   8: Harvester
   9: Freeze Tag

Bots are pretty useless with func_statics so be aware that if the given brush entities create a significant structural change that it will affect bot performance.

[Eraser]

Bots are pretty useless with func_statics so be aware that if the given brush entities create a significant structural change that it will affect bot performance.

It's detailing that I want to hide in non-CTF games, but it is rather obtrusive. So will the bots act according to whether the geometry is there or not or will they keep avoiding invisible geometry in non-CTF games?

[themuffinman]

I think bots consider all brushes etc. (I'm no technical whiz) and if you have those func_static brushes then the bots will consider them there no matter if the brushes have spawned in the given gametype or not. That's what I think happens. You'll have to test it out.

[obsidian]

According to documentation, bots will consider them to be solid for all game types. You can of course, compile a copy of your map and include an extra .arena file and wrap everything up in a single .pk3.

[Eraser]

Yeah I tested it after muffinman's post.


The blue brush is a func_static with "gametype" : "ctf".
I loaded the map in FFA, added a bot and it took the route as depicted by the green arrow towards the RL, even though the brush was invisible. Removing the brush made it go there directly.

I think that makes the "gametype" key/value pair not an option for me. I'll continue tinkering with this.

The other option is indeed to include a 2nd bsp but I'm hoping to avoid that

[VolumetricSteve]

This is an interesting idea, but I can't think of what advantage it holds over using multiple bsp files and extra .arena files, how come you're trying to do it this way, Eraser? It's an interesting idea though.

[Eraser]

Erm, something which, right now, I'd rather keep to myself
It's not some revolutionary new gameplay mechanic. In fact, it's not gameplay related at all. You'll see when ermap4 is released
Oh, and don't bother spitting through the beta release of the map. There's nothing in there which I'm planning on putting in.
Right now I'm also still busy reconstructing the bridge area (with the YA) and those jump platforms.

[VolumetricSteve]

I......well......ok then.

Is it at all related to that map of yours I went all A-Team on?

[Eraser]

Nope, the ermap4 one I posted a beta of a few days ago.

[^misantropia^]

Eraser, up for a quick experiment? I added a hacklet to bspc that makes it ignore a func_static if spawnflags == 1.

Link: https://github.com/bnoordhuis/bspc/tree/func_static

How to build:

Code: Select all

git clone https://github.com/bnoordhuis/bspc.git
git checkout -b func_static origin/func_static
make

[obsidian]

How would that work if the func_static is visible (and therefore is in the way of the bots)? Bots would "ignore it" and walk right into it, no?

[^misantropia^]

That's the experimental part. I think the bot code should be smart enough to adopt but it might turn out just like you said.

[Eraser]

Ok... erm, this is not entirely working out as I was hoping.
I checked out the files from github, but opening the sln file in visual studio 2008 and building it gave me 52 errors about files not being found (all of them botlib/ or qcommon/ files). As they were not part of the project, I manually added them (I found them in the deps folder on disk) but now it complains that OS_STRING is not defined (or at least, I get a bunch of "Operating system not supported" errors)

[^misantropia^]

Forgot there even was a sln file. Send your updated version as a patch or fork and commit it on GH and I'll pull it in.

deps/qcommon/q_platform.h constructs an OS_STRING based on platform/architecture sniffing but apparently it fails on your system. I've added a fallback (`git pull origin func_static`, then rebuild) but if you could somehow fix it, that'd be even better.

[Eraser]

Been fiddling around a bit. I really haven't made any committable changes. It just keeps whining that it can't find qcommon/q_shared.h (and other files), no matter where I put it or how I include it in the project. Not sure what I'm doing wrong.

I don't have a GCC compiler installed by the way, so makefiles aren't any use either right now.

[^misantropia^]

I take it msvc lets you specify include paths? . and deps/ are the ones.

[monaster]

I read that notfree and notteam can be used for item entities to hide them from certain gametype, but can this be used on func_groups (or other brush-entities) as well? It doesn't appear to work. And I want more specific control. I want a brush to appear only when the gametype is set to CTF. Is this possible without mods?

One further addition to that: it works, and it affects bot play. I've had that in a map a few years ago (2008/2009?) to have doors sealing off the flag rooms in every other gametype than ctf. They wouldn't simply open if shot at or having a player or bot approaching, they only worked normally in ctf mode. Unfortunately the bots didn't "realize" that there was a flag room after all anymore, including ctf, so I redid the map layout to work around that problem. If there's actually someone being able to properly solve this issue, it would be great.

[Noruen]

And what about to create trigger_multile in each info_playerSTART only active in some gametype, which will lock the doors in specific gametype? It can work with bots?

[monaster]

Sound interesting... anyone has the time to test that method anytime soon?

[obsidian]

You do.

[Noruen]

Great, so we awaits tomorrow some 10-slide presentation with meaningful conclusion and several examples monaster :P (you must obey obsidian)

[monaster]

You do.

I don't. That's why I asked if there's someone else to do that test, because I doesn't help anyone if I say "that's a good idea, lemme test it, I'll report back in 3 months".

[^misantropia^]

No dice, bspc only considers a trigger_multiple when it points to a target_teleporter.

Hard problem, probably can't be fixed without patching the source. It's a binary situation as far as bspc is concerned, either the brush is there (in all game types) or it isn't.