Discrepancy in DECORATE number parsing

Bugs that have been investigated and resolved somehow.

Moderator: GZDoom Developers

Forum rules
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.
Post Reply
_mental_
 
 
Posts: 3820
Joined: Sun Aug 07, 2011 4:32 am

Discrepancy in DECORATE number parsing

Post 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.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49223
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: Discrepancy in DECORATE number parsing

Post 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.
User avatar
randi
Site Admin
Posts: 7749
Joined: Wed Jul 09, 2003 10:30 pm
Contact:

Re: Discrepancy in DECORATE number parsing

Post 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.
_mental_
 
 
Posts: 3820
Joined: Sun Aug 07, 2011 4:32 am

Re: Discrepancy in DECORATE number parsing

Post 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 :)
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49223
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: Discrepancy in DECORATE number parsing

Post 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.
User avatar
randi
Site Admin
Posts: 7749
Joined: Wed Jul 09, 2003 10:30 pm
Contact:

Re: Discrepancy in DECORATE number parsing

Post 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.
User avatar
Shane
Posts: 102
Joined: Thu Dec 17, 2009 4:33 am
Preferred Pronouns: No Preference
Operating System Version (Optional): Gentoo GNU/Linux
Graphics Processor: ATI/AMD with Vulkan/Metal Support
Location: Las Vegas, Nevada, America, Earth, Sol, Milky Way.
Contact:

Re: Discrepancy in DECORATE number parsing

Post 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. ;)
User avatar
Hipnotic Rogue
Posts: 110
Joined: Fri Jul 15, 2016 5:06 am

Re: Discrepancy in DECORATE number parsing

Post 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. :)
User avatar
Accensus
Banned User
Posts: 2383
Joined: Thu Feb 11, 2016 9:59 am

Re: Discrepancy in DECORATE number parsing

Post 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.
Post Reply

Return to “Closed Bugs [GZDoom]”