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? 

add this into walkmonster_start_go (and the other ones) at the end. add an if check for the angry flag.


self.enemy = activator;
FoundTarget();
 

obviously, this means it will only work with a monster that has been triggered to spawn, since a monster that is spawned normally won't have an activator. 

this also assumes you are running the walkmonster_start function after spawning the monster... if you use the hipnotic method of creating a monster (spawn the monster, but set it invisible without running walkmonster_start, then copying the monster and making the copy run walkmonster_start) it won't work either.

difficult to say without knowing how your spawning works. 

I'm using PreachSpawn_v1.0, ("style" "1") so you got the right idea.

'self.enemy = activator;', doh!

As always, thanks for your help. 

Still having problems with fluctuating marksurfaces.

Please see attached file showing editor view, in-game normal and in-game showtris2.

http://img120.imageshack.us/img120/6706/marksurfacesgt2.jpg

Can anyone explain, or better still tell me how to avoid, the mashing of my brushes? 

a screenshot showing r_drawflat would be better, since showtris outlines the triangles drawn by the video card, but drawflat shows the polygons created by QBSP more clearly.

As for what's making those cuts, I don't know. Sometimes there's an obvious bit of brushwork nearby that can explain it. QBSP is still a mystery to me. 

Just for completeness:

http://img152.imageshack.us/img152/8837/marksurfaces2lz3.jpg

the ceiling is one brush with nothing else attached above i.e. it touches the void. The 'curve' that we see does not reflect any brushwork on the other side of the visible brushwork. The right-hand wall also touches the void.

With marksurfaces bobbling around 32K and a desire to ensure the map works with FQ, I find myself having to remove trim. I have already cut the map in half and it would defeat the object to split it any more.