GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Software projects like source ports (3DGE, Eternity, etc), launchers like ZDL, and other useful utilities belong in this forum.
Forum rules
The Projects forums are ONLY for YOUR PROJECTS! If you are asking questions about a project, either find that project's thread, or start a thread in the General section instead.

Got a cool project idea but nothing else? Put it in the project ideas thread instead!

Projects for any Doom-based engine (especially 3DGE) are perfectly acceptable here too.

Please read the full rules for more details.

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby boris » Tue Jun 12, 2018 4:20 pm

It's the same for UDMF, but there it's called BeforeFieldsChange (which apparently only calls BeforePropsChange). It's called all over the place.
boris
I post less than Manc and Hobo
 
Joined: 15 Jul 2003

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby ZZYZX » Tue Jun 12, 2018 5:57 pm

anotak — thanks for explanation :Р
I don't think this is properly fixable without blocking direct Args assignment and breaking old plugins... I mean I can make a SetArg function, but no one will make the programmer use this function if they can easily Args[n] = x; instead.
But to fix it for the cases where people knowingly and voluntarily want to preserve the undo, I think implementing a method with the following signature would be best:
Code: Select allExpand view
public void SetArg(int index, int new_value)
(for lines and things)

TwoDubyaz wrote:Can't run the new releases with .NET 4.6.1 (fresh Windows 10 install/64bit) and now windows won't allow installing any 4.6.x. Previously was running r3018 fine but reinstalled windows and lost all my old .NET frameworks. Have r2993 and DB2 2.1.2.1553 working here if it means anything.

Try reinstalling SlimDX from SlimDX's website: https://slimdx.org/download.php
You need End User Runtime for ".NET 4.0", then either "x86 Download" or "x64 Download"

Otherwise I need some details on what does it mean that you "can't run" it.
User avatar
ZZYZX
le chat du rabbin
 
Joined: 14 Oct 2012
Location: Ukraine

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby TwoDubyaz » Wed Jun 13, 2018 2:33 am

Thanks ZZYZX, installing the SlimDX stuff you linked worked.
some details[...]
Builder.exe wasn't even starting (w10 64 trying x64).
TwoDubyaz
 
Joined: 12 Jun 2018

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby anotak » Wed Jun 13, 2018 1:58 pm

ZZYZX wrote:anotak — thanks for explanation :Р
I don't think this is properly fixable without blocking direct Args assignment and breaking old plugins... I mean I can make a SetArg function, but no one will make the programmer use this function if they can easily Args[n] = x; instead.
But to fix it for the cases where people knowingly and voluntarily want to preserve the undo, I think implementing a method with the following signature would be best:
Code: Select allExpand view
public void SetArg(int index, int new_value)
(for lines and things)

i'd say we should put comments by Args warning that writing to Args[some_index] is bad and deprecated and prevents undoing, so that people are aware. but yes we have to leave access in, to not break old plugins, like you say :/

boris wrote:It's the same for UDMF, but there it's called BeforeFieldsChange (which apparently only calls BeforePropsChange). It's called all over the place.

wow i didn't notice, ty for letting us know

so how about
Code: Select allExpand view
public void SetField(string key, UniValue new_value)

as well? (this would be in MapElement)
anotak
 
Joined: 06 Dec 2016

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby MartinHowe » Thu Jun 14, 2018 6:27 am

I know it's another thing to ask, but it would be nice if the program ignored Windows metadata files in image folders such as "sprites" or "flats". For example, the resource loader complains about Thumbs.db and its associated NTFS streams (such as Thumbs.db:encryptable) as not being image files.

These are standard NTFS filesystem things, at least in Windows 7, and should never be loaded in any case. It's incredibly annoying to have that flashing triangle in the bottom-right of the window for something that isn't an issue anyway, or to have to explicitly load the error dialogue and clear it every. single. time. , especially as I do a lot of reloading of resources during development of custom textures.

Please can this be done?
User avatar
MartinHowe
In space, no-one can hear you KILL an ALIEN
 
Joined: 11 Aug 2003
Location: Waveney, United Kingdom

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby Rachael » Thu Jun 14, 2018 6:30 am

Windows 7 no longer uses Thumbs.db, and you should remove those files anyhow. Windows 7 now stores the thumbnail cache in your user folder elsewhere on the drive.
User avatar
Rachael
QZDoom + Webmaster
 
Joined: 13 Jan 2004

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby Graf Zahl » Thu Jun 14, 2018 7:22 am

