2026 Bugs list POR:

[iuli24]

As "promised" I made a bug list here with stuff I found most important for now. (it is by far not complete and does not cover every bug present in game for now)

I am aware that some of what I paste down below either was already fixed / is in the process of being fixed / may be fixed in the future. I am posting the fixed ones too for proof or record as requested by @StickManTwit / devs (I am in a sort of holiday so I didn't have time to post xd)

For the stuff that was already fixed. I just want to say @Highway @Narokath @Alewx etc (idk if I tagged all of you or not)... no idea what tools you use.. llms.. whatever (not that I care thaat much XD) but keep doing what you do because you guys are cooking recently. Logged in today to find the stuttering from drone switching not only fixed but completely gone. I have noticed this on other patches recently and it seems that you do manage to fix them properly and forever. Absolutely fantastic . I haven't had the time yet to check the white cooldown fix but considering the recent track record its likely gone as well.

Bugs that are already fixed but I didn't post fast enough XD:
(DISCLAIMER: The info I give on potential solutions / causes is from before the patch/es were live. The info in this section is what I considered might be happening at the time and might no longer be relevant / might be wrong!)

1. White cooldowns / items that are simultaneously active and in cd at the same time (thus.. white) (easy to reproduce)

Steps to reproduce: Use speed actuator until ~50-80% of its runtime (this item works best), orbit, land, wait for the cooldown to be ready and instantly turn it on.
Likely cause: Desync between the client and the server when zones are changed while an item is cooling down. The server knows X time left for that item but the client somehow leaps ahead and thinks the item is ready when its actually not.
Potential solution/s / workaround/s: Use the same code logic that deactivates running items when going to orbit as a right mouse button click event (example: speed actuator was given to a friendly player, orbiting leaves the friendly player with no speed actuator running, right click on the active item to do the same thing on planet even on white items to reset them) Similar to how players can deactivate items that are about to activate by right clicking them. (example: protector starting to activate.. right click.. cancels the action before turning on the item)

2. Drone switching stuttering (easy to reproduce)

Steps to reproduce: Right click on any drone to activate / deactivate / or to activate a drone past the max active drones number of 3.
Likely cause: Player ship rerender triggered by drone switching causing a small but perceptible and jarring stutter.
Potential solution/s / workaround/s: Don't trigger a rerender of the player ship when switching drones.


Bugs that are not yet fixed:

1. DS heads (custodian commander ds) and / or ds body (rocketeers marauders) are not rendering fast enough causing unexpected player deaths trough out the game (easy-medium difficulty to reproduce)

Steps to reproduce: Knowing ds paths, fly fast (afterburner) into said DS. Most of the time the resurrector will render first, followed by a very delayed rocketeer and marauder render and with an even more delayed custodian commander head render. This causes most players including myself to be taken by surprise (being stunned by seemingly nothing.. then rocketters, resurector and marauder render and sometimes the custodian commander head renders after me podding). This slow render happens on free roaming custodian commanders too on R60 earth for example. This effect does not happen with signor DS heads on R60 sol for example. So there is something about the mantis Custodian Commander.
Likely cause: Talked to stickman. The polygon count for the custodian commander model doesn't seem to be the issue. It's very likely something else. Can't quite put my finger on it since its such an odd thing to happen.
Potential solution/s / workaround/s: N/A (honestly no idea what's causing this.)


2. Some ingame timers are slower than realtime (easy to reproduce) (there are multiple bugs here)

Steps to reproduce: Ingame mission timer notifications are desynced from the real mission timer in the left mission log panel ingame (the one that opens with CTRL). The desync is usually constant and ~5s apart. Many missions have been failed because the log in the hud said 00:00 meanwhile the actual real mission timer was at ~00:05. Server restart timeout drifts ahead the more you stay in the same game zone, sometimes by minutes. Changing zones gets the timer to be very very close to the actual server restart timeout, but it still starts to drift again no matter if you changed zones previously or not. This causes the ingame top left timer to "lie" to players saying there are 2-3 minutes left until a restart when the notification in the hud can say 15s left.
Likely cause: Desync between the server and the client.
Potential solution/s / workaround/s: For the mission timers.. try to time them closer to real time so that the notification doesn't "lie". For the ingame server restart timeout: N/A / no idea.


(on this one i'm not entirely sure if it was sortof kindof fixed in the most recent bugfix patch? will have to retest but you guys can also test to see if it reproduces with the latest patch)
3. Spamming the materialize button / notification in hud for revive can cause multiple permanent hud notifications to stick, usually happens most often in OTB (easy to reproduce)

Steps to reproduce: Pod anywhere ingame, spam the notification in the hud, spam materialize until the timer finishes, you get 1-2 notifications to stick in the hud. This is repeatable in the sense that if you die again, spam the buttons again and materialize you can have upwards of 5-6-7 notifications stuck on screen.
Likely cause: Race condition in the code that does not like having the button clicked too fast.
Potential solution/s / workaround/s: Make sure only 1 notification is allowed to be on screen and only when the player is in a pod. Once in hangar / materialized.. have the notification dissapear.


4. Hangar ship drone slot input fields resize based on if a drone is installed or not (easy to reproduce)

Steps to reproduce: Have a ship with all drone slots occupied. All slots are the same size:
Then remove any of the drones especially the middle ones:

The drone slots that are empty become smaller which causes tons of missclicks if players try to switch drones quickly because the drone slots keep shifting around.
Likely cause: (my web dev exp comes in handy here) The gui container that holds the drone icon and the empty drone icon is dynamic, based on the content size inside. It tries to resize to the smallest size it can that fits the content perfectly.
Potential solution/s / workaround/s: Make the empty drone slot icon the same size as the drone icons. This way the gui container will be forced to keep the same size regardless if a drone is installed or not.


5. Switching ship configurations with drones installed can sometimes cause a secondary configuration to either not show drones when it actually has them or it can cause the drone slot field to not clear when clicking the unequip button (medium - hard difficulty to reproduce)

Steps to reproduce: See video recording. Sorry for the google drive link (can be viewed directly in browser) but this forum doesn't accept video files... https://drive.google.com/file/d/1QYK8jL0ehxMDVdcUvqWyz3Ik1DzU8ogG/view?usp=sharing (I simply entered hangar with a ship with no configurations. switched to a ship with configurations (griffon for that example but it happens on other ships too) and et voila. Bug triggered.
Likely cause: The drone slots code doesn't properly adjust to the currently selected ship config and doesn't update accordingly.
Potential solution/s / workaround/s: Make sure the indexing / etc is correct.


6. Typo in draconis wormhole description (credit to @Malevos for sending me the screeshot and typo)

"safe passage" not "save passage"




Now that you've reached the end of this post I want to say this:

I am very glad I can assist the community with bug reporting and etc and I hope to be able to keep doing it . I love that bugs are getting fixed and in a smaller or larger way.. I influence the game to be better for everyone.

This is by far not the end of the bug list. This is what i considered to be more or less important for now and what the community would appreciate more. There will be more coming soon (coming days / weeks when I manage to come back from my holiday and I manage to remember all the bugs glitches and whatnot and put them together in bug lists xd)

I will also make a new post in the feedback section with ideas for improvements QOL things too.

Looking forward to collaborating more

 

[iuli24]

Bug list part 2:

Bug/s that seemed to be fixed but are not:


1. White cooldowns / items that are simultaneously active and in cd at the same time (thus.. white) (easy to reproduce) [new information compared to the old report in my previous post] [this bug is still triggerable in the exact same ways as prior to the patch, validated by people in OTB discord and myself]

Steps to reproduce: [same as initial report]
Use speed actuator until ~50-80% of its runtime (this item works best), orbit, land, wait for the cooldown to be ready and instantly turn it on.
Likely cause: [same as initial report]
Desync between the client and the server when zones are changed while an item is cooling down. The server knows X time left for that item but the client somehow leaps ahead and thinks the item is ready when its actually not.
Potential solution/s / workaround/s: [new information]
Instead of trying to fix the core issue (if the game code is too spaghettified / may break something else / delivers an undesired behavior by you (devs).. what do you think about implementing a client side validation for impossible item states?)
What i'm thinking is this: implement a simple if statement in the game client code that executes once per item activation that checks if the item state is both active and in cooldown mode at the same time. (it should not cause any performance issues) If such a condition is met.. reinitialize the item state to the default (not active, not cooling down, able to be activated). This should effectively remove the need for implementing / porting over / etc game code logic just to be able to right click on the items to reset them and dealing with the possible bugs that might come alongside it. (my previous suggestion). This way even if an item does hit an impossible state.. the client code "automagically" resets it to default so that players can simply retry the action. If it happens again.. the item validation check solves that situation again and players can effectively retry activating x y z item until the server gives the client the go ahead and the item stays active and in a valid item state. As long as this if condition runs later than the odd active and cooling down code logic.. it should reset this condition every single time. Alternatively you can add a 500ms delay to the check to make sure it executes after the white cooldown bug may happen to avoid race conditions where the validation check happens before the bug. (try to avoid for loops because that is one quick way to undo any performance gains you guys did recently ))) )

For people that said in the otb discord server that "players do not care that if you orbit and reland the item goes white but rather they care that it happens in OTB / CQs" I want to say these points:

- I agree. Having white cds in OTB / CQs is waaaaaaaaaaay more annoying then it being triggered from relanding with items in cooldown and trying to activate them instantly when "ready" afterwards.
- I strongly believe (95% sure) that the miss behaving code that triggers white cooldowns is exactly the same in both scenarios described. They are just different manifestation of the exact same issue. Solving the easilly reproducible white cooldown bug should effectively fix the more rare ish white cooldown bug in OTB / CQs as well. That is why i gave the easy version as a good baseline to fix for the developers.

For the developers:
- I am aware that this new suggestion is basically placing the issue under the rug hoping nobody notices XD, but me and the entire community would much rather have this workaround in game than not having any solution available at all (besides alt f4 / changing game zones to reset the bugged item states which I hope you see the problems to). Me and (pretty sure) the entire community would highly appreciate if such a solution or something similar would be implemented while you try to fix the core issue in the mean time. (if its worth dealing with)

Bugs that are currently still present in game to date:


1. Sometimes players orbiting with item effects still on them leave the effects behind floating in the sky for a prolonged period of time ~2-5s. (medium difficulty to reproduce)

Steps to reproduce: (needs multiple players)
Have item effects on yourself and / or enemy effects at the same time. While said effects are active.. orbit. Other players may see the effects floating in the sky for 2-5s.
Likely cause:
A possible delayed turnoff timer for item effects once x player orbits.
Potential solution/s / workaround/s:
Try to invalidate / disable / clear item effects instantly when players finish orbiting.


2. Pressing ALT + END twice (to make the player ship go invisible and visible again) sometimes causes "cleared" item effects to spring back and get stuck on the player. Happens most often with protectors and graviton effects. (medium - hard difficulty to reproduce) [may be fixed from the item effects patch. if it's not reproducible you can keep it as POR]

Steps to reproduce:
Play normally on any planet for a long enough period of time using all player items and a couple gravitons. Do not change zones. Press ALT + END twice to make the player ship invisible and visible again, notice how either a protector or a previously used graviton effect pops out of nowhere and is permanently stuck.
Likely cause:
Potential memory leak caused by effects not being properly cleared?
Potential solution/s / workaround/s:
Make sure effects are cleared from memory and cannot spring back in such scenarios.


3. Players landing on any planet ingame causes the player position to spawn initially in the wrong place on map, usually a randomized position in the center of any ingame map and can cause a half shell to appear randomly anywhere for up to 10s (easy difficulty to reproduce)

Steps to reproduce: (needs multiple players)
Have 2 players, one in orbit one anywhere on the map, both have to be friends to each other to see the green dot on the map. The player in orbit lands, while he loads.. the player already present on the map notices that the green dot initially drops somewhere weird around the center of the map and when his game client actually loads the landing animation.. then the green dot position moves to the landing zone / where its supposed to be if the player selected to land on the squadron lead.
Simultaneously players that are not even friends with the person landing can sometimes see a transparent player object floating near them like they are about to spawn there instead of lz. (this usually is not tied to the planet center like the green dot is which is weird) The name is visible. The object is clickable and scanable. Then it teleports to where the player is supposed to be.
Likely cause:
The server loads a "default" state of the player object before the player is actually fully loaded / actually landed on x planet.
Potential solution/s / workaround/s:
Load the player object after the player is actually ready to land or load it just slightly before (if this was causing a stutter previously? not that anyone cares if it happens in a loading screen to be honest). This way players wont half render randomly on the planet and the friendly player icon on the map spawns exactly on the correct player position the first time.


4. Players mistakenly can land on a "logged in" player when he actually isn't and get sent to the landing zone instead. (easy to reproduce) [related to bug number 3 above]

Steps to reproduce: (needs multiple players)
Have a squad of minimum of 2 players. The squad lead must be on planet anywhere and the wingmen must be in orbit. Have the squad lead log off, have him log back in. Immediately after seeing X player is now online (by immediately I mean you have a window of ~8-15s) press F6 to land. There will be no prompt to ask the wingmen to land on the squadron lead and they will be sent to landing zone instead.
Likely cause:
Similar to bug number 3.. the player shell gets loaded halfway and the "player online" login message appears for friendly players before the player is anywhere near actually being online or loaded ingame. This causes players to press land thinking they will be prompted but they won't because the game code that checks for a valid player being actually rendered / active / present / w/e on planet does not validate, thus sending them to landing zone.
Potential solution/s / workaround/s:
Do not show the player is online message unless the player is actually fully loaded (in the loading animation on planet) first. Or do not show the message until there is a valid entity actually present on planet. Sometimes players with very poor connections can take so long to load that the player position and ship does show on the map but somehow players still get sent to the landing zone. So there might be multiple bugs to sort out here and in bug number 3 above simultaneously.


4. Changing player fighting states from blue to red or viceversa most commonly causes a similar stutter to the old drone switching stutter (which is fixed). (easy difficulty to reproduce)

Steps to reproduce:
Start a fresh game, land on any planet, do any ingame action to change states to red then wait for the red state to clear. Both scenarios cause a small stutter almost every single time. This tends to kindof clear with time, the more players play the less it happens which is weird.
Likely cause:
Hud changes related sutters? Maybe its something else entirely.
Potential solution/s / workaround/s: N/A.


5. Red state (fighting state) can sometimes be stuck for an extended period of time (it gets retriggered by something) and sometimes it can pop up from nowhere even if the player has not committed any action that would trigger such a state (hard - insane difficulty to reproduce)

Steps to reproduce:
Play around in erebos for example. Farm mantis w/e. Leaving fights (not shooting / not being shot at) sometimes causes the red state to stay up to 3-4X the normal duration. Sometimes just casually afking anywhere on any planet can cause the player state to change to red even though nothing happened visually to the player.
Likely cause:
Likely the code that changes player states from blue to red etc gets confused and sets the wrong state even if no actual item was used by / towards the player by anything / anyone.
Potential solution/s / workaround/s:
N/A. It happens relatively rarely and I haven't been able to find any way to reproduce it. It has a mind of its own. Maybe mantis around the player try to shoot the player even if they can't and the code sets the state to red even though it shouldn't? For example like a previously shot DS will still be aggroed on the player at a later date and will attempt to always shoot him if he gets close?


6. Scanning friendly mission NPCs that have a predetermined flight path change their path to following the player instead (happens usually in gemini / mizar missions and likely other places too) (easy to reproduce)

Steps to reproduce:
Accept an example known mission like: Dirty Water (Commerce Central). Get to the part where you have to follow Sara. Scan the NPC and watch it change its target to you instead of the mission flight path. The mission is effectively hard locked from this point and need to be retaken from orbit. (its not the only mission having this behavior. its just the most recent mission I remember having this bug)
Likely cause:
Game code logic that allows players to scan NPCs to follow them that is wrongly applied to NPCs that have a set flight path.
Potential solution/s / workaround/s:
Add a validation check for NPCs that have a predetermined flight path active so that they cannot change paths to following the player when scanned. If the NPC itself switched to following the player at a later part in x y z mission.. allow it to be scanned. There are venar missions where NPCs with a predetermined flight path can be scanned to stop them temporarely and rescanned to allow them to move again. Try to make sure the possible patch doesn't break code logic somewhere else.


7. Having 2+ players in a squad with an active mission can cause ingame enemy spawns / items / etc to spawn on the wingmen instead of the squad lead / player who triggered x y z mission event. (found in gemini and mizar missions but likely somehwere else too) (easy to reproduce)

Steps to reproduce: (needs multiple players)
Accept an example known mission like: Energy Depletion (Baumar) with a minimum squad of 2 players. Have the wingman anywhere on the map for example landing zone. Have suqad lead fly alone in any mission zone to collect a mission canister. Instead of the mission mantis landing on the squadron lead they land all the way in lz on the wingman position.
Likely cause:
Code that likely determines which player did what... wrongly assumes the wingman / another player did it instead.
Potential solution/s / workaround/s:
Make sure in mission events happen on the correct player that triggers said event.


8. Attempting to take any ingame mission with the accept button and not clicking "OK" on the prompted window and then with that window left open, turning on priate mode breaks the mission panel completely (easy to reproduce)

Steps to reproduce:
Execute the steps shown in the images below:

1. have the mission panel open with pirate mode off:


2. Click on any mission and click the accept button. Do not click OK on the window that appears:


3. Turn on pirate mode (as you can notice the bug already triggered):


4. Click on ok or cancel and then the mission panel is no longer usable. No missions can be accepted. Nothing can be done.


Likely cause:
The pirate mode pop up window overrides the previous popup window (makes it invisible) effectively making it impossible to click "OK" or "CANCEL" on the previous window. This permanently locks the mission panel until a zone change / game restart is executed.
Potential solution/s / workaround/s:
Make sure that both pop up windows can exist at the same time. They should not interfere with each other?


9. Trying to accept missions in orbit and canceling the action and then trying to accept them again can cause the mission panel to half glitch ( these icons disappear from the panel for some reason) and then the log says "the mission has expired. please select another one" (medium difficulty to reproduce)

Steps to reproduce:
Try to accept a mission w/o clicking on the "OK" button in the popup window. Click on cancel. Try to accept the same mission again. If it doesn't happen try again. Sometimes it can also be triggered with squads. Attempt to take the mission with 3 people in squad, cancel, let an extra player join. Attempt to fully accept that same mission again.
Likely cause:
Some validation code that doesn't properly check mission states or something similar.
Potential solution/s / workaround/s:
Make sure that missions can't "expire" if not fully accepted / turned on.


10. The infamous blaster bug. Shooting anywhere from 2/3 to 1/4 blaster shots when the keyboard key "1" is held down. (insane difficulty to reproduce) [Honestly? You may have better chances of winning the lottery and simultaneously witnessing the Betelgeuse red giant go supernova at the same time than seeing this bug happen twice in the same week XD]

Steps to reproduce:
Just start the game and hold 1 key and see if your blaster shoots constantly or "misses" shots (doesn't shoot 1/3 2/3 times). If it doesn't happen.. try again. (you have to restart the entire game. relog does not do it) Nothing triggers this bug during gameplay. It's only triggered at game boot. Something gets messed up and if it starts with the bug on.. the only way to get rid of it is to not relog.. not change zones.. you have to apply the magic ALT + F4 button combination to fully close it and start it back up again.

Likely cause:
N/A

Potential solution/s / workaround/s:
N/A


11. [Visual bug] Sun rays pass through solid objects like planet walls / planet objects in orbit / asteroids in the loading screen / etc

Steps to reproduce:
Just witness sun rays pass trough solid objects ingame (I will be honest this is just my OCD XD).
Likely cause:
No validation to stop sun rays to pass through said objects.
Potential solution/s / workaround/s:
Make sure sun rays are validated and cannot pass through solid objects.


12. Scanning a blueprint after having a mantis clicked / shot / killed can result in the scan window show the information for the previously selected object instead of the blueprint. Sometimes it can happen between cryonite and blueprints too (easy - medium difficulty to reproduce)

Steps to reproduce:
Have some bps / cryo already on the ground. Shoot mantis nearby. Select the blueprint / cryonite and immediately scan it. Notice how the information is incorrect. Rescanning the same blueprint / cryonite again results in the correct information being shown.

P.S. Something similar can happen in sirius with Commander Units like keops. And it shows the correct keops 3D object but the text information is just the back end variable name. Weird.

Likely cause:
Wrong indexing maybe? The scanning code thinks the previous entity is still selected and shows the wrong information?
Potential solution/s / workaround/s:
Make sure scanning objects always shows the information for the currently selected entity.


13. Killing Commander Units in Sirius on a inactive planet causes the cooldown respawn timer to reset instantly the first time and only for the following kills have a correct? respawn timer (easy to reproduce)

Steps to reproduce:
Go on a Sirius R5 planet that was inactive for a long time. (hours) Go near the respawn point of any Commander Unit on that planet. Kill it and notice how it instantly respawns (anywhere from 0-10s). Kill it again and notice that the respawn timer seems correct.
Likely cause:
Possible respawn timer roll over? It's possible that it counts the respawn timer even when the units are still alive on the planet thus thinking they are immediately ready to respawn on 1st kill even when they aren't supposed to?
Potential solution/s / workaround/s:
Make sure the respawn timer does not count down when said units are still alive on the planet.



P.S. I will also post a QOL / Feedback forum thread separately from this bug list thread soon.