ZScript Modules: A Proposal

[The Zombie Killer]

I'll probably be updating the document later today to remove the style section (minus the part about constructors), and various other tweaks based on feedback in this thread.

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

I probably should've been clearer on what I define a keyword as in ZScript. Sound, Sector, TextureID & Vector3 would not be affected by the keyword casing rule. When I split off the style guide into a separate document I'll add an explicit list of keywords.

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

It'd work fine for a TC (assuming the TC is still a pwad), but I don't think GAMEINFO is read from an iwad, so your standalone game would need to list modules in IWADINFO (inside gzdoom.pk3). Possibly a GZDoom extension is in order here.

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

Agreed.

[Graf Zahl]

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

With zk-acsbridge you can do things like

Code: Select all

ACS.CreateTranslationStart(1);
ACS.CreateTranslationPalette(64, 79, 32, 47);
ACS.CreateTranslationPalette(48, 63, 47, 32);
ACS.CreateTranslationPalette(144, 151, 32, 47);
ACS.CreateTranslationPalette(32, 47, 192, 207);
ACS.CreateTranslationPalette(168, 191, 192, 207);
ACS.CreateTranslationRGB(224, 231, 255, 255, 255, 128, 128, 255);
ACS.CreateTranslationPalette(208, 223, 192, 207);
ACS.CreateTranslationEnd(); 

And then just do Thing_SetTranslation(0, 1);

No, I don't want that. It's just too hacky. I'd rather add true translation support to ZScript than piggybacking on the ACS table. This can be done a lot better. In general, each ACS function should be carefully reviewed before being made accessible like this. Better do it right than be saddled with some unpleasant cruft later.

[The Zombie Killer]

No, I don't want that. It's just too hacky. I'd rather add true translation support to ZScript than piggybacking on the ACS table. This can be done a lot better. In general, each ACS function should be carefully reviewed before being made accessible like this. Better do it right than be saddled with some unpleasant cruft later.

Okay, but that's not what this thread is about. That whole thing is just an example of a ZScript module, not a proposal for ZScript to implement those functions.

(Also, "saddled with some unpleasant cruft" kinda describes a number of functions already present in ZScript, due to being direct mappings to internal functions)

[Graf Zahl]

Sadly that cannot be helped. All those functions are being called from somewhere. If you want to be able to code low level monster AI you need access to the engine's internals.
Regarding ACS, my long term plan has been to review all functions available in both ACS and FraggleScript, move them to a separate module and then write proper exports for all languages that should access them. Hooking in some bridge now may be convenient but not be the best long term approach.

But as it is, my long term plans haven't been too compatible with the new job I have since August because I got far too little time to work on GZDoom.

[The Zombie Killer]

The specification document has been updated. Changes are listed below.

* Split the coding guidelines into two sections: "Recommendations & Best Practices" and "Coding Guidelines". The latter will likely be moved into a separate document in the future.

* Tweaked the coding guidelines to allow four-space width tabs.

* Added an explicit list of keywords to the coding guidelines that should be written in lowercase.

* Added a section on backwards compatibility under "Recommendations & Best Practices"

* Added a "Notes" section

* Added an entry related to MAPINFO's GameInfo block under the "Forbidden Practices" section.

* Added (currently empty) "Versioning" and "Licensing" sections.

[Rachael]

Subject: ZScript Modules: A Proposal

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?

Alright - so here I go full moderator mode, but this comes with a few caveats... here we go...

This post has been reported for trolling. After careful consideration, I have closed the report on this post - but please understand where I am coming from in saying what I am about to say, here.

On one hand I will say that I can see the reason for the report. It's not a nicely worded post, but not truly hostile from what I can see, and it is a valid point and a real concern. I can see how the HOERS reference seemed like a personal attack, but I don't think it was meant to be an attack. It was a pointed remark about the flaws in this very topic, using a rather embarrassing historical reference to support his point.

I can't speak for Kinsie, but I can tell you what I believe - and what I believe is that I think Kinsie had high hopes for HOERS only to be disappointed when the project didn't actually go anywhere. I think this statement is an expression of frustration at that. I might be wrong, but I think that was the reason for him making the post he did here.

The statement was definitely provoking - I will not deny or question that. I do believe Kinsie crossed the line here, but not by much.

There's definitely more productive ways to express this concern, but despite the issues with how he worded it, this still did it quite effectively, in my opinion. I actually agree with his concern - this (or at least close to this) has been done once before, and that didn't go anywhere. But who knows - the author of this one at least seems a bit dedicated to it, and willing to put some time and effort into it; we'll never know.

I do agree with Kinsie on another point, too, although he didn't directly state it (it seems implied) - the majority of this topic does seem to be a form of bike-shedding and arguing over frivolities at this point that will ultimately doom the project before it even gains any momentum.

@ Kinsie: This has been a problem for you before. You bring up an important concern so I will let this one slide. But you still did it the wrong way - you could have simply said "someone else did this before and that didn't go anywhere." You did not need the pointed question in this. You are on notice that if I see it again, appropriate action will be taken.

Therefore, it is my decision that although poorly worded, the post is an important enough concern to remain the way it is. I am sorry for upsetting anyone for not truly taking sides with this report - but this is how I feel about it.

Anyway, that's all I have to say about that for now.