[Tea Monster]

Myself and the one other person who I know was contributing models to the HRP both stopped due to not having the patience to deal with Polymer's shader issues.

[Radar]

Zaxx, on 06 February 2020 - 05:42 AM, said:

Yeah, that's what I meant when I said that it "could be" better than the autoload: seems like this functionality is planned to work the same way as it does in GZDoom.

This is a non issue. EDuke32 doesn't just have autoload, but also has custom content folders available at launch so that you can have multiple mods organized neatly in different folders. That is vastly superior to running a batch file to run mods, which EDuke32 also supports, as you've already been corrected on. It really sounds like you are putting minimal effort into understanding how EDuke32 works.

[Radar]

Tea Monster, on 06 February 2020 - 05:51 AM, said:

Myself and the one other person who I know was contributing models to the HRP both stopped due to not having the patience to deal with Polymer's shader issues.

IMO The perfect HRP would have 3D models that look identical to the Chuck Jones renders (which may require model specific shaders to get the lighting on them right), and also normal maps applied to the stock textures (AI ERSGAN upscales may produce the best results). Something like that would be fully compatible with the entire original game. But a full re-envision of the original levels like HHR requires an entirely different engine imo.

[Mark]

I don't remember the early lore. Were DN3D textures created in high res and then lowered to the point of massive pixelation? If so, did any of the original higher res art survive on somebody's backup drive that we know of? I'm assuming no because it would have been released by now.

[Zaxx]

Radar 100 Watts, on 06 February 2020 - 06:49 AM, said:

This is a non issue. EDuke32 doesn't just have autoload, but also has custom content folders available at launch so that you can have multiple mods organized neatly in different folders. That is vastly superior to running a batch file to run mods, which EDuke32 also supports, as you've already been corrected on. It really sounds like you are putting minimal effort into understanding how EDuke32 works.

Having autoload and custom content folders don't help with the issue of EDuke32 simply not being able to run a bunch of stuff because of conflicting file names for example. Let's say you want to use Nightfright's Duke 3D fix pack with the voxel pack: functionally what you should be doing is putting the two packages into autoload and then it should just work. It won't because even if you load one through autoload and the other through your specified custom content directory ED32 won't know the difference so you'll have conflicting file names. If you want to fix that then you have to write a def file.

What woul happen in GZDoom? You say "-file fixpack.wad voxels.wad" and it works. That functionality is not in Raze yet but the usage of "GZDoom terminology" points towards it being a thing one day.

Overall I'm very sorry to say this because I know how diehard EDuke enthusiasts react to opinions like this but how EDuke32 handles custom content is well... fucking shit and it clearly needs some fine tuning so that the port could be more user friendly. That's the main reason why some people prefer BuildGDX, there loading stuff is just easy and hassle free.

[OpenMaw]

Mark, on 06 February 2020 - 09:00 AM, said:

I don't remember the early lore. Were DN3D textures created in high res and then lowered to the point of massive pixelation? If so, did any of the original higher res art survive on somebody's backup drive that we know of? I'm assuming no because it would have been released by now.

Some things like the skyline and some of the alien textures were sourced from magazines and H.R. Giger artwork. So, in theory you could use the original magazine sources to create higher res art.The porno video clips are sourced from actual video, so they could probably be resourced. I asked recently in another thread about the Octabrain blast, which was sourced from a match hitting gas. The explosions are all photo sourced from stock footage.

On the other hand if you look at some of the art it's pretty obvious that it was hand painted at the in game resolution. So, some of it simply can't be uprezzed for an "original source."

[NightFright]

Regarding HRP memories: It was a good idea for a while, but it died for sure once neural upscaling came up. Imitating textures in higher resolutions vs. upscaled originals - there can only be one winner. The models lacked consistency, there was a huge quality difference between old and newer entries. Old stuff never got remade while nobody wanted to do missing entries at some point, either. The voxel pack is the actual star by now. It's mostly driven by one guy recently, but who cares, his stuff is awesome.

As for Graf Zahl's port, I am curious about its capabilities and faithfulness. I am not an HRP fan any more by now, so as long as I can run those games flawlessly, with some eyecandy options and easy-to-use modding system, I'm signing up. EDuke32 however will always be the big daddy.

