DarkRadiant 2.0.4 pre-release testing

[greebo]

Glad to hear that.

[grayman]

All caught up, then some.

 

No sign of layer corruption.

[greebo]

Assuming you folks keep using the latest pre-release build for your work, I'll wait for feedback concerning crashes or other map-breaking stuff for another week, before rushing out the 2.0.4 release. I'd like to wrap up that thing rather sooner than later.

[grayman]

I've been using it since release, with no new issues. Prolly a few hours a day, so I've put in a fair amount of time.

[Bikerdude]

Same here, the only issue I have been having but its minor is the draw delay when resizing brushes.

[greebo]

Same here, the only issue I have been having but its minor is the draw delay when resizing brushes.

I thought I've already fixed this? Does it still occur and if yes, when exactly? Only when resizing brushes, or during other actions too?

[Bikerdude]

You sorta did, but the issue is still there. And its other scenarios too - I will post a video this afternoon.

[greebo]

Is there a difference in behaviour to the 2.0.3 release? If the phenomenon was there in previously released versions, feel encouraged to report it, but I probably won't tackle it for this milestone.

[Bikerdude]

Can't remember, let me download a copy and compare the two versions...

[Spooks]

I've a pet peeve and I don't know if it's easy enough to fix. The _color argument should have 3 points of decimal precision instead of 2. When you pick a color, and the 0 to 255 values get turned into the 0 to 1 values the spawnarg works with, they'll have 2 points of decimal precision, which does not represent the full color gamut, and will possibly band the color you've chosen.

 

You can observe this in the entity pane. Get an entity with a color argument (e.g. a _color on a light or an ambient_light on a location settings ent), then click on that argument. You have the raw 0-1 value in the type field and the RGB value below. Manually increase the RGB value by typing in its box. Suppose you have Blue at 17, which corresponds to 0.07. When you change it to 18, the raw value should change to 0.071 - 0.074, but it stays at two points of precision.

[greebo]

That's an easy one. Add that to the tracker, please.

[Spooks]

Hey, greebo, I've submitted an old bug I actually had encountered way back when I started mapping in Oct last year, it's completely on me that I forgot to report it all this time 2.0.4 has been in beta-testing, sorry. I just found another one with rotation too and it's pretty severe, I'll put it on the tracker post-haste.

 

edit: here's another small bug, I copied a shader from a patch and pasted it on a brush and the scaling was 0.0019500000000000001. In 2.0.3 it used to be scale of 1, which still wasn't ideal but this is worse.

Edited May 12, 2016 by Spooks

[Bikerdude]

I thought I've already fixed this? Does it still occur and if yes, when exactly? Only when resizing brushes, or during other actions too?

You sorta did, but the issue is still there. And its other scenarios too - I will post a video this afternoon.

Is there a difference in behaviour to the 2.0.3 release? If the phenomenon was there in previously released versions, feel encouraged to report it, but I probably won't tackle it for this milestone.

Can't remember, let me download a copy and compare the two versions...

I haven't forgotten about this, I will do/check this tomoz.

 

In the meantime some feedback about pre7, the old not remembering where daughter window location is back. The layers windows keeps appearing centred instead of off to the right where I usually place it.

[Goldwell]

So I decided to make the jump from 1.8.1 to 2.04pre7 and i'm loving it so far.

 

However two things

 

1) I found a bug in the entity list (could be a bug at least), when you update the name of an entity it doesn't seem to update on the entity list and just stays the same as the name when the list was first loaded.

2) When selecting colors in 1.8.1 you could easily set the brightness of say the ambient light but here it seems you have to change 4 settings in the color picker window to get that. Say if you want ambient at 5% or 10% or 45% you could just change one number on the old one but on the new it's a bit more complicated with that. I get that you have the slider bar on the side but yeah just a little thing I noticed.

Edited May 16, 2016 by Goldwell

[Bikerdude]

1. Bug tracker please
2. I have already logged this ages ago, its cant easily be fixed, You will need to get used to the new values, which isnt that hard.

@GW and everyone in general who are kind enough to test DR for us -

 

- Can you guys please create bug trackers for these, Greebo has said he is far more likely to catch and pick these up in a timely fashion than if they are posted in here etc.

 

kind regards

 

b.

[Bikerdude]

I haven't forgotten about this, I will do/check this tomoz.

Updated the Tracker.

[Bikerdude]

Can't remember, let me download a copy and compare the two versions...

I still need to do this...

 

And added a tracker for the child windows issue thats happeing again, that was fixed in a previous version -

 

- http://bugs.thedarkmod.com/view.php?id=4319

[greebo]

A new build (pre8) is available for testing, with some more stability fixes. I also moved the OBJ exporter code to a Python script, so the corresponding "Export to OBJ" command can now be found in the Scripts menu.

[Bikerdude]

Downloading.

[Sotha]

I've moved from pre4 to pre8 now.

 

Didn't spot anything to complain about pre4.

 

This version of DR is gonna rock! Thanks greebo!

[hypov8]

i am noticing some laggy brush editing updates in 3d viewport. its not overly bad, but its only been introduced in recent builds

 

when in 3d free look mode. hitting esc will disable free mode, not deselecting the brush. only mouse 2 should toggle view?

 

also when in free look, if i change the speed with num_plus num_minus, it will toggle the free look mode. but not show mouse cursor.

can this be set to not change free look modes.

 

cheers

dave

Edited May 23, 2016 by hypov8

[greebo]

when in 3d free look mode. hitting esc will disable free mode, not deselecting the brush. only mouse 2 should toggle view?

 

also when in free look, if i change the speed with num_plus num_minus, it will toggle the free look mode. but not show mouse cursor.

can this be set to not change free look modes.

I'm not entirely sure I get it. You're saying that when in Freelook mode, you hit ESC and you expect DR to deselect the brush instead of stopping freelook, right?

 

The second thing, you're saying that Numpad+ and Numpad- ends freelook mode where it shouldn't?

[hypov8]

yeah that's correct. ESC is disabling free look. ESC never used to effect free look mode.

 

numpad+ and - in old versions did disable free look. but it would give you your mouse back.

now you have to click mouse2 in vewport twice to get mouse back.(bug)

i was also wondering if this can be changed so that pressing numpad +/- would keep you in free look. it should resolve the bug to

[Bikerdude]

@Greebo, another thing that pre7 and 8 is doing that you fixed in pre6 -

 

If you have the main window selected and hit S or R to open up the child windows, DR via windows is beeping at me - as in its complaining that I dont have the child window opened at the time when trying to perform a function - hence the beep.

 

- tracked

[Sotha]

Is it known that pre8 seems to forget shaders randomly, but rarely?

 

Behold:

 

Left picture: I started DR and looked at my WIP. Some textures are missing. Confused, I shut down DR.

Right picture: I restarted DR and now the textures were there.

 

Mysterious.

 

EDIT: I restarted DR five times now, and the textures were okay always.

EDIT2: I restarted the computer, ran DR again, and still the textures were okay. Reloading map did not reproduce the issue.

 

EDIT3: I cannot reproduce it anymore. Other testers, please be observant if you see it too.