SPOILER I am peeved with Wynnscript today. [THREAD SUSPENDED]

Edit at 8:39PM, 12/17/23:
I don't want to take down the thread for a few reasons - mostly because I'm gonna fix it up, but I am gonna rewrite this over the next few days to clarify misinformation & get my point across more logically, appropiately, and have straighter facts.

The original thread is in the spoiler below, but I wouldn't recommend using it as a source of truth, me and some others have discovered high amounts of dis and misinformation so for now I want to temporarily put that out of commission to improve it. I didn't account for some things & messed up other things, and I don't like the state of the thread.

Spoiler

URGENT NOTICE
Quick notice before we begin, my old version of this thread was slightly inaccurate - here is Salted's response (which again, thank you for clarifying! I really love the work y'all are doing im ngl)

Corrections will slowly be applied over the next little while - I'm also doing chemistry homework intermittently while applying these changes so while this message is here, take the contents with a few heaps of salt.

Also turns out I messed a few things up - I'll correct them probably tomorrow. I don't have much time left on PC tonight & tomorrow would probably be best time. Again, heaps of salt. Here's their criticisms:

Personally I agree these are valid criticisms, although I'm gonna need some time to respond lol

I think the misinformation kinda stemmed from the fact I was a bit annoyed and wasn't thinking as logically as I should've - that's a character issue on my part, I'm sorry

END URGENT NOTICE

Hi!
I'm Endistic.
You may remember me from making WynnScript's Workings - a thread where I went into how WynnScript worked.
I'd highly recommend you read it first if you haven't: https://forums.wynncraft.com/threads/wynnscripts-workings-updated.307193/

Now that you know about it & what it is, we need to have a talk.
Because I am unfathomably peeved.

A message I sent in the Realm of Uz Guild Discord in response to Etherweaver telling me to not give in to joining Wynn CT and focus on another project (though I won't mention it for sake of not advertising).

The Scripter Form
Earlier today, Wynncraft announced they need more scripters [for Fruma?]
https://forums.wynncraft.com/threads/wynncraft-is-looking-for-scripters.314202/

This is great. This is awesome. Though, let's dig into the form together, shall we?

Your replacing Command Blocks. Good to hear.

Ok. I like that. Verification is nice. Though, in these SS's I will be putting nonsense info so I don't spend a lot of time.
Let's skip ahead a few pages in the form together.

Atomic Keyword

Oh dear god.
...
Please tell me this is a joke.
Please. I hope with all my heart. This is a massive joke. Surely this must be a trick on me, right? Surely. Definitely it is. There's no way atomic would or should do that.

A) Atomic doesn't actually mean that. Atomic operations are presumed to be instantaneous, not how they are stopping the world when they run.
B) This is extremely dangerous. For one, what if it takes more than a tick to run? Does the server just halt until it's done? Does the plugin crash? I don't know.

The only advantage to see is that:
A) Bukkit/Spigot/Paper APIs are generally synchronous. They can not be used in multiple threads - the atomic keyword's current form would prevent deadlocks, yes, though it's lag prone.
B) Mutexes are "complicated" (not really, they're just an extra layer of stuff that's thread-safe) and the CT doesn't likely have good CS experience.

I'm very mixed on this honestly. Why WynnScript? I believed in you, I thought you'd be great. But no, you rip my heart out of my body with no regret, but not in a physical way. In a sort of mental way with great anguish, to suspend in disbelief and to completely evaporate and extinguish a hoping mind. Why did you do this?

Although, with Salted's clarification, the great news is that the atomic keyword is actually used very little! It's only used in a very small portion of scripts written, which is great to reduce it's risk. I will admit I am still a little fearful of the risks, but it seems like CT has it figured out. This is just a theory - but it's probably used for smaller things. If we go back to an old message in Wynn's discord by lexnt, they discuss a bug affecting mob drops scarily similar to a data race. This was probably one of few instances where atomic was actually used.

