I understand Sock's motivation (not allowing a mess of forks)
People can fork or create their own mods using AD as a base as much as they like. I have no issues with that, as I said I just want the original AD mod to be left alone. Either make maps for it or create your own mod, its all setup ready to go with the devkit.

AD still needs a few things patched
like what critical stuff are you talking about? 

Thanks for the clarification, sock! I am indeed dense hehe. 

Nothing critical, just stuff like the statue gibs being bloody, for example. It would have also been nice to make some parameters user-controlled. I'm notably thinking about some particle effects like the grenade explosions that prevent the player from seeing the action or the footstep volume that you reduced slightly too much IMHO. 

The statues are squishy on the inside deliberately. 

Think of them like Pyura Chilensis (google it, but trigger warning: gross), which is a million times Quakier than some Harry Potter-esque magical rock monster 

Would it be cool for longer maps to have a trigger_sky entity, similar to trigger_fog, that could dynamically change the skybox during the level?

Kind of give a sense of day and night time passing. Could be neat if implemented correctly? 

Maybe?

I think it could be done but not sure if different engines use different commands to change skies 

I think it could be done but not sure if different engines use different commands to change skies

quakespasm uses 'sky foo' as a console command that persists only for that map, fte+ezquake+fuhquake+etc uses r_skybox as a cvar, dp has a loadsky command, markv has a cl_sky cvar (which only works on level changes), while the fitzquake protocol has a svc_skybox thing that will crash any clients that don't support it.

so yeah, good luck with that. :P 

lmao 

I suppose you could stuffcmd all of those commands to cover all engines and then follow with the "clear" command so the player doesn't see all the "unknown command" messages. Ugly as all hell, but we ain't going to get a standard on this across engines. 

And then the engine takes a shit on player immersion by hanging for several seconds when loading the heavy TGA files. 

Load up AD, then drop the console and type bind: bind j "sky moonhigh_", load up a map and walk around, while doing so hit J ;)

You'll see your post is nonsense. And I'm not using my SSD for Quake. It's only the slightest of hiccups. Defintely not several seconds and easily hideable in a level. 

if (strcmp(skybox_name, name) == 0)
return; //no change

If you reload the same skybox that is already in effect, the engine doesn't reload it.

It is, in fact, quite slow ... and you can experience this for yourself as follows ...

With Arcane Dimensions

Do bind j "sky interstellar_"
Do bind u "sky violent180_"

Alternately press j and u. It stutters pretty badly.

The reason your example doesn't cause a problem is that the skybox doesn't reload if the name is the same as the current one, hahaha ;-)


I'm not saying night and day transition wouldn't be cool, but some other method of achieving it would be preferred (darkening the sky? Fading in an alpha layer?)

Plus, the big thing: Why not change the lighting via QuakeC too. Would seem silly to have brightly lit outdoors with both sun and moon in the sky.

I'd like to see night and day transition. But the suggest method sucks donkey balls. 

When I use "loadsky moonhigh_" it's a snap of my fingers quick. That's on old WD Green drive and green is not known for going fast. 

BUT like Baker expressed, not the best method suggested. 

DoH! 

I'm not using the same sky man... c'mon! And I have the same experience as xaGe posted above. It's fast, really fast.

I've read enough of your posts not to doubt your technical knowledge in the slighest, but either something isn't right for you or we're just oddly lucky.

As far as lighting goes... if you mapped with this in mind, you would naturally create the lighting that was suitable for each area. Sky's are rendered fullbright perse right? Just like liquids? I don't see a problem. 

I see it now. It's a pretty hard hit and the sound stutters as well. Yeah, not good at all.

I guess since the 6 violent180_ .tga files weigh in at 21Mbs vs moonhigh_'s at 6Mbs I just got lucky with my selection. 

I would suggest you pursue your idea and then if others thinks it looks convincing ...

And you have a working prototype ...

Someone might come up with an idea of how to make it fast or a way to devise an awesome system for it.

Also: You might check out this https://quakewiki.org/wiki/lightstyle

metlslime once suggested a method for QuakeC based night/day transition for altering the lights.

Your idea has merit. And making a prototype IS the right thing to do.

If a decent prototype is made, even with a bit of stuttering, usually someone can look at the prototype and say "Here's how we can do this fast and make it easy on the mapper!" 

I almost have the "melee only" Golem prototype map finished ;)

Advice taken. 

Isn't it practically impossible to switch a light (for day/night transition, or otherwise) that covers a large area, unless it's almost the only light? I remember trying to do it in an unreleased map and it only took a few possible lighting combinations before I started getting lightmap bugs. 

There is a thin line between ...
1) "almost impossible"
2) "What do you mean it's impossible? My map already does that!"

Most of the elite mappers enjoy doing "almost impossible" things.

Probably for the same reasons QuakeC coders enjoy doing "almost impossible" things ... and that engine coders enjoy doing "almost impossible" things. 

four lightstyles per surface. big lights mean potentially more styles, means more surfaces will need more than 4 lightstyles, means more lightmap glitches.
the biggest issue with day/night cycles is getting the shadows to move properly (without rtlights anyway), but that's probably niche enough to not care about it.

lots of lightstyle changes might also result in stuttering.

whether an engine stutters or not when a skybox changes depends on that engine's caching, threading, tga performance, etc.
the more interesting issue is that you can only really change it when the player isn't staring at it, which should mean the engine also has a chance to spread the load over a number of frames to reduce stutter. 

Should I use this pack, if I only want to change some values? Like I think Pyro should have longer range like in Quoth mod. That is all I want to change at the moment, everything else seems just fine to work with. I'm too lazy to start "creating" bigger, and mostly just want to work with what you guys have already shared.

When I'm going to change couple values, and publish my maps/episode in the future. do I need to somehow patch modified files, it would be stupid to load entire ad mod in the same package? Is there way to point out, use this file instead, but when people play normal ad mod my files doesn't affect on those?

I'm not aware of technical stuff, and that is why I'm asking about it directly. Don't want to waste time on not knowing what is possible what is not.

Thank you for sharing this dev pack, if that is what I really need. 

personally i would be prefer no patches and things like that
include the whole thing bundled
that can be an extra 36 MB if you decide to include the devkit patch1 & patch2 or 28mb if you don't use hexen II stuff