GZDoom discussion (Version 2.3.1 released 2016/jan/7)
Re: GZDoom discussion (Version 2.3.1 released 2016/jan/7)
Push the tag please.
Re: GZDoom discussion (Version 2.3.1 released 2016/jan/7)
Hmm, getting this error now (in QZDoom, but I'm assuming Eruanna just merged this in from GZDoom):
Code: Select all
3>C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\xkeycheck.h(214): warning C4005: 'private': macro redefinition
3> C:\Development\Workspaces\dpDoom\src\scripting\codegeneration\dynarrays.cpp(40): note: see previous definition of 'private'
3>C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\xkeycheck.h(250): fatal error C1189: #error: The C++ Standard Library forbids macroizing keywords. Enable warning C4005 to find the forbidden macro.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49073
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: GZDoom discussion (Version 2.3.1 released 2016/jan/7)
Crap. For me it didn't warn - and certainly did not error out. I hacked around a private definition in that file because C++ is so utterly hostile toward keeping stuff private and exposing it to some external data structures. In order to do that I'd have to compromise the entire privacy mechanism.
Re: GZDoom discussion (Version 2.3.1 released 2016/jan/7)
Maybe I'm using a newer version of Visual Studio? I got Update 3 installed.
It is shame the friend keyword cannot be used in this context. The simplest solution I can think of would be to just make Count public. Alternatively make that static thing in the macro a global of a class that is friend of the class with the private member. That would require some additional macros tho, as I assume those globals need to be non-class globals.
It is shame the friend keyword cannot be used in this context. The simplest solution I can think of would be to just make Count public. Alternatively make that static thing in the macro a global of a class that is friend of the class with the private member. That would require some additional macros tho, as I assume those globals need to be non-class globals.
Re: GZDoom discussion (Version 2.3.1 released 2016/jan/7)
That would be great! I might suggest using AppImage to create a build that works on multiple distributions. It would also be great if your builds have FFMOD support (since getting FFMOD development packages for Linux involves sending the company an email).Eruanna wrote:I wouldn't mind providing GZDoom binaries for Linux, for all of x86, x86_64, and ARMv8. Getting x86 builds working might be a bit of trouble for me, though.
- Stormwalker
- Posts: 100
- Joined: Mon Sep 05, 2011 10:22 pm
Re: GZDoom discussion (Version 2.3.1 released 2016/jan/7)
I am experiencing a problem while running GZDoom 2.3.2 in Linux(Ubuntu). When I try to run the game Strife, GZDoom will find the iwad and start the game fine, except the voices will not play. I made sure that VOICES.WAD is located in the same directory as STRIFE1.WAD, yet GZDoom doesn't seem to be locating it. This problem does not occur in ZDoom. I am wondering what else I could be doing wrong, or if perhaps this is a bug. Any help would be appreciated. Thanks!
Re: GZDoom discussion (Version 2.3.1 released 2016/jan/7)
Don't you have to load that file with the -file parameter? I can't recall but I don't think ZDoom loads it automatically, just STRIFE1.WAD when selecting the IWAD.
Re: GZDoom discussion (Version 2.3.1 released 2016/jan/7)
From iwadinfo.txt:
Do not forget about case sensitive file system. It's a good idea there to have all IWADs with names in lower case.
So yes, it loads voices.wad automatically but not VOICES.WAD file.Code: Select all
IWad { Name = "Strife: Quest for the Sigil" // ... Load = "voices.wad" }
Do not forget about case sensitive file system. It's a good idea there to have all IWADs with names in lower case.
Re: GZDoom discussion (Version 2.3.1 released 2016/jan/7)
What? Since when? All of my IWADs are all caps, no problems. Is this a special case with voices.wad?_mental_ wrote:It's a good idea there to have all IWADs with names in lower case.
Re: GZDoom discussion (Version 2.3.1 released 2016/jan/7)
For finding IWADs, there's code that makes it so that if it doesn't find doom.wad (lowercase), it'll also try Doom.wad (initial cap) and DOOM.WAD (allcap). Such code must simply be missing for addons like voices.wad.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49073
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: GZDoom discussion (Version 2.3.1 released 2016/jan/7)
Nevander wrote:What? Since when? All of my IWADs are all caps, no problems. Is this a special case with voices.wad?_mental_ wrote:It's a good idea there to have all IWADs with names in lower case.
No, it's a special case with Linux.
- drfrag
- Vintage GZDoom Developer
- Posts: 3141
- Joined: Fri Apr 23, 2004 3:51 am
- Location: Spain
- Contact:
Re: GZDoom discussion (Version 2.3.1 released 2016/jan/7)
Since i can't register on the tracking system (application error) i'll mention this here.
BROKEN/INCONSISTENT DECORATE PARSING ON 2.3.2?
When i load my mutator brutalv20c_UP.pk3 after brutalv20b.pk3 some files in my patch are not parsed. These are files with the same name as in BD v20 inside my pk3, but other files also with the same name are parsed. The patch worked in 2.3 SVN.
I don't know how this is supposed to work, for instance BARON.TXT is not parsed. Since parsing already changed in 2.3 SVN when the file is named DECORATE.something i already changed the name to something different.
viewtopic.php?f=19&t=54525
BROKEN/INCONSISTENT DECORATE PARSING ON 2.3.2?
When i load my mutator brutalv20c_UP.pk3 after brutalv20b.pk3 some files in my patch are not parsed. These are files with the same name as in BD v20 inside my pk3, but other files also with the same name are parsed. The patch worked in 2.3 SVN.
I don't know how this is supposed to work, for instance BARON.TXT is not parsed. Since parsing already changed in 2.3 SVN when the file is named DECORATE.something i already changed the name to something different.
viewtopic.php?f=19&t=54525
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49073
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: GZDoom discussion (Version 2.3.1 released 2016/jan/7)
There shouldn't be any changes between 2.3.0 and 2.3.2, there's only some very minor alterations in the backend to fix 2 code generation bugs in places that normally aren't called from DECORATE, but nothing to the parser itself.
I conly can see that you do not include your definitions yourself, are these replacements of file names given by BD itself? Can it be that something changed in there?
I conly can see that you do not include your definitions yourself, are these replacements of file names given by BD itself? Can it be that something changed in there?
-
- Posts: 1774
- Joined: Sat Oct 17, 2009 9:40 am
Re: GZDoom discussion (Version 2.3.1 released 2016/jan/7)
I think it's a better idea to make a new symlink with lowercase name. I did it and works fine._mental_ wrote:From iwadinfo.txt:So yes, it loads voices.wad automatically but not VOICES.WAD file.Code: Select all
IWad { Name = "Strife: Quest for the Sigil" // ... Load = "voices.wad" }
Do not forget about case sensitive file system. It's a good idea there to have all IWADs with names in lower case.
Re: GZDoom discussion (Version 2.3.1 released 2016/jan/7)
At this point it's fair to expect any errors coming from BD mods are because of the mod itself. One thing I've always noticed is that apparently 1000 errors and warnings appearing the startup log aren't important.Graf Zahl wrote:are these replacements of file names given by BD itself? Can it be that something changed in there?