News | Forum | People | FAQ | Links | Search | Register | Log in
Fitzquake 0.85 Released At Last!
New in this version: increased map and protocol limits (can load all known limit-breaking maps,) model interpolation, per-entity alpha support, new network protocol, more external texture support, hardware compatability improvements, many bug fixes, and a cleaner source release to make it easier to install and compile.


(Thanks to the beta-testers: Baker, JPL, negke, Preach, and Vondur.)
First | Previous | Next | Last
Apsp1 Platform Bug 
I was playing apsp1 in quakespasm last night and noticed the mis-positioned elevator that mfx mentioned seeing too:

The bounding box is fine, so it doesn't affect gameplay, but it's just rendered in the wrong place.

I tried some different engines, and the problem started in Fitz 0.85. Fitz 0.80 is fine, as well as glquake/winquake. The lastest Darkplaces has the problem too though.

This is the entity text, from opening the bsp in a text editor:

"classname" "func_train"
"angle" "-1"
"sounds" "4"
"speed" "184"
"target" "3f_lift_p1"
"dmg" "5"
"noise" "plats/plat2.wav"
"noise1" "plats/plat1.wav"
"targetname" "tllift"
"model" "*10"

If I put a breakpoint in R_DrawBrushModel, e->origin is (0, 0, 0) and e->angles is (0, -1.40625, 0). The second component of e->angles seems to be related to the problem, if I zero it before the R_RotateForEntity call, the plat appears in the correct position. (I don't understand why adding a rotation to the OpenGL matrix shows up visually as the plat translated diagonally.) 
I have seen this before. The root cause is that func_train should not have an "angle" set. So I could blame it on the mapper. But, under most engines the -1 is rounded to 0, causing no visible problem. Therefore it's hard to blame the mapper when the engine came out years after the map!

Fitzquake (and apparently Darkplaces) round the angle to the nearest representable value instead of flooring it towards zero, resulting in more accurate angles for rotating entities. However as you can see, -1.4 may be closer to -1 than 0 is, but -1.4 results in the mapper's harmless error now being highly visible.

As to why the small rotation appears to be a diagonal translation, remember that bmodels have their origins at the world origin, so a small rotation around the world origin would result in a large lateral move for the visible geometry of the lift.

The solution may be to disable the "improvement" of better rounding for angles. 
Ah, Good To Know 
I remember seeing this with a lift in A Desert Dusk too, and, checking the bsp, sure enough it has a func_train with "angle" "-1". 
Rounding toward the nearest value is actually what the Quake code attempted to do, but did it wrong (due to an int cast of a float rounding toward zero, but the Quake code assumed it rounded down consistently).

So I'm both a little unnerved by the error, and inclined to blame it on the map rather than the engine, I could do a spot-fix for this specific map name but I don't normally do any spot-fixes for anything in the engine as I believe in having no map-specific or model-specific logic anywhere in the engine.

A .ent file could easily fix this...

sv_saveentfile while playing it, and then edit that one entity in there and any future loads will use the modified .ent file instead of the data in the .bsp.

A more important issue is that this angles is going to affect the MOVETYPE_PUSH directly because darkplaces supports rotated (and rotating) plats, so there is a physical difference here.

An alternative - however with unknown side effects - what if the engine chose to ignore incomplete vectors when parsing the entities? Because angles is a .vector field in the progs.dat, it is being parsed as a vector, it is an incomplete vector whose value is just "-1", right now this gets expanded to "-1 0 0" but perhaps it should expand to "0 0 0" due to incompleteness? 
i feel this is just a map bug that went unnoticed due to an engine bug.

the problem lies with the map. 
Angle Vs Angles 
Just to clarify, this is "angle", so that second approach I mentioned won't work as this isn't an incomplete vector.

A spot fix for specific map names to ignore "angle" "-1" seems to be the safest solution but still a complete hack and I don't like hacks. 
One Specific Workaround 
The engine could detect the following combination:
classname == func_train
origin == 0 0 0
angles != 0 0 0

And clear the angles in that case.

Any entity with origin 0 0 0 that is using angles is suspicious, but a func_train is highly suspect. 
I believe the cause for this is a mapper who started with a func_door with angle -1, then later changed the classname to func_train/plat to get better behavior, but didn't clear out the "angle" key.

As to the question of fixing it with an engine hack, i guess testing for "func_train" or "func_plat" with angle != 0 would be a fairly targeted way to do it. It's a hack no matter what unfortunately, and I'm not 100% against hacks (for example i put in a hack for the large shell ammobox texture) but what worries me is we don't know the complete list of existing levels that have this problem. 
I believe the cause for this is a mapper who started with a func_door with angle -1, then later changed the classname to func_train/plat to get better behavior, but didn't clear out the "angle" key.

To be clear, i mean that of the 3-4 cases I know about, the cause seems to always be the same. 
(not That I Know About Func_trains) 
but if they're not supposed to have angles, why don't you just always throw it away? 
quakec could do that. Engine doesn't know what is supposed to have what. 
Func_train Angles And Origins 
In engines that support rotating platforms (which darkplaces for example does), I can't just throw away angles on func_train automatically.

But in the specific case that the func_train has origin 0 0 0 (which is the default for any brush model), the angles make no sense - as it would just orbit around the center of the map. 
That's something I could see in abstract maps though. 
fair enough. I was assuming that all mods with rotation support would use func_rotate_train isntead, but i guess that isn't guaranteed. 
How bad would the side effects be of reverting to the original rounding code? whereabouts in the code is the rounding?

The hacks do sound dangerous to me, unless they were restricted to the known filenames with this bug.

The only good news is mappers won't make this mistake on new maps, since most SP mappers probably test in a fitz0.85 derived engine and/or darkplaces. 
The rounding is only for the networking (I.E. visual only), if the engine supports rotation in the underlying sv_phys.c code, then even if the visuals are not rotated, the physics will be (leading to a rather confusing jump and fall-through in this case).

DarkPlaces supports that, so I can't really just revert my rounding change.

Furthermore, the same rounding change gives a significant improvement in aiming, where it is widely known that stock quake has kind of a "down and to the right of the crosshair" characteristic, the aiming is more accurate because of this rounding fix (although darkplaces goes further and uses 16bit angles for aiming so you can hit a pinpoint location across the room). 
Negative Angles 
It is okay to throw away negative angles for a func_train.

Even in DarkPlaces, negative angles don't make any sense (except for func_wall or func_door where -1 and -2 have special meaning) because negative angles are invalid.

Rotated brushes/entities in any map editor have positive angles from 0 to 359.999999.

[This excludes the idea that someone would write custom func_train code that supported angles, but even then the values would be positive]. 
FitzQuake Sky Slowness 
My main reason for bumping this thread is this.

FitzQuake renders rather slow compared to other engines because of the sky. The sky draws first and in the case of a skybox, it literally draws the entire screen.

I'd like to Z-fail the sky, but I want the fog to render on the sky in the proper FitzQuake manner. And I'm not entirely sure what process sky entities does.

I always use A Roman Wilderness of Pain (arwop) map ROMAN1 as the example of an fps killer in engine testing. In Mark V, I get 20 FPS. DirectQ gets an insane 169 fps. In other engines, typically the fps is close to 30, which sounds low but is a 50% improvement over FitzQuake. (Even on a low end video card, some other engines often are hitting 600 fps with ease on id1/start.bsp and the FitzQuake renderer struggles to break 300).

FitzQuake does rendering far better than other engines, in my opinion, but the slowness is an obstacle and I think it is exclusive to the sky.

[There are other ways to increase the FitzQuake frame rate, like using 3 texture units to draw texture, fullbright and lightmap in the same pass, instead of using 2 texture units, but even if I essentially disable that with gl_fullbright 0, I still get 20 fps on ARWOP (no improvement).] 
with modern graphics cards, fitzquake could draw skyboxes using a cubemap (directly rendering the sky faces instead of drawing an actual giant cube.) And for the classic scrolling sky, i think you could do it with a pixel shader. 
To Disagree 
[This excludes the idea that someone would write custom func_train code that supported angles, but even then the values would be positive].

I don't think engines should make this kind of assumption based on the mods that exist today. Suppose someone writes a mod that unifies func_train and func_rotate_train under the former name. Then a negative angle is a deliberate signal to the mod - make the rotation towards the next waypoint move in the positive direction. 
Baker, I'm surprised sky is a bottleneck.

If I make Sky_DrawSky return immediately without drawing anything, I get essentially no change in fps. This is with a fairly fast cpu (2.3ghz i7), 2 year old laptop gpu (nvidia gt 650m).

For me over half the time in the roman1.bsp starting position is spent drawing entities (mostly on alias models), a bit less than half drawing the world. In Mark V I get 90fps, 205fps with "r_drawentities 0" and 135fps with "r_drawworld 0" (but r_drawentities 1). Try setting those to draw only the world / only entities, to see relatively how much time is spent on each. 
sky is expensive in terms of overdraw - if its drawn fullscreen anyway.
the vanilla code is ugly as heck, it warps in a horrible way as you move around.
the skybox code that seems to be fairly abundant has a few issues with certain situations, like side windows, that increase overdraw unnecessarily, which can be expensive. a good example is dm2, where the side windows (that noone remembers are there) result in the sky basically covering the entire screen.

it can be significant when you're framerate limited, but at least the worst-case is limited to (less than) only half the framerate. 

I suppose so, I hadn't considered that. The traditional func_train would never move up/down like a door or plat. ;)


Load up a skybox and instead of not drawing the sky, don't draw the world.

Now I understand what you say in regards to speed, I'm not blaming the fps in arwop on the sky (make no mistake) -- if you load up ARWOP and in Mark V and type in "cl_shownet 1" and then type "sv_cullentities 2" (which is DarkPlaces/FTE anti-wallhack level of culling server-side) --- you will watch the network traffic drop by 2/3rds --- ARWOP is a prime example of a beneficiary of network optimization (DarkPlaces and FTE probably breeze by it).

But I think the sky may be costing 100 fps on a map like id1\start.

I'll be finding out ... 
And By The Way ... 
Make no mistake, I love the FitzQuake renderer, obviously.

The sky has been bothering me for years! And it reared up yet again.

The way the rest of the rendering works, I have never been able to determine or intent of the sky drawing the way it does --- everything else in the engine is clearly a clockwork and quite deliberate.

My only guess is to render fog on it consistently. And I intend to find another way to do that, if so. 
Goals of the fitzquake sky rendering:

* sky should only be visible when looking at a sky brush, not void
* if a sky brush is in front of some other geometry in the PVS, you should see sky, not the geometry behind it.
* brush entities with sky texture on them should look like sky too
* sky should be rendered as if it was a giant cube, and should not be distorted by the actual geometry of the sky brushes or the movement of the camera

So what i do is clear the zbuffer, then draw all the sky surfaces (brush faces) untextured (to write to the zbuffer), then draw the skybox with the depth-test reversed so that only farther objects pass the test. This means the giant, distant box of the sky will only appear on portions of the screen where the sky brushes were already rendered. Then I draw the rest of the world, and since the sky surfaces have correct depth values, they occlude any polygons farther away.

Even when drawing the scrolling cloud sky, i use a giant cube that has been subdivided enough to approximate the dome shape (r_sky_quality controls the subdivisions)

There's also some code to attempt to draw less than a full box, when only part of the screen shows sky. This was disabled for skyboxes (couldn't get it right at the time, due to tjunctions), but enabled for the cloudy sky (since it's subdivided into a grid anyway, there are no tjunctions.) 
I've been looking at MH's home work, and because I want any speedup I do to render identical to FitzQuake 0.85, I think I'm going to try this:

1) Instead of drawing the sky first, run through the sky texture chain + sky entities and see if any sky surfaces are visible. Set frame_skyshown to true or false.