That is not correct

wikipedia wrote:However, when browsing network shares with write permission, Windows Vista and Windows 7 store a Thumbs.db file in the remote directory instead of using the (local) central thumbnail cache. This can cause issues when deleting remote shares, as the directory will become locked for a period of time when selected as Windows Explorer automatically creates a remote Thumbs.db file.


If I am not mistaken the same tends to happen on removable storage.
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby Rachael » Thu Jun 14, 2018 8:05 am

Ah, I didn't know that... that's ... quirky.
User avatar
Rachael
QZDoom + Webmaster
 
Joined: 13 Jan 2004

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby ZZYZX » Thu Jun 14, 2018 8:42 am

Does GZDoom ignore Thumbs.db if found? (with directory -file include, or if accidentally stored into a PK3)
User avatar
ZZYZX
le chat du rabbin
 
Joined: 14 Oct 2012
Location: Ukraine

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby Graf Zahl » Thu Jun 14, 2018 8:56 am

No, it will open the file and output an error message because it isn't a known image format
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby Kappes Buur » Thu Jun 14, 2018 2:17 pm

Spurred on by the above discussion about thumbs.db, I just had a look at my file system and found close to two hundred thumbs.db files. Will be hell to delete them all. Searching with Google I found this site and followed the steps. Hopefully I will not get any more thumbs.db files .
User avatar
Kappes Buur
 
 
 
Joined: 17 Jul 2003
Location: British Columbia

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby MartinHowe » Thu Jun 14, 2018 4:19 pm

Indeed; I am using Windows 7 in a VM to run DoomBuilder and exposing my computer's directories to it as a network share; so Windows 7 creates these files as GZ has stated. I didn't know this before, but guessed that it's what had happened as it seemed a logical explanation. I also didn't know that Thumbs.db had an associated hidden stream either - learn something new every day LOL

These files are normally hidden in Windows so even if created, GZDB wouldn't find them; however the way Linux files/directories hidden is pretty weird and Windows will surely not know anything about it. If you ever installed a multi-platform program that was originally developed on Linux or Unix, it will likely create a ".MyAppName" folder in your "C:\Users\MyName" folder; the initial "." means "hide this" in Linux/Unix.

Asking GZDB to ignore them would be useful. Pretty please? :)

( Porting GZDB to C++, Gtk and Linux would be even better :p )
User avatar
MartinHowe
In space, no-one can hear you KILL an ALIEN
 
Joined: 11 Aug 2003
Location: Waveney, United Kingdom

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby Empyre » Fri Jun 15, 2018 6:12 pm

OK, I can understand why thumbs.db is in your folders on your drive, but why is it in your pk3? It being there is an error that shouldn't be ignored by the editor. The game will not ignore it, but crash. Leave it in the folders on your drive where it is harmless, but remove it from your pk3 where it is not harmless.
User avatar
Empyre
The Ultimate Shining Example of Humility
 
Joined: 05 Apr 2007
Location: Garland, TX, USA

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby MartinHowe » Fri Jun 15, 2018 6:59 pm

If this was addressed to me, it's in the folders on the drive; since GZDoom can -file a folder, I haven't even created a .PK3 yet :)
It would be easy enough to script the PK3 to not include them when I get to that point.
User avatar
MartinHowe
In space, no-one can hear you KILL an ALIEN
 
Joined: 11 Aug 2003
Location: Waveney, United Kingdom

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby MartinHowe » Fri Jun 15, 2018 7:04 pm

I've found another bug - sorry :)
If you use the //$Title key in DECORATE, it works for actors that do not replace another; however if the actor replaces another, GZDB only shows the class name and ignores the title.

For example:
Code: Select allExpand view
ACTOR Farmhand : Zombieman 15000
{
    //$Title "Farm hand"
    //$Color 12
    var int user_HowKilled;
...

shows up in GZDB as "Farm hand".

However, this one:
Code: Select allExpand view
ACTOR RadiationSuit : RadSuit replaces RadSuit
{
    //$Title "Radiation Suit"
    Inventory.PickupSound "radsuit/pickup"
}

shows up as "RadiationSuit" and not "Radiation Suit" - note the missing space between the words.
User avatar
MartinHowe
In space, no-one can hear you KILL an ALIEN
 
Joined: 11 Aug 2003
Location: Waveney, United Kingdom

PreviousNext

Return to Software and Ports

Who is online

Users browsing this forum: No registered users and 0 guests