If you changed skill (typically to a higher skill) and reloaded the map, the amount of monsters/items usually increases. That's why you now get that warning; doing the same procedure in a normal engine would probably throw you out with a SZ_GetSpace ... error.

If you don't specify any skill at startup, the default is 1 (Normal).

Or am I missing something here? 

kind of re-inspired by the forcefield discussion:
is it possible to create a nonsolid wall (like func_illusionary) that is not treated like a static entity, so it can be removed with killtarget (info_notnull hack or something)? 

Yeah, this is possible. The basic method can be found in post 36 in here:
http://www.celephais.net/board/view_thread.php?id=37116&start=26&end=50
The example there looks like it would create a player model, but actually what matters is the modelindex n.

So if you set n to be the modelindex of an existing brush entity, you'll get a copy of that brush entity as a non solid removable info_notnull at the desired point. If you want to use an original brush model, one that isn't already in the map, you'll have to add it in as a func_wall somewhere, then remove the func_wall from the entity list after you've compiled the map. Probably easier to just leave the model in the map hidden unless you're pushed for entities. 

thanks! 

would that also work for moving entities - like a nonsolid door, for instance? 

Yeah, you could do that, but you'd only want to do it for simple, non linked doors. Well, I say that, but linked doors would really only be a matter of filling in more fields manually.

Basically to do it, just look at the func_door code in doors.qc, and imagine that running on your info_notnull. Then manually set all the fields to the values they would get. So for instance set

touch door_touch
use door_use
...

Although touch is actually a bad example as you don't need it here. Add any sounds you want, assuming they're precached elsewhere. Don't set think or nextthink, as you need them to set up the model. Also, don't set SOLID_BSP or MOVETYPE_PUSH, the former for the obvious reason, and the latter since it assumes SOLID_BSP. MOVETYPE_NOCLIP should work fine although I've not tested this.

Since you can't use think, you won't get a call to LinkDoors, as I alluded to above. But you can use the same trick about imagining running the LinkDoors function on some entities that should be linked and then manually setting what you would get. This involves manually creating a chain of entities in the enemy field, but refering to each component in the door by it's entity number. Ouch. So don't do that unless you really have to, and even then, probably easier to start with real doors, run the map, dump the in game entity info into a text file, then convert the entities to info_notnull, feed this info in and recompile.

Skipping the LinkDoors function means you also don't get the automatically generated trigger that surrounds it to open it. The easy fix here is just make it so your "door" is triggered by a trigger_once or trigger_multiple so it doesn't matter. You'll also need to set the enemy and owner fields to be the door itself in the simple unlinked case - remember that these fields expect an entity number, not a targetname.

Looking at this bit of code has also given me another exciting idea, but I'm gonna work on it and post it in the new tricks thread. This assumes it pans out... 

You are not correct, I didn't change the skill.
When I load the map by a shortcut with -game arcane +map new4 parameters, I get no errors/warnings. But when I type restart in console then (no skill changing, the same skill 1), I get all warnings I should get. I tihink it's a bug. 

not related to pulsar's question.

maybe this has been explained already: why is it that when manually restarting certain entities act differently than after a clean map load? e.g. items that spawn within the player (so he picks them up immediately) fall out of the level, or funcs that are removed upon startup (for suspended items) don't work anymore and the items fall to the floor... 

It can still happen if you're right on the limit (like you were with Menkalinan). Have you tried doing the same procedure in e.g. Fitz (restart a number of times)? Do you get any error then or is everything OK?

If you want me to look into it, I need the zipped bsp and other files necessary to reproduce the issue. 

do I make items glow or have effects fields? I've completely forgotten how to do this. Something like key=effects value=integer, but I'd like to see a run down of all the possible effects.

Anyone know if I can apply a glowing effect to the spikey ball used in end.bsp to create a moving light?

Gah, all these useful QC hacks are somewhere in this thread, but we need a definite list of all the hacks without all the comments and how-tos aswell. Maybe someone knowledgeable could whip something up for Qexpo? (I am a bit busy and have already planned a lot of stuff I might not be able to finish on time). 

http://www.celephais.net/board/view_thread.php?id=37116 

do i get worldcraft working with equake??? been trying for several days.. entered all the paths but it says it cant load such and such.. can anyone help? thnx in advance!!! 

cant load such and such

*reads your mind*

Ah yes I see it now, you got ERROR 46:

"You want help learning how to map but you're extremely ignorant of important details so you should just give up now" 

Never say die, Leo Triple X-y guy. 

im trying to compile this hexen2 level of mine, but i get a message saying i neeed gfx.wad! gah. what do i have to do?

what i did was to have worldcraft (1.6) compile the map into the data1/maps folder. im guessing thats where they go right? and whats with the gfx.wad thing? im using the original hexen texture.

