Fragglescript's Removal

Why was Fragglescript removed all those years ago? I couldn't find any clear answer about its removal. I'm not asking for you to reimplement it, just want to know why it was removed.

I remember Quasar discussing this in the podcast interview that was published last year (sorry I can't remember more details). I think there is an issue about the time of evaluation of scripts, for demo playback and/or network synchronisation.

I wonder what would it have been if the language was kept but the entire backend fixed/rewritten.

printz said:

I wonder what would it have been if the language was kept but the entire backend fixed/rewritten.

ZDoom would have copied it..?

ZDoom has FraggleScript with a fixed backend already.

Mordeth said:

ZDoom would have copied it..?

ZDoom already has already had ACS scripting ever since it inherited the Hexen code, and most people are happy with it.

printz said:

ZDoom already has already had ACS scripting ever since it inherited the Hexen code, and most people are happy with it.

ZDoom has had ACS support for Doom maps even before the Hexen code was released. That's why there are some subtle discrepancies between ZDoom and Hexen ACS.

Gez said:

That's why there are some subtle discrepancies between ZDoom and Hexen ACS.

For example?

Just asking for curiosity...

Angry Saint said:

For example?

Just asking for curiosity...

Script execution order is the big one. When several scripts are running simultaneously, the ACS VM not being a multithreaded thing (we're talking about stuff developed for 386 running DOS after all) the scripts are actually run one after each other. But how do you determine what is "after"? Do you go FIFO or LIFO? Turns out that the ACS VM in ZDoom is LIFO, but the ACS VM in Hexen is FIFO. Oops!

Here's a bug report discussion on the subject, now the ZDoom VM can handle scripts in either order, depending on required compatibility settings.

And, straight from my GitHub feed, here's what may be another:

Printz said:

There are conflicting implementations between ZDoom and Hexen, and Eternity chooses the Hexen one where the thing is always gibbed regardless of second arg. It does use the ZDoom extension from the third arg however, the optional sector tag.

I haven't dug in very old versions of ZDoom's code to verify when Thing_Destroy was first implemented, relative to Hexen code release, but the most likely reason was that it was an oversight while writing an original implementation of the feature way back then, and then it was deemed too late to fix.

Ok, good to know, thank you!

Gez said:

And, straight from my GitHub feed, here's what may be another:
I haven't dug in very old versions of ZDoom's code to verify when Thing_Destroy was first implemented, relative to Hexen code release, but the most likely reason was that it was an oversight while writing an original implementation of the feature way back then, and then it was deemed too late to fix.

For me that'd be a classic case for a compatibility option. But in the end for Hexen's monsters it is pretty much irrelevant how they die - it'll just look different -, while for new DECORATE monsters it can make a major difference if both death sequences are coded differently - take for example Quake's zombie which only dies permanently by the extreme death.

Which was the ultimate reason to leave it as it is.

printz said:

I wonder what would it have been if the language was kept but the entire backend fixed/rewritten.

I was able to fix the memory issues in there, but the overall design is probably beyond salvaging. But in hindsight it might have been the better choice than to replace it with Small only to see that get nuked by creator's stupidity. It's beyond my comprehension how someone can create a scripting language and then make it incompatible between 32 and 64 bit...

Mordeth said:

ZDoom would have copied it..?

Nah... Not for the language. The only reason this ultimately got into ZDoom was when 3D floor support was added so that some mapsets that got hit by Legacy's state of agony could be played again with a modern and functional engine.

But that was years after I have fixed that stuff in GZDoom, but that was only possible with ZDoom's garbage collector. The FraggleScript code was leaking memory like crazy.

Graf Zahl said:

I was able to fix the memory issues in there, but the overall design is probably beyond salvaging. But in hindsight it might have been the better choice than to replace it with Small only to see that get nuked by creator's stupidity. It's beyond my comprehension how someone can create a scripting language and then make it incompatible between 32 and 64 bit...

Another disadvantage of Small: it required to be compiled. And I believe it wasn't easy to decompile. But FraggleScript has to be included in source code form! Quite progressive for its day.

printz said:

Another disadvantage of Small: it required to be compiled. And I believe it wasn't easy to decompile.

... with incompatible binary formats between architectures. And this was the ultimate reason for its removal. Quite a design failure if you ask me.

printz said:

But FraggleScript has to be included in source code form! Quite progressive for its day.

... and interpreted from source. Quite slow...

I don't think it was ever designed with the assumption that people would use it to create really complex scripts that radically change Doom's gameplay and instead turn it into an emulation of a completely different game, like Mortal Kombat or Sid Meier's Civilization. It being slow isn't really relevant if all it's used for is to spawn a couple monsters after hitting a switch, or changing the camera briefly to show which door you've just opened.

Anyway, the best of both worlds approach is to have JIT compilation. Then you get something that's basically as fast as bytecode, and binary incompatibilities aren't a concern since it's the source that's shared.

Coincidentally, I've just seen this. Using plain old C as the scripting language is an interesting choice.

Interesting, yes, but for real scripting I wouldn't do without any form of class and object support.

C would be ok to replace ACS but not to script extensions to the native codebase.

At this point in time, I'd much rather see something like that person's experiment at embedding Lua, i.e. a real language with nice real features, than ACS (urgh) or Fragglescript or anything else that is a bit like having one hand tied behind your back.

Oh and whilst I'm at it, what we need in any such new thing is to build in the idea of *feature tests/detection* from the beginning, it's probably the only way we'll have any kind of graceful degredation of features for PWADs in ports, kinda like how HTML5 features are supposed to be used.

Jon said:

At this point in time, I'd much rather see something like that person's experiment at embedding Lua, i.e. a real language with nice real features, than ACS (urgh) or Fragglescript or anything else that is a bit like having one hand tied behind your back.

Who are you talking about that experimented with Lua on what game?

Oh and whilst I'm at it, what we need in any such new thing is to build in the idea of *feature tests/detection* from the beginning, it's probably the only way we'll have any kind of graceful degredation of features for PWADs in ports, kinda like how HTML5 features are supposed to be used.

What are you talking about? Could you provide a link explaining that?

printz said:

Who are you talking about that experimented with Lua on what game?

Well, Doom. I can't remember which project it was that I saw, I thought it was on DWF but I can't find it with a search, perhaps it was pasted on IRC. Looking now there are a few e.g. https://github.com/AlexMax/luadoom

What are you talking about? Could you provide a link explaining that?

The philosophical concept about features in HTML5 is that a web developer tests for the presence of support for a feature, and if present, can use it, and if not, could decide to do something else. This is because attempts to standardise HTML and get consistent support across browsers had basically failed despite a lot of effort and many years trying. I'm thinking that a similar concept could be useful for Doom features, as there's basically no hope for any standards to emerge post-Boom (and Boom support is not that consistent either)

See e.g.
http://diveinto.html5doctor.com/detect.html

Sonic Robo Blast 2 has built-in Lua support.

Death Egg said:

Sonic Robo Blast 2 has built-in Lua support.

That's very cool, I will have to take a look.