AST Interpreted
It's also likely WynnScript compiles to an AST. This is because during one point in a Hero Beta, WynnScript broke and printed out a Java stacktrace. Now, I don't actually have the screenshot so this all is very circumstantial - someone else does, though I want to keep others anonymous for now. I'll leave this section here for now as it is a valid fear, though this may all be completely invalid and possible to ignore. So just take all of this with a heap of salt.

All languages do that, well, compiling to an AST. But then they interpret THE AST?! That's not normal.

Now for those of you who are confused, I'm gonna give you a small sample of what this means.

Let's say you want to run this Python code (bare with me if you don't know what Python is):

PHP:

print("Hello world!")

The first thing the computer will do is split it into various tokens that the computer can understand.

PHP:

print ( "Hello world!" )

I just did tokenization based off spacing to help you understand.

These tokens are then parsed into a tree the computer can understand.

PHP:

  Print Statement(
    Text "Hello world!"
  )


Again, represented like this to make it easier to understand. In actuality, this process is a bit more complicated than it seems.

At this point, WynnScript interprets this tree. Now let's see what other languages do:

Python
Python compiles it to a bytecode & interprets that.

PHP:

LOAD_GLOBAL (print)
LOAD_CONST ('Hello world!')
CALL_FUNCTION 1
POP_TOP
LOAD_CONST (None)
RETURN_VALUE


Again, simplified for readability. Don't be afraid if you don't understand that bytecode at all - it's not meant to be human readable anyways.

Java & JVM
These languages compile to a virtual machine - a sort of computer that is programmed, not built. This interprets bytecode aswell, though typically compiles it to the host machine's machine code & runs it on that.

C, Rust, Go, & co.
These languages compile to machine code directly - not through any sort of bytecode, just directly to machine code.

So what's the problem?
Notice how in none of these methods, I compiled it to an AST and interpreted that. Why do we not compile to ASTs, you may ask? Performance.
A) AST resolving (identifying functions, variables, etc) generally takes a while to perform. At best, they use a HashMap to match functions, variables, etc. to their tree.
B) Because the nodes point to eachother, the computer is constantly jumping from place-to-place in memory, randomly. CPUs don't generally like when you do this as they can't predict where they'll go next.

Though, ASTs let you do some really cool self-modifying code stuff easily, though WynnScript does not do that.

What do I want?
I am moreso just annoyed that Wynnscript does these things. If I could wish upon a star for some changes, I'd like:
A) To atleast interpret bytecode like Python. This would improve Wynnscript performance significantly most likely. And, it's not that hard too (though the hardest part would actually probably be moving over the AST-based code to being bytecode-interpreted.)
B) At this point, `atomic` can't be fixed, but I think adding mutexes would be a much nicer improvement (though that would require both changing the entire Wynnscript code already written & mess with the language implementation aswell).

Salted's Response + How WynnScript is used internally
// TODO: write this & research this

Conclusion
That's all I really have to say.

In retrospect, this may have sounded rude or disrespectful. Sorry if it did, that was not my intent. I am just annoyed by misuse of atomic & some incredibly dumb decisions I found. I understand why this could happen - WynnScript is 8 years old after all and not all CT has extreme CS skills, I am just peeved my some small things. I also understand that Salted & co. that made WynnScript probably don't have the most PLTDI experience as that's a really uncommon niche to fully invest in. This is Minecraft anyways, 99.999% of server developers don't know a clue about making a programming language. Again, no mean intent is intended, all I want is to just talk about what I see & feel and try to help improve Wynnscript (even though I'm busy with other projects & aren't able to join the java dev team as such [i don't think i even legally could anyways - that's a paid job for 18+ and im 16 lol]).

I also might've gotten some things wrong due to extreme oversimplification (I want this thread to be understandable, after all). Sorry aswell about that.

If a mod allows, I might link to a project I'm working on that proves my credentials for saying this (though admittedly that project is very WIP. I'm also not the most happy with the parsing and what my project allows right now but I'll fix it up later).