[Mark]

Regarding HRP memories...NITPICKERS

[Kyanos]

I don't shed a tear over the HRP, but the mods Polymer has killed teased hindered engulfed

Quote

It just needs some more bugs fixed then optimaization.

[Phredreeke]

NightFright, on 06 February 2020 - 12:25 PM, said:

Regarding HRP memories: It was a good idea for a while, but it died for sure once neural upscaling came up. Imitating textures in higher resolutions vs. upscaled originals - there can only be one winner. The models lacked consistency, there was a huge quality difference between old and newer entries. Old stuff never got remade while nobody wanted to do missing entries at some point, either. The voxel pack is the actual star by now. It's mostly driven by one guy recently, but who cares, his stuff is awesome.

As for Graf Zahl's port, I am curious about its capabilities and faithfulness. I am not an HRP fan any more by now, so as long as I can run those games flawlessly, with some eyecandy options and easy-to-use modding system, I'm signing up. EDuke32 however will always be the big daddy.

*in hoarse voice* hey kids wanna download some upscale packs?

[Radar]

Zaxx, on 06 February 2020 - 10:08 AM, said:

Having autoload and custom content folders don't help with the issue of EDuke32 simply not being able to run a bunch of stuff because of conflicting file names for example. Let's say you want to use Nightfright's Duke 3D fix pack with the voxel pack: functionally what you should be doing is putting the two packages into autoload and then it should just work. It won't because even if you load one through autoload and the other through your specified custom content directory ED32 won't know the difference so you'll have conflicting file names. If you want to fix that then you have to write a def file.

What woul happen in GZDoom? You say "-file fixpack.wad voxels.wad" and it works. That functionality is not in Raze yet but the usage of "GZDoom terminology" points towards it being a thing one day.

Overall I'm very sorry to say this because I know how diehard EDuke enthusiasts react to opinions like this but how EDuke32 handles custom content is well... fucking shit and it clearly needs some fine tuning so that the port could be more user friendly. That's the main reason why some people prefer BuildGDX, there loading stuff is just easy and hassle free.

This is not what you were talking about, but I have no problem with this. I agree modifying DEF files are annoying. I also hope the IWAD/PWAD model can be adopted in EDuke32 if it ever gets a Doomseeker plugin.

[LeoD]

Zaxx, on 06 February 2020 - 10:08 AM, said:

Having autoload and custom content folders don't help with the issue of EDuke32 simply not being able to run a bunch of stuff because of conflicting file names for example. Let's say you want to use Nightfright's Duke 3D fix pack with the voxel pack: functionally what you should be doing is putting the two packages into autoload and then it should just work. It won't because even if you load one through autoload and the other through your specified custom content directory ED32 won't know the difference so you'll have conflicting file names. If you want to fix that then you have to write a def file.

What woul happen in GZDoom? You say "-file fixpack.wad voxels.wad" and it works. That functionality is not in Raze yet but the usage of "GZDoom terminology" points towards it being a thing one day.

Overall I'm very sorry to say this because I know how diehard EDuke enthusiasts react to opinions like this but how EDuke32 handles custom content is well... fucking shit and it clearly needs some fine tuning so that the port could be more user friendly. That's the main reason why some people prefer BuildGDX, there loading stuff is just easy and hassle free.

So BuildGDX does run DukeFix + VoxelPack out-of-the box? No, it does not. Simply ignoring CONtent isn't exactly 'hassle free'. On the other hand, EDuke32 running DukePlus with half a dozen ZIPs in autoload has been working for me for years now.

[Zaxx]

Radar 100 Watts, on 06 February 2020 - 01:59 PM, said:

This is not what you were talking about, but I have no problem with this.

It was what I was talking about, I just didn't specify it because I thought it was obvious. This was the original post:

Quote

Interestingly though you can load custom content with Raze just like you would with GZDoom: with the "-file" command. For example you want to play Blood with the voxel pack? You just "-file voxels.zip" and it works. That could be a better solution than EDuke32's unrealiable autoload feature.

So basically "Yay, you load mods like you would in GZDoom, this could be something!" I didn't remember / know about the "-g" command in EDuke32 though since I always used the autoload folder.

