What new features would you like for the next NewDark update (Suggestions) - by Cardia
ZylonBane on 13/8/2018 at 19:37
Quote Posted by LarryG
This issues with non-primitives like a Gothic arch are many, but first and foremost is that the directed distance calculations can be quite complex. Does object A hit said Gothic arch or no? The reason those 5 or 6 primitives are the standard set is simply because the math calculations are simple, known, and fast.
If you're talking about in-game, then no, there are no BSP primitives in-game. Portalizing converts all brushes into the worldrep, which is raw polygon geometry. A stripped MIS file contains only this geometry, discarding the terrain brushes.
Quote Posted by nicked
Like a prefab? That's basically what a multibrush is, but like others have said, it would be good if they were more powerful and less easily broken.
NewDark actually does enhance multibrushes quite a bit. The extended UV mapping mode allows multibrushes to retain texture orientation no matter how/where they're placed, and they can now retain the correct textures when loaded into a different mission.
Yandros on 14/8/2018 at 03:59
Quote Posted by ZylonBane
NewDark actually does enhance multibrushes quite a bit. The extended UV mapping mode allows multibrushes to retain texture orientation no matter how/where they're placed, and they can now retain the correct textures when loaded into a different mission.
This. Multibrushes were not particularly useful with OldDark, but now they are a more powerful building tool that makes prefab type stuff actually doable.
SlyFoxx on 16/8/2018 at 00:11
Just a bit of useless Sly/DromEd trivia...I have never used a multi-brush.
DrK on 17/8/2018 at 12:38
remove poly_edge error
I'd love to have a way to detect the faulty brush or area in the monolog window, through coordinates or maybe a highlight feature. I've had this weird error for a while and it seems it was a rather simple brush which was its source, but I'm not even sure I fixed it for now.
vfig on 18/8/2018 at 07:09
There are two enhancements to the texturing workflow that would help me a lot. First the problem:
Normally in the 3d view, left-clicking selects a brush and a particular face of it. I use this a lot in order to edit texture alignment, and often to set textures by number. I also use this to select a brush without especially caring which particular face is selected. My problem is, when the texture palette is open, left-clicking no longer selects a brush or a face—instead it applies a texture to the face that is clicked. This means I cannot easily select faces to edit their alignment while the texture palette is open. So I end up opening the palette, picking a texture, applying it, closing the palette, select face and align, open the palette again for the next face... I would like to be able to continue to select brushes and faces in the 3d view while the texture palette is open, without completely removing the ability to assign textures easily in the 3d view.
I would very much like the following options, or something to similar effect:
1. An option to change the texture palette's "apply texture" action from a bare left-click to alt+left-click, so that a bare left click continues to simply select brush faces even when the texture palette is open.*
2. A new shortcut, ctrl+left-click, when the texture palette is open, to apply the selected texture to the clicked brush's default texture instead of the clicked face.
(*Digging through gedit.c, I just discovered I can set "txtrpal_select 1" in dromed.cfg so that left-click applies the texture _and_ selects the face. For me this is better than the default, but still makes "picking" the texture off another face impossible while the texture palette is open.)
vfig on 23/5/2020 at 17:50
It would be insanely great if we could use Squirrel (or something) to script Dromed. Even fairly limited scriptability would be transformative and open up vast new capabilities and ease of mapping.
The dromed command scripts have some uses, but they can't really be used to manipulate brush/object positions and properties in a programmatic way.
Azaran on 23/5/2020 at 18:36
I'm probably in the minority, but I'd love better software mode emulation (currently replicated by changing "tex_filter_mode" to 0 in camext.cfg). The already fixed the lighting issues for it on one of the recent updates (for which I'm very thankful), but it would be nice to have a perfect replica.
I believe the main difference is that Newdark uses 32 bit colour, while 8 bit/256 colours were used in Old Dark - as a result, the latter has a grittier effect that I love. So maybe adding a 256 colour option?
NewDark
Inline Image:
https://i.postimg.cc/MH5k03GP/dump219.pngOld software mode:
Inline Image:
https://i.imgur.com/o0oaALC.png
PinkDot on 23/5/2020 at 20:15
Quote Posted by vfig
It would be insanely great if we could use Squirrel (or something) to script Dromed. Even fairly limited scriptability would be transformative and open up vast new capabilities and ease of mapping.
The dromed command scripts have some uses, but they can't really be used to manipulate brush/object positions and properties in a programmatic way.
I second that. Python would be even better!
gamophyte on 23/5/2020 at 20:59
Quote Posted by vfig
It would be insanely great if we could use Squirrel (or something) to script Dromed. Even fairly limited scriptability would be transformative and open up vast new capabilities and ease of mapping.
The dromed command scripts have some uses, but they can't really be used to manipulate brush/object positions and properties in a programmatic way.
Since 1.25
(
https://www.ttlg.com/forums/showthread.php?t=146448&p=2352241&viewfull=1#post2352241)
PinkDot on 23/5/2020 at 21:10
The request is about scripting inside the Dromed itself - not the scripts that run in the game engine. So, this would allow writing custom tools, that would automate all kind of tasks inside Dromed.