Surface inspector not allowing values

[Deep]

Hello everyone. In the newest version ( 2.13.0 64 win 10) surface inspector keeps defaulting back to 1 x 1 in the "Fit texture" fields. While working with some strangely small geometry (brush faces at a grid level of .25) I needed to adjust the texture scale to be .02 x .02 in the "fit texture" fields. I input .02 in the first field, clicking into the next field to input the same value... the first value switches to "1".

So, am I missing a setting to allow this or is this version not allowing me to set values smaller than 1?

[greebo]

Seems you are talking about this one: https://bugs.thedarkmod.com/view.php?id=5702
It's already fixed in source.

[Deep]

Thanx for the reply...

Sorry I guess I didn't post in the right area. In source you say... is that a patch? My version is the latest  - 2.13.0

[thebigh]

I ran into this too. I've been working around it by fitting to 1x1, seeing what the actual texture scalings become, and then manually multiplying by whatever factor I need.

[greebo]

1 hour ago, Deep said:

Sorry I guess I didn't post in the right area. In source you say... is that a patch? My version is the latest  - 2.13.0

It's not the wrong area, this forum is fine for this, I'd say.

In source means in the DR source code, it's been committed to Git. The next release will have the fix included, and if this is too long too wait, there are snapshot builds available on Github too.

[Deep]

so this is fixed in the snapshot build? 

-

Quote

I ran into this too. I've been working around it by fitting to 1x1, seeing what the actual texture scalings become, and then manually multiplying by whatever factor I need.

That"s a good work around. My issue is problematic because of small scale faces. All detail is lost at 1x1 scale so I need to pick a portion of a texture and basically use it at .02 x .02 or .008 to get the detail (roughness, or bump)

picture 1024 x1024 steel plate reduced to cover a nail head sized face.  I had no problem with this scaling in previous v.

- But thanx Greebo for filling your brain with my problems! very appreciative. - forgot to mention... the zoom in on .125 grid size absolutely rocks! Thank you

Edited September 21, 2021 by Deep

[greebo]

6 hours ago, Deep said:

so this is fixed in the snapshot build? 

Yes. One has to be logged into Github to see the download links, but there's a portable package for each pushed set of changes. E.g. https://github.com/codereader/DarkRadiant/actions/runs/1218642341

[Deep]

well, thank you but I'll wait for the newest I think because that fine detail was about .001% of my workflow. I might add that as well as the 1x1 default problem, there is also a scale issue on the horizontal/vertical arrows where 1 click sometimes spans out the texture beyond recognition - hoping this was addressed as well ( sounds like a related issue actually) Thanks again for the help greebo

[datiswous]

On 9/21/2021 at 8:00 PM, greebo said:

Yes. One has to be logged into Github to see the download links, but there's a portable package for each pushed set of changes.

So if I want to test a specific feature from 2.14 it's possible to make a (stable) 2.13 build from source with a small chunk of code from 2.14 through a portable package? Doing this instead of using the full dev branch as source, or is this the wrong idea? Personally I'm interested in testing the fix to issue 5711 .

[greebo]

It's more like an all-or-nothing thing, you can't really cherry-pick a fix to a specific issue*. By checking out the source code that includes the fix to #5711, you'll also get all the fixes and changes that have been made in between the release 2.13.0 and the fix to #5711.

I'd recommend taking a snapshot build that has been compiled from the recent "master", this should be good enough for your testing purposes. While there are no guarantees made, the code in the master branch is usually production-ready and can be used for actual mapping work. If I'm working on something that completely breaks features, I'll do that in a feature/dev branch, like the "textool" branch.

*) Coders will correctly point out that this is an incorrect statement, one can probably pick and stitch together certain code changes to get something like "2.13.0 + this fix", but this is more work than it's worth. Just use the latest master.

[datiswous]

On 9/24/2021 at 12:24 PM, greebo said:

I'd recommend taking a snapshot build that has been compiled from the recent "master", this should be good enough for your testing purposes. While there are no guarantees made, the code in the master branch is usually production-ready and can be used for actual mapping work. If I'm working on something that completely breaks features, I'll do that in a feature/dev branch, like the "textool" branch.

So normally I use the compilation guide to build from source, does that install DR stable, or production? If I want a snapshot of the latest source, where do I download that?

Btw. I use Linux (Manjaro - Arch based distro)

[greebo]

The compilation guide refers to the master branch, since the command

git clone git://github.com/codereader/DarkRadiant.git

will check out master.

I wasn't aware that you're on Linux, because the snapshot builds above won't apply to you, it's for Windows x64 only. You'll have to build from source to test anything in between releases.

[datiswous]

@greebo

So basically if I want to install a new version of DR and build from source is my only option I always install the development (production) version anyway? Sorry, I just want to be sure I understand this correctly.

Edited September 26, 2021 by datiswous

[greebo]

Simply put, yes. The "master" branch is moving forward as development progresses.

You could checkout a specific revision from Git history and compile that, but I don't see much benefit in doing so for regular users.

Apart from building directly from source, you can also use the .deb packages uploaded to @OrbWeaver's private repository, assuming that it is still hosting a recent package.