[enderandrew]

NightFright, on 06 February 2020 - 12:25 PM, said:

Regarding HRP memories: It was a good idea for a while, but it died for sure once neural upscaling came up. Imitating textures in higher resolutions vs. upscaled originals - there can only be one winner. The models lacked consistency, there was a huge quality difference between old and newer entries. Old stuff never got remade while nobody wanted to do missing entries at some point, either. The voxel pack is the actual star by now. It's mostly driven by one guy recently, but who cares, his stuff is awesome.

As for Graf Zahl's port, I am curious about its capabilities and faithfulness. I am not an HRP fan any more by now, so as long as I can run those games flawlessly, with some eyecandy options and easy-to-use modding system, I'm signing up. EDuke32 however will always be the big daddy.

In theory they could be mixed with upscales being used for missing textures the HRP doesn't touch.

Individual components in the HRP pack are higher quality than the upscales, but the upscales are consistent. It is just going to be a matter of preference.

[LeoD]

Btw., modders should know this. If they don't, or do not care, it's not EDuke32's fault when things don't work as intended.

enderandrew, on 06 February 2020 - 02:55 PM, said:

In theory they could be mixed with upscales being used for missing textures the HRP doesn't touch.

Yeah, but in reality both Phredreeke and the majority of HRP maintainers have opted against mixing. But no one will come after you for what you put into your autoload folder behind closed doors...

enderandrew, on 06 February 2020 - 02:55 PM, said:

Individual components in the HRP pack are higher quality than the upscales, but the upscales are consistent. It is just going to be a matter of preference.

When I returned to playing Duke, HRP development was in its heydays. Therefore, my preference is still "Duke on LSD" as someone called it.

[Jimmy]

Sanek, on 06 February 2020 - 03:34 AM, said:

And there's multiplayer too?

LOL. Don't count on it.

Sanek, on 06 February 2020 - 03:34 AM, said:

Anyway, I think it's a very good news for Duke's and Build games' gaming community's, becasue it'll bring...more players? On the other side, it's not a good news for modding community. I also agree that it kinda sucks that Doom guys beat us in this area.

You are right, you are confused. "The Doom Guys" didn't beat anyone to anything, unless you somehow thought backloading EDuke32 into GZDoom was important somehow.

Sanek, on 06 February 2020 - 03:34 AM, said:

@Mark I wouldn't stick to Mapster if I were you. At least if you want more people to know about your work. It took me almost 17 years to become somewhat decent mapper, and by the time I started to make my best maps ever, nobody cares anymore.

You are so fucking salty it's pathetic. Build a bridge and get over yourself, mate. If you're doing any of this for validation from other people, you're doing it for the wrong reasons.

Zaxx, on 06 February 2020 - 05:42 AM, said:

Yeah, that's what I meant when I said that it "could be" better than the autoload: seems like this functionality is planned to work the same way as it does in GZDoom.

Except it works exactly the same.

Tea Monster, on 06 February 2020 - 05:51 AM, said:

Myself and the one other person who I know was contributing models to the HRP both stopped due to not having the patience to deal with Polymer's shader issues.

And dozens before you two.

Mark, on 06 February 2020 - 09:00 AM, said:

I don't remember the early lore. Were DN3D textures created in high res and then lowered to the point of massive pixelation? If so, did any of the original higher res art survive on somebody's backup drive that we know of? I'm assuming no because it would have been released by now.

Commando Nukem, on 06 February 2020 - 10:26 AM, said:

Some things like the skyline and some of the alien textures were sourced from magazines and H.R. Giger artwork. So, in theory you could use the original magazine sources to create higher res art.The porno video clips are sourced from actual video, so they could probably be resourced. I asked recently in another thread about the Octabrain blast, which was sourced from a match hitting gas. The explosions are all photo sourced from stock footage.

On the other hand if you look at some of the art it's pretty obvious that it was hand painted at the in game resolution. So, some of it simply can't be uprezzed for an "original source."

Commando is right. Although some of the art was drawn at higher resolutions and then downscaled, if you look at LameDuke and other beta materials you'll find art in higher res than the released game. 3D Realms used Deluxe Paint II and Deluxe Animate to make the game's art. Some of it is probably out there, but Duke3D beta materials would need to be released. Theres one or two assets in LameDuke though.

