the jizz would be the awful bump maping? ja!

- i dislike bump maping. in old games, in new games.
- i don't like the new dp particle, smoke and blood effects either.

+ i don't have problem with hd textures, though

- i remain unimpressed with RTlights

+ i like water reflections, dp have those right? pretty water and all that... i couldn't make it work.

+ i like seven's smc mod. well, half of the mod, but comes with a .cfg to disable things.


+ and i would bow and praise if i see actual realtime raytracing lightning coming from those bizantine mosaics.
+ or, more realistically, sun rays like those in stalker clear sky in the morning, but colored (and various colours!). those mosaics are begging for something like that 

why would we actually need multigamedir?
For cleanliness and ease of use? A new folder for each map pack would prevent the cluttering of the mod's \maps folder. 

omg, omg
i remembered

i didn't play tfuma, azad or magna yet!
omg, omg

i will record demo in skill 3. without deaths if possible, with quickloads instead of restarting the level if i die 

I do! Dp and fte support multiple game directories which I use all the time with no issues. Not to mention all of their other features, but having those features doesn't mean you have to turn them all on or turn up the "jizz". Whatever the hell that is to you...LOL 

Avoiding use of default.cfg/quake.RC? Very few developers have managed that level of professionalism or quality in their releases over the past 20 years.

Okay, so how do we provide our own settings while staying professional? 

It's not my criteria, don't ask me. A lot of people seem unhappy with the idea of you providing your own settings though... 

i thought quake.rc was the correct way to do it. autoexec.cfg and config.cfg are the ones that you should never include. 

Yeah I for one definitely vote for having multiple gamedir support in an engine as it gives so much freedom to the end user with regard to how he wishes to combine different gameplay mods, assets, and maps. I have been using this feature for years with DP, and since its development slowed down, I have picked up first QS then Mark_V but the multi gamedir support has always been what I miss most of DP, on par with multi folder mod directory support (e.g. DP.exe -game ./addon/czg07) 

Are you aware that LordHavoc is working on his engine again? Check the link in post #159 and download either the nightly autobuild or one of the 2016 betas. No, they're not in the Downloads section... Bonus: you'll get alpha-masked texture support, so these vines in AD will no longer look broken. 

using a default.cfg in a base mod that a map pack depends upon runs the risk of a user installing the map pack, and getting a config.cfg auto-saved from it when the base mod wasn't installed. Which means that the default.cfg still doesn't do anything when they do finally get the multiple games enabled.

In multiplayer, the client will not know that it needs to download a new default.cfg.


I'm not necessarily saying no default.cfg ever, rather I'm saying that any changed settings within the default.cfg will not always be usable.
Just be aware that custom default.cfg files won't always be execed, or might be execed after its settings were already saved into config.cfg

