News | Forum | People | FAQ | Links | Search | Register | Log in
Mapping Help
This is the place to ask about mapping problems, techniques, and bug fixing, and pretty much anything else you want to do in the level editor.

For questions about coding, check out the Coding Help thread: https://www.celephais.net/board/view_thread.php?id=60097
First | Previous | Next | Last
It Appears To Me 
that there's a difference in that I still get the error message even if I return right after the setmodel and before the walkmonster_start call.

The actual call to setmodel is what triggers the error. Could something be wrong with the ne_egypt.mdl or is it just that including it becomes too much for the engine? 
Well.. 
i think it's just that there are a lot of monsters, so with the added setmodeling of the other monsters is what pushes the engine over the edge, so to speak...

have you tried doing return; on other monsters?

i don't see what could be wrong with the model though, it was straight from the DoE expansion with only a reskinning, and it worked fine for that pack (and was used again in SoE, i think? or was that OuM?) and plus i've had him working before in test maps, earlier versions of the map, etc...

i think it's just quake choking on so many setmodel calls. 
Putting In 
a return at the same spot for any of the Ogre, DeathKnight or Shambler will also do the trick. It certainly looks like it's the total sum of them all that pushes the message size and thereby engine over the edge. 
Yep, I Fixed It. 
used a modified version of the zer spawn code, so that way it sets model only when needed (ie when spawned) theoretically, this should allow ridiculous amounts of monsters... hmmmmm ;) 
Necros & PuLSaR 
Both your latest maps seem to have excessive # marksurfaces (> 32k), check the compiler log summary for details.

Some engines might behave unpredictably (e.g. crash) while playing as a result. PuLSaR has already noticed this behaviour in a previous version of his map. Unfortunately, even with the bad brush rebuilt, marksurfaces are still too high.

I haven't been able to actually produce a crash in neither of the latest versions of your maps but some engines clearly have this limitation (and don't enforce it).

I've added warnings in my upcoming compiler version for this and other limits. 
Who's Mark Surfaces? 
and what does it mean? you mean, just plain surfaces? like wpoly? 
Mark Surfas 
Mark Surfas was the founder of PlanetQuake, and therefore the owner of GameSpy Industries. He's also $20 million richer than he was ten years ago thanks IGN buying him out. 
Metlslime (or Any Knowledgable Soul) 
On what we previously discussed. If you were to resample the pixel resolution of the Quake textures in use in your map to twice their normal density you wouldn't significantly change the visual quality of the texture (without touch up work, like adding gradients), but it could noticeably increase the qualitiy of the light map resolution? Do I have that right? Would you think it worth the evening of experimenting I plan on doing tonight? 
Could Be Definitely Be The Geekiest Post Ever 
Any one know where I can find an Elvish font type set? (I am so emberassed) I need it for some textures I wittling. 
I'm Wittling 
spelling/gramatical error compounding my red cheeks 
Nevermind 
Headthump: 
yeah, becuase lightmap resolution is tied to texture resolution. 
Necros 
Look in the compiler log summary for the marksurfaces value.

Unfortunately I don't know what they are or exactly how to reduce the value. I assume they are related to brush faces somehow and by reducing complex geometry, they will also be reduced.

What I do know is that if they exceed 32k, some (or maybe even most) engines might behave unpredictably or crash at some point while playing the map.

It's a bug in the original engine code, the bsp limit is actually 64k. 
Marksurfaces 
These are pointers to actual surfaces. Each leafnode has one marksurface for each actual surface that touches the leaf. Since QBSP merges surfaces, a surface may be shared by more than one leafnode, so there are often more than one marksurface for each actual surface. 
P.S. 
An "actual surface" = a wpoly. 
><((((�> 
Mark Surfas was the founder of PlanetQuake, and therefore the owner of GameSpy Industries. He's also $20 million richer than he was ten years ago thanks IGN buying him out.

Bastard. 
Yep, "Bastard" Is His Quake Alias 
Error Help 
hi everyone. i just tried to load up the latest build of my map in winquake, and it crashed with this error message:

"SZ_GetSpace: 8002 is > full buffer size"

can anyone shed some light? 
Too Many Entities 
this is a usual error in big maps, remove some entities (better bmodels).
I think you need to remove only 1 or 2 entities. 
Thanks Pulsar. 
bugger. that makes sense, as i've added a load of bmodels since my last build. (and i had planned to add a load more!).

i really don't know where to start cutting down... :( 
I've Seen Those Funny 
error messages a lot lately ... 
That's My 
fave error :)
cuz sometimes engines crash without any errors. 
Related Question... 
in quake, you know how the ammo boxes etc. are bsp models? well, does the engine treat these similarly to "proper" brush models like doors etc, i.e. if my error is caused by having too many bmodels, could it also be solved by reducing the no. of ammo box models (replacing them with .mdl versions for example)? 
Kinn 
If you haven't already, take a look at the archived QMap thread at my site, there are a lot of good stuff in there. Just d/l, unzip and open in a browser. 
GTKRadiant Again 
anyone ever notice when your map starts to get big (+4000 or so brushes), there seems to be some sort of lag on the mouse, when right clicking and dragging to move the view? but not really lag... but like, when you right click and start panning the view, sometimes, it "won't let go" and keeps panning for a few seconds... like it received the +rmb, but not the -rmb..? anyway to fix this? is this a problem with the editor or windows? 
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2025 John Fitzgibbons. All posts are copyright their respective authors.