The mapobject_custom is basically an info_notnull in every other way, so if you were to apply other hacks to it they'd work fine.

Applying the "give the player a DBS" fields from my info_notnull to my mapobject_custom made the backpack model not appear.

{
"classname" "mapobject_custom"
"origin" "320 184 -244"
"model" "progs/backpack.mdl"
"skin" "14"
"think" "InitTrigger"
"touch" "BackpackTouch"
"items" "2"
"netname" "Double-barreled Shotgun"
"nextthink" "0.2"
"targetname" "pack_dbs"
} 

InitTrigger is to blame there, it intentionally hides the model of whatever it is run on, so that you can't see triggers. 

Any way around it? 

the flag would mean "This map is free of hacks, so go ahead and aggressively optimise it"

this isn't that bad an idea... like setting a strict doctype. 

onetruepurple: try swapping the classname and the think.

necros: yeah, I think it's what will have to happen. Maybe you can have the local opt-out flag as well. Opt-in flag means: "I will let you know when I'm hacking", opt-out means: "This is a place I am hacking" 

Other than a missing precache, causes Quake to crash without error?

Dusting off my coding skills and this has me stumped.

No errors in the compile either.. although I am running FTEQCC. It's definitely something I've done recently though. 

Best advice I can offer is call traceon() in the worldspawn function, then run with -condebug on. You'll get a massive log file, but you probably only need the last few lines to find out what runs immediately before the crash. Otherwise, maybe try a few different engines, darkplaces will often tell you something that other engines don't. 

infinite while loop? had that a few times 

Another crasher: whatever's happening on e2m2 when you pass the front gate without shooting both buttons on easy skill. 

Will get this figured out. 

Preach,

So recently, I treat QuakeC as if it were an OO language in that I ALWAYS create new .variables for all entities.
I do this mainly for readability/clarity reasons after getting burned when trying to make sense of some older code that was using things like t_width and lip all over the place.

Of course, now every entity has like an extra 100 variables attached to it. While it's unlikely to really impact the code much (it's not like we're lacking memory or processing power here) it does bug me a little in that it's not really the right thing to do for this language.

So... would the proper course of action be to declare a handful of invisible fields:

internal_float1__ ... internal_float10__
internal_vector1__ ... internal_vector5__
etc...
and then overlap the same fields with unique names? 

It could work, but you've got to be really careful that you're never overlapping fields that will cause problems. You don't need to give them names like internal_ etc, you can just pick one name as the original and overlap the others on that.

Doing this kind of overlapping in monster code might be safest. Make sure each monster has its own QC file, and define the overlapped field name at the top of the monster's own QC file. Then you can make sure all use of these fields is localized to functions in the one QC file. To be doubly sure, instead of using the "var" keyword to overlap, use a #DEFINE macro to give the field its name, and then undefine it at the bottom of the file. Then you only need to watch out for other QC files calling your functions (and map-hacks).

What would be really nice would be a sort of QC++ compiler which creates the idea of a "class". It would let you subclass entities, have functions that only accept particular classes of entity, and prevent you accessing entity members which aren't defined for that class (or parent classes) at compile time. Then the compiler would overlap private fields for you safely.

This isn't quite as crazy as it sounds, the original C++ compilers were source code transformers which output C code and then called a C compiler to build it. A fun project for someone who wants to learn Lexers and Parsers... 

After rolling back everything - models, sounds, code, maps I still got the crash on map load.

So I open up the map and clean out the values I'd added to control the enemy in question, and that solved it.

pose 0
skin -1
cnt 0

One of those was the guilty party I'm assuming the skin value - I was using -1 as 'random'.

(this is about a crash I mentioned earlier in the thread, thought it might be of passing interest) 

I can imagine how that might cause a crash, yeah. Setting fields to zero in a map should do nothing at all, fields are zeroed to begin with. The -1 on the skin might do it though! The engine probably uses -1 as an offset into the skins array, and reads some random memory just before the site of the model data. If you still want to live dangerously and use -1 as the "random skin signifier", you can probably do it just by altering your QC a little - handle the -1 case and randomly select a skin before any call to setmodel. 

With a skin of -1, MSG_WriteByte will coerce the value to a unsigned char, which I think gives it a value of 255? Then the client gets the 255 and and uses that index to look up the gltexture in an array. This array access is probably out of bounds, causing the crash. 

So when I cleaned up the code and put setmodel / setskin in the right places it broke...

I had to delete a lot of stuff, but I don't see it as wasted time - now I can build it much quicker and better.

It's for an undead enemy that 'hatches' from dead marine corpses - the unlucky guy's own skeletal and muscular structure, minus the skin. 

