An impossible bugfix...

[ajay]

.. maybe

It's been ages since I've played the mod in other engines than DP.
It's been ages since I've tried to go up and down the two func_ladders.

Anyway, I was having a little scoot round the map, and tried to go up a ladder. Nothing happened. I went to the other ladder in the map. Nothing happened.

Even though I was sure DP worked fine with the func_ladder code I tried the map w/ FQ and DQ, they wouldn't load it, tried an earlier version of the map with no incompatible models. It loaded, but weirdly now I couldn't move the player, I played around with the controls; all was fine. The player just wouldn't move, not sideways, up or forward/backwards. (The player wouldn't even move when on a platform...)

My problem is that so much has changed since I've tried the ladders or other engines, that tracking the bug is going to take ages, so my question is:

Is there a known error that would break all movement in FitzQuake and DirectQ and just the func_ladder movement in Darkplaces??

Fingers crossed.

EDIT: I've not put this in a specific forum as I've no real idea what it relates to...

[leileilol]

What kind of func_ladder code are you using? TomazMod? p0x Extras r4? DPMod?

I know the p0x ones break on darkplaces because of per-frame gravity check abuse, kind of the inverse here.

[ajay]

Sorry, was in a rush posting that (sunshine, fun and an excited 9yr old here) I'm using Extras r4...

[Spike]

the pox ladders, I think - if that's the ones in RMQ, don't work properly in DP because they set the velocity to a fixed value, and move only if the velocity is large enough (meaning the mod keeps clearing out the velocity preventing the player from accelerating fast enough to trigger any motion). dropping your client framerate in DP to about 20 should make them work again, but its not nice, which may be why you thought it worked in the past. The fix for this is to use .movement instead of .velocity to calculate the player's desired motion (FTE has the same problem, and same solution).
The same ladder code also does some nasty self.origin assignments, which is fatal in quakeworld engines (quakeworld has no 'oldorigin' field to repair the origin damage when stuck, and instead trys to find a nearby safe spot, which in this case does not exist), but could probably also cause other engines to get stuck if they're unlucky with their BSP collisions.

[mh]

The only thing I'm aware of that could cause the "player not moving" symptom is if DP has different clipping hull handling, or generates different-sized server-side bboxes for entites (perhaps based on the actual model dimensions rather than using those defined in the QC). I have seen one other map where the same thing happens in every engine aside from DP; in that case the player was started off in a fairly tight tunnel. I ddn't investigate it much so I can't be certain, but I would be of the philosophy that if it breaks in everything aside from DP, then it's probably broken to begin with (or at least reliant on behaviour that's a good way off the Quake standard).

[ajay]

I know it must be something major-ly off-standard, but I'm really struggling to find it.
I did fiddle with stuff when making trailers, but I'm sure I've put it all back to standard and commented it all... bugger
Thanks anyway, I'll keep searching

Edit: I ran a standard Quake map, but with -game earthquake. I could move in fitzquake. So does that mean problem with the map? Would all the BSP standards that its exceeding cause this?

Or would a particular model or other entity thats loaded with the map do this?

Oh lordy!

[Spike]

is if DP has different clipping hull handling

It does.

Hulls are offset based on the mins of the entity's bbox and the hull size. This is true for all Quake/QuakeWorld engines (that have hulls, anyway).
To clarify, BSP collisions are based on the effective absmin, rather than the origin itself.

Normally, setmodel sets the size to '-16 -16 -16' '16 16 16'. DP sets it to whatever size the model is meant to be.
If you don't do a setsize after calls to setmodel (for mdl models anyway) then you get different min sizes in DP from other engines, and thus different hull offsets. Which means that your start spots need to be moved up or down, or anything moved to that origin with a different mins. Or something. Same problem as the key missing in some e3 map.

Additionally, DP does single-recusion traceing as an optimisation. while other engines tend to walk down the nodes multiple times to check their solidity, though I'm not sure that this would noticably fix anything.

[ajay]

So, I changed setsize in PutClientInServer (just to test it) to -16 -16 -16', '16 16 16 and now it player movement is returned to FQ and I can go up ladders in FQ.
Still cant get up ladders in DP tho' ....