2) Provided frame_skyshown, at end of drawing instead of beginning, either do a sky surface stencil pass or draw with glColormask (FALSE, FALSE, FALSE, FALSE) using sky surfaces + sky entity surfaces.

3) Then use the drawing code more or less as-is.

I understand the trickery of handling the skybox, ironically the software engine Makaqu supports skyboxes in WinQuake and draws the skybox only on those brushes (and it looks perfect too).

While tempting to give that a shot in Fitz, I think I'll try the more simple method outlined above at least at first.

Hopefully, it results in some fps. 
Stencil buffer sounds like a reasonable way to do it. At the time I didn't want to introduce a new hardware requirement but since every card for 15 years has had stencil, it's probably safe :) 
In Fitz 0.85's Host_Game_f (), do you remember why this is commented out?

//Cbuf_InsertText ("exec quake.rc");

We were discussing re-adding it in Quakespasm. Not doing it creates a disparity between the "-game" flag and the "game" console command, where "-game" will exec the mod's quake.rc possibly with custom settings, but "game" won't. This is a problem for some mods, e.g. those that set an increased max_edicts required for their maps in their quake.rc.

The only issue I can see is execing quake.rc might trigger a video mode change, if the gamedir you're switching to has some different vid_width/vid_height saved in the config.cfg. But it's easy to work around that with the vid_locked mechanism. 
both are annoying every time you change gamedir. and yeah, engines that unconditionally shove a vid_restart into configs are annoying too.

