ZScript Modules: A Proposal

Ask about ACS, DECORATE, ZScript, or any other scripting questions here!

Moderator: GZDoom Developers

Forum rules
Before asking on how to use a ZDoom feature, read the ZDoom wiki first. If you still don't understand how to use a feature, then ask here.

Please bear in mind that the people helping you do not automatically know how much you know. You may be asked to upload your project file to look at. Don't be afraid to ask questions about what things mean, but also please be patient with the people trying to help you. (And helpers, please be patient with the person you're trying to help!)

After reading the specification, do you believe this should be an accepted standard?

Yes
3
30%
Yes, but only after the specification has received changes (please specify)
5
50%
No
2
20%
No, I do not believe modules are the right solution
0
No votes
 
Total votes : 10

ZScript Modules: A Proposal

Postby The Zombie Killer » Thu Nov 16, 2017 8:16 am

I just finished writing the first draft of my specification for writing ZScript "modules."

I am very interested in hearing all of your thoughts and suggestions, as I think this could be a very useful system to adopt.

While writing the specification I created a series of sample modules. They are:

Last edited by The Zombie Killer on Thu Nov 16, 2017 9:33 am, edited 1 time in total.
User avatar
The Zombie Killer
King of the Kangaroos
 
Joined: 14 Jul 2011
Location: Gold Coast, Queensland, Australia
Discord: Zombie#1795

Re: ZScript Modules: A Proposal

Postby Graf Zahl » Thu Nov 16, 2017 9:26 am

zk-acsbridge: I'm not sold on this. Most ACS functions are geared towards how ACS works and make little sense out there. Translations, for example, would require quite a bit of refactoring first, most importantly making a translation a garbage collected object instead of some flat data type like it currently is.

Long term, scripting features should be taken out of ACS and put into a common module accessible to all scripting languages.

zk-stream: Export ScriptMan as a garbage collected object and you should be done.

zk-testsuite: Feel free to write it. I don't have time to conceptualize and develop such a thing.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: ZScript Modules: A Proposal

Postby The Zombie Killer » Thu Nov 16, 2017 9:29 am

I may not have been clear enough, I've already written those modules.

With zk-acsbridge you can do things like

Code: Select allExpand view
ACS.CreateTranslationStart(1);
ACS.CreateTranslationPalette(64793247);
ACS.CreateTranslationPalette(48634732);
ACS.CreateTranslationPalette(1441513247);
ACS.CreateTranslationPalette(3247192207);
ACS.CreateTranslationPalette(168191192207);
ACS.CreateTranslationRGB(224231255255255128128255);
ACS.CreateTranslationPalette(208223192207);
ACS.CreateTranslationEnd(); 


And then just do Thing_SetTranslation(0, 1);
User avatar
The Zombie Killer
King of the Kangaroos
 
Joined: 14 Jul 2011
Location: Gold Coast, Queensland, Australia
Discord: Zombie#1795

Re: ZScript Modules: A Proposal

Postby Marisa Kirisame » Thu Nov 16, 2017 9:30 am

I'm all for this but I'm not exactly a fan of the "four spaces for indentation instead of tabs" choice.
User avatar
Marisa Kirisame
ZScript Crimester
 
 
 
Joined: 08 Feb 2008
Location: Vigo, Galicia
Discord: 霧雨魔理沙#1666
Twitch ID: MarisaDOOM
Github ID: OrdinaryMagician
Operating System: Other Linux 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: ZScript Modules: A Proposal

Postby Marrub » Thu Nov 16, 2017 9:58 am

Marisa Kirisame wrote:I'm all for this but I'm not exactly a fan of the "four spaces for indentation instead of tabs" choice.

Obviously, we should all be using three spaces for indentation. :D
Also, my two cents: That we finally have a way of writing proper library code in ZDoom is great, standardizing it like this is a great idea.
User avatar
Marrub
Xevv Va Rkvyr
 
 
 
Joined: 26 Feb 2013
Discord: Marrub#5455
Twitch ID: marrubdaskuleion
Github ID: marrub--
Operating System: Other Linux 64-bit
Graphics Processor: ATI/AMD with Vulkan Support

Re: ZScript Modules: A Proposal

Postby ZippeyKeys12 » Thu Nov 16, 2017 10:08 am

