Quake3World.com • View topic - Hiding brushes in certain gametypes

Quake3World.com Forums

Level Editing & Modeling

Hiding brushes in certain gametypes

Print view

Previous topic | Next topic

Topic Starter

Topic: Hiding brushes in certain gametypes

Eraser
Cool #9

Joined: 01 Dec 2000
Posts: 44139

Posted: 01-10-2011 12:19 AM

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?

Top

dONKEY
The Afflicted

Joined: 14 Oct 2001
Posts: 581

Posted: 01-10-2011 02:05 AM

I think you can do that with func_static iirc

Top

themuffinman
Insane Quaker

Joined: 05 Mar 2010
Posts: 384

Posted: 01-10-2011 03:58 AM

Code:
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:
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.

Top

Eraser
Cool #9

Joined: 01 Dec 2000
Posts: 44139

Posted: 01-10-2011 05:00 AM

themuffinman wrote:
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?

Top

themuffinman
Insane Quaker

Joined: 05 Mar 2010
Posts: 384

Posted: 01-10-2011 06:01 AM

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.

Top

obsidian
I'm the dude!

Joined: 04 Feb 2002
Posts: 12498

Posted: 01-10-2011 07:11 AM

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.

_________________
GtkRadiant | Q3Map2 | Shader Manual

Top

Eraser
Cool #9

Joined: 01 Dec 2000
Posts: 44139

Posted: 01-10-2011 07:21 AM

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

Top

VolumetricSteve
Insane Quaker

Joined: 05 Nov 2010
Posts: 449

Posted: 01-10-2011 03:37 PM

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.

Top

Eraser
Cool #9

Joined: 01 Dec 2000
Posts: 44139

Posted: 01-11-2011 01:41 AM

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.

Top

VolumetricSteve
Insane Quaker

Joined: 05 Nov 2010
Posts: 449

Posted: 01-11-2011 06:55 PM

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

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

Top

Eraser
Cool #9

Joined: 01 Dec 2000
Posts: 44139

Posted: 01-11-2011 11:43 PM

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

Top

^misantropia^
Mentor

Joined: 12 Mar 2005
Posts: 3958

Posted: 01-12-2011 07:49 AM

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:
git clone https://github.com/bnoordhuis/bspc.git
git checkout -b func_static origin/func_static
make

Top

obsidian
I'm the dude!

Joined: 04 Feb 2002
Posts: 12498

Posted: 01-12-2011 07:52 AM

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?

_________________
GtkRadiant | Q3Map2 | Shader Manual

Top

^misantropia^
Mentor

Joined: 12 Mar 2005
Posts: 3958

Posted: 01-12-2011 07:55 AM

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.

Top

Eraser
Cool #9

Joined: 01 Dec 2000
Posts: 44139

Posted: 01-13-2011 12:22 AM

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)

Top

^misantropia^
Mentor

Joined: 12 Mar 2005
Posts: 3958

Posted: 01-13-2011 03:15 AM

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.

Top

Eraser
Cool #9

Joined: 01 Dec 2000
Posts: 44139

Posted: 01-13-2011 04:26 AM

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.

Top

^misantropia^
Mentor

Joined: 12 Mar 2005
Posts: 3958

Posted: 01-13-2011 06:57 AM

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

Top

monaster
The Afflicted

Joined: 28 Apr 2008
Posts: 530

Posted: 01-14-2011 06:31 AM

Eraser wrote:
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.

_________________
If you are caught on a golf course during a storm and are afraid of lightning, hold up a 1-iron. Not even God can hit a 1-iron.
-Lee Trevino, golfer who actually has been struck by lightning.

Top

Noruen
Insane Quaker

Joined: 28 Jan 2010
Posts: 308

Posted: 01-14-2011 07:00 AM

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?

Top

monaster
The Afflicted

Joined: 28 Apr 2008
Posts: 530

Posted: 01-14-2011 07:02 AM

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

Top

obsidian
I'm the dude!

Joined: 04 Feb 2002
Posts: 12498

Posted: 01-14-2011 07:48 AM

You do.

_________________
GtkRadiant | Q3Map2 | Shader Manual

Top

Noruen
Insane Quaker

Joined: 28 Jan 2010
Posts: 308

Posted: 01-14-2011 08:32 AM

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

Top

monaster
The Afflicted

Joined: 28 Apr 2008
Posts: 530

Posted: 01-16-2011 03:10 PM

obsidian wrote:
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".

Top

^misantropia^
Mentor

Joined: 12 Mar 2005
Posts: 3958

Posted: 01-16-2011 04:50 PM

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.

Top

Quake3World.com | Forum Index | Level Editing & Modeling

I *think* you can do that with func_static iirc

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.

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.

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.

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

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

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_staticHow to build: Code:git clone https://github.com/bnoordhuis/bspc.gitgit checkout -b func_static origin/func_staticmake

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?

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.

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

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?

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

You do.

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

obsidian wrote: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".

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.

I think you can do that with func_static iirc

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

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

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:
git clone https://github.com/bnoordhuis/bspc.git
git checkout -b func_static origin/func_static
make

obsidian wrote:
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".

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.