Photonic, on 06 February 2020 - 01:17 PM, said:

I don't shed a tear over the HRP, but the mods Polymer has killed teased hindered engulfed

What, like four that barely got off the ground? 100x more mods died before the Duke 3D Source was ever released.

[Jimmy]

Zaxx, on 06 February 2020 - 10:08 AM, said:

Having autoload and custom content folders don't help with the issue of EDuke32 simply not being able to run a bunch of stuff because of conflicting file names for example. Let's say you want to use Nightfright's Duke 3D fix pack with the voxel pack: functionally what you should be doing is putting the two packages into autoload and then it should just work. It won't because even if you load one through autoload and the other through your specified custom content directory ED32 won't know the difference so you'll have conflicting file names. If you want to fix that then you have to write a def file.

What woul happen in GZDoom? You say "-file fixpack.wad voxels.wad" and it works. That functionality is not in Raze yet but the usage of "GZDoom terminology" points towards it being a thing one day.

Ummmm no. This has nothing to do with how EDuke32 works, but rather that these mods were not made to be used with one another. It's a problem with the mods' design, not EDuke32. They could be designed in such a way that you can more easily use them together, but they're not.

Zaxx, on 06 February 2020 - 10:08 AM, said:

Overall I'm very sorry to say this because I know how diehard EDuke enthusiasts react to opinions like this but how EDuke32 handles custom content is well... fucking shit and it clearly needs some fine tuning so that the port could be more user friendly. That's the main reason why some people prefer BuildGDX, there loading stuff is just easy and hassle free.

You still can't load two GAME.CONs in BuildGDX. Face it Zaxx, you're making shit up. You barely know how EDuke32 works, most of this can be attributed to user error. You would have died back in the pre-EDuke32 days. It's easier to load, and create, custom content than any other single point in time up to now.

Radar 100 Watts, on 06 February 2020 - 01:59 PM, said:

This is not what you were talking about, but I have no problem with this. I agree modifying DEF files are annoying. I also hope the IWAD/PWAD model can be adopted in EDuke32 if it ever gets a Doomseeker plugin.

This will probably never happen because of the way Duke3D uses numbers and Doom uses names, in laymen's terms.

Zaxx, on 06 February 2020 - 02:36 PM, said:

It was what I was talking about, I just didn't specify it because I thought it was obvious. This was the original post:

So basically "Yay, you load mods like you would in GZDoom, this could be something!" I didn't remember / know about the "-g" command in EDuke32 though since I always used the autoload folder.

User error.

LeoD, on 06 February 2020 - 04:10 PM, said:

Btw., modders should know this. If they don't, or do not care, it's not EDuke32's fault when things don't work as intended.

This post is so fucking good, how has no one upvoted it before? I can't love this post enough. People just straight up do not know how this game works.

[Zaxx]

Jimmy, on 06 February 2020 - 06:11 PM, said:

Ummmm no. This has nothing to do with how EDuke32 works, but rather that these mods were not made to be used with one another.

You can use them together just fine if you write a def file though.

Quote

It's a problem with the mods' design, not EDuke32. They could be designed in such a way that you can more easily use them together, but they're not.

Or EDuke32 could be intelligent enough to sort stuff out by itself like GZDoom does. That way modders won't have to go out of their way to support mods made by others and I won't have to mess around with writing def files = everybody wins.

Quote

You still can't load two GAME.CONs in BuildGDX.

So? The example I've written about has multiple CON files but it doesn't have multiple GAME.CON files. But sure, when I used BuildGDX I did Blood stuff with it and Blood doesn't have CON so okay, the comparison is not perfect and BuildGDX shares some of the shortcomings.

Quote

It's easier to load, and create, custom content than any other single point in time up to now.

That's great but the "competition" is not any other point in time here but things like GZDoom and Doom Builder. I like EDuke32 too but I won't defend stuff that's bad about it.

[Jimmy]

Zaxx, on 06 February 2020 - 06:39 PM, said:

You can use them together just fine if you write a def file though.

This is pretty much incidental. Again, just because they happen to work together with a def line doesn't mean they were designed to work together.
Boo hoo, dude. You had to write one line in a file. What is the problem here?

