Erm, slopes work in 3d mode. Completely, in fact.Leonard2 wrote:Quick question, are you going to have the slope mode a separate plug-in or are you going to include it with the 3D floor mode?
Currently this slope feature alone could be incredibly useful.
It's one plugin. That's because the logic was closely related to the 3D floor mode in the beginning.Leonard2 wrote:Quick question, are you going to have the slope mode a separate plug-in or are you going to include it with the 3D floor mode?
Currently this slope feature alone could be incredibly useful.
He's talking about the modes provided by this plugin, not about the 3D visual mode.TammySilverwolf wrote:Erm, slopes work in 3d mode. Completely, in fact.Leonard2 wrote:Quick question, are you going to have the slope mode a separate plug-in or are you going to include it with the 3D floor mode?
Currently this slope feature alone could be incredibly useful.
First it has to be in a 100% usable stateNash wrote:Can't wait for this to be merged into mainstream GZDB.
The big part of the slope mode that's missing is the undo/redo part. Plus lots of small things here and there that add up to a huge pile 
EXCELLENT STUFF! I NEED IT NOW!boris wrote:A little progress with slopes:
Spoiler:
I guess I'll go with a dummy sector the user has to configure, where all the required info is stored in custom UDMF fields. Not the nicest solution, but better than not being able to undo/redo.I'm not sure if the data you are referring to is for slopes but if it is the case then all you should really need to do is store a slope's coordinates and its assigned surfaces in a map's .dbs file.boris wrote:So after trying out some options it looks like somehow interacting with the existing undo/redo process doesn't seem to be viable
[edit] While writing this post I got the idea that using a "real" dummy sector (i.e. without lines, invisible to the user) might work. Gotta play around with that.
Not sure if that's what you mean, but there's already an intermediate layer. The slope vertices are not stored in the sector, but rather only a slope id (one for the floor and one for the ceiling). That way you can draw one slope and have it applied to multiple sectors. You can actually see that in thevery beginning of the last video.Leonard2 wrote:You know, after looking more at the latest video you posted (slopes demonstration) I had an idea:
Rather than having a slope assigned to a sector, why not have the opposite, where you assign any surface (ceiling/floor) from any sector to a slope (a simple 3D vector) this way you could easily duplicate a slope if you use regular geometry on your map and would allow to replace the need for a "copy floor/ceiling plane" thing.
I have to disagree that undo/redo is not important. Anything that can fuck up your map should be possible to undo. It's a moot point anyway, since I got undo/redo working they way I planned.Leonard2 wrote:I'm not sure if the data you are referring to is for slopes but if it is the case then all you should really need to do is store a slope's coordinates and its assigned surfaces in a map's .dbs file.
Also, not being able to use undo/redo isn't such a big deal (concerning slopes that is) since the input it needs isn't as big (just two coordinates and a surface).
That's pretty cool. When editing in Hexen format, nothing will change. As for UDMF, the multiple tags feature somewhat diminishes the use of the plugin, but I think it will still be handy. When MaxED adds support to GZDB I'll also add it to the plugin.Nash wrote:But it seems that multiple tags just got implemented... I wonder how will this affect the inner workings of this plugin?
Copy/paste works now. Code's in the repository, no compiled package, though. Might put one up this weekend.blackfish wrote:Would you think there's a way to copy slopes and assign them to new sectors?
