i changed the object in question to a health trigger. thx 

...I have just added 20+ monsters without making any changes to brushwork. Marksurfaces have risen from 31065 to 31665.

If marksurfaces are created as a result of the way the brushes are split in the qbsp stage, does it mean that monsters can cause a different split? And if so, is there a benefit to keeping monsters off of the ground in the mapping stage.

I ask because I have at least another 80 monsters to go and am in danger of exceeding the marksurface limit, and I want my map to be playable in FitzQuake.

(I am probably getting too tired/old to adhere to the critical technical disciplines of Quake mapping these days) 

Compile the map one with all the monster entities in it and let it exceed marksurfaces. Use adquedit or similar to export the entity list to a .ent file. Compile the map again in it's current state(ie. with enough point entities stripped out to compile with marksurfaces under the limit). Then just import the ent file into that copy of the bsp. Equivalently you could do an -onlyents compile to add the monsters back in, and this might be a little easier to set up with batch files. 

monsters have no effect on the bsp tree :)

As for what caused your increase in marksurfaces, I have no idea. Are you sure you didn't do anything?

Also, I've heard rumors which I find very hard to believe that things like vis results are actually different based on the speed of your CPU and stuff... I really have a hard time accepting that the compiles are non-deterministic. But, I don't know everything, so :P 

once I noticed the same thing as Mike did. I exceeded the marksurfaces limit when placing monsters (no brush changes). Wise people told me that monsters don't affect marksurfaces, so I believed them.

Anyway, some maps with exceeded marksufaces limit can still be playable in fitzquake (and all the other engines I think). When I got the crash problem the first time I started making small changes to the map and tried it in the engine each time. After n attempts map started to load without problems. Though I still have no idea what was the case of the problem and solution.

It's kinda Quake mysticism. 

I always get a message when I test my map on skill 2 (-developer 1 option, aguire's engine):

TH_STAND CALLED
WALKMONSTER_START_GO WORKED

WTF is this? And why it appears only when I play on hard skill? I suppose that's because of a big ammount of monsters (>200), but I don't get it on skill 1 where monsters are only about 20-30 less. This message dissappears only closer to the end of the map after I kill about 150-170 monsters. 

th_stand is the standing animation for all monsters, and walkmonster_start_go is the function that gets called everytime a new monster is made to set up common stuff between all walking monsters...

but i've never seen error code like that in the qc, so it must be an engine thing... 

I doesn't cause any problems (at least I didn't notice them so far). It is just annoying message at the top of the screen. I just wanted to get some ideas of how can I get rid of it. 

Are you using a custom mod for this map, perhaps with a custom monster that only appears on hard skill? Those messages sound like the kind of thing I'd add to a monster when diagnosing a bug and trying to pin down where it occurs. 

It happens in my map that you've seen (beta1). But I think all custom monsters appear in all skills. So no new custom monsters on skill 2 that weren't on skill 1 

Didn't we discuss (and solve) this issue five months ago? It's a bug in the Arcane progs that I later sent you an update for. 

thought you were talking about stock id progs :)

yep, that'd certainly explain it. 

indeed, I forgot about it.

The thing is that I found another bug in progs and asked Preach to fix it, but I forgot that I was using your fixed version.

So I have two versions of arcane progs atm: the first - your version without crashing bug but with version with ammo bug and the second - Preach's version without ammo bug but with crashing bug.

I think you should contact with each other and make an ultimate version. 

Are lights with "style" toggleable? And if not, has some clever person devised a 'hack' to make them so.

I am sure I remember this cropping up quite recently but I can't seem to find anything. 

but no way to do with in stock progs, afaik.

toggleable lights have a unique style for every different toggle light (set by the light.exe), which is set to a single light level and only goes from on to off in the progs. 

How I suggested to do this last time it came up can be found on the following page:

http://www.celephais.net/board/view_thread.php?id=4&start=4458&end=4482

But yeah, you need a custom progs to do it. 

Thanks. 

Hub-style level transitions.



cool, you're still reading.

For a real useful implementation you'd (I'd) want:
o persistent entity states upon returning to a map
o a set of global flags for triggering things across maps
o the final exit trigger to display the intermission with stats for all levels totaled (or even broken down)


What would be necessary for such a thing? There's a lot to do in QC, of course. But QC doesn't have control over saves IIRC - so you would be required to mess around with the engine, no? And if you're messing with the engine, why not just up the limits to allow the whole map in one huge BSP instead?

(the answer to that being, of course, compile time on the map, and ease of messing with savegame code vs. difficulty of raising all internal limits).

So assuming one is not above including an .exe with his maps, what's involved?

I would think the following but go ahead and argue with me cuz I'm dumb:
o Bunch of stuff stuck into the player struct for preserving cross-level trigger flags, and filenames of temp saves used to track recently visited bsp's
o Bunch of additions to endlevel trigger to handle preserving vs. dropping cross-level information, and stashing away level state in a savegame file
o Bunch of additions to player spawning functions to handle preservation of keys and stuff, and correct location within the map based on previous exit trigger 

i'm interested in this issue too.
some old rpg/adventure-style mod (don't remember the title) had some sort of hub code even back in 1997 or so. but i think it didn't have a 'final intermission' summarizing the stats of all maps... 

some old rpg/adventure-style mod (don't remember the title) had some sort of hub code even back in 1997 or so.

The Demon King 

but there's is a limited amount of what you are saying in quoth. basically, you can make it save the monster count from previous levels and tally up a total count after a bunch of maps and to also retain certain keys between maps, instead of resetting it. also, there's the mapindex to close off maps after you played them in the start map.

basically, it's just passing numbers from map to map via the parm# floats. monster counts are straight floats, keys and mapblocking are handled with bitflags.

thing is, there are only 15 parm variables, i think. if you were making a new .exe, you could just up the amount of variables passed from map to map, so you could carry along whatever you could possibly need, and just store map settings in variables on the player.

but if you're modifying the exe, you could probably get rid of all this hackery, and make a proper hub engine i suppose... 

Hexen2 which is directly based off Quake has a hub system.

IIRC there's nothing stopping you from looking at the code. I know that there is an open-source Linux port. 

Hammer of Thyrion

http://uhexen2.sourceforge.net

Hexen2 port for Unix, Mac and Windows

why not email the devs there? they're pretty active. 

I seem to remember there being an experimental codebase for having a hub using the old (now I beleive not even managed) MHQuake engine. It involved using the FRIK_FILE qc extension (requires engine support also) to automagically save all state changes between individual bsp loads.

oh, and since it's relevant: http://hosted.planetquake.gamespy.com/fatty/default.asp?opinion=hub 

Without going in to too much detail (it's too embarrassing) I have 'lost' my heavily modified progs.dat.

I have managed to replicate most of it as I kept sources and had notes for my own ideas but I am stuck on one thing: I had monsters who were spawned-in being angry regardless of whether they could see the player. I have an 'angry' flag on the monster (spawnflag = 8) but cannot figure out what actually made him angry when he landed.

I've played with FindTarget and FoundTarget but am getting nowhere. I cannot remember where I got this idea from but as I have added the angry flag to every monster, I must have had something working originally.

Is there any chance that someone knows what I am talking about?