Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Danfun64

Fragglescript's Removal

Recommended Posts

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.

Share this post


Link to post

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.

Share this post


Link to post

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

Share this post


Link to post
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..?

Share this post


Link to post

ZDoom has FraggleScript with a fixed backend already.

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
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...

Share this post


Link to post

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.

Share this post


Link to post

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.

Share this post


Link to post

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.

Share this post


Link to post
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?

Share this post


Link to post
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

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×