After working on inspecting the interior mechanics of DarkPlaces, I go to close my image editor.

It ask confirm closed unsaved image about 50 times, I had taken screenshots in Visual Studio of the variables and call stack watching it work many times, noting the call order so I don't mess anything up by failing to understand what is going on fully.

I make DarkPlaces do the things that a single player enthusiast will do, find small things that are important. DarkPlaces marks all data for clearing on a restart, it performs a restart on gamedir change or video mode change. But it retains a list of the models currently used, for faster loading.

And noticing this, I solve a crash that I didn't understand. If you switch gamedir, "maps/start.bsp" might not be the same map. In fact, anything could be different.

After reaching the end of "the list"

I ask ... "spent all this time and haven't got to do anything 'fun' or 'cool' yet?" which is a separate list.

And the counter thought is "DarkPlaces needed someone to do this long ago".

And the other counter thought is DarkPlaces has a feature set by dozens of imaginative and talented people.

Where will the future lead?

There are always 2 questions that anyone should ask ... "what are you doing" and "why are you doing it".

The answer for me is I want see what happens if I can unlock the unused value from several underutilized resources all the same time and see what .. if anything ... will happen.

For me, this is both benign intent and the desire to see if the results are amusing. I am curious to know. 

So testing things out in DarkPlaces, come upon a map with dogs floating in air.

I do some ground work and find the last version without the issue (2012 Dec 22). droptofloor is a little different. And it might have even been to make DarkPlaces work better with Quake.

The motivations for DarkPlaces are different and new games/mods were priority.

As far I can tell, there really is no one developing DarkPlaces as a Quake client, seems to be non-Quake development uses only.

I don't know why exactly ... perhaps they got demoralized with bug reports about Quake? I am just guessing.

The reason that I feel this could be the case is to debug Quake issues you need to know:

1. the mechanics of QuakeC
2. How monsters/physics work in a single player Quake map, the order they occur. Someone can engine code but without knowing the mechanics of QuakeC, some of the issues are going seem unsolvable.
3. Be someone who has played a lot of Quake maps, particularly custom single player maps and know the oddball maps that do crazy stuff.

All of the above is taken for granted here. 

You might want to check the dpcompat_* cvars in FTE. Those cvars generally denote behaviour differences that I added to allow FTE to be configured to act like DP for compat with DP-only mods, instead of is more traditional behaviours. Not all of it is relevant for QS compat, but dpcompat_noretouchground is a good one to start with.