Marisa Kirisame wrote:I'm all for this but I'm not exactly a fan of the "four spaces for indentation instead of tabs" choice.

Exactly what I'm thinking :?
ZippeyKeys12
 
Joined: 15 Jun 2016

Re: ZScript Modules: A Proposal

Postby The Zombie Killer » Thu Nov 16, 2017 10:11 am

The style stuff is mostly a set of guidelines rather than rules. If you're a fan of tabs over spaces, use tabs.
User avatar
The Zombie Killer
King of the Kangaroos
 
Joined: 14 Jul 2011
Location: Gold Coast, Queensland, Australia
Discord: Zombie#1795

Re: ZScript Modules: A Proposal

Postby Gutawer » Thu Nov 16, 2017 10:17 am

I'm interested in this, I was struggling with this here viewtopic.php?f=3&t=58377 and this would be a nice way to get around it. I've voted for the specification needing changes for reasons I've explained on the ZDoom Discord.
User avatar
Gutawer
User Accounts Assistant
 
Joined: 16 Apr 2016
Discord: Gutawer#3431

Re: ZScript Modules: A Proposal

Postby Xaser » Thu Nov 16, 2017 11:53 am

Super-thanks for leading the charge on this! About time. :D

At any rate, the gears are turning on a few additional thoughts, but the core seems pretty solid thus far. I'm 200% behind the concept, for sure.

The biggest omission at the moment (IMO) is the lack of versioning; distributed modules really ought to have a version number in the filename. Suppose there are two mods that utilize different versions of "zk-stream.pkm"; well, the user can only have one file by that name on their HDD, so it's liable that one of the two mods will become unplayable.

Proposal: semver is awesome and we should adopt it. In such a world, we'll not only know that "zk-stream_1.0.0.pkm" and "zk-stream_2.0.0.pkm" are incompatible versions, but the user can also have them both "installed" and mods that depend on each version will work swimmingly.

Also, while there's nothing wrong with coding/style guidelines, I think they're a bit out of place here -- I'd suggest splitting that off into its own proposal since it's pretty bikeshed-prone and I don't wish to distract from the actual topic.
Last edited by Xaser on Thu Nov 16, 2017 7:40 pm, edited 1 time in total.
User avatar
Xaser
anarchivist
 
 
 
Joined: 20 Jul 2003

Re: ZScript Modules: A Proposal

Postby Kinsie » Thu Nov 16, 2017 6:33 pm

Xaser wrote:The biggest omission at the moment (IMO) is the lack of versioning; distributed modules really ought to have a version number in the filename. Suppose there are two mods that utilize different versions of "zk-stream.pkm"; well, the user can only have one file by that name on their HDD, so it's liable that one of the two mods will become unplayable.
I'm seeing big issues with doing this, and also with not doing this.

Having every version be a seperate incompatible PK3 will lead to lots of clutter (having 20 different versions of the same module) and will inevitably lead to a situation where, say, the user wants to play a mod that uses v1.1 of a module, but only has v1.0 and v1.2 installed, leading to lots of trying to hunt down the right version (which will inevitably have a broken link).

