Questions About Raze

[MadeMan]

Will Raze Feature Decorate And ZScript Support? Loading PK3s And WADs And Option Search? 

[taufan99]

WADs are a DOOM thing, not Build Engine. For other features, maybe let Graf Zahl confirm this anytime sooner or later.

[Pablo_Doom_Guy]

there is a "raze sourceport" thread already created, you should ask there 

[Redneckerz]

17 hours ago, MadeMan said:

Will Raze Feature Decorate And ZScript Support? Loading PK3s And WADs And Option Search? 

• No, because it is based on eDuke32, not Doom. Decorate and ZScript target Doom, not eDuke32. Something like EScript could work, but that's beyond the scope of Raze.
• No, because it is based on eDuke32, not Doom. Same goes for WADs.
• Option search may be the only plausible thing here, but you will have to ask Graf for that.

[Graf Zahl]

It's a lot more complicated.

First, of the currently supported Build games there's 5 different game modules - two of them very similar and possibly mergeable - but the thing is, even with that you got 4 entirely different ways to define actors. The DN3D family uses CON scripts for that, Blood uses a mix of internal static tables with binary animation scripts, Shadow Warrior defines everything internally in its code and Exhumed works similar to Blood, but here even more actor logic is defined in binary scripts.

 

All this means that DECORATE is completely out of the question - it's a definition language to define actors for the Doom engine, it cannot be used for any of the Build games.

ZScript minus its DECORATE based parts might be doable if all the game code was restructured. But here's the caveats: The only game whose actor data is in a state where this might yield usable results is Shadow Warrior. Blood comes in second here, but first its binary scripts would have to be decoded to allow replicating them in a text based language, and some of the actor logic is not cleanly separated but part of bigger functions. The same is likely true for Exhumed as well, but its internal memory organization is a roadblock, too much data is held in small static arrays. And the Duke family is totally out. I'm still amazed that this code even works. Calling it "messy" would be a major understatement - it's one unbelievable clusterfuck of badly structured code - change one small detail and the entire house will come crumbling down. Just have a look at the side effects of EDuke32's recent refactoring and fixing of the collision detection code to understand what I mean. Adding a new scripting language here would never be able to do more than replicating CON with a better syntax. What's worse - in order to support all the games that are based on the DN3D engine it is virtually impossible to do it the ZDoom way and expose all features to editing. Much of the native code is so hardwired to its respective games that opening it up will most likely fail.

 

To summarize, adding more scripting here is not a worthwile endeavour. The nice thing about Doom is that despite some of its technical flaws (like the broken actor movement model) the overall structure of the code was years ahead of its time.

While both engines were written in C, Doom has a lot in common with modern OOP code - which made it easy for ZDoom to reimplement the core logic in real OOP - but Build games have a lot more in common with assembly programming and the lack of structure that implies - and this heavily impacts the usability of scripting.

 

 

Also, PK3's which are merely renamed Zips, can already be loaded. Of course they need to contain Build compatible content, so they look very different

 

Edited February 25, 2020 by Graf Zahl

[Graf Zahl]

25 minutes ago, Redneckerz said:

• Option search may be the only plausible thing here, but you will have to ask Graf for that.

 

Could be doable but the code for this is written in ZScript. The menu in Raze is an older pre-scriptification version. So it'd all have to be backported and the menu engine be enhanced to handle it. There's more important things to do right now (like making all the games work.)

 

[fabian]

Will Redneck Rampage ever be supported? Granted, the game was crap, but it was a Build engine game anyway.

[Graf Zahl]

It already is supported. And please don't call it crap! If you want crap, think Witchaven.

And since Nuke.YKT started adding Redneck Deer Huntin' to his RedNukem port yesterday, Raze will automatically inherit that one, too, once it's working.

 

[Redneckerz]

2 hours ago, Graf Zahl said:

 

Could be doable but the code for this is written in ZScript. The menu in Raze is an older pre-scriptification version. So it'd all have to be backported and the menu engine be enhanced to handle it. There's more important things to do right now (like making all the games work.)

 

I figured as much, i was just stating in short what you now replied in detail :)

 

After all, just because it uses GZDoom derived code does not make it a Doom engine source port.

34 minutes ago, Graf Zahl said:

It already is supported. And please don't call it crap! If you want crap, think Witchaven.

And since Nuke.YKT started adding Redneck Deer Huntin' to his RedNukem port yesterday, Raze will automatically inherit that one, too, once it's working.

 

I thought we all agreed Paladins 3D was the actual crap, with Tekwar a close second? ;)

 

Would be fun to have Deer Huntin' getting proper support. It reminds me of the old Cabela's hunting sims on Playstation, which look similar (but use a 3D engine afaik).

[Graf Zahl]

I have tried to "play" Witchaven and found it entirely unplayable thanks to the crappy player movement. I cannot comment on the other two yet. But from what I gathered they are all quite poor games.

 

 

[markanini]

It would be pretty cool to see Fresh Supply mod support. I don't know hot feasible Angelscript integration would be in Raze.

 

[Graf Zahl]

Without any reference source that shows how it is all connected? Next to none. There's also the added caveat that FS's gameplay is not authentic and that may impact the script interface, too.

 

[seed]

Indeed. It would be a cool thing to introduce in the future, but one problem: closed source.

 

The source to FS was never released, and without that it's not possible to integrate its features. And yes, the other problem would also be the fact that FS is buggy and its gameplay isn't faithful to the original at all.

[markanini]

Sure but the thread is about open source scripting langues, is it not? If Angelscript would be added it would take less effort for modders to convert their work when the time comes.

[Graf Zahl]

Yes and no. The language is only one part of the story, but if two engines implement a different API that won't help you much. Just like Duke3D and Blood are too different to share any game code, despite both using the Build engine.

 

[legoliamneeson]

hi, I have a question about raze, how do you set up raze for duke nukem 3d world tour on mac os as you can't install it on steam

[legoliamneeson]

On 2/25/2020 at 7:05 AM, Graf Zahl said:

Yes and no. The language is only one part of the story, but if two engines implement a different API that won't help you much. Just like Duke3D and Blood are too different to share any game code, despite both using the Build engine.

 

would you know how to set up duke nukem 3D world tour on raze on mac os?  you are a lead dev for this source port right?