ZScript Documentation

Forum rules
Please don't start threads here asking for help. This forum is not for requesting guides, only for posting them. If you need help, the Editing forum is for you.

Post a reply

Smilies
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :geek: :ugeek: :!: :?: :idea: :arrow: :| :mrgreen: :3: :wub: >:( :blergh:
View more smilies

BBCode is OFF
Smilies are ON

Topic review
   

Expand view Topic review: ZScript Documentation

Re: ZScript Documentation

by Major Cooke » Mon Jul 31, 2017 6:28 am

...So this is where this thread was relocated to.

Re: ZScript Documentation

by dpJudas » Thu Jul 27, 2017 10:41 am

That would be this branch: refdocs

I didn't really try to finish it because it felt like I got a combination of shrugs and "yeah you go code that" feedback. As I didn't need ZScript documentation myself I figured that there's better things to spend my time on. :)

In any case, the code is there if anyone wants to pick up after where I stopped.

Re: ZScript Documentation

by Kinsie » Thu Jul 27, 2017 5:59 am

UsernameAK wrote:I think there's need for JavaDoc-like documentation generator for ZScript.
DPJudas was toying with something like this in a QZDoom branch back in February in the mainline ZScript Discussion thread. I haven't heard head or tail of it since, so I don't suspect it ever reached a point where it could be rolled into a release build.

Pity, it'd come in very handy, both for the mainline engine itself and for modders to document their work and welcome additional content to be bolted onto theirs, ala Reelism's makeshift mod system or Brutal Doom's endless forks.

Re: ZScript Documentation

by UsernameAK » Tue Jul 25, 2017 1:43 pm

I think there's need for JavaDoc-like documentation generator for ZScript.

Re: ZScript Documentation

by Major Cooke » Fri Jul 21, 2017 3:29 pm

Sorry. Bad habit. I was raised in a setting where if it has a title, It Must Have a Capital Except for Certain Words. As in, they put a drill to the back of my head. Almost.

...private schools I swear...

Re: ZScript Documentation

by Gez » Mon Jul 17, 2017 8:57 am

Please keep wiki style in mind when creating pages. Capitalize only things that actually need to be capitalized.

Tutorial On How To Make A Door -- wrong! don't do that! stop doing that!
Universal Doom Map Format -- caps okay because it's the proper name of a standard
A_FireMissile -- caps okay because function names use CamelCase

Re: ZScript Documentation

by Gutawer » Mon Jul 17, 2017 6:00 am

Assuming you're talking about in the C++ source, it just wouldn't have, as C++ doesn't have that feature. Can be replicated easily with something like an std::tuple, though.

Re: ZScript Documentation

by Nash » Sun Jul 16, 2017 6:57 pm

Curious... if multi-return is a LUA feature, how did ZDoom do multi-returns in C++ before?

Re: ZScript Documentation

by Major Cooke » Sun Jul 16, 2017 1:11 pm

I made this page in the effort to help programmers who are transitioning into using ZScript become a bit more familiar with its syntax, but it probably needs more work done.

Re: ZScript Documentation

by Kinsie » Tue Jun 20, 2017 2:40 pm

Graf Zahl wrote:Of course you cannot use Actor.GetCVar from an Event handler without specifying the actor in which context to use it.

So 'players[0].mo.GetCVar(...)' would be the proper way to read a CVar from player 1's context.

And for static CVARs you do not need any function at all, you can just use their name as a global read-only variable.
Thanks for this, cleans things up a little bit.

Re: ZScript Documentation

by Graf Zahl » Tue Jun 20, 2017 3:15 am

Of course you cannot use Actor.GetCVar from an Event handler without specifying the actor in which context to use it.

So 'players[0].mo.GetCVar(...)' would be the proper way to read a CVar from player 1's context.

And for static CVARs you do not need any function at all, you can just use their name as a global read-only variable.

Re: ZScript Documentation

by Kinsie » Tue Jun 20, 2017 2:47 am

Here's a gotcha I haven't seen anywhere else that's worth mentioning: Apparently [wiki]GetCVar[/wiki], for what it's worth, can't be used by EventHandlers. Even with like, server cvars. It just causes an Unknown Function error on startup.

You can take a long way around using CVar.GetCVar. For example, CVar.GetCVar("CVARNAME", players[0]).GetInt() will get the cvar's value from player 1. There's probably a better way to do this, and I welcome suggestions. This is for a serverside cvar, though, so it'd be the same value for all players anyway, right?

Keep in mind, though, that typos and such are not acceptable this way around. If you try to call a cvar that doesn't exist, you'll get a Very Fatal Error that doesn't tell you jack about what caused it. It's a Very Unhelpful Very Fatal Error.

Thanks to DrPySpy for shepherding me through this. Hopefully it saves someone out there, like, at least 15 minutes of frustrated debugging.

Re: ZScript Documentation

by camaxide » Mon Jun 19, 2017 11:41 am

Is there anywhere I can find info on the statscreen or on how to alter intermission?
I've looked at https://github.com/coelckers/gzdoom/blo ... screen.txt as well as https://github.com/coelckers/gzdoom/blo ... een_sp.txt but can't really make out how to add the world map in addition to the things I've already got going between levels.
I made these two posts a long time ago but got no replies, likely because noone knows how to do it: viewtopic.php?f=3&t=55284 - viewtopic.php?f=3&t=55841
But according to graf it should be possible to do this with zscript now. https://mantis.zdoom.org/view.php?id=280

Any help on this would be greatly appreciated. I hope to find out how I can add one extra step into the intermission between levels, so that I can have the world-map show up without having to remove the full-picture enterpic I've already got in the intermission-cycle.

Might be something with CurState = LeavingIntermission; but I really can't understand how to alter the zscript code to do this - compared to ACS and the old decorate-type coding there seem to be a lot more code needed with zscript, and at least for my head the code seem way less logic and self-explanatory.

Re: ZScript Documentation

by Major Cooke » Sun Apr 16, 2017 7:37 am

Just an update, I know the menu system has remained barren for some time but I've been making the templates offline to ensure they're in working order when they do go up.

It's taking longer than I thought because documenting every little thing and how it works is quite exhausting, since all I can do is continuously testing things out.

Having said that, I think I will take a small break and switch to documenting status bars, something that's far easier to work with than menus. Graf was right in that regard, they're a lot simpler than they look. :D

They still require knowledge on how to work with ZScript, but once you know those, you merely need to know what functions to use to get things to draw. If you have any experience with working on ACS or SBARINFO, it combines the strengths of both and allows one to completely convert all systems truly over to ZScript.

HUGE thanks to Graf for all his hard work!

Unfortunately documenting this may take a long time as well -- there are many, MANY things to cover.

Re: ZScript Documentation

by Major Cooke » Sun Apr 02, 2017 12:36 pm

Awesome! Thanks!
I take it the rest won't come until overlays can handle them as well? Just curious.

(Rolling hud elements would work wonders with things like scoping in and displaying little rotating wheels until it stops.)

Top