+1
Planned

Colorblind datapad option

Tyler Owen (Lead Developer) 1 year ago in Graphics/Visual Performance • updated 1 year ago 2

From Steam forums:


Hi, nice game I must say, I really enjoy the survival, but I have problem with datapad using. The cursor is almost invisible for me. Can You Devs please change cursor (active button) to more contrast colour to other buttons?
Thanks in advance :)

+1
Under review

Mac build 0.5 unplayable due to performance issues

Thrantor 2 years ago in Graphics/Visual Performance • updated by Tyler Owen (Lead Developer) 1 year ago 9

I just got the most recent build off of Humble Bundle after the announcement today and I was excited to play. However, after downloading it, unzipping it and starting it. At beautiful, 1440x900(i think) it was unplayable. maybe 3 frames a second. After turn quality down to simple, it sped up to around 5 frames a second. I've got a somewhat newish macbook pro(Four Core I7) with a built in Nvidia GT 650M. But... it's just chugging away?


Is there a configuration that I'm not doing correctly? I'm hoping to play this game.

0

Extra light source in "Habitat_A" interior

Mr. Fusion 2 weeks ago in Graphics/Visual Performance • updated 6 days ago 1

There is an extra / out of place light source right in front of the food rack in the "Habitat_A" interior, which adds a noticeable extra illumination to the food rack area, and it's reflected in the screen of the datapad when standing/moving in that area. By moving around with the datapad open it's possible to locate the exact spot in space where the light source is by watching it's reflection change on the screen and edges of the datapad.

I don't know if there might be a similar issue in the other two interiors as I haven't seen those yet.

0

Sunlight entering the airlock room on the exterior map

There are some narrow light transparent gaps / cracks at the edges of the airlock room walls on the exterior map, which, depending on current light contidions / sun position cause a shimmer on the edges of the wall detailing and other objects and/or casts spots of light on the ground at along the wall beyond which the sun is on the outside. The gaps themselves are not visible, only the light they let through interacts with the surfaces.


The airlock door model itself also has the same issue, it has a lot of "cracks" that are not visible, but letting light through which then illuminates the floor when the sun is towards the airlock end of the hab (such as the North-East hab in the afternoon).

This is not a new issue, at least the one with the airlock was there for a while now, but now that the airlock room is completely dark in an unpowered hab, it has become very visible.

0
Fixed

Bright white area on the escape pod hatch

Mr. Fusion 2 weeks ago in Graphics/Visual Performance • updated by Tyler Owen (Lead Developer) 4 days ago 2

During the escape pod landing, there is now a bright white area on the inside of the escape pod hatch, where previously there was a metallic surface as I recall. If this is intentional and meant to be an opaque window, then it should be similar in color to the hab windows from the inside during the day instead of being pure white.

0

Issues with the hab lighting in 0.64.3

Mr. Fusion 2 weeks ago in Graphics/Visual Performance • updated 6 days ago 2

I caught a few oddities / issues with the new hab lighting effects so far:

The outer sides of the outer door windows (both the one of the airlock and the one at the back end of the hab) are lit according to the outside light levels, not based on if the hab is powered or not. During the day they are lit even when the hab is not powered, during the night they are dark even when the hab is powered. The outer window on the inner airlock door seems to be matching the power state of the hab. Even if it's because it's not possible to set a different state for the outer and the inner side of the airlock door window, the non usable one at the back end could (should) behave like the outer window of the inner door since that's visible only from one side when looking at it from the outside so it doesn't need to be in two possibly conflicting state at the same time (dark when looking from the outside and lit when looking from the inside if the hab is unpowered).

When inside, the rest area and kitchen windows are very visibly reflecting an invisible light source (especially the kitchen one) somewhere in front of them. I'm guessing this light illuminates the areas near the windows, but since it's a "fake" light source that is not actually there, it should not be reflected by the window surface.

The North-East hab had some initialization / state change issues. When I turned electrical on, the side windows and the window of the inner airlock door remained dark. The airlock room also remained unlit even though the overhead lights were in their lit state visually, but there was no actual light. When I clicked on the inner door to enter, the lighting came on for a moment before the transition started and the screen went black. When I exited the hab after, all lighting got fixed: theere was actual lighting in the airlock room and the side windows were also lit. All lighting also responded to turning the power off and back on as they should at this time.

0
Not a bug

Held items don't receive sun shadows

