Discussion in 'Change Log' started by Drui, Mar 8, 2018.
Who cares who's first, second third or forth? the first page of post is garbage
You know what? I'm not entirely sure that's a bug. I think it's merely a consequence of the way things are done in the game. I have experienced it and it's not hard to work around.
Well, they apparently also care about the cockpit interior appearing out of order in the build process, something I'm sure a lot of survival players would appreciate. They also seem to want spectator view to work properly. The size of the boulder dummies when hand drilling was definitely an issue.
This is how a game like this gets finished. Get the little stuff out when you can cause it adds up. Don't release the big stuff until there is a high degree of confidence it will work.
The heady days of a new block/feature every week are over. Now we get bug fixes, which is what everyone screamed they wanted when we were getting new blocks and features every week. Might not seem exciting, but since my game crashed less often in 1.186.5 than it did in 1.186.4 I'm going to conclude keeping the boots from lighting up when you exit a cryopod was not a high priority but a relatively easy fix they were glad to take care of.
I think many people thought those things were too aggressive and, in the case of the wolves, they are perhaps trying to get them to behave more like actual wolves.
That eat metal.
One step at a time
Aside from this, I'm coming from the last update's comments... let's not talk about those.
But something caught my attention about the update threads lately, which I usually browse through...
A need for a roadmap.
And an upvote from Whiplash141 in the last thread made me realize that mayyybe some of the more well-known names in the community might agree with me, so I created this thread to try and get the message through.
Fair wind... ahem, err... Best of luck to all.
you cant stop fun
OMG MY SUBMITTED BUG GOT FIXED!!!!! Large Boulders were a deal breaker for me.
This probably has a more complex underlying reason. No one at the company thought: "yeah, let's *just* give that guy backproblems".
Always bringing out good updates with the entire community awaiting the next great major update.
don't understand why it was increased in the first place.
but you know...ok thanks for fixing that by changing a number.
LOL no there is new code that looks like it should work in MyRemoteControl that checks the distance to the ground when you are in a natural gravity field, and scales the autopilot max speed from 15% below 50 m to 100% at 150 m. The function that checks the distance to the ground is still this:
internal double EstimateDistanceToGround(Vector3D worldPoint)
It will always assume that the ship is at zero distance and scale the console's autopilot max speed (default 100 m/s) down to 15%.
There is a working height detection in MyRemoteControl.PlanetCoordInformation.Calculate(Vector3D worldPoint),
or in Sandbox.ModAPI.Ingame.IMyShipController.TryGetPlanetElevation(),
or in MyGuiScreenHudSpace.DrawArtificialHorizonAndAltitude().
Even if they fix the inexplicably broken height check, it would still scale all autopilot speeds down at low altitude. I thought people would just use the autopilot's precision mode for landing.
internal double EstimateDistanceToGround(Vector3D worldPoint)
The hand welder was fixed in update 1.186.3. If you're having further issues, make sure your game actually updated first, and if it is up to date then file a bug report if you haven't.
I mean, I'm not one to try to stomp on fun, but... you can...
That's not a bug - that's a feature ,
Seriously, Keen, when are you going to address the real problems ?
* remote control,
* character tilting,
* multiplayer desyncs
* wheels exploding (that's my personal reason for stopping to play)
We demand an answer !
Yeah, we know about it and I have already been solving it some time ago. It is probably scheduled for some later update.
Even though it might seem as easy fix there are different problems. What else does the change influence? As of new voxels, this exact function got reduced to this as functions used inside are no longer supported by new voxels. So it had to be done in bit different way. It requires testing, if the performance hit will be not bigger than it was (there is lot of randomized ground checking). It needs testing that everything behaves exactly as it did before so what people used before new voxels will still work. It needs testing to find out that campaign drones and custom pirate drones that have been using it still works correctly and such things. (Lot of different cases and bit of randomization also makes each test results bit different.)
It also could be completely removed (the speed limitation) but flying in 5 m above ground in 100m/s would be a bit suicidal and again, all the things mentioned above would still have to be tested.
There is many things that needs to be checked so when we release it, you won't start complaining that we can't fix even simple thing and that we broke it again. QA guys on the other hand have ----load of work to do themselves (It is hard to not know if you sit 2 meters from them) and I can imagine, that things they are testing (like things for major) have probably bigger priority for them as these things must be polished as much as possible and any problem needs to be known as soon as possible.
PS Yeah, the speed multiplier scaled with height from ground with 15 m/s up to 50m above ground and lineary rising to 100 m/s at 150m above ground.
PPS Man, I am not completely sure about it, but I think that you shouldn't be posting SE code into public threads.
Well said Petr.
Why so many people somehow think that all of SE (and ME) is easy and quick to create, is just beyond me.
I personally think the multiplier should be removed completely, so that remote controls work predictably. How terrible would it be if you went to all the trouble of designing a safe, low-altitude cargo transport, only to find it's hard-coded to be stuck at 15m/s? I know it was a bit of a bummer to have my ship go out of antenna range towards my other base, only for it to run out of power before it arrived since it was only going at 15m/s.
Precision Mode exists, and I always make sure it's turned on before my vehicles dock. Collision Avoidance exists, and if applicable, I turn it on for long journeys.
If you don't do that and your thing crashes, big deal, it's your own fault for not being careful. Now you know for the future, and you can work on it. An arbitrary speed-cutter doesn't really seem to make sense.
Plus, you can just set the speed limit yourself using the handy slider you guys provided; I'm pretty sure that can be accessed with both Programmable Block and Timer.
If it really needs to be there, it should be a checkbox or something, since I prefer to fine-tune my drones, and having this be absolutely out of my control is just frustrating.
The Github still exists, and the code is still mostly applicable.
The only difference there is that it's been locked to always report zero, I guess as a stopgap while you're still adapting stuff to the new voxel system.
Keen knows how to stop it...
By that logic, there are no such things as bugs. If something behaves in a way other than what was intended, then it's a bug.
I never said nor implied that anyone at Keen wants this bug to exist. I only said that it's existed for at least 6 weeks, that it's frustrating a lot of people, and I suspect (though can't know without seeing the current source code) that it wouldn't take a huge amount of effort to fix.
If players want to risk that, I say let them lol. Let us be free to be dangerous
I mean in the Discord we are permitted and sometimes encouraged to use decompilers (like ILSpy) to view the code since the GitHub is terribly out of date. It would be odd if we could post the code there but not here, especially if that code helps to reveal some strange buggy behavior
The boot emissivity is the new dirty windows for Marek, no longer does the landing gear go bang (the wheel do he, he) but only the boots should now be focused on, as for the rest of the game, WHO CARES!!!!
That's good news then, Maybe you can rewrite that part and send it to Keen?
I'm sure they would appreciate it very much, if it isn't already rewritten and being cued for an update release later on.
Sure, just point me to the source code for 1.186.x
Man, i read your text completely wrong.
In a haste i read something along the likes of, that you could see that it wouldn't take a huge amount of effort to fix by looking at the source code
But if you can't, then i'm not sure why you could estimate the level of effort at all.
You can't know what's beneath this.
They still have not fixed the problem that the server does not use all the processing power of the server. Using only a kernel making the server slow.
The lighting is still not fixed. Your HDR is not properly implemented. The highs (whites) are too strong and their specular is too wide, making large white spaces show up with even weak light sources (like the engineer's flashlight) when there is no ambient light.
The game is not really playable in space at the moment, or anywhere where there is very low ambient light (like the moon), due to the stark, sheer whiteouts that appear on blocks when running around with the flashlight. This isn't a big deal on planets with lots of ambient light, but in some scenarios - Easy Start Moon and Lone Survivor types, the game is not playable with current lighting.
This is what it looks like in space. Lone Survivor:
And with the sun gone down in Easy Start Moon (low ambient):
I could go on... and on... :/
I don't understand. The game was super fine before you decided to crank up the graphics into this oily, specular mess. It was GORGEOUS.
If it ain't broke don't fix it.
But now that you broke it I hope you guys fix it soon, before you roll out another major update and forget all about the problems with the current update you just rolled out.
I have been complaining about weird and broken HDR for a while now but nothing changed. I doubt they will fix this anytime soon.
I loved the looks even before the last major graphics update wshich introduced horrible reflections for glass. It looks like a weird screenshot is made for what should appear in the reflection and that screenshot gets overlayed by new screenshots and only moved around X and Y axis as you move around it.
I recently came back to SE (2500+ hrs played) and started a survivor solar system game, set it to no wolves and when I landed on the planet there were wolves with this non aggressive mode, perhaps I will try turning the wolves on in the game settings and see if I get the aggressive version.
You realize that's pretty much how reflections have always worked in this game, right? It renders a cubemap of your surroundings every so often and that is shown with reflective surfaces. Really, how do you expect them to do it? Calculate the path and bounces of light in real-time?
I don't know what you're talking about with the X and Y thing; of course they move on a two-dimensional plane if you're walking, that's kinda how walking works.
They recently increased the speed that the reflections are calculated, though, so the process is a bit more visible. They seem to change their minds every now and then for whether the reflections should update slower with a longer view distance, or faster with a shorter one.
I think they've struck a pretty good balance right now.
So is they any chance of a temp fix untill major update if thats when the fix is comming so my encounter Mod can rain down terror on humans players once again please lololo
Why? The space suit is useful for the two genders. Make new models for being correct politically, seems me a waste of time. That is not important. The game mechanics are importants.
Keen has really pushed the "immersion" idea lately. " From Marek's latest blog: http://blog.marekrosa.org/2018/02/overhaul-visuals-audio-wheels.html
Better immersion => Happier Engineers
If you identify as female, immersion is insta-killed when you raise your visor. "Politically correct" has little to do with it (a tired old refrain anyway, IMHO). It's about choice and providing an avatar that is more interesting and, perhaps, more reflective of some members of the audience.
Tell me, please, your definition of "politically correct" in this context. It's also important to note that Keen's artistic team works on the visual aspects independently of the team working on, as you put it, game mechanics.
Separate names with a comma.