Page 1 of 1

Discrepancy in DECORATE number parsing

Posted: Mon Feb 22, 2016 9:49 am
by _mental_
Consider the following actor definition

Code: Select all

Actor T
{
	States
	{
	Spawn:
    		TNT1 A 0 A_FadeOut(0.L) // floating point number is expected
	}
}
The current maintenance branch treats the argument as zero. The master branch fails to load with Expected ',', got 'L' critical error.
If letter L is changed to something nonsensical like K, the behavior is identical: Expected ',', got 'K'.

The question is: which one is correct, maint or master?
In other words, is it a bug in the current version or a was it a works-by-occasion feature of older versions?

I suppose that 0.L means zero of long double type in C/C++ but I'm curios about its meaning in DECORATE.

Re: Discrepancy in DECORATE number parsing

Posted: Mon Feb 22, 2016 10:15 am
by Graf Zahl
This is clearly bug in the old parser. And it's not the only one. This is something that may need some thinking when someone actually uses it.

Re: Discrepancy in DECORATE number parsing

Posted: Mon Feb 22, 2016 5:35 pm
by randi
If I remember correctly, I discovered that the re2c grammar was accepting more for floating point numbers than it should have, which I fixed, so that's probably what's up here.

And here it is: Don't accept l as a suffix for floating point numbers in the scanner. Not sure how I feel about reverting it, but it could be if it serves the greater good. But that would depend on whether or not it exists in the wild. Some DECORATE cooked up using this to explicitly disable loading on 2.9+ does not count.

Re: Discrepancy in DECORATE number parsing

Posted: Tue Feb 23, 2016 1:48 am
by _mental_
randi wrote:Some DECORATE cooked up using this to explicitly disable loading on 2.9+ does not count.
It's from the latest version 20b of the mod that cannot be named :)

Re: Discrepancy in DECORATE number parsing

Posted: Tue Feb 23, 2016 3:26 am
by Graf Zahl
And it's clearly a typo in the mod. I'd say let them fix it. No need to make the parser unstable for something that's proably going to fixed anyway.

Re: Discrepancy in DECORATE number parsing

Posted: Sun Mar 06, 2016 10:19 pm
by randi
Brutal Doom is constantly updating. If this is only a problem with Brutal Doom, then I don't think it's worth worrying about.

Re: Discrepancy in DECORATE number parsing

Posted: Fri Jun 24, 2016 9:38 am
by Shane
Use the old values from v19. Open up brutalv20b.pk3 in something like 7zip or Winrar. Open blood.txt.

Find this area of code:
Spoiler:
And change it to
Spoiler:
Now you can continue using the developer builds until something else goes wrong. ;)

Re: Discrepancy in DECORATE number parsing

Posted: Thu Sep 15, 2016 5:06 am
by Hipnotic Rogue
Hi. I wonder if someone could help me. I had the same issue so I followed the above instruction re: replacing the code in blood.txt. Now, when GZDoom loads, it just ignores my edited brutalv20b.pk3 and doesn't load it.

This is what I did:

I used the latest release of 7zip to unpack the pk3 file.
I opened blood.txt in Notepadd++, found the above code and replaced it with the new code
I saved the txt file
I used 7zip to create brutalv20b.zip and then renamed it to a pk3

What have I done wrong?

Any help would be appreciated. :)

Re: Discrepancy in DECORATE number parsing

Posted: Thu Sep 22, 2016 6:13 am
by Accensus
Issue is most likely the inability of ZDoom to load stuff that's in a folder. Put all the files in the root folder of the pk3 instead of a subfolder.