if you can change gamedir without any side effects then you're a miracle worker.

your current settings getting wiped is pretty annoying too, if you bind your controls then change gamedir.

changing gamedirs without restarting is actually quite complicated if you want to to do it properly. plus its annoying if its not done properly.

FTE checks if the various configs change over the gamedir change, so it doesn't oblierate settings if there was no point in doing it in the first place. this helps reduce how annoying it is. There's still other issues, but they don't appear as often thanks to this. :P 
I originally added that line for the same reasons you want to resurrect it; to help make the mod's configuration closer to intended. But I disabled it because i encountered a lot of awkward problems as mentioned by Spike.

I decided it's better to do to little rather than too much, in this case.

I still think the config behavior is awkward, due to the fact that it only saves when you quit, and this means only one mod dir gets the updated config. I had plans to save it before switching mods, so the mod you are leaving gets any modified settings you created while in that mod.

It's still weird, though; and there are some settings that should probably be engine-specific vs. mod-specific, like graphics and audio settings. So there really should be two configs, one that is always stored in id1 and the other that is saved per mod. Each cvar would know which config it belonged to. 
Engine-specific Configs 
A system where engines effectively intercepted the "exec config.cfg" command and converted it to the moral equivalent of "exec config.cfg;exec fitzquake.cfg" could work, especially if engine specific persistent variables got saved to that custom file instead of config.cfg itself. 
Thanks For The Hints 
It sounds like the best option for QS right now is not changing anything and just document the behaviour/bug. 
So much old mods that can be broken by these sort of changes. 
Viewmodel Lerping Bug 
I saw an interesting bug report on quaddicted by NoNameUser, here:

