Page 65 of 97

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Posted: Sun Jan 13, 2019 5:28 am
by Gez
There are no engines that support what the lightmap thread is about. No standard for what format would be used to write them. It's completely pointless. You could as well say "feature suggestion: navmeshing" and yeah sure it'd be cool except that nothing exists that could use it.

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Posted: Sun Jan 13, 2019 8:17 am
by Tormentor667
I thought GZDoom is capable of lightmaps?

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Posted: Sun Jan 13, 2019 8:35 am
by dpJudas
There's an experimental branch that can do it, but it has several of outstanding issues. Those would have to be resolved first.

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Posted: Sun Jan 13, 2019 10:02 am
by IvanDobrovski
Found a small bug regarding 3D Mode: If you use a patch on a wall that also has a flat of same name in UDMF format instead of applying the patch it applies the flat on the wall. It works properly in game though. Notably can be found when used with OTEX made by ukiro. Sample texture to see the problem: OBKMTD01

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Posted: Sun Jan 13, 2019 2:51 pm
by Kappes Buur
IvanDobrovski wrote:Found a small bug regarding 3D Mode: If you use a patch on a wall that also has a flat of same name in UDMF format instead of applying the patch it applies the flat on the wall. It works properly in game though. Notably can be found when used with OTEX made by ukiro. Sample texture to see the problem: OBKMTD01
You should provide an example pwad of the problem
instead of having us hunt for the resource!

Anyways, this has been reported before.
See the issue with STEP1

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Posted: Wed Jan 16, 2019 3:33 pm
by Enjay
Recently, when I've been trying to save a map, I sometimes get this:

Image

Code: Select all

***********SYSTEM INFO***********
OS: Microsoft Windows 10 Pro
GPU: NVIDIA GeForce GTX 1080
GZDB: R3041
Platform: x86

********EXCEPTION DETAILS********
Visual Styles-related operation resulted in an error because visual styles are currently disabled in the client area.
   at System.Windows.Forms.VisualStyles.VisualStyleRenderer.IsCombinationDefined(String className, Int32 part)
   at System.Windows.Forms.VisualStyles.VisualStyleRenderer..ctor(String className, Int32 part, Int32 state)
   at CodeImp.DoomBuilder.Controls.DockersTabsControl.DrawTab(Graphics graphics, Int32 index) in w:\dev\GZDoom-Builder\Source\Core\Controls\DockersTabsControl.cs:line 112
   at CodeImp.DoomBuilder.Controls.DockersTabsControl.OnPaint(PaintEventArgs e) in w:\dev\GZDoom-Builder\Source\Core\Controls\DockersTabsControl.cs:line 182
   at System.Windows.Forms.Control.PaintWithErrorHandling(PaintEventArgs e, Int16 layer)
   at System.Windows.Forms.Control.WmPaint(Message& m)
   at System.Windows.Forms.Control.WndProc(Message& m)
   at System.Windows.Forms.TabControl.WndProc(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
Any ideas?

If I press "continue" everything seems to work.

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Posted: Thu Jan 17, 2019 11:42 am
by QuakedoomNukem Cz
It's also crashing for me, it doesn't tell me how, not because of saving, but it seems to happen in the visual mode, when I'm making the map. No bug reports are printed or anything, it just shuts down completely.

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Posted: Sun Jan 20, 2019 9:31 am
by leodoom85
Well, looks like I have problems loading the map in the latest build of the editor, R3045-x86. Could be possible that rotating the grid and resetting it before saving fuck things up?
In any case, I had to revert it back to R3041.

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Posted: Sun Jan 20, 2019 12:33 pm
by Remmirath
leodoom85 wrote:Well, looks like I have problems loading the map in the latest build of the editor, R3045-x86. Could be possible that rotating the grid and resetting it before saving fuck things up?
In any case, I had to revert it back to R3041.
I've traced down the problem to the .dbs files, more specifically to these 3 lines:

Image

The affected parameters are the brand new "gridrotate", "gridoriginx" and "gridoriginy". If I delete them from the .dbs files, I am able to open the map again. Seems like the editor manages to save these parameters, but can't parse them correctly upon map load.

Steps to reproduce:

1) Create new map
2) Draw a non orthogonal sector
3) Rotate grid according to linedef angle
4) Save map
5) Close map, and reopen
6) Editor freezes

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Posted: Sun Jan 20, 2019 12:50 pm
by DavidN
I just wanted to add a note saying nicely done with the grid rotation feature! It was something I never realized I needed, but it makes non-orthogonal rooms so much easier. Hopefully the save bugs are easy to hammer out.

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Posted: Mon Jan 21, 2019 7:31 am
by Volte
Hey guys, author of the grid rotation feature here. I can seemingly confirm that it freezes if you save and reopen a map with grid settings applied. I generally set the grid rotation, draw the geometry, and then reset, so I never hit that myself. I'll take a look and make a PR as soon as I can.

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Posted: Mon Jan 21, 2019 8:03 am
by Volte
I submitted a pull request to hopefully fix this issue. It seems that the first time the grid is rendered after a map load, the grid size values aren't initialized properly and you end up with size = infinity, and it caused the rotated grid drawing algorithm to go into an infinite loop. The normal grid algorithm doesn't have that problem.

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Posted: Mon Jan 21, 2019 9:00 am
by Nash
Volte wrote:I submitted a pull request to hopefully fix this issue. It seems that the first time the grid is rendered after a map load, the grid size values aren't initialized properly and you end up with size = infinity, and it caused the rotated grid drawing algorithm to go into an infinite loop. The normal grid algorithm doesn't have that problem.
Thanks for this really cool feature. Could you add some buttons to access the new grid features? I'm having a hard time remembering too many keyboard shortcut binds.

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Posted: Mon Jan 21, 2019 9:54 am
by Volte
No problem. I'd be happy to make it a bit more user friendly when I get some time, possibly this evening. (In the meantime, I use the following binds: Keypad-plus to align, Keypad-period to set origin, keypad-slash to reset)

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Posted: Mon Jan 21, 2019 10:31 am
by Remmirath
Thank you for the fix. Also thank you for this awesome feature. You might've opened a new frontier of mapping: if this feature skyrockets, the amount of non orthogonal mapping might grow exponentially in the future! :)