Page 72 of 79

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

PostPosted: Fri Jun 14, 2019 4:41 pm
by Enjay
Ah, right, thanks. I knew about DRD being down but forgot GZDB updates came from there. :oops:

Thanks again.

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

PostPosted: Sat Jun 15, 2019 7:17 am
by Rachael
The way files are served from that site has been altered slightly. The content-disposition is now always an attachment and the mime-type is now always application/octet-stream. I don't know if that's going to affect how it reads files from the dev builds site, but this is the only it will work right now. Hopefully it doesn't cause issues.

Basically, it means that nothing in a folder can be read simply as a page, anymore. It directs browsers to download anything and everything that appears there... and it may have some effect on how files are read directly.

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

PostPosted: Sat Jun 15, 2019 10:07 am
by Enjay
I have a minor inconsistency between visual mode and how things appear in game. In ZDoomHexen mode, if a line type 121 has flag 16 set to wrap middle textures, the texture is not wrapped in GZDB Visual.

The setup:


Visual mode:


In Game:

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

PostPosted: Sat Jun 15, 2019 3:29 pm
by boris
There's now support for OBJ models. I think I got everything right, but who knows with all the MODELDEF weirdness.

I also notices that it's already possible to copy the map analysis results to the clipboard. Just select everything and press Ctrl+C.

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

PostPosted: Sat Jun 15, 2019 5:40 pm
by Cherno
boris wrote:There's now support for OBJ models. I think I got everything right, but who knows with all the MODELDEF weirdness.

I also notices that it's already possible to copy the map analysis results to the clipboard. Just select everything and press Ctrl+C.


Thanks for working on OBJ support. However, After downloading the latest version, the program crashes when I load a map with a OBJ model defined in MODELDEF.

The MODELDEF entry:
Code: Select allExpand view
Model HG_Map07_All
{
   Model 0 "models/maps/map07abandoneddepot/map07mesh.obj"
   SurfaceSkin 0 0 "textures/style1/s1florc.png"
   SurfaceSkin 0 1 "textures/style1/s1flora.png"
   SurfaceSkin 0 2 "textures/style1/s1walla.png"
   SurfaceSkin 0 3 "textures/style1/stairs1.png"
   SurfaceSkin 0 4 "textures/style1/s1florb.png"
   Scale 1.0 1.0 1.0
   ZOffset 0

   FrameIndex FRAM A 0 0
}

Note that it uses 5 textures, maybe that's the issue?

The error log from GZDB:
(Sorry for German language, but it should be clear what went wrong. Index out of array bounds)
Code: Select allExpand view
***********SYSTEM INFO***********
OS: Microsoft Windows 10 Home
GPU: NVIDIA GeForce GTX 670
GZDB: R3063
Platform: x64

********EXCEPTION DETAILS********
Der Index war au├čerhalb des Arraybereichs.
   bei CodeImp.DoomBuilder.GZBuilder.MD3.ModelReader.ReadOBJModel(BoundingBoxSizes& bbs, Dictionary`2 skins, Stream s, Device device, String name)
   bei CodeImp.DoomBuilder.GZBuilder.MD3.ModelReader.LoadModel(ModelData mde, List`1 containers, Device device)
   bei CodeImp.DoomBuilder.Data.DataManager.ProcessModel(Int32 type)
   bei CodeImp.DoomBuilder.Map.Thing.UpdateCache()
   bei CodeImp.DoomBuilder.Data.DataManager.Load(DataLocationList configlist, DataLocationList maplist)
   bei CodeImp.DoomBuilder.Data.DataManager.Load(DataLocationList configlist, DataLocationList maplist, DataLocation maplocation)
   bei CodeImp.DoomBuilder.MapManager.ReloadResources(Boolean clearerrors)
   bei CodeImp.DoomBuilder.MapManager.DoReloadResource()
   bei CodeImp.DoomBuilder.Actions.Action.Begin()
   bei CodeImp.DoomBuilder.Actions.ActionManager.InvokeAction(String actionname)
   bei CodeImp.DoomBuilder.Windows.MainForm.InvokeTaggedAction(Object sender, EventArgs e)
   bei System.Windows.Forms.ToolStripItem.RaiseEvent(Object key, EventArgs e)
   bei System.Windows.Forms.ToolStripMenuItem.OnClick(EventArgs e)
   bei System.Windows.Forms.ToolStripItem.HandleClick(EventArgs e)
   bei System.Windows.Forms.ToolStripItem.HandleMouseUp(MouseEventArgs e)
   bei System.Windows.Forms.ToolStrip.OnMouseUp(MouseEventArgs mea)
   bei System.Windows.Forms.ToolStripDropDown.OnMouseUp(MouseEventArgs mea)
   bei System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
   bei System.Windows.Forms.Control.WndProc(Message& m)
   bei System.Windows.Forms.ToolStrip.WndProc(Message& m)
   bei System.Windows.Forms.ToolStripDropDown.WndProc(Message& m)
   bei System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

