SE1.188 New welded blocks require painting a second time

CptSavarus shared this bug 22 months ago
Considered

Newly welded armour blocks appear with a "hard border" to those around them, even though they were placed pre-coloured in the same colour as the neighbouring blocks.

SE Version 1.188

Windows 7 x64 Professional

NVidia GT730 x4

Bug appears in SP / offline Survival mode. Not tested in MP or Creative mode.

Steps to reproduce: Place a new armour block frame (blocks depicted in screenshot are Light Armour). Weld the block to completion. Notice block is same colour as those around it but still has a "hard border" as if it were a different colour. Paint the block again in the same colour - hard border disappears.

Screenshot for reference....

https://steamcommunity.com/sharedfiles/filedetails/?id=1564711086

Comments (4)

photo
1

I think it's because color migrates between vector<3, double> and vector<3, float>, sometimes in RGB and other times HSV format instead of staying RGB vector<3, byte> or even better RGB uint only.


I think game shoud use only one format (preferably RGB uint) internally and use other formats only for preparation.


And I think the game should let us choose between RGB or HSV formats all the time, not forcing to use HSV in one place and RGB in other.


I hate the HSV format with passion.

photo
1

@Domingo... I have absolutely no idea what you just said but yes, the thing is definitely the wrong thing for the other thing and there should never be more than one thing thinging with the things unless we can choose which thing to thing the things with!

Hate the thing though, not the thing!

photo
1

No problem :-)


The issue is that there is loss of floating point precision when converting, saving and reloading. Something like 1 != 0.99999999 ...

Game then thinks two adjanced blocks have different colors (although they differ only in insignificant fraction of number) but the graphic engine converts them to same 32bit color.

photo
1

That makes slightly more sense! Hehe! Clearly you know a lot more about this stuff than me, so I'll defer to what you know.

I've noticed this problem has popped up many times over the last 5 years & is variously fixed / not fixed by nearly every update there's ever been.

Some updates have caused other wierdness with the colour pallet - sometimes the changes in value are extremely noticeable.

I'd always assumed it was the designers playing with values to find the ones they liked best, though given what you're saying it seems the wierdness may be partly caused by how the game handles colours.

Would be nice to have the issue resolved once & for all though, so if there's a way to do that - like you say by sticking to a single format or something, then yes, let's please do that. At least then we'd know our colours could be trusted to behave themselves from one save/load to the next.

photo
photo
2

Hello, Engineer!


Thank you for your feedback! Your topic has been added between considered issues.

Please keep voting for the issue as it will help us to identify the most serious bugs.

We really appreciate your patience.

Kind Regards

Keen Software House: QA Department

photo
1

Thanks for the response Keen. Please let us know if more info is needed to help you fix.

photo
photo
2

having the same problem, new blocks kinda maintains the colors but i noticed that the value slider changed slightly from the original picked color, say, it was 5.2%, the newly built blocks when CTRL + P holds a value of exact 5.0%


this could be culprit, and yes, they need to be painted over or armor edges are created.

photo
1

I'm getting exactly the same issue, the game rounds whatever paint values you have selected to the nearest .5 when you place a block. It's odd that so few people seem to be encountering this problem. Are you using Windows 7? Because both me and OP are, so I'm thinking the bug might only occur on just this OS.

photo
1

@Ak Jumper.... I honestly don't think it's an O/S issue.

Paint values & behaviour have been changing in strange & subtle ways with almost every update since SE first released in early alpha; and the nature of the changes / bugs is different from one update to the next. With some updates you may not see anything wrong at all, then with the next update the whole pallet might change or you may get weird issues like this cropping up.

It's sometimes just Keen playing with values to find the ones that look the best with their graphical improvements. Other times (like in this instance) it's obviously unintentional / undesirable and so is effectively what we would call a bug.

Graphical bugs tend to affect everyone differently, since everyone has different hardware & drivers, so quite often with stuff like this it'll only be a handful of people with specific hardware that report them.

Also have to account for the fact that since issues like this one have always occurred from time to time, many long-standing players have learned to simply not see them because they know the issue is known and that a fix will be coming... that and probably half of people will experience a bug but never report it unless they see someone else has.

So chances are if you're still seeing this problem then many others will also be seeing it & just not saying anything.


I haven't personally seen this bug since shortly after Keen posted their response here. Certainly not since the Survival update, so for me at least it's been resolved for now.

No doubt it'll continue to come & go with future updates & that's fine. Ours is just to report it when we see it.

photo