Zaxx, on 06 February 2020 - 06:39 PM, said:

Or EDuke32 could be intelligent enough to sort stuff out by itself like GZDoom does. That way modders won't have to go out of their way to support mods made by others and I won't have to mess around with writing def files = everybody wins.

It has nothing to do with intelligence. Again, you don't know how these games work. It's a problem of file structure. Duke3D uses numbers, and Doom uses names, in laymen's terms, by design. Not all Doom mods work together either.

Zaxx, on 06 February 2020 - 06:39 PM, said:

So? The example I've written about has multiple CON files but it doesn't have multiple GAME.CON files.

Even the fact it has multiple .CON files and works together is merely incidental, much like many Doom mods.

Zaxx, on 06 February 2020 - 06:39 PM, said:

But sure, when I used BuildGDX I did Blood stuff with it and Blood doesn't have CON so okay, the comparison is not perfect and BuildGDX shares some of the shortcomings.

Okay, what?

Zaxx, on 06 February 2020 - 06:39 PM, said:

That's great but the "competition" is not any other point in time here but things like GZDoom and Doom Builder.

You're comparing apples and oranges. There is no competition between Duke and Doom because they're entirely different engines. If you prefer Doom so much, go play that?

[Zaxx]

Jimmy, on 06 February 2020 - 06:45 PM, said:

This is pretty much incidental.

Of course it is but the great thing about GZDoom is that you can make "happy accidents" like this happen more easily and that gives the modding scene a lot of flexibility.

Quote

Boo hoo, dude. You had to write one line in a file. What is the problem here?

Hey, it was 3 lines! The thing is though that if you're a layman like me then it takes some actual time and effort to find out how this stuff works for the first time, you have to look up and figure out what to include and that may be too much of a barrier for a lot of folks. With GZDoom it's like "okay I downloaded these wads so I'll just include these" and you're done 90% of the time.

Quote

You're comparing apples and oranges. There is no competition between Duke and Doom because they're entirely different engines. If you prefer Doom so much, go play that?

And I play Doom too just like you do because that's where the content is... yet we kinda know that even a lot of the more advanced stuff GZDoom offers Build could do better. Of course I won't blame the nearly non-existent Build modding scene on the janky autoload or the janky mapping tools because while I don't know a lot about Build I know enough to realize that the engine was fucked from the start compared to Doom but those two things are part of the problem. If I load up Doom Builder I can make a Doom map but I'm not sure I could put up with Mapster, the point is that I think improving these things could help in getting more people to do stuff.

[Jimmy]

Zaxx, on 06 February 2020 - 07:05 PM, said:

Of course it is but the great thing about GZDoom is that you can make "happy accidents" like this happen more easily and that gives the modding scene a lot of flexibility.

Hey, it was 3 lines! The thing is though that if you're a layman like me then it takes some actual time and effort to find out how this stuff works for the first time, you have to look up and figure out what to include and that may be too much of a barrier for a lot of folks. With GZDoom it's like "okay I downloaded these wads so I'll just include these" and you're done 90% of the time.

You also end up with a lot of user errors in Doom still. The only difference here is really where you write "include." One's in a command line/drag & drop and one's in a file. EDuke32 could definitely use better documentation, but once you know how to do it, it's really not that hard. I still use ZDL to play Doom mods, so maybe someone should create a frontend that auto-creates .DEFs for certain supported popular mods. That's a great idea actually. It's not like there's literally hundreds of mods released a year for Duke.

Zaxx, on 06 February 2020 - 07:05 PM, said:

And I play Doom too just like you do because that's where the content is... yet we kinda know that even a lot of the more advanced stuff GZDoom offers Build could do better. Of course I won't blame the nearly non-existent Build modding scene on the janky autoload or the janky mapping tools because while I don't know a lot about Build I know enough to realize that the engine was fucked from the start compared to Doom but those two things are part of the problem. If I load up Doom Builder I can make a Doom map but I'm not sure I could put up with Mapster.

The only reason I haven't been playing Duke is because of how unstable it has been in recent times. Testing it the past week or two it's really felt a lot better to me. As for Doom Builder VS Mapster, I can't figure out how to do anything in Doom Builder, and I was using BUILD/Mapster before I was ten years old.

