Re: ZScript Documentation

Oh and Vaecrius, that edit about A_Jump* is wrong. That only applies to anonymous functions.
override String GetObituary(Actor victim, Actor inflictor, Name mod, bool playerattack)
{
static const String picker[] =
{
"%o message 1",
"%o message 2",
"%o message 3"
};
return picker[random(0,picker.Size())];
// If you want to do a fallback to the default message, simply do:
// return Super.GetObituary(victim, inflictor, mod, playerattack);
}
Major Cooke wrote:Menus: These are by far the hardest things to work with in ZScript.
Nash wrote:Sorry for the double post but I think this is also pretty important for the wiki and deserves a special mention:
Each built-in function needs to have all of their parameters documented. Right now, I have gzdoom.pk3 opened in SLADE to look up an Actor function, and I see these string of parameters and I have no idea what that bool parameter is supposed to do... then I have to open Visual Studio (thank you Intellisense) to look it up... very time consuming...
AFADoomer wrote:Could be worse! I don't have Visual Studio installed on my current machine... I usually keep at least 2 or 3 browser windows open to different pages in the GZDoom github site. At least the repository is searchable now - or wasn't until fairly recently!
Nash wrote:Hahaha oh man, this needs to be printed in font size 200.
Done.
Out of all the things you could do with ZScript, menus are by far the closest you'll get to C++'isms - very low level stuff. There are no convenience functions, no helpers, nothing like that. Of course the plus side is that you are given (pretty close to) free reign to design your menus - you literally could make a menu from scratch that does not even look like the built-in menu at all.
If there was a boot camp for programmers... This is all just day 1.
I remember every now and then there were talks of how "no matter what you do, menus will basically just end up looking like re-skinned menus" - well, ZScript menus will let you tear everything down and build menus from scratch.
And will also tear one's sorry ass asunder from the amount of headache one can induce because of the sheer heightened amount of possibilities to do stuff with it. It's insane.
If you barely understood the concept of building menus in ACS, don't expect to be building from-scratch menus with ZScript within the first few months. I mean, I'm not trying to intimidate or scare people away, but this is the truth that people need to realize before spending many hours and end up being disappointed and then grumpy.
The examples I've made I feel have contributed as some of the harder parts, though not the hardest. The hardest will soon come when I finish them for D4D. And agreed, making them in ACS does not transfer over to ZScript. If you are an ACSer, you are a goose. If you are a ZScripter, it becomes a duck. Incomparable. Or, y'know, the whole apples to oranges crap...
What I'm trying to say is, if you expect to just sit and wait for people to spoonfeed you documentation, it's not going to make you suddenly become a ZScript menu wizard. Of course, I agree that the BASICS should be documented (like, where the entry points are, how to do a basic bare-bones menus, things like that) but other than that, the ONLY way to master ZScript menus is to actually DO menus.
Eh, kinda hard to motivate people towards coding if they don't want to code in general. But you speak truth. One has to grind one's face in the dirt to get it going.
I have done some ACS menus in my time, and even then, I'm still fairly confused when it comes to ZScript menus currently. So yeah, expect a very high learning curve. And no, I'm not looking for a pat on the back and I'm definitely not bragging - I'm just saying the truth. Menus are hard. Expect a looooooooot of frustration during your lifetime of learning to make them.
Been going on for 3 weeks on trying to make this damned menu work for D4D, all for the sake of making it multiplayer compatible when that time comes. Not to mention breaking down the ability to cheat by changing the cvar prices...
Hopefully when the wiki starts filling up, it will be a good foundation for people to start experimenting.
Sadly you can have some of the most well-documented materials and people will still feel like it's pulling teeth.
Now that the scary stuff has been said, what I CAN tell you is, the best way to learn is to make menus and post questions on whatever you don't understand. You have to break several eggs before you get to make an omelet.
Welcome to Development Hell.
And therein lies the problem. The basics aren't being documented. And given that the attitude whenever it's asked about is "Oh, no way, man, shit's too hardk0er for mortals", it never will be.Nash wrote:Of course, I agree that the BASICS should be documented (like, where the entry points are, how to do a basic bare-bones menus, things like that) but other than that, the ONLY way to master ZScript menus is to actually DO menus.
Kinsie wrote:And given that the attitude whenever it's asked about is "Oh, no way, man, shit's too hardk0er for mortals", it never will be.
Nash wrote:Each built-in function needs to have all of their parameters documented. Right now, I have gzdoom.pk3 opened in SLADE to look up an Actor function, and I see these string of parameters and I have no idea what that bool parameter is supposed to do... then I have to open Visual Studio (thank you Intellisense) to look it up... very time consuming...