you mean fteqcc?
anyway, thanks. :) 

What is the maximum centerprint length?
Does it matter if you use the extra centerprint that allows multiple arguments?

Fitzquake has a bug that allows longer centerprint strings, but Quakespasm 'fixed' this, so that strings that display fine in Fitzquake spam the console with errors and truncate the string in Quakespasm.

:( 

http://www.inside3d.com/qip/q1/qcenhanc.htm#centerprint

From the page :
* The maximum number of characters in one string or multiple strings printed at once is around 2000.
* The maximum number of characters per screen line is 40, independent from the current resolution.
* The maximum number of lines per screen is 13, as more will cause weird problems in 320x200.

The links says max 2000 chars but 13 lines of 40 characters is 520 total. I assume Quakespasm is not liking those above limits? 

I brought this up before, and iirc, the 'limit' was actually higher than it should be. Apparently, the centerprint had some kind of unchecked thing which allowed strings that were too long to go through and it was only through luck that data wasn't being corrupted somehow. (and probably why it was never noticed?). 

I've got a bmodel with MOVETYPE_PUSH and SOLID_TRIGGER that moves via velocity.
Normally, I can be inside this entity when it moves.
For some reason, if I touch a rotate_object (which has no touch function, is MOVETYPE_NONE and is SOLID_NOT), the moving trigger bmodel becomes blocked! (it runs it's .blocked function too).
It's the weirdest thing ever... 

This sounds like it might be quite a specific problem and so hard to reproduce, can you e-mail me a map/progs that displays the behaviour? 

This might be a little opaque for anyone outside of me and necros.

The engine code underlying this problem is quake's blocking detection system. It's crude to the point of being technically incorrect, but infrequently enough that nobody has cared - before now. When a door moves, each entity is tested against the door:

Is the entity within the bbox for the door?(i.e between its mins and maxs, not exact intersection) If not move on.
Is the entity currently stuck? If not move on.

At this point the code attempts to move the entity the same distance as the door moved, in the hope this pushes it clear.
To see if it worked, we test again if the entity is stuck.

If it is stuck, we declare the door blocked and revert all the movement for this frame.

The flaw in this system is that we only test if the entity is stuck, not if it is stuck in the door. You can test this with a map with a func door which encloses the player without touching them in any way, combined with a solid brush which impales the player inside. The door will crush you without ever making contact.

Here endeth the general lesson. Specifically for necros: Your post missed something important out, the func_pressureBolt is MOVETYPE_FLY, which apparently causes the player to count as stuck and hence block the trigger. You set MOVETYPE_NOCLIP at line 73, but change to MOVETYPE_FLY at line 95. If you delete line 95 your trigger will work again.

If you are worried this class of bug might recur in other circumstances, I can outline an alternate design which uses a static rather than moving trigger, just ask! 

If you hadn't found the solution, I would have done the trigger movement via setorigin (since there's no collisions to check (beyond .touch of course).

You set MOVETYPE_NOCLIP at line 73, but change to MOVETYPE_FLY at line 95

*sigh* man, one day I need to rewrite my code... that's just sad. :P

But yeah, you are a genius man. I never would have imagined the rotation controller entity was behind the problem. Both it and the accompanying rotate_objects are SOLID_NOT. Why would the engine even check collision if it's not solid? Maybe because movetype_fly was intended for use with projectiles?
Very strange!

Thanks for yet another awesome bit of quake wisdom. :) 

My suggestion was going to be have a trigger which starts off at full height. Then just add

��if(other.mins_z < self.owner.maxs_z)
����return;

to the touch function for that trigger. Here self.owner is the visible moving entity which marks the upper end of the trigger. If there was no visible part you could calculate the height mathematically based on the time since triggering.

I'm still not sure why MOVETYPE_FLY matters, it might also be tied up in using a bsp model for the func_pressureBolt...the physics code is pretty dense and circuitous. 

Is this also related to that bug where a lift moving up/down will get the player 'stuck'? I had it happen more on some lifts than others, for example, that big lift in ne_ruins with the rotaters did it so much, there is actually code that sets the blocking entity's origin 1 unit up to stop the player being crushed. 

Can that physics issue happen in DirectQ or the RMQ Engine? Both those engines have very intricate physics fixes that essentially make sure that the physics always run at Quake normal speed.

I ask because it is an engine physics issue, that isn't something you should worry about too much because MH has the cure that needs to get into other engines. 

"I ask because IF it is an engine physics issue" ... [basically can you reproduce the problem in the RMQ engine or DirectQ with that lift? If not, maybe mentally mark that problem off the proverbial list ...] 

you can test to see if it's happening by going loading ne_ruins, turning on dev mode to 1 and riding the lift up.
It's very random and may or may not happen, but you will see "corrected bmodel collision bug." if the qc detects a block that shouldn't happen.

it doesn't happen in DP, so if the collision fixes are as extensive as it is in DP, then it probably doesn't. The collision in DP is really sweet. 

That's enough info then. Yeah, DarkPlaces is fixed up in that way as well (and has been for ages and ages).

I wouldn't spend any time worrying about this one.

I intend to extract the fixes from RMQ/DirectQ and more or less document how to implement them.

[I just haven't done it yet because of the things on my list, well, it's kinda boring and tedious ... ] 

I'd like to check something with people who are familiar with the BSP file format. Suppose we have a very simple map with one room containing a func_wall. The room has 20 faces and the func_wall has 6. Is it correct that there is just one list of 26 faces in the bsp:

0
...
19
20
...
25

then the model headers go
"world: I own 20 faces starting at face 0"
"wall: I own 6 faces starting at face 20"

The same then goes for vertices, nodes etc, that the bsp file collects all alike data types into a single list and each model in the file operates on a subset of that same list? (with exceptions like textures which are instead shared).

Why? I was thinking about the external bsp models trick - initially I was just trying to write a tool to pack them back into a single bsp for release. However, if the above is correct, it might also mean that the external file gets a new lease of life - as a limited way to help maps which exceed bsp limits  

interesting...

rezTarget.think =
rezTarget.nextthink = time + 0.1;

compiles fine with fteqcc, but flat out crashes quake. :P 

Yes, that's the way everything is stored, but there are subtleties.

"Faces" as you understand them in a map have little relationship to surfaces in the generated BSP file. QBSP will remove faces (facing out, never visible, overlapped, etc) and generate more from splits, so you can't really use the map file as any kind of guideline to what the BSP will contain.

Regarding use of external BSP models, you can use them to go through BSP limits, but lighting will be wrong for them. Lighting for an external BSP model doesn't take account of any geometry in the world that might occlude those lights, and they fail to get dynamic lights. That might be OK with you, but it might not be OK with someone playing your map. 

That's good to know.

On lighting: Although losing dynamic lights is a shame, I don't think that the static lighting is much of a obstacle.

Although I've been talking external bsps in general, the best use-case for external models is for objects that rotate or move. Static lighting of course can't get these right, so there's less worry they might be lit "wrong". Along the axis of rotation it makes more sense for the lighting to be uniform, instead of baking in a shadow which will be wrong as soon as the object moves.

For statics moved outside the BSP for limit reasons only, I suppose it's not impossible to write a version of light that applies occlusion from a base map onto an external bsp (using the code-path from the light executable which occludes lights on models 1-n based on the geometry from model 0, except loading model 0 from a different file to model 1). Think I'll stick to the bsp packer for now though... 

Dynamic lights can be fixed in-engine; there's a (slight) performance cost but the visual consistency is more than worth it. I have it in my current (unreleased) codebase, but I don't believe any other engine has implemented it yet (aside from those with fully real-time solutions).

Along the axis of rotation it makes more sense for the lighting to be uniform, instead of baking in a shadow which will be wrong as soon as the object moves

Definitely agree with that.

I suppose it's not impossible to write a version of light that applies occlusion from a base map onto an external bsp

It's an interesting idea. It would break if more than one entity used the same BSP model (an example would be a generic door modelled as a BSP) but for limited special cases it should work. 

would it be possible to make an 'fake ambient occlusion' mode in light.exe such that, when enabling it, it creates an array of suns like it does with sunlight2, except that these suns do not require sky textured brushes?

that way we could make some external brushwork and get some nice shadows that look good from all rotation angles.

heh, maybe I should do that... I'll see if I can puzzle it out. 

http://necros.slipgateconstruct.com/temp/sillygi.jpg

hmm, seems like it was easier than I thought it would be. o.0 

http://necros.slipgateconstruct.com/downloads/ne_ag_LightMHColourR2.zip

This is based off of mh's coloured light/multicore tweak of aguirre's light utility, so it has all the good stuff.

Two new command switches are added:

-fakeGISun2
Makes sunlight2 cast additive light in a full sphere (as opposed to a dome).

-fakeGIMode
Makes sunlight2 not require skybrushes (ie: the light comes from the void)
NOTE: REQUIRES -fakeGISun2

Also note you need to set the worldspawn keys 'sunlight' to '1' otherwise it's not activated at all and the 'sunlight2' settings should be low, 2 or 3. 4 is pretty bright.

I basically just turn off the check that requires sunlight to pass through a skybrush first, so with -fakeGIMode, the sunlight comes from the void.

Source included. Some small changes to LoadEntities() and TestSky() and maybe one or two other tiny things I've forgotten. 

The spherical illumination might also be handy for coagula style maps. 

not bad results on space maps with only the fake gi light enabled: http://necros.slipgateconstruct.com/temp/nesp10GI.jpg

Might be cool to do another space map one day with this lighting. The only thing is that exposed faces tend to look flat. The above screenshot is only interesting because of those high walls. 

That actually looks pretty cool; kinda radiosity-like.