agh, im so confused it makes me go pee-pee :-( 

here is a little help file that can help you on your way...

http://members.home.nl/gimli/WC33_H~1.ZIP

maybe not the instant help you need, but for working with the program it can be a good catch! 

i realised the maps folder goes on the portal one (hehe), but i cant still compile the map with the hexen2 tools. what the hell. can anyone help me on this? i really wanna see the crap i did ages ago. :-(

i dont know what im doing wrong. everything is how its suppose to be.. damn this. im gonna go cry. 

So, I've already split the map in two, (it was three, then one)removed huge swathes of brushwork to get under the marksurfaces limit and chopped out loads of monsters, and now I've hit a SZ_GetSpace error!

How do I find out how far over the limit I am and which items should I look to remove. I have a few switchable lights I could drop, I have loads of torches (three types) but want to keep them, I only have 86 monsters in this part of the map and half of those spawn-in as opposed to teleporting, I have the usual number of triggers (trigger_once, monster_push etc) and buttons (only 8).

Ho hum... 

I just had a thought. With those looong compile times of big maps (like Tyrann: the long vis times required (~48 hours I'm guessing, still waiting...), how about something like SETI or the rc-72 project where lots of computers divide the cpu work. Would it possible to extend the compilers to do that? 

I wish! I don't think it would be all that easy though. There was something called 'netvis' around a long time ago (I never had it, but read about it), which could apparently be used over a LAN to speed up vis. If anyone knows any more about this, I'd be interested in looking into it.

I'm currently vis'ing my map on the fastest machine I have access to (dual 2.8GHz P4 Xeon, running Linux) and it's already taken more than 48 hours. If anyone has a faster machine they can offer, let me know! 

There was a version for quake, but it can't be downloaded now: http://www.bluesnews.com/archives/nov97-2.html

There were/are distributed tools for Half-Life compiling. Sounds like I was right about needing LAN speeds: http://collective.valve-erc.com/index.php?faq=source_mod_faq&section=106159033732043100&question=106159940663775100

Oh well, that's enough time spent on that for now. 

I already discussed that point with aguirRe during "Castle of the Dark Ages" fullvis runtime (around 51 days ... remember...). I asked him about multi processors vis executable existence, and maybe re-coding vis sources to target multi processors platform... He told me that first releases of vis.exe (correct me if I misunderstood please) were able to support multi processors... but on Unix environment only.. It was used by Id initially..
And as most of PC have only 1 processor.... it was not really a "priority"... well.. It is well known that it would divide runtime by two at most (or more if you have more than 2 processors installed on your PC)...
However, I never saw multi-processor PC platform... except at office (..under Linux... exactly like Tyrann's PC, but with P4 3.2GHz, 4Go RAM, 180 Go HD, etc..etc.. )...
Maybe these high performances machines will become cheaper in the next coming years... and then a multi-processors vis tool could help... though.. 

So, the map won't load in Fitzquake but does load in a couple of other engines. So, I am using aguirRe's 1.31 and although the map loads and I can play, I get some weird effects like certain monsters not taking their shots i.e. I cant kill them but they can kill me!

Also, some monsters don't wake up until I walk right up to them AND blast them with both barrels.

One question for aguiRre direct: you say the GetSpace error can be caused by too many static entites, max 128. Does this mean 128 different entites or a grand total of 128? And what is a 'static' entity: non-moving models (torches), triggers, doors?

My Qbsp output says that I have 1296 entities (1013 of which are lights) and I have 111 BspModels. The monster count is 118. There are 10 monster types.

Looking at the figures, is there any benefit to getting rid of torches and braziers, and replacing them with lights?

I'm gonna play with some worms :-( 

Right now I can't remember in which case the engine aborted with a GetSpace error when having too many static ents, but I recall having that problem.

In any case, the static ents are just the ones that are made static from QC by calling the makestatic function. I don't think there's any check for if they're the same type; it's the # makestatic calls that counts. Calling makestatic also frees up that edict.

In my engines, you can check the current status by using the staticents command. It's hard to say from your description whether replacing torches with simple lights would help.

If you send me the zipped stuff (or better just a link if it's big) to reproduce the error, I can probably help you more. 

I already discussed that point with aguirRe during "Castle of the Dark Ages" fullvis runtime (around 51 days ... remember...).

Argh! You're scaring me :-P

I asked him about multi processors vis executable existence, and maybe re-coding vis sources to target multi processors platform...

Yes, I know how to do this now (at least on Linux, but I think I can do the same for Windows). I'll put it into my next version of rvis and I'm sure aguirRe will pick it up soon after that. It won't be 'til after this map is done though.