ZScript Discussion

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!)
User avatar
Agentbromsnor
Posts: 265
Joined: Wed Mar 28, 2012 2:27 am

Re: ZScript Discussion

Post by Agentbromsnor »

Major Cooke wrote:
The Zombie Killer wrote:
Major Cooke wrote:However, I suggest you drag TheZombieKiller in here to post his even more recently revised one as that one takes care of some further issues which mine had.
Already available here
Right here, Agent.
What should I be looking for there? Sorry, but I haven't followed any of the discussion up till now, so I don't have any idea about the context of what tackles this issue.
User avatar
Xaser
 
 
Posts: 10771
Joined: Sun Jul 20, 2003 12:15 pm

Re: ZScript Discussion

Post by Xaser »

Caligari87 wrote:Just a quick tangent here. I haven't delved into ZScript for my own projects yet so I'm curious: What can't ZScript do? My project is still very small code-wise, but has a decent chunck of ACS I'd like to refactor into the ZScript equivalent if possible, but I don't want to start yet if I'm just gonna run into some roadblock.
One important thing that's not yet in is the ability to add new functions to the root Actor definition. This meant it's not possible to create a common function for actors that don't inherit from a custom class (e.g. if you're modifying Doom's monsters by extending them rather than defining monsters from scratch ones). If you can get away with inheriting from a common class for whatever you're doing, though, you're all set.

[This is the part where Gez pops in and brings up the desire to modify existing actors in-place (e.g. ammo) without resorting to DEHACKED. Yes, I'd love that too, but that's opening an oil drum of worms. ;]


FWIW, I don't think this should discourage you in starting the conversion anyway. I've done so myself even though there's a few ACS-ish bits (UI mostly) hanging around. It's a much better base to build on, for sure.
User avatar
Major Cooke
Posts: 8081
Joined: Sun Jan 28, 2007 3:55 pm

Re: ZScript Discussion

Post by Major Cooke »

ZZYZX wrote:UI
Soon.
ZZYZX wrote:networking
Never.
Agentbromsnor wrote:What should I be looking for there? Sorry, but I haven't followed any of the discussion up till now, so I don't have any idea about the context of what tackles this issue.
base_player.zs, function UpdateLegsAndBody, line 61. This code smooths player movements and compensates for whenever the player tries to move into an unreachable place.
Last edited by Major Cooke on Fri Jan 20, 2017 11:08 am, edited 1 time in total.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 48331
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: ZScript Discussion

Post by Graf Zahl »

ZZYZX wrote:
Caligari87 wrote:What can't ZScript do?
UI, networking
UI will eventually be doable. Networking of course not, it's too low level.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 48331
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: ZScript Discussion

Post by Graf Zahl »

Xaser wrote: One important thing that's not yet in is the ability to add new functions to the root Actor definition. This meant it's not possible to create a common function for actors that don't inherit from a custom class (e.g. if you're modifying Doom's monsters by extending them rather than defining monsters from scratch ones). If you can get away with inheriting from a common class for whatever you're doing, though, you're all set.
You can already do that by using static functions. It may not be as nice but it's certainly doable.
Xaser wrote: [This is the part where Gez pops in and brings up the desire to modify existing actors in-place (e.g. ammo) without resorting to DEHACKED. Yes, I'd love that too, but that's opening an oil drum of worms. ;]
And I won't open that can of worms. I think what makes a lot more sense is to expose the Dehacked editing capabilities for ammo and weapons to some other control lump - but absolutely NOT to the part that DEFINES the actors.
User avatar
Major Cooke
Posts: 8081
Joined: Sun Jan 28, 2007 3:55 pm

Re: ZScript Discussion

Post by Major Cooke »

Static functions? Could we get a quick example of that in zscript?
User avatar
ZZYZX
 
 
Posts: 1382
Joined: Sun Oct 14, 2012 1:43 am
Location: Ukraine

Re: ZScript Discussion

Post by ZZYZX »

Code: Select all

class A
{
  static void DoSmth()
  {
  }
}

Code: Select all

A.DoSmth();
This is how you call BlockThingsIterator.Create(). Look at the definition of that in the ZScript files.
If you need to provide the self pointer, you will have to do so manually with Actor parameter to the function.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 48331
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: ZScript Discussion

Post by Graf Zahl »

Better like this, so that it can do something with the calling actor:

Code: Select all

class A
{
  static void DoSmth(Actor me)
  {
      me.A_PlaySound("loudnoise");
     me.A_SpawnProjectile("fireball");
  }
}

Code: Select all

A.DoSmth();
[/quote]
User avatar
Major Cooke
Posts: 8081
Joined: Sun Jan 28, 2007 3:55 pm

Re: ZScript Discussion

Post by Major Cooke »

So then I can just call A.DoSmth(self); from any other class without inheriting from A? Will I need to declare A in the actors I wish to call them?

Also what about returning?
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 48331
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: ZScript Discussion

Post by Graf Zahl »

Static functions can be called from everywhere, unless they are declared protected or private.
And they can return just like any other function, the only difference is that they do not have a hidden 'self' pointer.
User avatar
ZZYZX
 
 
Posts: 1382
Joined: Sun Oct 14, 2012 1:43 am
Location: Ukraine