Mr. Fusion 1 month ago in Graphics/Visual Performance • updated by Tyler Owen (Lead Developer) 3 weeks ago 1

When equipped outdoors, the datapad and the pickaxe doesn't receive sun shadows from environment objects such as the hab, the PRT or the hab systems (likely also not from larger rock formations), while they do receive a shadow from the otherwise invisible player model.

0
Under review

Pickaxe has a blue "highlight" outdoors

Mr. Fusion 1 month ago in Graphics/Visual Performance • updated by Tyler Owen (Lead Developer) 3 weeks ago 3

The orange parts of the pickaxe are receiving a faint dark blue light from somewhere while outdoors. It is only visible when the pickaxe is not in direct sunlight, eg. turning the player character in a direction where she casts a shadow on the pickaxe, and most noticeable along the edges, kind of like faint rim lighting or edge highlight. At night, it is barely visible but still there.


There is a similar highlight indoors, but there its white, which matches the white indoor lighting, so it looks correct there. So I'm guessing this is intentional, only the light source used outdoors for it is set incorrectly.

0

Visible daylight inside unpowered habitats

Mr. Fusion 2 months ago in Graphics/Visual Performance • updated 2 months ago 0

As I recall I made a similar suggestion some time ago in the other direction, but this might be a bit "easier" to implement.


One thing that makes the unpowered habs feel "wrong" to me is that there's always pitch black inside (not counting that low red light), even during the day. They have windows, even if relatively small ones, so the interior should receive at least a small amount of external light through them, that changes according to time of day and possibly storm density if any.


And the reason I said "easier" is that it might be possible to pull this off by a combination of ambient light and with the use of light sources similar to the one giving the faint red illumination, placed to where the two side windows and the airlock portholes are located. (For the best results, the windows themselves should also appear to be bright, which then essentially becomes the same problem as making them appear lit from the outside during the night when the hab is powered up.)

0
Planned

Floating PRT, take 2

Mr. Fusion 3 months ago in Graphics/Visual Performance • updated 1 month ago 8

The PRT appears to be still prone to not settling properly to the ground under certain circumstances, and it migth be either the result or the cause of a massive transient performance issue.


When I left a "cell" with a PRT in it on foot, then returned to that cell later, the PRT was in the air with the wheels being at about eye height, but overall aligned to the slope of the terrain under it. The odd thing is that it did not not occur on the initial discovery of the PRT(s), at that time it was properly on the ground. It also doesn't occur after a transition to hab interior then back out when the PRT is in the same cell (ok, not sure about if it's true for the entire cell, but it doesn't happen with the PRT right next to the hab I'm exiting from).


The other issue is that when entering (on foot, at this time I'm not sure if it happens when driving a PRT too, when you have two of them available) into a cell which has a PRT in it that's already been discovered (but not necessarily moved / used), the game goes through a really bad stall. First I get the usual short cell load period, which causes a slight stutter, then massive HDD usage starts, the game locks up, the system cursor appears over it, then the game minimizes itself and cannot be brought back up by clicking on its taskbar icon. During this time, there's constant HDD activity, but the memory/CPU use of the game process does not change from what it normally is. Then after about a minute the HDD activity suddenly stops and the game pops back up on its own with the pause menu open, and from there it runs with the expected performance again.


A factor in all this might be that in this game I have two PRTs, however, they are in different cells, so not loaded together.


Brief description of what happened and when:

  • Initial discovery of first PRT at a random location, no issues with cell load, PRT was on the ground.
  • Moving the PRT to home base, entering/exiting the hab multiple times but not leaving the cell, no issues (other than the loading indicator being stuck as reported in another topic).
  • Driving the PRT to another cell with the third hab and a second PRT in it, which is the initial discovery of both, no issues with cell load, second PRT was on the ground.
  • Driving first PRT back to home base (second stays where it was, never having been entered), entering/exiting the hab multiple times but not leaving the cell, no issues.
  • Exploration on foot to a third cell with no PRT in it (first PRT is at home base, second PRT is in the cel it was discovered), no issues.
  • Returning from third cell to the one where the home base and the first PRT is, game stall on cell load, PRT is in the air once reached.
  • Exploration on foot to the same third cell as before with no PRT in it (first PRT is at home base, second PRT is in the cel it was discovered), no issues. Continuing from that cell to the one where the second PRT is, game stall on loading the cell which has the second PRT, second PRT is in the air once reached.