Page 93 of 123

Re: ZScript Discussion

Posted: Fri Jan 20, 2017 9:43 am
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.

Re: ZScript Discussion

Posted: Fri Jan 20, 2017 10:54 am
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.

Re: ZScript Discussion

Posted: Fri Jan 20, 2017 10:58 am
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.

Re: ZScript Discussion

Posted: Fri Jan 20, 2017 11:08 am
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.

Re: ZScript Discussion

Posted: Fri Jan 20, 2017 11:10 am
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.

Re: ZScript Discussion

Posted: Fri Jan 20, 2017 11:16 am
by Major Cooke
Static functions? Could we get a quick example of that in zscript?

Re: ZScript Discussion

Posted: Fri Jan 20, 2017 11:22 am
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.

Re: ZScript Discussion

Posted: Fri Jan 20, 2017 11:24 am
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]

Re: ZScript Discussion

Posted: Fri Jan 20, 2017 11:32 am
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?

Re: ZScript Discussion

Posted: Fri Jan 20, 2017 11:37 am
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.

Re: ZScript Discussion

Posted: Fri Jan 20, 2017 11:45 am
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.

Re: ZScript Discussion

Posted: Fri Jan 20, 2017 11:48 am
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...

Re: ZScript Discussion

Posted: Fri Jan 20, 2017 11:56 am
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.

Re: ZScript Discussion

Posted: Fri Jan 20, 2017 2:30 pm
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.

Re: ZScript Discussion

Posted: Fri Jan 20, 2017 2:46 pm
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.