Also, "r_lerpmodels" is set to 1 by default, but the weapon models lose their smooth animations outside the start map; monsters are ok, though, and everything else seems fine too. I've had this problem with the weapons animations with other mods too (Warp Spasm, The Horde of Zendar, and others).

I was able to reproduce it in two big maps (warpd.bsp, zendar.bsp) on various Fitz engines (0.85, QS 0.90.0, MarkV). What was happening was, this condition in CL_ParseClientdata was firing every frame, even when I wasn't changing weapons:

if (cl.viewent.model != cl.model_precache[cl.stats[STAT_WEAPON]])
cl.viewent.lerpflags |= LERP_RESETANIM; //don't lerp animation across model changes

The cause was, the above check was done before handling the SU_WEAPON2 byte, so only the bottom 8 bits of cl.stats[STAT_WEAPON] were set, which would cause the test to always fail if the weapon model was > 255. I just moved the if() statement to the end of the function, seemed to fix up the issue; here's the diff.

Does that look sensible? The lerping if() block used to be inside
if (cl.stats[STAT_WEAPON] != i), but I think it should be safe to move it outside of that, because the lerping if() is also testing that the weapon changed. 
Good catch. Your fix makes sense to me. 
Sounds like a great catch. 
Model Lerp And R_shadows 
Is there a way to code in so modders can choose which models can and cannot cast shadows, and which weapons/enemies are lerped?

I am using a bunch of models in one of my maps and they cast unwanted shadows. 
Fitz/Quakespasm/Mark V all have r_nolerp_list.

Mark V has r_noshadow_list too. 
Huh... how do you add to this list? Rc file? Cfg file? 
Nolerp/noshadow List 
They're just cvars so you set their values the same as any other.

It would probably be a usability improvement to have commands to add individual items to these lists rather than having to require the user (or moder) to respecify the entire list. 
yeah, it's not very user or modder friendly, but for modders adding it to quake.rc is the best idea. (alternate idea: use stuffcmd)

In the case of modders, you should be able to create a full list of what should have shadows and what should interpolate (since you wrote the mod!)

As a player you end up creating a really long list that applies to multiple mods, since most mods do not provide their own lists.

The ideal would be an extension to the model format or new fields on quakec entities for the modder to define the behavior for each model or entity. All of those things require engine support, plus either a tools change or protocol change.

Hence, the hacky config file method. 
who's idea was it to add all this stuff to console commands anyway? can we change this to some text file where we just put a full path in from the mod dir (eg: progs/flame.mdl) and anything in that text file is not lerped?

config files are infinitely easier for modders and users alike. 
necros, it already works like that, you can set up the list in your config file. 
Darkplaces has a EF_NOSHADOW flag (4096) for the 'effects' entity field that you can set from qc, but it won't work in protocol 666 which only has 1 byte for 'effects'.

