Duke4.net Forums: Extending DEF script language to have working if statements - Duke4.net Forums

Jump to content

Hide message Show message
Welcome to the Duke4.net Forums!

Register an account now to get access to all board features. After you've registered and logged in, you'll be able to create topics, post replies, send and receive private messages, disable the viewing of ads and more!

Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

Extending DEF script language to have working if statements

#1

I previously posted a thread about whether there could be an option to pass console commands at runtime due to the different HRPs for Polymer and Polymost.

The file in the HRP "duke3d_hrp.def" contains commented out if statements:

// Extra additions to the game - High Resolution Pack

//if polymost then
//  include duke3d_hrp_polymost.def
//else
  include duke3d_hrp_polymer.def
//endif


Being able to include a different DEF file based on running configuration would be great. Is there any plans to extend the interpreter to parse if/else/elseif/endif statements?
0

User is offline   LeoD 

  • 536

#2

View PostMitch Richters, on 16 July 2019 - 01:44 AM, said:

Being able to include a different DEF file based on running configuration would be great. Is there any plans to extend the interpreter to parse if/else/elseif/endif statements?
No. Since I'm the one who wrote that example code: I don't think it is worth the effort. And running and configuring EDuke32 is more than complicated enough already. Users should know which files they have in autoload (like the Polymost override pack) and which other DEFs they use to run the game in their intended way. Only some "load_DEF_file_if_it_exists"-like statement would be nice to suppress unintended warning messages.


This post has been edited by LeoD: 16 July 2019 - 02:22 AM

0

#3

View PostLeoD, on 16 July 2019 - 02:21 AM, said:

No. Since I'm the one who wrote that example code: I don't think it is worth the effort. And running and configuring EDuke32 is more than complicated enough already. Users should know which files they have in autoload (like the Polymost override pack) and which other DEFs they use to run the game in their intended way. Only some "load_DEF_file_if_it_exists"-like statement would be nice to suppress unintended warning messages.


Definitely not wrong on the complicated part... I don't have the HRP in the Autoload folder either, I have the scripts that fork the SVN repository to your local disk.

By selecting "hrp" as the addon folder to load in the setup window, it will eventually snake its way through include lines in each DEF file, loading the Polymer DEF, which does not render right in Polymost. As such, I've configured the following shortcuts:

eduke32.exe -j "hrp" -h "duke3d_hrp_polymer.def"
eduke32.exe -j "hrp" -h "duke3d_hrp_polymost.def"


I think from a HRP developer point of view, some kind of automation via an if statement would be desirable, but what I've posted above works in any case. I guess most users see a checkbox for "Polymer" and think "Gee, that sounds amazing" and never think about it further.
0

User is offline   Phredreeke 

  • 444

#4

The problem is the user can switch between Polymost and Polymer at will. Should eduke32 have to force reload def files upon switching renderers?

Would IMO be better extending the texture and model commands to allow defining an alternative texture for Polymost (I haven't looked into the specifics of the Polymost override pack so I may be overlooking something though)
0

User is offline   LeoD 

  • 536

#5

View PostMitch Richters, on 16 July 2019 - 02:47 AM, said:

eduke32.exe -j "hrp" -h "duke3d_hrp_polymer.def"
eduke32.exe -j "hrp" -h "duke3d_hrp_polymost.def"

I think from a HRP developer point of view, some kind of automation via an if statement would be desirable, but what I've posted above works in any case.
The DEF hierarchy was expanded to provide this very solution after reviving the Polymost HRP part.

View PostMitch Richters, on 16 July 2019 - 02:47 AM, said:

I guess most users see a checkbox for "Polymer" and think "Gee, that sounds amazing" and never think about it further.
I once proposed to expand the startup window to have three radio buttons for the renderer: classic, OpenGL Polymost, OpenGL Polymer
Probably after writing the code snippet above. But it didn't happen.
Btw., implementing that "if rendertype" thingy would deny users to run the Polymer renderer/Polymost HRP combo, which can be a performance compromise for some hardware setups.

View PostPhredreeke, on 16 July 2019 - 02:59 AM, said:

The problem is the user can switch between Polymost and Polymer at will. Should eduke32 have to force reload def files upon switching renderers?
IIRC Hendricks266 once thought about that, indeed. Not worth the effort.

View PostPhredreeke, on 16 July 2019 - 02:59 AM, said:

Would IMO be better extending the texture and model commands to allow defining an alternative texture for Polymost (I haven't looked into the specifics of the Polymost override pack so I may be overlooking something though)
Not worth my effort. The OVR Pack is as simple as it gets by loading a different DEF file hierarchy from toplevel.


This post has been edited by LeoD: 16 July 2019 - 03:21 AM

0

#6

View PostPhredreeke, on 16 July 2019 - 02:59 AM, said:

The problem is the user can switch between Polymost and Polymer at will. Should eduke32 have to force reload def files upon switching renderers?

Would IMO be better extending the texture and model commands to allow defining an alternative texture for Polymost (I haven't looked into the specifics of the Polymost override pack so I may be overlooking something though)


That's a very fair point, and not one I considered. I just got the override pack but basically it just replaces the DEF files that come with the HRP to load alternative Polymost versions of other DEF files, which I already have as I believe the DEF files in the override pack are already in the SVN repo.

This request wouldn't be if I could set console commands at runtime. I have another topic open on that but noted the if statements commented out and thought I'd ask the question. :)
0

#7

View PostLeoD, on 16 July 2019 - 03:12 AM, said:

The DEF hierarchy was expanded to provide this very solution after reviving the Polymost HRP part.

I once proposed to expand the startup window to have three radio buttons for the renderer: classic, OpenGL Polymost, OpenGL Polymer
Probably after writing the code snippet above. But it didn't happen.
Btw., implementing that "if rendertype" thingy would deny users to run the Polymer renderer/Polymost HRP combo, which can be a performance compromise for some hardware setups.

IIRC Hendricks266 once thought about that, indeed. Not worth the effort.

Not worth my effort. The OVR Pack is as simple as it gets by loading a different DEF file hierarchy from toplevel.


Thanks :). I think this one can just be parked here. Both valid points from Phredreeke and yourself, and I think the better solution to what I really need would be to be able to pass console commands at runtime so I can have a few shortcuts configured. Just asked about the if statements as I saw them and thought it was potentially an alternate solution to my problem.
0

Share this topic:


Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic


All copyrights and trademarks are property of their respective owners. Instead of reading this text, you could be playing Ion Fury! ;) © 2019 Voidpoint, LLC

Enter your sign in name and password


Sign in options