Another fun way to go out of bounds with skins is to use a skin coordinate which goes off the edges of the skin. GL engines handle this fine, they start tiling the skin which is very handy. Unfortunately software engines just do blind pointer arithmetic, and so start rendering the rest of the model data as if it were the skin... 

I understand the problem well enough now to think of a workaround. A lot of the bad practices in Quake (mapping, sounds, coding etc) aren't really documented anywhere clearly and exist as generally known knowledge, making it hard to know it all...

Thanks for the help :) 

After playing Something Wicked This Way Comes. I started thinking about the expansion of the BSP format, the VIS times involved in expansive maps, and the task of managing large maps in an editor. Has anyone tried to create an engine/QC that would allow information sharing over multiple bsp files? I think that making the BSP format larger is one way to make larger maps but the time to compile/test/compile is going to be a problem. Fixing one end of the pipeline at the expense of the other. Wicked could have been split in two, both halves in memory and the textures loaded, a transition would be almost instant. I'm not a coder but that seems better than making vis run for weeks. 

Vis doesn't need to run for weeks. What Quake is really missing is its own method for doing detail brushes.

If you look at those massive towers in something wicked, you'll see that they're both func_wall - noclip out of the world and they'll vanish.

If those had been part of the vis process then it would have taken significantly longer.

What the RMQ engine does to enable stupidly big and complex func_walls is to fix the entity flicker bug.

Normally, if you try to have a func_wall that stretches across various vis leafs, it flickers in game as the player moves between the different leafs.

With this bug fixed, you can make a func_wall that spans across practically a whole level, with lots of small details, curved surfaces or whatever and doesn't impact vis time at all.

There is of course a trade off in performance, but seeing as vis was designed to work on 1997 hardware - with 8K of ram - this point is pretty much moot.

These tools aren't automatic though, and a certain amount of technique must be learned in order for them to be used.

I'm far too impatient to vis a map for anything over an hour - and I don't want levels that are choppy either. 

Is work continuing on the RMQ engine? I hope it does because it's performance is so much higher than other engines like Fitz which is much more interesting to me than extra eye candy :/ 

I know a lot of mappers use func_wall like detail but I always have problems with their shadows when aligned to world geometry. An object which is part of a wall will cast better shadows than the object as a func_wall placed against a wall.

Personally I think the compiler tools could do with some upgrades more than allowing mappers to create long range shooting galleries.

* Consist lighting across bmodels and geometry.
* bmodels having a minlighting options so it is easier to get rid of solid black surfaces.
* Having external light maps so the lightmap density can be increase (would need engine support)
* Being able to having textures with phong shading (probably need a new compiler tool to split the surfaces off in a separate area of the BSP for the light tool to work with them.)

Some of the most radical visual/mapping upgrades to Q3 was when Yndar was working with the compiler tools. I am sure it was the same when Bengt Jardrup worked on the Q1 tools. 

this is interesting... what exactly is it, and how does it work? ie: external vs internal, is it just upping lightmap resolution?

I am sure it was the same when Bengt Jardrup worked on the Q1 tools.

Pretty much. It was a huge loss when he moved to q2. He consolidated like a dozen different compilers together and his work on the light utility in particular was amazing, not to mention vis progress saving. 

Don't know - Mh was working on it.

The lack of shadows can be an issue, I tend to avoid it for large objects by placing a simplified mesh inside the func_wall - just a block usually, which won't upset vis but still give shadows.

Not perfect shadows, but the resolution of the shadowmap isn't great in any case and small details are usually lost.

For external lightmaps do you mean direct access to the lightmap texture? I think it can be extracted from the bsp, though not sure how.

And yeah, Bengt did amazing work to consolidate and improve everything. 

@necros, external lightmaps are large (usually tga) files which only have light data. They are external because the internal bsp format only supports small light maps. By increasing the size of the maps the lightmaps on objects can be bigger (less fragments) and high density for remapped on to the relevant compiler surface. To create this feature would require a lot of effort to include in the Q1 compiler tools.

The most linked article on external light maps! :P
http://sgq3-mapping.blogspot.com.ar/2009/01/using-hi-resolution-external-lightmap.html

Probably the most annoying thing about light maps is that they are rarely consistent across multiple object types (brushwork, models, entities) and will produce different results depending on how the compiler tools organize/sorts them. Even Quake 3 with all of its fancy features still has different compiler pipelines for models and brushwork which can cause strange lightmap errors.

Some examples of weird lightmap errors:
http://www.quake3world.com/forum/viewtopic.php?f=10&t=46294&p=901394&hilit=#p901394