[Sanek]

Micky C, on 06 February 2020 - 04:26 AM, said:

The port's not even properly out yet. If you're implying that Raze will have better modding support than eduke32 before it even gets the basics right, then you're a bit premature.

I was judging by the Blood video that Zaxx made. On the surface, it looks very good and yes, considering the sheer size of Doom community, I think it's safe to say there'll be plenty of modding support. They have plenty of guys who know how to code, compared to our group.

Anyway, if it'll be even better "franken-port" than original EDuke32 port, the days of EDuke32-only are numbered as of this moment. I give it about a year, tops.

[Phredreeke]

You can’t just take scripting from GZDoom and plug into a Build Engine game. People have too high expectations in that regard.

[ReaperAA]

Phredreeke, on 07 February 2020 - 04:54 AM, said:

You can't just take scripting from GZDoom and plug into a Build Engine game. People have too high expectations in that regard.

Agreed. I honestly would love to see something like Decorate/Zscript in Build engine games. But I understand that it would be a mammoth task to do so (if not downright impossible).

[Jblade]

You don't need to do that though. DECORATE is far more primitive than CON code, and ZScript is basically on the same level as CON.

The entirety of Ion Fury was done in CON code with the regular Eduke32, the only hardcoded things are just compile flags set for standalone builds IIRC

I don't understand where this ignorance of Build modding has come from. Even from day one Duke has always been far more modifiable than Doom, it had all the tools you needed on the original CD to do everything. The other games had no scripting support, but the maps still supported a ridiculous amount of malleability.

Quote

It has nothing to do with intelligence. Again, you don't know how these games work. It's a problem of file structure. Duke3D uses numbers, and Doom uses names, in laymen's terms, by design. Not all Doom mods work together either.

Exactly - there's nothing 'intelligent' about how GZDoom loads wads; due to how the game works Doom can handle multiple WADs dropped on top of each other slightly better but there's no magic behind the system.

[Doom64hunter]

Jblade, on 07 February 2020 - 07:22 AM, said:

You don't need to do that though. DECORATE is far more primitive than CON code, and ZScript is basically on the same level as CON.

DECORATE is less powerful, but ZScript is at least as powerful, and way, way more usable, simply because it uses high-level language design, rather than this weird assembly-like syntax that CON has.

[Radar]

Jimmy, on 06 February 2020 - 06:08 PM, said:

You are so fucking salty it's pathetic. Build a bridge and get over yourself, mate. If you're doing any of this for validation from other people, you're doing it for the wrong reasons.

Perhaps he should build a Bridge Between Two Islands?

[ReaperAA]

Jblade, on 07 February 2020 - 07:22 AM, said:

DECORATE is far more primitive than CON code, and ZScript is basically on the same level as CON.

DECORATE may be less powerful, but also much much more user friendly in terms of syntax. And Zscript (which has similar syntax as DECORATE) is easily as powerful as (if not more powerful than) CON. Doom's modding scene today is bigger than Duke's modding scene for a reason.

[AlektorophobiA]

Jblade, on 07 February 2020 - 07:22 AM, said:

I don't understand where this ignorance of Build modding has come from. Even from day one Duke has always been far more modifiable than Doom, it had all the tools you needed on the original CD to do everything. The other games had no scripting support, but the maps still supported a ridiculous amount of malleability.

The community using basically the same tools for more than two decades only with "under the hood" enhancements may be a reason, it's not 1996 anymore and people are spoiled with more modern tools like Doom Builder, so going from that to BUILD may feel "archaic" to some people.

[Jblade]

Reaper: that has nothing to do with scripting though. My projects, as well as Dan's, are more complex than 99% of Doom mods out there as far as what they do with the engine; that's not a flex, just the reality that I know what I'm talking about (I think Doom RPG, Doom roguelike arsenal are very complex...Caco's latest mod also looks very complicated) I can't explain why Doom is far more popular, but I'd be willing to bet it's more the ease of the level editors than scripting.

Alek: Build is difficult, but we had someone new join our team and she learnt the basics in a week. It's really not difficult at all, just how much effort someone wants to put into doing it is what counts.