Additionally, the areagrid changes in DP will result in triggers getting touched in a different order (primarily breaking maps with lots of trigger_push volumes). FTE has the same issue. :(

droptofloor is a recurring issue for DP mods - setmodel did setsize(ent, '-16 -16 -16', '16 16 16') in vanilla, but various engines including DP use the model's size. QS has the same issue, but QS tends to have fewer people replacing models willynilly and then getting surprised when the hull collisions change resulting in ents traces going skewy. I suggest you use the filename and only use the actual size for inline and .bsp models (like fte does) rather than doing it based on actual file type - slightly reducing issues when people replace ammo boxes with mdls.
Obviously if it makes a difference then the mod is buggy anyway, but that tends to be their default state.
Sidenote: SV_RecursiveHullCheck got completely replaced (for good reason). Expect some droptofloor differences because of that too.

and yeah, have fun with the whole sv_gameplayfix_* nightmare...

And once you'd fixed QS compat stuff, all the DP stuff will be broken and a different group of people will complain at you instead (more likely both groups).
Compat is a fun never-ending nightmare. Enjoy the treadmill. 

I've carefully plotted my navigation with the perils of those gameplay fix cvars.

However thanks for pointing out the potential bmodel thing.

I should be "ok" because standard QuakeC sets bmodel sizes for all the box models. So replaced or not, that should be ok as a general rule of thumb.

I thought DarkPlaces had solved the all the floating models thing by (attempting) to set everything to baseline Quake.

The floating dogs wasn't a setsize thing. That was the first thing I checked. And I think I have the issue fully solved, but the impossibility of verifying 3000 maps/mods leaves that "tbd". 

Spike, I see you have been on a furious rampage while I have been gone. Congratulations of the sheer volume and scale of your works!

Super, super, super impressed by fteqcc.

I was able to use my Vulcan mind meld ability (that happens when I have read someone else's code a million times) to imagine features that Spike would do in fteqcc to derive undocumented or barely mentioned features.

I think my batting average was an insane 98% or so, and I just kept getting more impressed as I kept on finding you had already done "something I wish it would do" over and over and over.

You have made QuakeC like real C about as much as it can be. 

Of all the features, the surprise discovery of variadic macro support was the one that made me the most happy.

I have abused that one to no end.

(yes, triple post. But no edits here .. what else can I do.) 

Spike, DarkPlaces uses vid_conwidth and vid_conheight during CSQC_UpdateView.

Xonotic and stuff like Quake 1.5 depend on this behavior. Xonotic will set vid_conwidth/height in CSQC_UpdateView which does not take effect in the current draw frame.

In my opinion, CSQC_UpdateView should receive a full canvas of vid.width and vid.height.

To give mods like Xonotic or Quake 1.5 what they expect, but to give a mod the option of a full 2D ortho canvas .. I am doing this at the moment ...

I have created a cvar csqc_full_width_height_available 1.

A mod can check to see if the engine has the option of giving a full canvas.

In default.cfg or quake.rc, a mod can set csqc_full_width_height 1 to ask for the fullscreen canvas.

In CSQC_UpdateView, checking those cvars allows the mod to act on either canvas type, giving DarkPlaces the right stuff or Zircon the better stuff.

fteqw does something different and I imagine it gives full canvas.

I hate the method I have come up with, but it will work. Yes, I could turn the cvars into extensions, but I don't know what extenison numbers are safe to use -- there is no "Baker's range" from 1500 to 1800.

I want any qc mods I make to eventually be compatible with fteqw (fteqcc says detected "DarkPlaces only mod").

I know you have already thought about this topic and know a better way. 

I'm not sure what you mean by 'fullscreen canvas' - the canvas that csqc draws on is ALWAYS the full-window. Other programs running on the same machine are generally hidden and irrelevant anyway.

What your 'csqc_full_width_height' refers to is unclear too. 'Full' as in a 1:1 ratio in your 2d projection matrix? So that mods running at 8k end up with un-readably small huds? Most mods are badly written monstrosities that won't remember to add custom scaling factors everywhere (or will fail to test it properly and generally screw it up).
There's a reason there's scaling. It simplifies mods, reducing these issues.

IIUC, DP mods that stomp on the user's choice of values for vid_conwidth/vid_conheight are generally trying to work around various other DP bugs. I've gone on this rant before.
If you're reading vid_width to compute the 'proper' vid_conwidth then you're going to bug out when vid_restart fails (or just hasn't been used yet), or when resizing the window and just completely bypassing vid_width entirely.
This is why vid_conwidth 0 (or height) means 'auto' in FTE - so the CSQC_UpdateView's width+height args can always have the right aspect without needing cvars to change when cvars are changed etc.

It should also be noted that the vid_conwidth+vid_conheight cvars do not exist in QSS. Cvars are evil. They do not make for good APIs, especially cross-engine ones. Mods depending on specific values for them is an additional nightmare for modders when their mod doesn't work for that one user who just loves to set random cvars and assumes other mods need them too, or w/e. If a mod needs to read/write a cvar just to get its drawpics in the right place then its a bad/buggy mod.

Poke me on discord if you want a real discussion, func doesn't seem appropriate for walls of text that isn't even relevant to mappers. 

Poke me on discord if you want a real discussion

You efficiently communicated everything above. ;)

Most mods are badly written monstrosities that won't remember to add custom scaling factors everywhere (or will fail to test it properly and generally screw it up).

Yes, I was already leaning towards that.

I will say, it is not their fault, per se.

The original Quake C source code is pretty ... well ... shitty and compared to fteqcc, the original Quake C compiler is very shitty.

And csqc and the extensions are marvelous. I have been able to capitalize on them.

If I were not an engine coder, I would stand no chance of effectively using csqc. I probably had to look at the engine source 300 or more times, and numerous times had to watch a function in action with the engine in debug mode.

And csqc and the extensions are marvelous --- if the community were of greater size that had an ecosystem of scale to document and video and tutorialize .. things might be different.

Enough said ... 

Poke me on discord if you want a real discussion, func doesn't seem appropriate for walls of text that isn't even relevant to mappers.

I really hope you keep talking about this on func (maybe in a better thread though) as I am sure there are plenty of mapper/coders around who love to read this stuff. Moving conversations to discord will mean the information will be lost for searching in the future. 

EOM 

There would have to be incredibly compelling reasons for anyone in this community to consider switching from ericw-tools.

Total feature parity with ericw-tools would need to be a starting point I would say, and then it would come down to what a new compiler system could offer in addition to that.
Sounds like corporate approach to something that was supposed to be fun. But maybe it has to be this way for major projects like AD?

I don't know to what extent feature parity can possibly go, afaik ericw's method of illumination from skybox is about creating multiple fake suns to gather light from them, but Valve's approach is more physically correct. These two methods can't possibly produce identical lightmaps, can they? 

There's a difference between "feature" and "implementation".

Having skybox lighting is a feature, but how it's implemented should be allowed and even encouraged to be different, because that's a part of how we get progress.

Having feature-parity is generally a useful thing.

Having implementation-parity might be useful if you wanted to recompile a map on a different toolset but get broadly the same output. Otherwise, a different implementation that gives a different output is a good thing because it lets people see and compare different ways of doing things. 

What sock said, basically.


Also, I guess everyone here already knows about this, but thought it's worth mentioning just in case someone has not heard about it yet:

Imgur is about to delete all images not tied to registered accounts, as per their new policy coming into effect next month: https://help.imgur.com/hc/en-us/articles/14415587638029-Imgur-Terms-of-Service-Update-April-19-2023-

Of course this means a massive number of images are about to be disappear from the net, including screenshots linked here and elsewhere (which is probably a good argument for using quaketastic instead, but that doesn't change the fact that plenty of people have been using imgur for showing off their mapping).

Not sure if there's anything to do but mourn the imminent loss of a whole bunch of content. 

begone spammer 

just found out about this: https://github.com/Immorpher/Bandither

its nice
github is full of cool quake stuff 

possible to somehow get the improved explosions and axe out of Bastion mod/game as progs so that I can use them in every other map somebody pls? 

if they have the same frames as the originals, you could just extract them and put them in a new pak file in your id1 folder. 

or the fixed axe from Copper. possible to get it as stand-alone progs somewhere pls? 

Greetings slipgaters!

I would like to play the original quake maps with fog enabled, but is it possible to have it enabled permanently without having to set the value in the console on each map?

Maybe the better question is has anyone made custom fog values for each original map and posted them somewhere?

Please be kind to this first time poster ;)
Thank you! 

is to copy id folder from Your steam or epic library, rename it to smth like id2022 and run Your favorite souceport with parameter -game id2022