This is obviously a false positive (a quick search and the same scanner detected a similar issue in some version of VLC). Virus scanners use heuristics that often pick up on something in legit programs. Not worth much effort to avoid IMO unless there is something obvious that it could be noticing that wouldn't be too hard to work around.

0.431.8 on mac broke lighting and textures. all ringroids are just gray blobs, crew has no faces etc.

looks normal again, thanks.

Has anyone noticed the weird cloning effects in the Equipment animations?

If I select an Autopilot and click on the "User Manual" tab, the animation will start to distort and it shows clones of itself. Is this normal?

I'm running dev version 0.494.11 (64-bit) on Windows 10.

Bug Report: Visited a previously discovered Moonlet. Pilot gives "lead" to nearby "Iceroid". Navigate there using 'J'. ... I arrive at the same Moonlet.
Expected: Only currently not tracked targets should qualify.
Bonus Points: Leave possible for inexperienced Pilot, but should say something about not recognising the two objects were one.

Change request: Crew members should ask for raises on station, not during dive.

Change request: Geologist skill "Mineral Discovery Range" should increase frequency of samples together with range, such that time-to-identified for individual samples remains roughly constant.
Currently individual samples will remain unidentified for longer and longer times the higher this skill, providing a Perverse Incentive to keep it minimal.

Feature Request: Show hired crew skill level on mouse over or halve width of their stats table to add them there.
(Candidates display skills relative to active crew, but there is no way to e.g. check what changed on Experience gain or to check which level of skill felt "sufficient" as intermediate goal in new games.)

Feature Request: Provide the same delta stats in the Dealer screen when selecting a new ship, as happens in the Equipment screen when selecting new modules.

Feature Request: Provide list of all existing ships in tab of Dealer screen, allow setting alert for specific ship type, if available when entering station. (Or alternatively allow outright ordering of ships, to arrive at unspecified later date and in unspecified condition.)

Feature Request: Button to "hail ship"; if later overhaul is planned as a stopgap measure: Just force trigger said ship's conversation as if player had moved in range. ... Sometimes we have to get very close for ships to hail us, sometimes they do so from outside the visible screen, sometimes ships just do not talk - it would be much more convenient to be able to force the interaction, if present.
(Later, having dedicated text for "we hail them" vs. "they hail us" would be nice, but only nice to have.)

Feature Request: Function to select interaction target without priming auto pilot. For AR-1500 Manipulator, aforementioned "hail ship" feature, Microseismic Drone output, etc.
Currently target of those interactions (insofar present) cannot meaningfully be selected, rendering them very cumbersome. Manipulator grabbing low-yield rocks instead of nearby high-yield ones is very irritating, before much more expensive MPU/MSU can be procured.

Feature Request: When Pilot scavenges an abandoned ship, please make them...
- check whether main engine points at player ship and turn away first, lest they burn their employer rather literally
- not move at all, while still attached to an allied AR-1500 Manipulator - wait to be detached

... Current gameplay nice, stability much appreciated. FYI: Had alien(?) attack on story mission finding and claiming abandoned ship of missing geologist - crew did not react at all... unsure whether WaD/unfinished/broken, but felt odd.

Bug Report: PoIs teleport.

Discovered a previously discovered Habitat in an entirely different location even though my Astrogator was still tracking it at the old location. After the position update, the Habitat was now in the new position, even though PoIs do not move when visited only via fast travel.

Expected: PoI positions should be self-consistent: Change on all maps the same way or change on no map.

Bug Report: Different Moonlets are tracked as the same PoI. (Possibly related to my Bug Report in the previous post.)

Had Astrogator track a Moonlet with Uranium Caves inside. Discovered Moonlet containing Space Bar. "Updated location". PoI Uranium Caves was still in its old place, but PoI Moonlet now only overlapped with new PoI Space Bar.

Expected: Every Moonlet should be its own PoI.
Bonus Points: When discovering a PoI inside a Moonlet, replace the Moonlet PoI with this one outright, rather than adding it on top.

Apologies, I might have been unclear in my description: That Habitats move is perfectly fine and even rather cool. The bug is twofold:
- They never actually move, that is: While tracked by the Astrogator, their position is constant relative to the rings.
- Yet, even though they never move, they just appear from nothing in a new position when exploring. If you can turn away fast enough (before the PoI updates), you can fly right back to their tracked position - and there they will be!

I find that this eventually discourages exploration a lot: For every habitat found close to a beneficial position - say, right next to a mass concentration - the risk increases that we might accidentally relocate said habitat into the middle of nowhere. There is a lot more nowhere than everything else, after all.

