3 types of portal skies, the standard, the global (the one like HL2 ), and the local for cutscenes

[BielBdeLuna]

/added 3 portal skies types

-> this should not collision with any other mod so it could be added to the base so all can use

here is an example video of how it works:

[BielBdeLuna]

related to: dhewm/dhewm3#582

[DanielGibson]

I'm not sure what to do with this.
It certainly is a nice feature.

But it's a nontrivial amount of code, so putting it into master would make merging future mods harder.
Merging it into all mods doesn't make much sense either, because the existing maps don't use the feature anyway and it would break existing savegames..

Also, a more specific note: Shouldn't these changes be merged into d3xp as well? IIRC so far it only supports one kind of portal sky?

Maybe we could have a branch that can be used for new mods which includes some nice features vanilla doesn't have, like the portal skies and some nice features from the existing mods.

But then again, who would use that?
Does anyone still create new mods for Doom3?
And those who do, would they even use the dhewm3 SDK (only example I can think of is Phobos who for some reason insist on using Vanilla and not supporting dhewm3 at all).

Also, what other features from other mods deserve to be included?
(Nothing from Sikkmod because Sikkpin requested that his works aren't used in commercial products, and I wouldn't want such a restriction on a generic modding base)

[BielBdeLuna]

I could work it out so it is also in d3xp, it isn't difficult to implement, it got two extra types of portal skies, besides the standard one of d3xp, also the other mods have their own branch, so it isn't a problem for them isn't it? Newer mods, its the same as any other improvements in the master branch isnt it?
And the problem of saved games, shouldn't be an issue for any developer, and if this repository is an SDK for Dhewm3, it's meant to be for developers, isn't it?

[BielBdeLuna]

I added the new portal skies for D3XP now both the d3xp and game have the same modified content, and both play the portal skies testmap correctly

[BielBdeLuna]

is there a way I could change your stance on including this in the main branch?

[DanielGibson]

Dunno, do you have any arguments for it?
As I wrote above, I really don't see how that would be useful, but maybe I'm just missing something

[BielBdeLuna]