Also, to those that say "just make WynnScript yourself and make it better"
I talked with CT before, and I asked if I could do just that. I got a response of basically "we can't stop you but we'd prefer you'd not" and I want to respect their wishes, so I will not be making WynnScript myself.
I have a lot of admiration for the CT, I'm not really interested in robbing them of their work and "making it better".
There's an extra two cents from me.

I think I'm calmed down now. Again, please refer to the note at the top of the thread. Have a good night!

 

IS ATOMIC THE CAUSE OF THE INFAMOUS WYNNCRAFT LAG ISSUE?!?! THE ONE WHERE YOUR HURTBOX IS UNBOUND FROM YOUR PLAYER?!?! THIS MAKES SO MUCH SENSE

in general just seeing what atomic does is very scary as a programmer, im not even too advanced and alarm bells started going off when i saw that since i feel like any bug with atomic code could cause some um. issues.

 

extremely common tigeryaisou W
If anyone else mentions lag issues, feel free to say. I'll eventually dedicate a small section of the Atomic Keyword section to talking about how it's a probable cause of lag. I just want to hear a bit more input first.

 

i dont mean general lag, i mean a particular type of lag that wynn has that ive not seen anywhere else. basically i THINK what happens is the server stops recieving your inputs, meaning that your clientside is still moving around just fine and your still recieving data(such as you being hit by the swarm of mobs standing where you were 5 seconds ago), but your location and clicks arent being updated serverside, hence the unbound hurtbox. i havent seen this on any other server and always assumed it was a funny code issue, this seems like a potential cause but it very likely is something else since its pretty random when it happens. really unfun when it happens since if your glassy you just kinda sit there like "well guess i'll die". it has gotten better over time tho and i havent seen it for awhile

 

Ah ok, thanks!
Also some staff are looking at this thread so if they see this reply, to repeat. No harm is intended, I want to see WynnScript succeed. I want to make this as clear as possible.

 

wholeheartedly agree, with a server this unique bugs are BOUND to occur, honestly its a miracle there are so few that have any gamebreaking issues. thanks for making such a cool game CT! :D

 

Good to know, thank you for clarifying!
I was mostly just worried because this seemed like a dangerous thing - I didn't know how often it was used. I also do admit I did underestimate, sorry about that. I don't really know much about WynnScript, but this was mostly just going off what I knew. I'm probably gonna make some adjustments to this thread to clarify some things.
Again, thanks for clarifying :)

 

This makes a bigger deal of it than need be. Javascript has much the same issue, but few complain with such fervor that Javascript "is SINGLE THREADED! USES AN EVENT LOOP! IS DANGEROUS! IF MY CODE TAKES A BIT TO RUN THEN IT WILL BLOCK OTHER EVENTS AND BUTTONS MAY HAVE DELAYED RESPONSES!"

