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 

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

If you want to change the pyro attack speed then you will require a different progs file, which means you should use the devkit.

The AD pyro is based on rubicon2 code, which is why it works different to Quoth. The speed/distance of the flames are linked to skill level (250=easy, 300=normal, 350=hard, 400=nm) and the debuff flame damage is skill based as well. Changing the pyro setup will have to be tested for all skill levels. 

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?

The AD devkit is all about freedom to mod however you want. its a base for you to play with and gives you a set of mapping tools to create maps easier and access to much more flexible functions.

This is essentially what Quake modding is all about, there are no closed source files, its like how rubicon2/rrp is done. You create your own mod package, it will install much easier with QA injector and only require one game directory. Worrying about download size is pointless nowadays, most people download gigabytes of data all the time.

Either work with the existing AD progs/assets or just do your own thing! Learning how to make a mod might inspire you to create your own mod from scratch one day! 

If you're really worried about your derivative mod's download size, I don't think it would be that hard to look at every asset you're using and then just remove all the ones you're not from your package. Depending on what that stuff is it could definitely cut down on file size. 

Thank you very much. I will not worry about the size of my package then. I will start working on Pyro soon again, and also test it on all skill levels. 

What is the situation with models like misc_lightpost.mdl? Are they not included in AD's devkit because sock didn't have permission to?

I'm asking because I'm trying out tweaking the QC (I made a grunt with 3000hp, it took a minute and ten seconds to kill with the shotgun and axe!!) but I had to copy the missing models from the 1.50 release directory to my devkit directory to get my map to load. 

Hi, just noticed a typo in the .def file - for func_breakable, the key to override the impact direction should be "angle", not "angles"

Even more minor, but the behaviour of the angle key for func_breakable is described in a paragraph, but it is omitted from the "Breakable entity details" key listing, so it might be missed by someone just skimming the key listings. 

Was about to ask the same question but with misc_smoke.mdl

The misc_smoke entity is in the documentation, but the model is not included in the devkit.

Is there a permissions problem with using misc_smoke.mdl, or was it just an oversight? 

The permissions on misc_smoke.mdl can be found at https://tomeofpreach.wordpress.com/about/

... offered without licence terms or conditions for use in Quake

So no problems there. 

 

What is the situation with models like misc_lightpost.mdl? Are they not included in AD's devkit because sock didn't have permission to?
I did not include many of the misc_ files because they are not required to run the MOD with minimum assets. Every version of the devkit has an example map which shows what assets it does support.

The dev kits are about showing what assets are required for a new mod to use the AD QC. Ideally as you use more assets in your project you will add them to your mod directory. The final AD mod included many maps which used special assets (lightpost.mdl) which are not essential.

I made a grunt with 3000hp, it took a minute and ten seconds to kill with the shotgun and axe!! I had to copy the missing models from the 1.50 release directory to my devkit directory to get my map to load
If you are copying stuff from the 1.5 directory for your map then its something to do with your map requiring unique assets. One example I can think of is the misc_smoke entity loading a special model. The devkits are really just the bare bones of AD with no bells and whistles! 

Yeah, my map does use some of the misc_ models, like the lightpost I mentioned. Hence me wondering if it was allowed for me to include them in something released based on the devkit - I remember you stating at points that it was tough to get permission for some of the things in AD, and I didn't want to end up using things I didn't have a right to.

Of course, if I actually want to release a mod using the devkit foundation, I probably ought to have more maps and models of my own anyway...