However, making each version supercede the previous version will result in a situation where the module updating will potentially break every mod that uses the older version unless the module author is very, very careful (they won't be), cue a lot of frustration and confusion and mod authors finding out how Graf feels every day.

Given the ZDoom community's violent phobia for standardization and the "right thing" (reminder that Brutal Doom still ships with instructions to throw it in the skins folder!) I feel like an Elder Scrolls-esque external dependencies system for mods will create more problems than it'll solve.
User avatar
Kinsie
Dog Days
 
Joined: 22 Oct 2004
Location: MAP33
Discord: Find Me...
Twitch ID: thekinsie

Re: ZScript Modules: A Proposal

Postby Nash » Thu Nov 16, 2017 6:55 pm

Just dumping my quick thoughts before heading out for now:

- Not a fan of the .pkm extension
- Keyword casing: why not follow what GZDoom (for the most part) uses? The special ones like Sound, Sector, String, TextureID, Class, Vector3, while the "normal" ones like int, double, etc
- Tabs, not 4 spaces. Following GZDoom's engine source

EDIT: I am actually concerned about how all this fits into a TC/stand-alone workflow. I am making a stand-alone game and will most likely bundle any modules into my game's main ZScript
User avatar
Nash
AKA Nash Muhandes! Twitter/Facebook/Youtube: nashmuhandes
 
 
 
Joined: 27 Oct 2003
Location: Kuala Lumpur, Malaysia
Twitch ID: nashmuhandes
Github ID: nashmuhandes

Re: ZScript Modules: A Proposal

Postby Rachael » Thu Nov 16, 2017 7:04 pm

I think I will only throw my support behind this if the following conditions are met:

- The libraries are designed for compatibility, as much as possible, with every gameplay mod out there.
- Agreed with others - tabs, not spaces. Sorry.
- These libraries are LGPLv3 licensed and special care is taken not to include non-GPL conforming content. If these are to reach any sort of standard, they have to be something that myself and Graf can officially sanction without worry of the implications this may have. This means, of course, among other things, that all submissions may be used by others without permission (if credit is given, of course), and must be 100% original work by the author submitting them. (Another reason this is important is because including them with the distribution - if this even goes that far - would do a lot towards reaching a standardization point)
- Also I think these should be put on Github. I don't feel as strongly about this point as the other 3, but it's important and still hugely helpful.
User avatar
Rachael
Admin
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Graphics Processor: nVidia with Vulkan support

Re: ZScript Modules: A Proposal

Postby Xaser » Thu Nov 16, 2017 7:50 pm

Kinsie wrote:Having every version be a seperate incompatible PK3 will lead to lots of clutter (having 20 different versions of the same module) and will inevitably lead to a situation where, say, the user wants to play a mod that uses v1.1 of a module, but only has v1.0 and v1.2 installed, leading to lots of trying to hunt down the right version (which will inevitably have a broken link).

It's definitely not a perfect scenario, but it's much better than the everything-breaks alternative by a long shot. Improving module distribution problem can be done down the line; accepting some sort of standard is a necessary first step.
User avatar
Xaser
anarchivist
 
 
 
Joined: 20 Jul 2003

Re: ZScript Modules: A Proposal

Postby Kinsie » Thu Nov 16, 2017 7:58 pm

Nash wrote:I am actually concerned about how all this fits into a TC/stand-alone workflow.
Simple: It doesn't.

I feel like you guys are busying themselves coming up with standards and regulations and so on and so forth to avoid actually having to write stuff using ZScript. How's HOERS or whatever it was coming along, anyway?
User avatar
Kinsie
Dog Days
 
Joined: 22 Oct 2004
Location: MAP33
Discord: Find Me...
Twitch ID: thekinsie

Re: ZScript Modules: A Proposal

Postby phantombeta » Thu Nov 16, 2017 8:11 pm

Just wanna drop in my opinion on this.

Xaser wrote:Also, while there's nothing wrong with coding/style guidelines, I think they're a bit out of place here -- I'd suggest splitting that off into its own proposal since it's pretty bikeshed-prone and I don't wish to distract from the actual topic.

I agree very much with this.
The only part of the coding guidelines that I really agree with is the part about having the "constructor" method be named Create, because having several different modules follow different conventions for "constructor" methods would be extremely annoying and confusing.

Rachael wrote:- Agreed with others - tabs, not spaces. Sorry.

(See above.)

- These libraries are LGPLv3 licensed and special care is taken not to include non-GPL conforming content. If these are to reach any sort of standard, they have to be something that myself and Graf can officially sanction without worry of the implications this may have. This means, of course, among other things, that all submissions may be used by others without permission (if credit is given, of course), and must be 100% original work by the author submitting them. (Another reason this is important is because including them with the distribution - if this even goes that far - would do a lot towards reaching a standardization point)

While I agree that they must have an actual license, I very much highly disagree with forcing LGPL onto everyone.

Kinsie wrote:
Nash wrote:I am actually concerned about how all this fits into a TC/stand-alone workflow.
Simple: It doesn't.

I feel like you guys are busying themselves coming up with standards and regulations and so on and so forth to avoid actually having to write stuff using ZScript. How's HOERS or whatever it was coming along, anyway?

I imagine you're kinda wrong there. At least in TZK's case, you can see he definitely would do this...
Specially considering he already posted three modules he made in the OP. :wink:
User avatar
phantombeta
Tired of being treated like trash by control freaks
 
Joined: 02 May 2013

Next

Return to Scripting

Who is online

Users browsing this forum: No registered users and 2 guests