I trust the designers of Wynnscript to have the sense to disallow waits in atomic scopes (which from Thomka's extension already seems to be the case).

Your proposed solution is mutexes- which you do mention are perceived to be "complicated"- and though while I would say it would not be a good idea to expose direct manipulation of mutexes to potentially non- CS-savvy GMs, I do actually think it could work, with some abstraction and syntax sugar. But what's the point? It has the same issues as atomic, only reworded. What if it takes more than a tick to run the code between the mutex lock and release? Does code dependent on the mutex data just halt until it's done? Does the plugin crash? I don't know. Yes, at first glance this might restrict any potential problems to only one global variable, but if you realize that Wynnscript most likely runs on an event loop it is actually severely worse to have mutexes. A sensible implementation of mutex-esque action in Wynnscript would have to wrap the block of code that uses the mutex in an "atomic scope" anyways- because consider this:

Thread A accesses mutex `foo`. Thread A will wait 5 ticks before accessing `bar`, then another 5 ticks before unlocking `foo`.
While Thread A is waiting, Thread B accesses mutex `bar`. Thread B will wait 5 ticks before accessing `foo`, then another 5 ticks before unlocking `bar`.
After 5 ticks, Thread A tries to access `bar`. It cannot, as Thread B has `bar`. Thread A gets kicked to the back of the event loop queue.
Thread B tries to access `foo`. It cannot, as Thread A has `foo`. Thread B gets kicked to the back of the event loop queue.

This goes on forever and ever (or maybe the designers of Wynnscript forgot to make it kick threads waiting on locked mutexes and the infinite wait would block not just the two threads but everything). Or Wynnscript can reveal lower level details to CT, but that still does not prevent hte possiblity of the above from happening, nor does it stop possible carelessness. But atomic scopes, as long as waits are disallowed, are a completely okay solution.

You also attack Wynnscript for something you are not even certain it actually does. And your biggest issue with tree walk interpreters is performance. Performance? If they cared so much about performance they should teach the CT Java. Or make Wynntale and stop using Minecraft. But performance is really most likely a non-issue for Wynnscript. This is like saying that you should choose programming languages based on the performance of their networking libraries. The HTTP request itself will take more time than it takes for the programming language- be it Python or Rust- to do whatever trivial manipulations it needs to do. The same goes for Wynnscript- modifying blocks and spawning mobs is probably going to be much more significant than the time it takes for the call that modifies said blocks or spawns said mob to be processed in Wynnscript. It's not like the entire server is built upon Wynnscript. No one's training neural networks or mining bitcoin with Wynnscript. It doesn't matter whether it takes Wynnscript x amount of time to process a statement or twice that- because running the behind-the-scenes operations that that Wynnscript statement interfaces is going to take much more time than the processing of the statement.

No string interning? Also how is this limited to tree walk interpreters?

 

Valid criticisms honestly. I don't really have a solution to any of these at the current moment, but I'll think about it for an upcoming while.

Also my idea about it being limited to treewalk interpreters was honestly kinda a brain glitch.
While bytecode and targets can use it, I just don't see it that frequently (they use indexes instead of names). Though, I also don't see many ASTs using indexes, though that could just be an oversight of mine. Besides that, I don't have much else to say. Good criticisms, will think over them.

 

Gonna add another thing: atomic doesn't necessarily mean instantaneous. It means indivisible (and in this context, uninterruptable). And that is exactly what atomic in Wynnscript is described as.

 

Good point.

Also due to misinformation both clarified by you and Salted, for now I put the thread in an "out of commission" state until further notice, so I have time to fix up dis and misinformation without spreading lies.

________________________________

The original thread is still there if anyone is curious + for archival purposes, though I wouldn't recommend relying on it as a source of truth.

________________________________

Also also, this idea of MC asynchronousness causing problems is very familiar, I'm actually struggling with a very similar issue on the project I discussed slightly in the O.G. thread. IMO atomic doesn't actually seem that bad of an idea in retrospect, especially with how Wynncraft actually does use it, but I am a little hesitant to put it in my project because not everyone may use it safely. I'm gonna try to look for alternative solutions and if I find one I'll definitely share it (though I probably won't).

Currently I'm looking into Folia and how it does things - though I don't know how much that'd apply to my project or Wynncraft, especially considering Folia doesn't have an official stable release.

________________________________

Actually, if Wynncraft uses Velocity, the scheduler could be useful. Maybe an abstracted version of it could be exposed to Wynnscript? Though I feel like that has similar issues to atomic that I'm missing.

 

Was pretty funny seeing Endi nearly blow up in guild discord tho XD.

 

it was funny indeed and i came back to my computer after a while so i spent like 10 minutes figuring out what was happening

 

thank you salted very cool

________________________________

i think the main issue is idk how much of the processing is hardcoded in minecraft, it could lead to the wynn code being single thread with the mc stuff kinda doing its own thing on the side

oh well, if it works it works!