As soon as we'd actually track an actual course of habitats, the disincentive disappears: Today the habitat might be in a sweet spot, but by the time we return from our current dive, it will have moved considerably and by the next dive it will almost certainly be in an uninteresting position - until it finally approaches the next interesting position and thereby informs the next dive destination.

With less capable Astrogators (or with slow enough travelling speed, in general) this might also motivate the player for repeat visits (to refresh tracking) before the habitat reaches an interesting place, because it moves towards one.

(Side note: For the habitats in particular, it sure seems odd that we cannot just request a flight plan - maybe for a fee - and get a fixed time of not tracking but "knowing where they are supposed to be"... could then be a nice event handle, when they are not, too.)

...

Bug Report: Beryllium ore - and only Beryllium ore is imparted with a large impulse on spawning, if anything but engine exhaust is used to make it spawn. This impulse is often too large for the ore to be caught even by the 2x drones of Eagle Prospectors.

Several issues here:
- Only Beryllium does this, even if the ore is 10x or even 100x as much water than metal.
- Only exhaust as the extraction method does not (always) do this.
- Other ores already behave quite consistently by the rule "energy imparted ~ impulse of ore spawned", so a better functionality is already in the game.
- Technology meant to counter this issue (and otherwise quite useless / merely mildly convenient) does not manage to actually manage to counter it.

In combination, this makes for a very frustrating experience. I myself have begun to mostly ignore Beryllium ore given that it behaves as it does "just because". Picking up ubiquitous tungsten is much less of a hassle and in terms of time-to-profit, risk-of-accident often just the better money maker.

Feature Request: There are probably means to make Beryllium harder to mine than other materials, which would be much less arbitrary:
- being very brittle, it could be especially reactive to mass accelerators (starter gear)
- being diamagnetic, it could be especially reactive to microwaves (cheap upgrade, very low mass and power requirements, as point-defense the most convenient mining weapon)
- having a high heat capacity, it could be especially unreactive to lasers (heavy, expensive, power hungry mid-to-end game equipment)
(Note: I have not checked how these attributes measure up relative to those of the other metals in the game. Even if Beryllium would end up being one of the easier mined minerals, though, I personally would consider it worthwhile to have such different reactions to different mining techniques, as it will encourage specialisation. For balancing one may always adjust the relative abundance, given that abundance is this game's point-of-diversion from reality anyway.)

Well, if you say so?

Beryllium is about 1/6 of Vanadium in density. Thence, I'd expect an ore piece of 1'000 kg water and 18 kg of Beryllium, to behave:
- identical to a piece of 1'000 kg water and 18 kg Vanadium, as far as mass is concerned (because mass is identical)
- identical to a piece of 1'000 kg water and 3 kg Vanadium, as far as volume is concerned (but all ores currently have one constant volume, at least graphically)
- very similar to a piece of 1'000 kg water and <20 kg of any other ore, in any way (because the water content dominates by two orders of magnitude)
- not identical to a piece of 100 kg water and 18 kg Beryllium, neither by mass nor by volume

None of these expectations seems to hold in the game, though. ... And yes, microwaving is great for all the other metals, but does not seem to work too well with Beryllium - that seems to be the only ore which reacts to microwaves exactly as to a tuned-to-minimum mass driver, whereas for all other ores comfort of the microwave very visibly beats the mass driver.

... Random armchair software engineer thoughts:
- Could this be Catastrophic Cancellation in the formula, because Beryllium is the least dense metal in the game?
- Could ore water mass be ignored in the formula?
- Could Beryllium have been the first metal to be included and still use some old placeholder code instead of the proper formula? Or maybe a later inclusion but hanging on a prototype formula that was not adapted but neither discarded?
(Sorry, neither of those probably helps. I just held off reporting this for several days, to rule out bias from the ore's high value, so I am now pretty convinced it is somehow broken.)

addendum: Figured I might be using the microwave wrong: I had it tuned to max. beam width, max. water resonance - almost all the non-Beryllium ore spawns are slow enough with that setting.
Now I gave it a try with the rest of the permutations:
- minimal water resonance, maximal output: 1 slow Beryllium ore, ~12 fast ones
- maximal resonance, minimal output: 1 slow Beryllium ore, ~12 fast ones
- minimal resonance, minimal output: I was not able to break even the smallest rock - 0 spawns

... So, well... yeah. It just seems to behave that way: Beryllium is "always" fast. Or more precisely: Is always imparted with big impulse. Its range of speeds does not look much wider or narrower than that of other ores, it is just consistently shifted "upwards". Unless extracted with engines - then it behaves exactly like everything else.