r_noshadow_list sounds like a decent compromise, thinking of adding it to Quakespasm too. 
Mdl Bboxes 
We got a bug report for QS that the changelevel triggers in Xmen TC are harder to hit than with winquake. The changelevel triggers are point entities with an mdl model set on them.

What's happening is in Fitzquake, calling setmodel() also sets the mins/maxs based on the contents of the mdl, while winquake just sets them to '-16 -16 -16' '16 16 16'.

The Xmen code was calling setmodel() as the last thing in the setup code for this entity (xmen_teleport), so they were relying on the hacky behaviour of vanilla quake to set a 32x32x32 bbox.

Anyway - just thought I would document this for future reference; I suppose there could be a sv_gameplayfix cvar to revert to Winquake compatible behaviour, but it doesn't seem very urgent - lol. 
Oh... That would explain some seriously annoying issues I had with qc in the past 
if 1, uses the model's bbox. if 0, uses +/- 16 for mdls.
just using +/-16 for *.mdl means that dedicated servers need not bother loading mdls at all, note that the vanilla quakeworld server does not support loading .mdl at all.
FTE uses +/-16 purely based upon the filename extension, while uses the real size in other cases. This means that replacement content still gets a suitable size with things that were originally .bsp (where they always got the bsp's size) while .mdl entities get their +/-16, and convieniently sidesteps issues that are so problematic in DP with replacement content.
Depending upon the filename extension like that is a bit of a hack, but it does indicate the original expectation much better than anything else.

quakerally is similarly (and severely) broken by mdls not getting size +/-16. 
That would explain some seriously annoying issues I had with qc in the past

Same! I figured it out after vtos() printing sizes of misbehaving things in desperation and getting non-power-of-2 dimensions. I started always calling setsize after setmodel assuming it was another QC quirk everyone knew about but me, and not something specific to Fitzquake. 
Haha, ages ago Spike and some QuakeC modders discussed that.

I did notice that anomaly in the FitzQuake source code last year when carefully comparing versus WinQuake.

I thought about it 10 seconds, and decided no one ever complains about FitzQuake.

This may be the first time someone has spotted a behavior difference in the wild and brought to someone's attention. 
Personally I'm baffled that engines still use this style of MDL bbox handling when all the code needed to handle them properly - including full rotation support - is there in Quake 2 -

It's not hugely difficult to port that to Q1 and all of these problems just go away. 
@metslime / Mh / Spike ... Re: Realmodelbox 
I don't QuakeC much, but I've listened to plenty of conversations of QC.

I always thought in QuakeC, you were *always* supposed to do setmodel and then setsize.

But QRally doesn't, it would seem. And perhaps above comments from Necros and Lunaran indicate they don't always do setmodel and setsize too? And other mods may have made similar mistakes.

@metslime ...

Could you describe what FitzQuake was solving with the sizing the model?

Spike advocates all engines using the -16,-16,-16 to 16,16,16 but ...

I know you *never* implemented anything without a reason.

You made one of the most conscientious and thorough engines typically having a broad set of knowledge from a great number of sources. (The change wasn't accident or an oversight, but rather to solve something).

Was the issue for place_model, misc_model, mapobject_custom type of entities? 
iiuc it fixes glquake's model culling.

on the other hand, software rendering has more complicated culling, hence how it got away with hacking the size. I ought to verify that because frankly its an assumption.

and yes, qrally is NOT nice code. it violates other obscure rules too.

using +/-16 means that the server can avoid even loading the mdl in the first place. that's the biggest advantage. :) 
I am also curious about Baker's question.

Spike mentioning culling made me think.. if the server-side bbox is the +-16 units default, but the MDL is really huge (e.g. vermis), you could have a situation where the player can see the tip of the MDL, but the entity origin is outside of the player's PVS so the server culls it (wrongly).

It does seem like the main advantage of fitz's approach is for mapobject_custom type things, so very large MDL's can be supported without the mapper having to manually input the bbox size. 
I meant client-side frustum culling, rather than serverside pvs culling. 
Look at Quake 2's alias model culling code. It's easily adaptable (the key difference is that Quake 2 stores a bbox per frame) and handles rotation better than the FitzQuake code.

If it looks weird on first encounter then I'd encourage you to cross-check with modelgen.c, specifically the code it uses to scrunch the position data down to bytes. 
If you're talking about Mod_CalcAliasBounds the purpose is to calculate the bounds for the client.

GLQuake has a bug where large models are culled incorrectly, for example a dead shambler can disappear if you turn to a certain angle even though his arm should still be on screen. So my goal was to fix that.

e->model->mins/maxs are used by client for frustum culling, and that is what my change affects. ent->v.mins/maxs are used by server for PVS culling, and that is controlled by PF_setsize which I did not modify. 
@metslime -- the change isn't setsize actually, it's setmodel. I triple checked and ... well ... it is different.

I'd like to go the Spike route of -16,-16,-16,16,16,16 since it is standard Quake default.

But if even one FitzQuake targeted single player release would act up ... *sigh*

DarkPlaces defaults to original behavior with that sv_gameplayfix_setmodelrealbox 0 ... but I think many people if they heard a "DarkPlaces don't work right" with this 5 year old release would automatically blame DarkPlaces. 
I think I see what happens now in post #691 (Xmen TC). metl didn't change PF_setmodel (except for an unrelated change to do with BSP bmodels), but when a mod doesn't call setsize() after setmodel(), the new size calculated by CalcAliasBounds "leaks" into the server ent->v.mins/maxs bbox, because PF_setmodel reads e->model->mins/maxs, and uses those to set ent->v.mins/maxs.

While it sounds like an unintentional bug, I also think you are right that changing it might break serverside PVS culling for mods that are relying on the behaviour, especially in the case of a mapobject_custom with a large MDL (quoth, AD?) 
I think the only way we can know is by asking people to test sv_gameplayfix_setmodelrealbox 0 (Quake original).

Arcane Dimensions works in DP and is tested in DP and DP uses sv_gameplayfix_setmodelrealbox 0 (Quake original) and thus far no one has *seemed* to nothing anything.

/But yeah, I'm very afraid of sv_gameplayfix_setmodelrealbox 0 since nearly all single player releases have targeted that.

You'll like my source code on that, it's basically a 2 liner. 
(*) "single player releases have targeted FitzQuake in the last 10 years." 
I never realized setmodel sets the size as a side effect and that some mods rely on that.

Sounds like the fix is to set a minimum (or just force) size of 32^3 in PF_setmodel. I guess this could introduce PVS culling bugs, but only in mods that don't call setsize afterwards? And anyway culling bugs are not as bad as gameplay functionality bugs. 
Quake 2! Quake 2! Quake 2! Quake 2!

Seriously, Quake 2 has the fix for this. It has the correct +/- 16 for the server-side stuff, and it culls small/large models correctly for the client-side stuff.

There's really no need for this discussion. Grab the Quake 2 code (, adapt it for the Quake differences, and all of these problems Just Go Away. 
@mh -- you 100% this is only about culling?

What does setmodelsize do? What does QuakeC do with the mins/maxs?

Is it ever used for physics?

Spike says has Q-Rally has a *physics* issue with the FitzQuake way.

/My somewhat limited QuakeC internals is why I ask 
Clarity ...

If QRally has a physics issues with the FitzQuake way.

How do we know that there aren't single player releases designed for FitzQuake that will show physics problems if this is reversed? 
Probably Not A Problem -- Here Is Why ... 
Very few single player authors do QuakeC.

Enhanced GLQuake was often used before FitzQuake 0.85 so releases from 2009 and earlier should be safe.

Preach, Tronyn, metslime, necros are among the group. I would presume that they are sticklers for setmodel and then setsize. Most of the others are multi-engine types.

Sock is also targeting DarkPlaces.

Until Preach doesn't setmodel in mapobject_custom in Quoth, using the original Quake box should be fine. 
Arcane Dimensions works in DP and is tested in DP and DP uses sv_gameplayfix_setmodelrealbox 0
DP defaults this cvar to 0 but experienced DP users set it back to 1 for compatibility with some custom maps. 
Do you know the name of any particular map that it is known to make a difference? 
Well, before I set the gameplay fixes to 1 there were several maps in which I encountered bugs with pickups stuck in walls or missing altogether. I don't remember which maps specifically, except Solarfall: at the beginning of the map, turn right then left and you arrive in a room with a green armor pickup which was missing when I first played it. Though I suspect this particular issue might be fixed with sv_gameplayfix_droptofloorstartsolid 1, not setmodelrealbox. 
Similar problem with latest darkplaces in VR on android port.

Set gl_nopartialtextureupdates 1 to fix 
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2019 John Fitzgibbons. All posts are copyright their respective authors.