DarkRadiant, Feature Proposal Thread

[nbohr1more]

I think that a "Feature Proposal" thread would be good to have around to let mappers express their DarkRadiant desires without making Bugtracker a mad-house of random requests.

 

(My apologies for the Normal Map sculpting feature request ...)

 

I'm not sure Greebo will read anything here but he might get a couple of chuckles at least...

[nbohr1more]

My first request:

 

 

I'm not sure if there is already an easy way to do this but it would be cool if there were a feature that let you position an envshot or camshot script event to more precisely collect cube map images for reflections (etc).

 

Thanks.

[Tels]

We already have a thread for this:

 

http://forums.thedarkmod.com/topic/3499-wishlist-for-darkradiant/

 

But I think it might not be public

[jaxa]

We already have a thread for this:

 

http://modetwo.net/d...or-darkradiant/

 

But I think it might not be public

 

Yup, it's not.

[STiFU]

Well, there is also a public thread collecting the most annoying dark radiant issues: Click! Sure, not really a feature request thread, but if you're missing a feature, it is an issue for you. Anyway, I doubt anyone will be pissed because of this thread, so go ahead.

[Xarg]

If this thread is gonna ahead, I'd like to ask for windows to stay the size you left them at, or be set to a strict initial size which can then be modified once opened...

 

When I create a speaker or entity, the window is very very very wide (like, 3800 pixels wide) and must be resized for sane usage.... When I create an entity the window is a square, but it's a very very large square that doesn't fit on the page, I have to resize it horizontally very slightly to make the top of the window (which begins offscreen) come down to the top of the screen, which then forces the bottom of the window offscreen, and this window cannot be resized vertically. In the create entity window, the preview box is xbawks hueg, (we're talking something like 800x600 huge), it's like this window is being scaled up way too large.

 

I think that'd be my current wishlist for DR features/improvements

[greebo]

Can you give me a screenshot of that? I thought I had set the initial size of those windows already to fit the screen, but maybe there is some regression in 1.5.0. You are using 1.5.0, aren't you?

[Xarg]

Pretty sure it's happened in every version of DR I've used, but ONLY in eyefinity. When I had 2 monitors, disabling eyefinity displaygroup made it behave normally. Screenshot incoming. Oh and yes, currently using 1.5.0

 

http://i643.photobucket.com/albums/uu159/xalgan/entitywindow1.jpg

http://i643.photobucket.com/albums/uu159/xalgan/entitywindow2.jpg

http://i643.photobucket.com/albums/uu159/xalgan/modelwindow.jpg

 

linked not image tagged to prevent computer destruction

Edited February 25, 2011 by Xarg

[stumpy]

maybe its taking the x value of the 2 combined monitor widths and deducting what the y value would be without checking, so its seeing 4 monitors in a 2 x 2 array.

[greebo]

This is the code:

 

// Set the default size of the window
const Glib::RefPtr<Gtk::Window>& mainWindow = GlobalMainFrame().getTopLevelWindow();
Gdk::Rectangle rect = gtkutil::MultiMonitor::getMonitorForWindow(mainWindow);
set_default_size(
static_cast<int>(rect.get_width() * 0.7f),
static_cast<int>(rect.get_height() * 0.6f)
);

_modelPreview->setSize(static_cast<int>(rect.get_width() * 0.3f));

 

Apparently eyefinity's feature is to emulate one large monitor, that's why DR is tricked into that huge size. The model preview is always square and there's the problem. Due to the large x/3 value of monitor 0's geometry the y value of the preview is set to the same value, but that value is far too large for the monitor, even though it's just one third of the width. I guess I could add an additonal check in there to prevent the monitor's height from being exceeded.

[Xarg]

That would be much appreciated. Allowing the entity window to be vertically resized (which would mean the preview box would need to be resizable) would be great too. IMO, best of all, would be to have it remember the dimensions you used it in last, meaning no more resizes .

 

Either way, whatever you can do will be great Greebo.

[greebo]

Tracked here: http://bugs.angua.at/view.php?id=2657

 

Which platform are you using (32 or 64 bit)? I can build a pre-release build to check whether the issue is solved, I don't have Eyefinity here.

[Sotha]

I have one feature proposal for DR.

 

Nowadays we do have the decal placement button. It works like this:

• the mapper chooses a face and clicks the decal button.
• A decal covering the whole face is generated and the mapper has to stretch it to correct dimensions

This is of course easier than creating the patch from start, but using the above method to place a lot of decals is maddeningly tedious.

 

I do not know if it is possible to do make this feature, but I'll try to propose it anyway.

There would be a "decal stamp" tool. The mapper activates the tool and writes in somewhere the decal dimensions, 16x16 units for example. Then the mapper would only need to click a face with the tool activated and a decal with chosen dimensions with texture fitted in it would appear in the spot clicked with the tool.

 

Like this:

 

The benefit of such a feature would be significant in my opinion. Instead of spending quite a lot of time adjusting the decals, the mapper could only set the decal dimensions and texture and then clickety click that decal in all the places required. Then the mapper just changes the texture&dimension and gives another go filling the map with other decal type. Scorch marks here, smut there, dirt here, cracks here, blood stains here, etc..

 

Thanks for considering...

[STiFU]

Hehe sounds a lot similar to what the Rage editor does. The idea sure is nice. I was also thinking that something similar could be done with griming up concave edges. I can't comment on how well this could be implemented though.

[New Horizon]

Hehe sounds a lot similar to what the Rage editor does. The idea sure is nice. I was also thinking that something similar could be done with griming up concave edges. I can't comment on how well this could be implemented though.

 

Yes, I was thinking the same thing. The rage decal stamp tool.

[Xarg]

Win7 Pro 64 bit, I'll be happy to help test it.

[ungoliant]

The benefit of such a feature would be significant in my opinion. Instead of spending quite a lot of time adjusting the decals, the mapper could only set the decal dimensions and texture and then clickety click that decal in all the places required. Then the mapper just changes the texture&dimension and gives another go filling the map with other decal type. Scorch marks here, smut there, dirt here, cracks here, blood stains here, etc..

Thanks for considering...

 

I have something to add to this request. On top of possibly creating mapper specified dimensions, I think that multiple selected adjacent faces should have an option to create one decal that covers the whole surface (if the resulting face is rectangular). This would make covering large areas with grime or dirt or ivy much simpler.

 

And I have my own request, this ones probably a lot simpler: I dont know if this is a bug, or if its intended this way, but please adjust the snd_accel and snd_decel spawnargs to work properly if accel_time and decel_time are set to 0. currently the specified sound will not trigger, and i'd like to have movers make start/stop sounds without requring an acceleration or deceleration (sometimes movers are synchronized and don't work well with accel/decels even at 0.1).

[ungoliant]

new request relating to sorting spawnargs in entity viewer. Once you sort spawnargs by property, or by value, it is difficult to revert back to default. On default settings, inherited values are all in grey and filtered to the bottom of the list, and manually entered values are at the top. I'd like an easy way to re-sort spawnargs to divide inherited/default values in this way, it would make things much easier

 

edit: also, accelTime, accelTo, decelTime, decelTo script events do not seem to work for func_rotating entities. I'm fairly sure that at the very least accelTo and decelTo should work for func_rotating because one of the parameters is 'speed', which is an angular velocity in degrees/s, which should definitely apply to a rotater. file to bugtracker? can anyone else confirm?

Edited March 7, 2011 by ungoliant