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. 

can you force qbsp to split the brush the way you want by first shaping the brushes in the proper pattern, then doing a texture shift of 1 unit difference on each brush so that qbsp doesn't combine them? 

I removed the 3 brushes that gave me a curved corner, and this was the result:

---- WriteBSPFile ----
Before After
10568 10559 planes
32563 32164 vertexes
13300 13015 nodes
3107 3106 texinfo
25959 25429 faces
24486 25105 clipnodes
7356 7261 leafs
32165 31634 marksurfaces
119337 117378 surfedges
60330 59343 edges
145 145 textures

Increased clipnodes and decreased marksurfaces.

http://img71.imageshack.us/img71/8720/marksurfaces3ys1.jpg

If anyone has not yet fallen asleep, what have we learned here?

No, I don't know either. Oh well; plug on, plug on. 

The thing is that these are pretty much single brushes: the wall behind the ammo is one, the ceiling is one the two faces are one etc.

Is there an optimum size that qbsp likes to find? (although I would hate to map to specific sized brushes, so perhaps I don't want to know that)

I'm just going drop some more monsters in and then call it a day. 

Thanks to ORL, I've found a bug in Tree when having >32k clipnodes that corrupts the clipnode information.

Hopefully I've fixed the bug now, but I recommend switching to TxQBSP permanently as it doesn't have this bug. 

but there is no way to have opaque water and solid sky with txqbsp... 

TxQBSP even for QuArK users? I remember TreeQBSP was recommended for us (if I am not wrong). 

TxQBSP run fine even with QuArK... It is just an external program to call from QuArK, and has nothing to do with the editor. Maybe only the saved map format could have an effect (i.e V220, etc..) and I'm not sure about that point.

FYI, I'm currently using QuArK 6.5.0-alpha2 with aguirRe's TxQBSP, aguirRe's VIS, and a aguirRe's modified TyrLight ... and all the stuff works fine ... 

i got same as JPL but QuArK 6.5.0-alpha8 new version of quark :\ suck :((( dont compile my base map :( give lots of errors :( leaks everywehere and say stuff like maxsufarces limit bla bla bla :) errrr i will keep this version a lottttttttttt 

There was something wrong with the new version, they released a bugfixed build.

JPL: It was something with the map format QuArK writes, maybe with the .12345 floating point stuff or something. Dunno. 

thks Spirit_ i think i will stick to this version a litle wile :) is perfect for me!!!

;) i dont have problems at all, despist other poeple say Quark owns!

;o)

ban worldcraft :p 

can have opaque liquids, just add -nowatervis. I don't know what you mean by solid sky, both compilers use CONTENTS_SKY for sky.

Tx was originally the *only* compiler for QuArK so it'd better work with it ... ;)