Re: ZScript Discussion

Post by ZZYZX »

By the way apparently you can call a static method parameter 'self' instead of 'me' so that you can easily copy code around.
User avatar
Major Cooke
Posts: 8081
Joined: Sun Jan 28, 2007 3:55 pm

Re: ZScript Discussion

Post by Major Cooke »

Graf Zahl wrote:Static functions can be called from everywhere, unless they are declared protected or private.
And they can return just like any other function, the only difference is that they do not have a hidden 'self' pointer.
Ah right, I see now. So in a way this is almost no different from a struct being declared and used.
But out of curiosity, what would be better to use for global functions, structs or classes with static functionality? So far it appears both methods are the same, but structs are more 'stick to the declared actors' and as a result use less memory...?
ZZYZX wrote:By the way apparently you can call a static method parameter 'self' instead of 'me' so that you can easily copy code around.
I have my suspicions...
Gez
 
 
Posts: 17684
Joined: Fri Jul 06, 2007 3:22 pm

Re: ZScript Discussion

Post by Gez »

Graf Zahl wrote: And I won't open that can of worms. I think what makes a lot more sense is to expose the Dehacked editing capabilities for ammo and weapons to some other control lump - but absolutely NOT to the part that DEFINES the actors.
All I'm asking for is the ability to do what dehacked can do for actor properties. I'm not even asking about changing states, here, just the properties. I don't care about whether it propagates or not to inheritors (what would make sense to me is that it doesn't propagate to stuff that inherited during a previous compilation unit, and would propagate in stuff that inherits in a later unit -- coincidentally it's the approach that requires the least amount of work).

I'll point out that Eternity's EDF can do that with its thingdelta. i'm not even asking about the framedelta and others here, just thingdelta. It's nothing that is desperately needed.

With DECORATE or ZScript, if you want to change the max ammo of the Hexen mana, you'll have to replace the mana, which will mean replace the weapons, which will mean replace the classes, and also replace the HUD, and disable the old mana from the alt HUD, so you end up getting encumbered by a ton of MAPINFO, SBARINFO, ALTHUDCF and redundant DECORATE/ZScript code. It's ridiculous is what it is.

And it's dumb that if you load a mod that gives cacodemons blue blood and a mod that gives cacodemons health bonus drop items, they won't work together, when each of them is simply a modification of an actor property. That's the stuff that shouldn't need complete actor replacement. Would be so much better if they could simply update properties of the same actor, magically working together as a result of not having to use replacements.
User avatar
Xaser
 
 
Posts: 10771
Joined: Sun Jul 20, 2003 12:15 pm

Re: ZScript Discussion

Post by Xaser »

Graf Zahl wrote:static functions
Well, well! That will do nicely -- can't believe I missed that! :P

re:"thingdelta"-equivalent; given some explicit syntax (i'd propose "extend class A" if it wasn't already taken) and limiting it to JUST properties, would this really be that problematic in practice? Gez's order of propagation makes sense in my head, and the big lingering danger would be having Mod A unintentionally overwrite something essential from Mod B... but we already have of that problem with "replaces" (try loading ARGENT with a mod that modifies monsters; surprise! Chaingun and Gauss aren't dropped by the bosses anymore). Curious to know what other problems are extant since I've only got limited insight to the big picture.
User avatar
ZZYZX
 
 
Posts: 1382
Joined: Sun Oct 14, 2012 1:43 am
Location: Ukraine

Re: ZScript Discussion

Post by ZZYZX »

ZScript will eventually need to have a way to hook various engine events (for doing manual rendering of the UI for example — for which Tick is not enough, but per-frame precision is needed, as well as manual interpolation in thinkers, if any).
Example — UIEventHandler, that receives mouse input, keyboard input and canvas paint event, allowing it to draw stuff on the screen.
So:
  • EventHandler -> (UIEventHandler, WorldEventHandler, PlayerEventHandler)
  • EventHandler.Register(handler) // since event handlers are required to derive from either of the system handlers, type argument is not needed
  • EventHandler.Unregister(handler)
  • MAPINFO/GameInfo definition for specifying default handlers that are automatically loaded (for zscriptifying SBARINFO later for example, also for ZScript functioning outside of the map, i.e. in menus)
And:
  • WorldEventHandler: OnMapLoaded, OnMapUnloading, OnActorSpawned, OnActorDestroyed, OnLineAction
  • PlayerEventHandler: OnPlayerJoined, OnPlayerLeft, [OnPlayerSpectated]
  • UIEventHandler: OnPaint (called every RENDER frame), OnKeyDown, OnKeyUp, OnMouseMove (absolute X/Y coords, mouse in menus), OnMouseDelta (relative X/Y delta, ingame), OnMouseDown, OnMouseUp, OnMouseScroll
Additionally: expose some basic canvas methods (draw string, draw texture, getting screen dimensions, etc)
For each handler these are the virtual methods, whatever methods are overridden are executed for every event. There might be needed some way to block further propagation of the event, but that's something to do after it's been implemented IMO.

Graf, what do you think about this scheme? I might try to implement it if it's ok.
Last edited by ZZYZX on Fri Jan 20, 2017 3:57 pm, edited 11 times in total.

Return to “Scripting”