qss+fte have a customisable binds menu, which is one way for a user to fix things up if their prior config.cfg overrode newer defaults (an updated default.cfg might still rebind stuff if something was not previously bound, at least, just don't depend upon the user having no prior binding).

qss+dp+fte all support set+seta console commands to create custom cvars from eg default.cfg (as well as autocvars, in case the default.cfg was missing or the engine ignored set/seta). Such custom cvars won't exist in prior config.cfgs so they'll pick up their correct default once the correct default.cfg is installed. Not (ab)using temp1 means that its default value of 0 becomes irrelevant.

Imho the only valid use of a custom quake.rc is to change the auto-play demo list. any changes before config.cfg should be done by modifying the default.cfg instead, while any changes after override the user's settings and are thus user-hostile. 

Seasoned mod users delete the .cfgs shipped with a mod before even running it anyway, so they're basically useless. 

But it can bite you in the aft end if a mod binds custom impulses, so the truly seasoned just rename it, skim it for anything modspecific, the paste in their own cfg and add the mod binds as necessary. 

ad_azad
skill 3
37:11 ; 2/10 secrets ; 161/192 monsters ;; 3 deaths
so much for no dying
good architecture 2/10 secrets... those secrets are well hidden. i died the three times because of monster ambushes
i liked that section with those wood.. mmm.. scaffoldings... or whatever...
https://drive.google.com/open?id=0B72Jjyg-RfNFZGZUNkhoUWl2Njg 

I thought I should mention one of the main motivations for having some way of separating out the content that comes with a map from the content that comes with a mod. There is a benefit to neatness, and with that you get the ability to "uninstall" a map and its content cleanly. But the main benefit to my mind is to avoid conflicts.

Suppose that two maps released for AD both come with their own unique skybox, but by coincidence both name the skybox "dusk". If you just extract both maps directly into the AD folder, one skybox will overwrite the other. The direction of the lighting at dusk needs to match with the position of the sun in the skybox, so it's likely that one map now looks broken.

The same risk applies to external models, sounds, and other resources, and the important change that AD and Quoth make is that these custom resources can be loaded by a map without needing to create a new mod. As more people take advantage of the features, there is a greater need to bundle together the map and its own resources into a single package.

A pak file makes for a nice, easy to handle bundle, because it's all a single file (and pk3 has the bonus of compression). However, I think the gamedir has won the day because it has lower cost of creation, has the necessary engine support, and degrades gracefully - people who can't or don't want to use the feature can continue to extract the zip file into the base directory. Cheers Spike for making that happen, it's always fun when you ask for a feature and get equally forceful replies of "stop asking for that, it's impossible" and "stop asking for that, we did it ages ago"! 

If you just extract both maps directly into the AD folder, one skybox will overwrite the other. The direction of the lighting at dusk needs to match with the position of the sun in the skybox, so it's likely that one map now looks broken.

A bit of offtopic, but I'm glad people care about these things now. Some years ago developers small and big were seemingly unaware of the relationship between the shadows on the ground and that weird bright spot in the sky.

Attaching a lens flare effect to the latter - sure, looks purdy. Shadows are pointing towards the sun - uhhh, so what? 

Back in 2005 I do remember trying to get quake engine authors to agree on a standard orientation for the skybox. I wouldn't be surprised if there's still inconsistency in sky orientation even today*

(* no evidence to back that up, just saying I wouldn't be surprised) 

When I first discovered the credits map, I was absolutely charmed. My first and last thought was something along the lines of "This is the best version of Oneiros I've ever seen, minus the color palette". But not because I didn't like the palette, it was just different.

Now it looks much closer to Oneiros, but I'm not sure it actually benefits the map. The old version was like something out of a fairy tale. The 1.5 version is white on magenta - rather cold and lifeless, but not in a cool way.

Maybe a warmer shade for the main color would improve it, but right now it kinda lacks contrast.

Or maybe it's the baby duck syndrome again. 

First off, the connection you made with Oneiros never ocurred to me while making the credits map.
But i see your point now.
Concerning the light in the map, the bounce and phong shading has a general "brighten up everything" tone to it, it lacks contrast in the end. Besides other points.

I admit wholeheartly, those features where just "tacked on" to the original map files when recompiling, so the results are what they are.

Glad for your feedback tho, thx a ton, you actually spoke out one of my main concerns about it...and any future maps will be lit accordingly... Yep. 

Thanks for your demos so far! Glad you liked it. 

Is this a Quake map? I've searched Quaddicted with this keyword but it returned no result.

I never played the 1.42 version of the end map but I saw a screenshot with a decidedly different dark blue sky. Any specific reason for the tone change? This can't be just because of the lighting, can it? Now I have to reinstall 1.42 to see the difference!

Anyway, I enjoyed the 1.5 version quite a lot. I love the islands-in-the-sky theme. BTW, what's with the monster count? I got only 2 frags in the end while having actually killed much more - and no fish. 

Great game. 

i was refering to this

https://fr.wikipedia.org/wiki/Oneiroi

Clive Barkers Undying had no influence on the design tbh, as i don't know this game :) 

and the monstercount you can't rely on.
All of the monsters spawned via the hidden button do not add up to the final count, because of the "nomonstercount" flag. 

not a flag, its just a key set on those monsters. 

First off, thanks for the french wiki link, that's a nice attention, though I wouldn't have minded an english link.

Hmmm, "demons with black wings"... So I guess the Night Gaunts are these Oneroi.

As a Clive Barker fan, I did play Undying back in the day. I thought it was a pretty good game but I don't remember much of it, and Oneiros doesn't ring a bell. I might reinstall it someday.

BTW, you haven't answered my question about the color tone change.