GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Looks like now, when you connect two linedefs, it automatically creates a new sector, instead of waiting to you to finish drawing your sector. What am I doing wrong?
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
I spy with my little eye...improvement in resource loading time! Many thanks, ZZYZX!
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Try to explain your workflow more thoroughly. Step by step. What are you doing and what does it produce and how? Video would be best.Pedro vc wrote:Looks like now, when you connect two linedefs, it automatically creates a new sector, instead of waiting to you to finish drawing your sector. What am I doing wrong?
Because for me, in all modes (vertex, line and sector), drawing two linedefs doesn't result in automatically making a sector. It only finishes when I either press mouse2 or close the loop.
What is the loading time for you now? Because for me it was 1.5 seconds and still is 1.5 seconds That update was more theoretical.Lud wrote:I spy with my little eye...improvement in resource loading time! Many thanks, ZZYZX!
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Yes, that is exactly what I'm talking about. It automatically create a sector when I connect two linedefs.ZZYZX wrote:Try to explain your workflow more thoroughly. Step by step. What are you doing and what does it produce and how? Video would be best.Pedro vc wrote:Looks like now, when you connect two linedefs, it automatically creates a new sector, instead of waiting to you to finish drawing your sector. What am I doing wrong?
Because for me, in all modes (vertex, line and sector), drawing two linedefs doesn't result in automatically making a sector. It only finishes when I either press mouse2 or close the loop.
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Wait, so you create a linedef, and cancel drawing? And it creates a sector? Well that's somewhat legit behavior. Don't do that. Just draw a complete rectangle that connects these rooms.
If it _automatically_ cancels drawing though, send me the map or a minimal example map where this reproduces. I'll try to fix ASAP.
If it _automatically_ cancels drawing though, send me the map or a minimal example map where this reproduces. I'll try to fix ASAP.
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
I noticed with the latest devbuild that my ZScript-exclusive project now loads much faster and even doing a refresh (F8) it's still quite fast (0.61 seconds). Good work, and thank you for the continued fixes. =D
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Hi all, just noticed the existence of this fork.
Where can I find a list with versioning info? I mean, for viewing the changes made through versions.
Thank you.
Will do my best to feedback.
Where can I find a list with versioning info? I mean, for viewing the changes made through versions.
Thank you.
Will do my best to feedback.
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
@Resource loading time: It says 1.38 seconds, but that's not the time between pressing F8 and actually loading the resources & unfreezing the window. Still, seems faster for me. Perhaps a restart was the fix I needed.
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
I sent you a PMZZYZX wrote:Wait, so you create a linedef, and cancel drawing? And it creates a sector? Well that's somewhat legit behavior. Don't do that. Just draw a complete rectangle that connects these rooms.
If it _automatically_ cancels drawing though, send me the map or a minimal example map where this reproduces. I'll try to fix ASAP.
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
https://github.com/jewalky/GZDoom-Build ... its/masterNumnzel wrote:Hi all, just noticed the existence of this fork.
Where can I find a list with versioning info? I mean, for viewing the changes made through versions.
Thank you.
Will do my best to feedback.
No numbers though, only hashes. For numbers, idk, maybe something displays it like that. My fork changes start after the last m-x-d commit.
No automatic cancellation takes place for me: https://www.youtube.com/watch?v=ek6D7MVUJWsPedro vc wrote:I sent you a PM
Can't reproduce.
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Got this while scrolling through the list of game configs when making a new map.
Code: Select all
Object reference not set to an instance of an object.
at CodeImp.DoomBuilder.Config.ConfigurationInfo.Finalize() in w:\dev\GZDoom-Builder\Source\Core\Config\ConfigurationInfo.cs:line 233
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
That's extremely weird, but shouldn't happen anymore.
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Here's what is happening with me. I'm not pressing the finish drawing buttonZZYZX wrote:https://github.com/jewalky/GZDoom-Build ... its/masterNumnzel wrote:Hi all, just noticed the existence of this fork.
Where can I find a list with versioning info? I mean, for viewing the changes made through versions.
Thank you.
Will do my best to feedback.
No numbers though, only hashes. For numbers, idk, maybe something displays it like that. My fork changes start after the last m-x-d commit.
No automatic cancellation takes place for me: https://www.youtube.com/watch?v=ek6D7MVUJWsPedro vc wrote:I sent you a PM
Can't reproduce.
https://www.youtube.com/watch?v=D6AnggfqnNw
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
No idea honestly. Maybe someone here can help. (/me looks at Kappes Buur)
Are you 100% pressing NOTHING after 0:04? Because I see there is a zero length line, which means the vertex is placed and you are supposed to draw the next one, then nothing happens for 2 seconds, then it creates a sector.
Like you pressed something additionally.
Are you 100% pressing NOTHING after 0:04? Because I see there is a zero length line, which means the vertex is placed and you are supposed to draw the next one, then nothing happens for 2 seconds, then it creates a sector.
Like you pressed something additionally.
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Hello, after some time with the R2859, I can tell some things about.
1. The texture browser takes more time to load (about 1 second), in R2787 the load time is about ~1/4 of a second.
It's not a problem (at least not if it doesn't worsen), but improvements are always welcome.
2. The classic view is pretty nice, I like the fact that the used textures are separated with a line like before.
But then I lost a 'column' of texture view because of the separation of the border. Anyway, having the option to chose view is appreciated.
3. There is an apparent bug with some textures I've on my wad, seems like if they were scaled down so bad for unknown reasons. (Only in classic view) Here an image:
IE: I select the texture 'GRAYTALL' to see if it fits good on my floor, but it doesn't, so I press the 'G' to continue searching from where I left, but instead of going to where I expect, it writes G on the search bar thus limiting my search.
Also, I'm not even sure about if others might make use of it, but I would consider making an option to disable the texture stretching that the browser has currently, I find annoying to have a texture of 16x16 and viewing it zoomed-in just confuses me, I mean, I need to actually read the dimensions to know that it is indeed a small texture.
As a side note, where do you would prefer to discuss feedback/bugs? Should I report bugs here or on Github?
1. The texture browser takes more time to load (about 1 second), in R2787 the load time is about ~1/4 of a second.
It's not a problem (at least not if it doesn't worsen), but improvements are always welcome.
2. The classic view is pretty nice, I like the fact that the used textures are separated with a line like before.
But then I lost a 'column' of texture view because of the separation of the border. Anyway, having the option to chose view is appreciated.
3. There is an apparent bug with some textures I've on my wad, seems like if they were scaled down so bad for unknown reasons. (Only in classic view) Here an image:
Spoiler:Things being said, I have a request that was implemented in old versions of gzdb but was lost when maxEd updated the texture browser. I'm wondering if you would consider reintroduce it; It's about having an option to not autofocus the search bar on the texture browser. It was a core feature on my tool range when working with gzdb.
IE: I select the texture 'GRAYTALL' to see if it fits good on my floor, but it doesn't, so I press the 'G' to continue searching from where I left, but instead of going to where I expect, it writes G on the search bar thus limiting my search.
Also, I'm not even sure about if others might make use of it, but I would consider making an option to disable the texture stretching that the browser has currently, I find annoying to have a texture of 16x16 and viewing it zoomed-in just confuses me, I mean, I need to actually read the dimensions to know that it is indeed a small texture.
As a side note, where do you would prefer to discuss feedback/bugs? Should I report bugs here or on Github?