for me at the moment it could be useful in order to show it to the Phobos team, so they can use it, experiment with it, and enhance their mod. Dhewm3 is the easier way to allow them to test it.
I guess the Phobos are scared of the amount of work of porting their extensive changes (which i don't perceive to be that extensive) to Dhewm3SDK, they've told you that they don't want to port it to Dhewm3SDK? or that making it would be too much work? maybe I could volunteer that work for them

you say it's a non trivial amount of code, no, it's a small amount of code, of only 5 changing files, no new files, the changes are not different than any push with small fixes in the code.

of course any map uses the feature, because it's an improvement over the other way to do it via scripts, other maps would have used it if they had the chance, it's the only credible way to make huge spaces with a reasonable space in current doom3. it' is difficult that any future doom3 map would ever use it if you gatekeep it out of this SDK.

is this SDK then only for fixes to the game code? in this case the idea of a branch with improvements and new mechanics from the community its a good idea then?

[DanielGibson]

Phobos ... port to dhewm3 ... maybe I could volunteer that work for them

I've always told them that all they have to do is release their source (publicly or just send it directly to me) and I'll port Phobos to dhewm3. If zipping up their sourcecode and sending an E-Mail is too much work then no one can help them.

For at least four years (and two releases) they've told us that they'll look into it "after the next episode has been released" - apparently they have no intention to ever release it and are just trolling.

You can show them your portal skies and tell them they can only use the code if they release their source under GPL, but I doubt it'll convince them. Honestly, I wouldn't waste much time on them.

it's a small amount of code, of only 5 changing files

It's almost 600 lines of code in 17 files, according to https://github.com/dhewm/dhewm3-sdk/pull/35/files

it' is difficult that any future doom3 map would ever use it if you gatekeep it out of this SDK

You are aware that the game DLLs of the base game and D3XP that are shipped with dhewm3 are not built from this SDK, but from the code in game/ and d3xp/ in the dhewm3 main repo?

I don't know if anyone still creates maps for Doom3; even less likely for the mods maintained in this repo (except maybe Revility for Ruiner and Rivensin, but if/when he wants this feature it could be merged directly into the corresponding branches)?
And even if they do, do you think there are many mappers that want their maps to only work with dhewm3, but not Vanilla Doom3 or fhdoom or whatever other source ports are out there?

is this SDK then only for fixes to the game code?

So far it has only ever been used to port existing Doom3 mods, and that is easier the fewer changes there are to the code (and thus to the original SDK), as every change is a potential merge conflict.
So yes, I try to only have bugfixes (and changes required for changes in dhewm3) in the main branch, which is used to port mods.

in this case the idea of a branch with improvements and new mechanics from the community its a good idea then?

Yeah, that's what I was trying to suggest.
That code could also be used for some kind of standalone-base for new games based on the dhewm3 engine (sometimes people ask for something like that).

[BielBdeLuna]

on the 600 lines of code:
Sorry, it is true, i was only thinking on my porting to D3xp, sorry my bad

Dhewm3 game/d3xp folders not being Dhewm3SDK ones:
Why not incorporate Dhewm3SDK as a submodule via CMAKE script, so when you compile Dhewm3 you also already compile Dhewm3SDK d3xp/game dirs, so Dhewm3 wouldn't have neither D3xp nor game dirs per se (this also means less code to mantain)

• and also I wonder if an agreement could be reached with Robert so their BFG game/d3xp folders that should be pretty similar to Dhewm3's could use the same Dhewm3SDK as a submodule? maybe this way those already ported mods could also have a second life in RBDoom3BFG?

maps and mappers:
fhDoom is unmaintained, retail engine is not only unmaintained but nowadays you already buy the BFG with it so you already have access to the more modern version of the retail engines, so Dhewm3 is the only current alternative for a maintained Doom3 engine, also a system agnostic alternative.
Now with the push from Robert for the Trenchbroom doom3 extension, and the existing Darkradiant editor, it's credible that Doom3 maps will keep being produced.

new branch:

• I worked with the retail SDK cars (are those models GPL?) i added sound to them, and the starting of the code for collision (i know Fragging Free have colliding cars) but I didn't finish my implementation, I also ported the cvars to spawnvars for every car, so the car are more customizable.
• there is also the water mod which could be very convenient for mappers

what do you think?

[DanielGibson]

Why not incorporate Dhewm3SDK as a submodule

Submodules are a pain in the ass, you always need special commands for updating the repo etc, not gonna happen.

and also I wonder if an agreement could be reached with Robert so their BFG game/d3xp folders that should be pretty similar to Dhewm3's could use the same Dhewm3SDK as a submodule

I don't think that's technically feasible, AFAIK D3BFG uses a different Game API and network protocol.
Furthermore, in D3BFG the same code is used for the base game, d3xp and d3le, while here it's different code, with implications for the game data (for example which weapons exist and which _impulse numbers they use)

fhDoom is unmaintained

AFAIK people use it anyway for its graphical effects

retail engine is not only unmaintained but nowadays you already buy the BFG with it so you already have access to the more modern version of the retail engines

Pretty sure people still use it anyway, for example to play Phobos or other legacy mods

Now with the push from Robert for the Trenchbroom doom3 extension, and the existing Darkradiant editor, it's credible that Doom3 maps will keep being produced.

That would be nice - but I still guess they'll stick to the features available on all ports (incl. D3BFG)

I worked with the retail SDK cars (are those models GPL?)

I don't think those models are GPL, they weren't released with the Doom3 GPL source, but only with the (proprietarily licensed) original Doom3 SDK.
That's no problem for Doom3 mods, but standalone projects shouldn't use them.

there is also the water mod which could be very convenient for mappers

I agree that a water mod would be a very nice addition for a branch targeting new mods.
Of course for this there again is the license-question - ideally any gamedata (scripts/defs, textures, shaders, ...) for this mod should be under a license that is permissive enough to use it in a commercial project.

Of course we could have two versions of assets: A nice one for Doom3 mods, and a more barebones one for standalone projects, that may look like shit but at least demonstrates how water or vehicles are used