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 

That looks similar to making lightmaps in doom3.

I guess the compiler would need to both export the lightmap as a texture AND output uv information for the bsp faces being mapped?

I don't know how likely someone can do that for q1... 

Looks very similar to what you could do in ut2k3, making entire levels out of meshes that were pre-lit in Max/Maya.

crappy screenshot

Was a gorgeous effect if used properly, fantastic lighting and such (on the environment at least), given that ut2k3 didn't have any kind of light bounce and meshes were purely vertex lit... problem was building an entire map in Max was a bastard :( 

Yeah, that was the same thing for d3. I found building maps in max to be much easier too, because you could make complex shapes much more easily and utilize the scripting capabilities to quickly build stuff. 

Do models have their own centre point that Quake somehow reads?

I'm trying to swap models and my enemy is getting stuff stuck in the floor. I set the bbox manually, but it seems to get confused depending on when I make the walkmove! check.

Might be better off just setting model to null until it needs to be alive and using a .entity for the other version. 

There's an 'eye plane' or something like that, but AFAIK it's just some helper that Qme included and didn't actually do anything. 

There is an origin on quake models. You need to have the model's feet 24 units below the model origin in order for it to line up with the ground. 

Need to throw more DropToFloor experiments at it.

What's 24 units in normal dimensions? I googled a bit and this: http://www.gamers.org/dEngine/quake/QDP/QPrimer.html

Tells me it's 72cm...

Feel like I should know all this stuff, but its the first time I've had this problem - or maybe just the first time I've noticed since I'm mixing legacy with new assets in the same monster. 

The engine bounding box plays a role in determining the position of the model as well.
eg: '-16 -16 0' '16 16 64' is not the same as '-16 -16 -24' '16 16 40' 

That's probably it then - I've been getting odd behaviour and after the previous problem tried changing the order of where I was defining the box / changing the model asset.

Sure enough, things got free that weren't stuck before.

Weird how it was done. Especially using imperial measurements. 

hold on... i might be wrong on my last post... it's been a while since i've messed with models and bboxes too. :S 

Well, I'm going to be redoing the mesh from scratch anyway, but want to get something lashed together in the code for now anyway.

So will have to experiment and see what works.

FYI it's based off that model you sent me some time ago, although I've modified it pretty heavily into something else now, next step being an updated mesh... 

Thanks for the help :) 

How do I get a flyer to prefer to be higher than the standard 'eye level' fly height?

Searching around, it seems that movetogoal is the answer, but this is in the C code apparently and I want to stick to qc.

I don't exactly want a B0b vertical dodge - although that could be useful as well for when it's in hunt mode. 

Look at rubicon 2 source, I have a hard-coded min and max altitude that can easily be changed. The trick is using an invisible dummy entity as .enemy to trick movetogoal into seeking the desired altitude. 

That's how i've done it too. Here's my implementation: http://mobile.sheridanc.on.ca/~jonescor/temp/ne_q2hover(01.09.13).qc 

Thanks guys.