PostPosted: Sat Jun 15, 2019 5:52 pm
by boris
Can you supply the OBJ?

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

PostPosted: Sat Jun 15, 2019 6:04 pm
by Cherno
boris wrote:Can you supply the OBJ?


Here is the download link from my DropBox:

map07mesh.obj

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

PostPosted: Sat Jun 15, 2019 7:46 pm
by Enjay
Not sure if this is a bug or just an unimplemented feature (I suspect the latter).

If you make a 3D floor using flags 32 to draw the sidedefs lower texture on the side of the 3D floor (and if floor heights are the same either side of the line so that the texture isn't required for any other architecture), if you don't put a lower texture on the line, the "texture missing" error checker does not pick up that the texture needed for the side of the 3D floor is missing.

The 3D view correctly shows the "texture missing" orange texture, but the error checker doesn't pick it up. I assume the same situation would happen with flags 16 to use the upper texture too.

Floor set up with flag 32:


All lower sides have SHAWN2 on them except the one with the missing texture symbol, which has no lower texture set.

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

PostPosted: Sat Jun 15, 2019 11:57 pm
by Bauul
boris wrote:There's now support for OBJ models. I think I got everything right, but who knows with all the MODELDEF weirdness.

I also notices that it's already possible to copy the map analysis results to the clipboard. Just select everything and press Ctrl+C.


Let me again say how grateful you are for jumping on this so readily! It's super, super appreciated!

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

PostPosted: Sun Jun 16, 2019 4:29 am
by Enjay
Another error checking one: "Check Unknown Textures" doesn't detect a bad texture name if the bad texture name is on a part of a sidedef that will never be seen.

e.g.








The above "Fake" 1 & 2 textures do not exist. They are just names that I put on the back sides of the above sectors. The front sides face out, so the back textures are never seen.

Fake3 & 4 are on one of the single sided lines around the edge

A GZDB texture name check gives a clean bill of health:



But the at GZDoom console:
Code: Select allExpand view
MAP01 - Entryway

Unknown top texture 'FAKE3' on first side of linedef 1
Unknown bottom texture 'FAKE4' on first side of linedef 1
Unknown top texture 'FAKE1' on second side of linedef 4
Unknown top texture 'FAKE1' on second side of linedef 5
Unknown top texture 'FAKE1' on second side of linedef 6
Unknown top texture 'FAKE1' on second side of linedef 7
Unknown bottom texture 'FAKE2' on second side of linedef 8
Unknown bottom texture 'FAKE2' on second side of linedef 9
Unknown bottom texture 'FAKE2' on second side of linedef 10
Unknown bottom texture 'FAKE2' on second side of linedef 11


Although those textures probably shouldn't even be placed on those lines (even if they were real textures), we've all made or seen maps where some textures were placed unnecessarily. This was actually noticed when converting a map to use a different set of textures from the set that it was originally made with. After I had finished most of the changes with find-replace, I used the F4 error checker GZDB to the few remaining ones that I wanted to change manually. I thought I'd finished but when I fired up GZDoom, the console told me otherwise. It wasn't a big deal, in as much as I just used DeePsea to find them instead, but I reckon that GZDB should be picking them up.



And, on quite a different topic, is there a toggle that prevents geometry being merged? I was working on a map and I'd drawn a little sector inside a bigger sector and I wanted to move some of the sides top of and merge with some of the lines from the bigger sector. However, no matter how I did it (moving vertices, lines and the whole sector) the lines just sat on top of each other and would not merge. I saved the file, quit and restarted and I was then able to merge stuff. I'm guessing that I hit a hotkey of some sort that disabled merging of geometry and that restarting reset things to default, but I have no idea what I hit. I didn't find anything that made the same thing happen when trawling through the menu and the options. It'd be nice to know how to do this in case I do it again by accident.


And, yes, I'd like to echo Bauul's comments. Thanks very much for picking up this stuff and running with it boris. It's very much appreciated.

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

PostPosted: Sun Jun 16, 2019 5:17 am
by boris
Cherno wrote:
boris wrote:Can you supply the OBJ?


Here is the download link from my DropBox:

map07mesh.obj

Fixed in 3064. However, the textures won't display correctly. It looks like they are not wrapped, and I'm not sure why. I don't really have a clue about SlimDX/Direct3D, so it's pretty hard for me to figure out what's going on.

Enjay wrote:stuff

If you happen to have a GitHub account I'd really appreciate if you opened issues for that. In here it's pretty much bound to get lost if it doesn't get fixed immediately.

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

PostPosted: Sun Jun 16, 2019 5:28 am
by boris
Enjay wrote:And, on quite a different topic, is there a toggle that prevents geometry being merged? I was working on a map and I'd drawn a little sector inside a bigger sector and I wanted to move some of the sides top of and merge with some of the lines from the bigger sector. However, no matter how I did it (moving vertices, lines and the whole sector) the lines just sat on top of each other and would not merge. I saved the file, quit and restarted and I was then able to merge stuff. I'm guessing that I hit a hotkey of some sort that disabled merging of geometry and that restarting reset things to default, but I have no idea what I hit. I didn't find anything that made the same thing happen when trawling through the menu and the options. It'd be nice to know how to do this in case I do it again by accident.

You probably had "Snap to geometry" turned off. For some disabling it doesn't merge geometry. Without having a look at it I'd say that's a bug. You can merge geometry while having it disabled by holding Ctrl when releasing the RMB. You can stop geometry from being merged while snap to geometry is enabled by holding Ctrl when releasing the RMB, so the behavior seems to be inverted.

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

PostPosted: Sun Jun 16, 2019 5:46 am
by Enjay
boris wrote:You probably had "Snap to geometry" turned off.

Aha! That'll be it. I found snapping to geometry could get quite annoying if I zoomed out but still wanted to do fine work. I assume the tolerance for snapping is screen pixels rather than map units because I can move vertices, things (or whatever) very close to lines when zoomed in but if I zoom out, even with the same grid displayed, things start snapping to geometry long before what I would regard as close to the line. It took me ages to figure out what was going on because snap to geometry is not a feature that I am familiar with from DeePsea (it doesn't have it). It's a useful feature though, I just didn't realise what was happening and I couldn't figure out why the mouse seemed so inaccurate when zoomed out.

The other mouse button/Ctrl stuff is useful too, thanks.

As for opening Git issues, all done:

https://github.com/jewalky/GZDoom-Build ... issues/269
https://github.com/jewalky/GZDoom-Build ... issues/270
https://github.com/jewalky/GZDoom-Build ... issues/271

I've also linked the reports back to the relevant posts in this thread too (easier to format posts with pictures on the forum). I'll post issues on Github in future.

Thanks again.

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

PostPosted: Sun Jun 16, 2019 6:27 am
by boris
Ctrl also enabled/disable snap to grid temporarily (depending on your default setting) while you're holding it. Just remember to release it before releasing the RMB if you don't want to alter the geometry merging. [Edit] Holding Shift will invert snapping to grid.

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

PostPosted: Sun Jun 16, 2019 6:37 am
by Enjay
Also good to know. Thanks. :D