GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
It's the same for UDMF, but there it's called BeforeFieldsChange (which apparently only calls BeforePropsChange). It's called all over the place.
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
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: (for lines and things)
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.
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 all
public void SetArg(int index, int new_value)
Try reinstalling SlimDX from SlimDX's website: https://slimdx.org/download.phpTwoDubyaz 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.
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.
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Thanks ZZYZX, installing the SlimDX stuff you linked worked.
Builder.exe wasn't even starting (w10 64 trying x64).some details[...]
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
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 :/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:(for lines and things)Code: Select all
public void SetArg(int index, int new_value)
wow i didn't notice, ty for letting us knowboris 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.
so how about
Code: Select all
public void SetField(string key, UniValue new_value)
- MartinHowe
- Posts: 2022
- Joined: Mon Aug 11, 2003 1:50 pm
- Location: Waveney, United Kingdom
- Contact:
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
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?
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?
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
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.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49067
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
That is not correct
If I am not mistaken the same tends to happen on removable storage.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.
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Ah, I didn't know that... that's ... quirky.
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Does GZDoom ignore Thumbs.db if found? (with directory -file include, or if accidentally stored into a PK3)
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49067
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
No, it will open the file and output an error message because it isn't a known image format
- Kappes Buur
-
- Posts: 4120
- Joined: Thu Jul 17, 2003 12:19 am
- Graphics Processor: nVidia (Legacy GZDoom)
- Location: British Columbia, Canada
- Contact:
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
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 .
- MartinHowe
- Posts: 2022
- Joined: Mon Aug 11, 2003 1:50 pm
- Location: Waveney, United Kingdom
- Contact:
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
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 )
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 )
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
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.
- MartinHowe
- Posts: 2022
- Joined: Mon Aug 11, 2003 1:50 pm
- Location: Waveney, United Kingdom
- Contact:
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
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.
It would be easy enough to script the PK3 to not include them when I get to that point.
- MartinHowe
- Posts: 2022
- Joined: Mon Aug 11, 2003 1:50 pm
- Location: Waveney, United Kingdom
- Contact:
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
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:
shows up in GZDB as "Farm hand".
However, this one:
shows up as "RadiationSuit" and not "Radiation Suit" - note the missing space between the words.
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 all
ACTOR Farmhand : Zombieman 15000
{
//$Title "Farm hand"
//$Color 12
var int user_HowKilled;
...
However, this one:
Code: Select all
ACTOR RadiationSuit : RadSuit replaces RadSuit
{
//$Title "Radiation Suit"
Inventory.PickupSound "radsuit/pickup"
}