ZScript Discussion

[Rachael]

@Graf: Do you want me to pull from your gz-zscript branch, or is that just experimental for you?

[Graf Zahl]

No, that's just the latest version from yesterday merged into ZDoom so that I could do a compile myself for some actual playing. But you should do an update from ZDoom before compiling.

[Nash]

Oh, that's interesting. Could that function be used to set an actor's sprite property directly via something like:

Code: Select all

self.sprite = GetSpriteIndex("SHTG");

?

(Can't test that code presently but that seems to be way thingdef_states.cpp is using said function internally. This would be extremely useful for a thing I'm planning on making).

Yes, that should work.

YOOOOO that is amazing. :O :O :O

Suggestion: could someone please make a wiki page or section about iterators, documenting any of the following:

- brief introduction, their purpose, and how they work
- iterator types (ActorIterator, ThinkerIterator, anything else?)
- what sort of task does each type excel at
- perhaps a brief explanation of the performance cost
- usage instructions, the options available, example code

Yes please; I would like a noob-friendly tutorial on how to use the scripted iterators.

[Rachael]

No, that's just the latest version from yesterday merged into ZDoom so that I could do a compile myself for some actual playing. But you should do an update from ZDoom before compiling.

My auto-update script usually takes care of that. As of now, it's up-to-date.

[Major Cooke]

Suggestion: could someone please make a wiki page or section about iterators, documenting any of the following:

- brief introduction, their purpose, and how they work
- iterator types (ActorIterator, ThinkerIterator, anything else?)
- what sort of task does each type excel at
- perhaps a brief explanation of the performance cost
- usage instructions, the options available, example code

Yes please; I would like a noob-friendly tutorial on how to use the scripted iterators.

I'll do it when I get home. It's actually pretty easy. And BlockThingsIterator too.

[ZzZombo]

Are overloaded functions planned?

[Rachael]

Actually - I had asked this before.

Subject: ZScript Discussion

Function overloading is an ugly can of worms I won't touch. I think named arguments will be more than enough to handle such things.

[Graf Zahl]

To elaborate on that, function overloading is one of the most problematic things because it needs to make some educated decisions which overload to use if the parameters do not match 100%. And this can turn ugly. Even C++ has its share of misses here that would cause some non-trivial bugs. In 99% of all use cases you are better off naming the functions differently (like ZDoom already did internally with the SpawnMissile family) and the rest can be dealt with with named and default arguments.

[Graf Zahl]

Quick note:

I just fixed a major bug with the chainsaw in the scripting branch, so I think I am pulling up the merge because that one's too important and I see no point applying the same fix to the old code a few days before it goes away. I'm giving this a few more hours but this evening I''ll merge it back to master.

[Rachael]

I've gone ahead and started the build for what might be the last GZZScript build then.

[ZZYZX]

To elaborate on that, function overloading is one of the most problematic things because it needs to make some educated decisions which overload to use if the parameters do not match 100%.

No 100% match for overloaded method = compiler error.

[Graf Zahl]

That's not possible because some types can be implicitly converted. And the rules for this are some of the most obtuse in C++, it's a mess I'd like to avoid.

[ZzZombo]

Eh, eh eh eh. I hope you at least won't declare it set in stone for the week, as per your previous post, should a design issue arise. BTW, where am I supposed to grab the latest ZScript build? ZDoom/GZDoom, no difference for me.

[Rachael]

https://devbuilds.drdteam.org/gzzscript/ if you can't/don't want to compile it yourself.

[ZZYZX]

That's not possible because some types can be implicitly converted. And the rules for this are some of the most obtuse in C++, it's a mess I'd like to avoid.

I meant disabling this specifically for the overloaded methods. People should use proper types anyway.