ZScript Discussion

[ZZYZX]

But the point was to avoid transition problems from ASCII to Unicode. The first 255 code points in Unicode are Latin-1, which corresponds to code pages such as Windows-1252, not Windows-1251. I agree with 0-127 being a better choice.

This translates to "stop supporting non-English mods". All other lumps are parsed with 8bit characters and make no assumptions on the codepage, transparently allowing you to use any extended 8bit encoding you want with any character set.
Unicode, on the other side, is not supported and probably is not going to be supported in the near future. So yea, block non-English mods, cause differences in parsing and provide no alternative.
(note that "non-English" doesn't necessarily mean "cyrillic" as well — it may be western codepage with characters like ё (this particular example is cyrillic 'yo', but you get the point)).

[Graf Zahl]

I disagree with limiting it to 127, should be 0-255. People use one-byte non-ASCII encodings a lot, more specifically russian mods that use single-byte windows-1251 cyrillic encoding, which works perfectly with ACS, LANGUAGE and FONTDEFS.
Also, utf-8 won't be affected because utf-8 is two chars, and trying to support utf-8 natively is a bad idea IMO — ZDoom itself has nothing to support it.

Yes, and all those may show unexpected behavior, should the internal encoding be changed to UTF-8. I do not really trust the script parser sufficiently here, using such encodings in other text files (and in real strings) should be fine.

[The Zombie Killer]

So I had a horrible idea, and that horrible idea worked.
https://gist.github.com/DaZombieKiller/ ... f8e2a4adcb
You are all free to cry tears of blood after looking at this.

[ZZYZX]

p = new("GlobalStates");

And that's why actors should be marked nonew. Here's the first real life example of coders creating actors like that.

[Xaser]

From what I'm reading from that PR, what you're really trying to communicate here is "Actors don't behave properly if created without using Actor.Spawn".

To that effect, TZK's code ought to Spawn a GlobalStates at (0,0,0) and give it +NOINTERACTION (and probably just make it inherit from Actor; I don't think it needs to be a Weapon). Other than that, this is an interesting concept -- any danger to doing something like this? A random use case would be something like giving a common death sequence (e.g. burning) to Doom's former humans without having to copy+paste the states.

[Graf Zahl]

The main problem here is simply that object construction is still very much unfinished business. That the modders inevitably jump at every new feature like rabid sharks, screw it that the stuff may still need some work, is not helping, actually. I don't think that 'nonew' is a good idea. I would like to add genuine constructors with proper private/protected/public access control and use that as the main decision factor in what may be done - and allow the current new function only on classes that export a public parameter-less constructor or are derived from a base class saying it's ok to do such a thing.

The main question here is: How can this be locked down for the time being until a real construction framework can be added? If all else fails I'd just hard code all classes that must be blocked for the next release. As important as this is, there's some other non-ZScript issues that are far more pressing right now so this is something I'd rather put aside for later.

[The Zombie Killer]

From what I'm reading from that PR, what you're really trying to communicate here is "Actors don't behave properly if created without using Actor.Spawn".

To that effect, TZK's code ought to Spawn a GlobalStates at (0,0,0) and give it +NOINTERACTION (and probably just make it inherit from Actor; I don't think it needs to be a Weapon). Other than that, this is an interesting concept -- any danger to doing something like this? A random use case would be something like giving a common death sequence (e.g. burning) to Doom's former humans without having to copy+paste the states.

Inheriting from Weapon is necessary so that these "global states" can be used on weapons as well as regular actors.

[Xaser]

The main question here is: How can this be locked down for the time being until a real construction framework can be added? If all else fails I'd just hard code all classes that must be blocked for the next release.

I'd say just hardcode 'em until the real feature gets in. Proper construction would be fantastic, and "nonew" is a limited-use stopgap.

[ZZYZX]

I'm afraid proper constructors require method overloading. Otherwise it's no different from nonew+static create methods.
Also, 'protected' is not implemented. Just saying. (I've seen uses of it in the code, but I didn't find anything that actually checks for protected while implementing the play-ui barrier).

Also, my play-ui thing partially depends on commits that add nonew. Do I need to remove nonew in order to make a PR? (or the whole thing is on hold?)

[Marrub]

Code: Select all

class InputHandlerThing : EventHandler
{
    //
    // InputProcess
    //
    override bool InputProcess(InputEvent evt)
    {
        if(evt.type == InputEvent.Type_Mouse)
            CallACS("oh no");
        
        return false;
    }
}

Why doesn't this pick up anything?

[Major Cooke]

Because that's not how it works.

See this for an example.

Also don't forget to add the event handler in the gameinfo section like this:

Code: Select all

GameInfo
{
	EventHandlers = "MyHandler"
}

[Marrub]

That's not what I was asking. It works fine with keyboard events, but it doesn't seem to give me any mouse events.

[Major Cooke]

I have reason to believe CallACS will no longer work due to InputProcess being changed to a UI event. And as such searching for keyboard events will also not work, unless you use NetworkProcess.

viewtopic.php?f=3&t=55073&p=982190#p982190

But I'm still experimenting.

[Xaser]

I'm not ZZYZX, but an educated guess here is that InputProcess is operating on raw input prior to it being processed by the playsim, which would indeed cause Bad Things(tm) to happen in multiplayer if things were monkeyed around with.

I haven't been following this super-closely so I'm not sure what the status on this is (or even if it's officially slated), but there was talk of adding some means for certain UI things to queue playsim-altering commands to be executed in the next tic. Is this/will this be a general thing or was that concept limited to the menu system?

[EDIT] Sniped by a pseudo-edit; it looks like "NetworkProcess" is the thing I'm describing in my second paragraph.

[Major Cooke]

Boom headshot, baby.

Anyway, yeah. You now need to send a network event -- that other stuff's not gonna fly anymore, marrub.