Discrepancy in DECORATE number parsing

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 a reply

Smilies
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :geek: :ugeek: :!: :?: :idea: :arrow: :| :mrgreen: :3: :wub: >:( :blergh:
View more smilies

BBCode is OFF
Smilies are ON

Topic review
   

Expand view Topic review: Discrepancy in DECORATE number parsing

Re: Discrepancy in DECORATE number parsing

by Accensus » Thu Sep 22, 2016 6:13 am

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.

Re: Discrepancy in DECORATE number parsing

by Hipnotic Rogue » Thu Sep 15, 2016 5:06 am

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

by Shane » Fri Jun 24, 2016 9:38 am

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

by randi » Sun Mar 06, 2016 10:19 pm

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

by Graf Zahl » Tue Feb 23, 2016 3:26 am

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

by _mental_ » Tue Feb 23, 2016 1:48 am

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

by randi » Mon Feb 22, 2016 5:35 pm

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

by Graf Zahl » Mon Feb 22, 2016 10:15 am

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.

Discrepancy in DECORATE number parsing

by _mental_ » Mon Feb 22, 2016 9:49 am

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.

Top