Grid Sage Forums
- May 13, 2024, 05:05:33 AM
- Welcome, Guest
|
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
1
Fixed Bugs & Non-Bugs / [Beta 13] (spoilers) Compactor not attacking Gs
« on: May 02, 2024, 09:17:21 AM »
As visible in the attached screenshot, Compactors apparently don't attack Golems.
This one was capable of going as far as fully integrating a weapon before dying to corruption!
I'm guessing this a is bug with the faction system.
Good thing i (accidentally) found that out in my adventurer mode bug-seeking run, would've been annoying to try to drop a GOLEM Unit to distract Compactors with no effect in a more serious run.
This one was capable of going as far as fully integrating a weapon before dying to corruption!
I'm guessing this a is bug with the faction system.
Good thing i (accidentally) found that out in my adventurer mode bug-seeking run, would've been annoying to try to drop a GOLEM Unit to distract Compactors with no effect in a more serious run.
2
Fixed Bugs & Non-Bugs / [Beta 13] 0b10 outpost sentry backup request is based on Cogmind's FOV
« on: April 28, 2024, 04:10:48 AM »
In order to request backup, outpost sentries of cave branches need to have made their pre-backup request statement.
In order to make that statement, they have to :
1 - Be tracking Cogmind.
2 - Do the same thing that NPCs like Exiles need to do when they want to tell you something, which is to say be within Cogmind's FOV.
This makes no sense whatsoever, as it means having a Visual Processing Unit-type utility can cause the sentry to request backup before it actually sees you (if you shoot it from afar, for example).
This also makes disabling visual range utilities a good idea (and makes Cloaking Devices useless for preventing backup) when attacking 0b10 outposts.
In order to make that statement, they have to :
1 - Be tracking Cogmind.
2 - Do the same thing that NPCs like Exiles need to do when they want to tell you something, which is to say be within Cogmind's FOV.
This makes no sense whatsoever, as it means having a Visual Processing Unit-type utility can cause the sentry to request backup before it actually sees you (if you shoot it from afar, for example).
This also makes disabling visual range utilities a good idea (and makes Cloaking Devices useless for preventing backup) when attacking 0b10 outposts.
3
Fixed Bugs & Non-Bugs / [Beta 13] "My part are pretty effective for their mass" with transmission jammer
« on: April 27, 2024, 03:10:12 AM »
As visible in the attached screenshot, this Tinkerer says their makeshift parts are "pretty effective for their mass", which implies that the parts are of lower mass but still as/more effective than same-mass non-makeshift parts.
However, one of the parts here is a Mak. Transmission Jammer, which has a higher mass than its same-range counterpart.
The only way it can be considered more effective is with its energy cost, but it still has a higher mass than any other Transmission Jammer.
It's probably normal in some way, but unless i'm being annoying by posting so many of these bug reports i'll keep posting what feels wrong to avoid not reporting an actual bug.
However, one of the parts here is a Mak. Transmission Jammer, which has a higher mass than its same-range counterpart.
The only way it can be considered more effective is with its energy cost, but it still has a higher mass than any other Transmission Jammer.
It's probably normal in some way, but unless i'm being annoying by posting so many of these bug reports i'll keep posting what feels wrong to avoid not reporting an actual bug.
4
Fixed Bugs & Non-Bugs / [Beta 13] (Spoiler) Projectile penetration increases range
« on: April 27, 2024, 02:43:43 AM »
As visible in the attached screenshot, i shot the tile directly down-right of the upper Wall Chamber's lower right corner using my Imp. KE Penetrator, which was as far as i could shoot directly up-right diagonally.
This hit the barely out-of range Wall Chamber, which i think is normal? But the projectile penetrated the first tile, which made it travel to the next tile(?) and broke it, which i'm pretty sure breaks the rules of how weapon range works.
I later tried to see if you could hit a stationary hostile by extending the range using this method, but i'm not sure if it worked, as it might have been an Infiltrator i didn't recognize as friendly because of only have an Imp. Signal Interpreter (I hadn't seen Infiltrators yet), who didn't move when i shot them because they weren't 0b10?
This hit the barely out-of range Wall Chamber, which i think is normal? But the projectile penetrated the first tile, which made it travel to the next tile(?) and broke it, which i'm pretty sure breaks the rules of how weapon range works.
I later tried to see if you could hit a stationary hostile by extending the range using this method, but i'm not sure if it worked, as it might have been an Infiltrator i didn't recognize as friendly because of only have an Imp. Signal Interpreter (I hadn't seen Infiltrators yet), who didn't move when i shot them because they weren't 0b10?
5
Fixed Bugs & Non-Bugs / [Beta 13] Phase wall remains open and unpassable
« on: April 26, 2024, 02:43:37 AM »
As visible in the attached screenshot, i can see through it and i can inspect it. However, my shots pass through it, but i can't move into it.
That phase wall is just completely invincible (phase generator excluded).
This happened after i destroyed the Behemoth standing on the four visible phase walls by aiming at the same tile as the bugged phase wall.
I remembered to make a copy of the save file, so it's also attached in case it's useful.
That phase wall is just completely invincible (phase generator excluded).
This happened after i destroyed the Behemoth standing on the four visible phase walls by aiming at the same tile as the bugged phase wall.
I remembered to make a copy of the save file, so it's also attached in case it's useful.
6
Fixed Bugs & Non-Bugs / [Beta 13] Explosion prediction can be misleading
« on: April 26, 2024, 02:25:40 AM »
If you aim a launcher at a wall, the explosion prediction will show you how it looks like if the weapon exploded in the wall, but the actual projectile would explode against it, not on the same tile.
It's probably how it's supposed to work (after all, explosion prediction shows the explosion at the point you're aiming at, not where the explosion would end up), but it's something that's very easy to unconsciously understand but never really consciously notice until something you calculated shouldn't happen happens anyways.
And so one might end up aiming the target of an explosion to be barely out of range of Cogmind, but because it actually explodes in front of the wall it hits, you get hit by the explosion anyways.
(That's how i once got hit by my own ST in the very last area.)
It's probably how it's supposed to work (after all, explosion prediction shows the explosion at the point you're aiming at, not where the explosion would end up), but it's something that's very easy to unconsciously understand but never really consciously notice until something you calculated shouldn't happen happens anyways.
And so one might end up aiming the target of an explosion to be barely out of range of Cogmind, but because it actually explodes in front of the wall it hits, you get hit by the explosion anyways.
(That's how i once got hit by my own ST in the very last area.)
7
Fixed Bugs & Non-Bugs / [Beta 13] (spoiler) Misleading projectile arc prediction
« on: April 26, 2024, 02:11:26 AM »
When firing multiple weapons in a volley, including a weapon with an arc such as a Rocket Array, the arc prediction always shows, even if the target is out of range (and you therefore won't fire).
This can be misleading, since it makes it look like the launcher would fire alongside the other weapons.
This is especially bad if the weapon is a launcher, since those do show explosion predictions only if your target is in range of the launcher.
(Also, not only is the majority of the very few arc weapons launchers, launchers are also the most common arc weapons!)
The confusing thing is that the two parts of the projectile prediction for arc launchers don't behave the same way;
The arc prediction always shows, but the explosion prediction doesn't (and also gets almost completely hidden by the arc projection before it disappears).
It isn't technically a bug, but it is misleading!
Screenshot attached for clarification.
This can be misleading, since it makes it look like the launcher would fire alongside the other weapons.
This is especially bad if the weapon is a launcher, since those do show explosion predictions only if your target is in range of the launcher.
(Also, not only is the majority of the very few arc weapons launchers, launchers are also the most common arc weapons!)
The confusing thing is that the two parts of the projectile prediction for arc launchers don't behave the same way;
The arc prediction always shows, but the explosion prediction doesn't (and also gets almost completely hidden by the arc projection before it disappears).
It isn't technically a bug, but it is misleading!
Screenshot attached for clarification.
8
Confirmed Bugs / [Beta 13, non-modal UI] Unable to label Operator (and other robots) above part
« on: April 23, 2024, 03:13:53 AM »
As visible in the attached screenshot, i'm hovering my cursor over an operator (sensed through a trojan) in order to see what level this Operator is to see if it could be responsible for the level 2 terminal i'm next to.
However, the game only labels the item the Operator is hovering over.
This happened before in the same run, with directly visible allies also standing over items. However, it only happened to some of my allies that were standing on items, not all of them.
I didn't think to save & quit to see if the bug persisted through relaunch and copy the save file.
Also visible in this screenshot, i clicked the /SCAN/ [1 - HOSTILE] button, to try to get the class rating that way, but it says there are "No hostiles to label". I don't know if this is related.
(I ended up getting the class rating by comparing the color to a different Operator. (I'm not familiar with the Operator color levels with SHIFT_HUE(340) yet.))
However, the game only labels the item the Operator is hovering over.
This happened before in the same run, with directly visible allies also standing over items. However, it only happened to some of my allies that were standing on items, not all of them.
I didn't think to save & quit to see if the bug persisted through relaunch and copy the save file.
Also visible in this screenshot, i clicked the /SCAN/ [1 - HOSTILE] button, to try to get the class rating that way, but it says there are "No hostiles to label". I don't know if this is related.
(I ended up getting the class rating by comparing the color to a different Operator. (I'm not familiar with the Operator color levels with SHIFT_HUE(340) yet.))
9
Fixed Bugs & Non-Bugs / [Beta 13] Allies ignore trap knowledge too often
« on: April 19, 2024, 03:39:55 AM »
As visible in the screenshot, i had downloaded the garrison registry, which includes all trap locations. Despite this, an allied grunt still decided to step on a known Fusion Bomb Trap, just to get a better chance to attack a Watcher. As a result, i lost two allies and four potential allies. For a Watcher.
And it's not just this specific situation, either. In the last few Betas (starting from 10ยน), it's happened far too often that an Operator ally would hover around me and over know traps, or that when going through a 1-tile gap in Ambush Traps, a group of allies following me would not attempt to dodge them (that one only happened once in Beta 11, but still).
That a Behemoth would have trouble avoiding known traps, i can understand. That a group of allies would trigger a known Alarm Trap, i can understand, it's not the worst trap. That allies wouldn't attempt to go around traps when they would need to make a huge detour, i can also understand.
However, i can't understand allies not avoiding group-destroying traps.
The worst part is that sometimes, they do actually try and avoid traps. And i don't understand why only those times and not the others.
And it's not just this specific situation, either. In the last few Betas (starting from 10ยน), it's happened far too often that an Operator ally would hover around me and over know traps, or that when going through a 1-tile gap in Ambush Traps, a group of allies following me would not attempt to dodge them (that one only happened once in Beta 11, but still).
That a Behemoth would have trouble avoiding known traps, i can understand. That a group of allies would trigger a known Alarm Trap, i can understand, it's not the worst trap. That allies wouldn't attempt to go around traps when they would need to make a huge detour, i can also understand.
However, i can't understand allies not avoiding group-destroying traps.
The worst part is that sometimes, they do actually try and avoid traps. And i don't understand why only those times and not the others.
10
Fixed Bugs & Non-Bugs / [Beta 13] Ally-repaired broken propulsion auto-activates despite settings
« on: April 19, 2024, 03:18:27 AM »
As (not technically) visible in the attached screenshot, after an allied Surgeon repaired my Broken Gyrokinetic Inverter, said propulsion unit auto-activated despite the fact that i set my advanced.cfg setting disableSecondPropulsionAutoactivate=1
I guess it isn't technically a bug, given that the manual entry for disableSecondPropulsionAutoactivate states that it's specifically for attaching propulsion, not anything else, but i thought i'd mention it here in case it's not the intended behavior.
I guess it isn't technically a bug, given that the manual entry for disableSecondPropulsionAutoactivate states that it's specifically for attaching propulsion, not anything else, but i thought i'd mention it here in case it's not the intended behavior.
11
Fixed Bugs & Non-Bugs / [Beta 13] Mouse auto-pathing goes around repaired/collapsed walls
« on: April 19, 2024, 02:51:17 AM »
As visible in the attached screenshot, mouse auto-pathing completely avoids the shorter path through the broken tiles, because those tiles have been repaired since the last time i saw them (from the north side).
At least i think that's what's happening here. I don't *think* auto-pathing is trying to avoid collapsable tiles?
I'll try to investigate more later to make sure.
At least i think that's what's happening here. I don't *think* auto-pathing is trying to avoid collapsable tiles?
I'll try to investigate more later to make sure.
12
Fixed Bugs & Non-Bugs / [Beta 13] Propulsion Burnouts scoresheet entry refers to parts lost that way
« on: April 12, 2024, 12:17:22 PM »
Maybe it's intentional, but just in case, the "Propulsion Burnouts" scoresheet entry seems like it counts the number of parts destroyed due to burnout, even though it feels like it should count the amount of times burnout took out integrity from propulsion units.
13
Ideas / No ground-to-attached-to-inventory-to-ground auto-replacement option
« on: April 12, 2024, 11:16:16 AM »
One thing that has caught me off-guard multiple times, sometimes in a really bad way, is the auto-replacement mechanic throwing away an inventory item when i only wanted to swap the part on the ground with an equipped part.
For example, when autoreplacing a Storage Unit, Storage Units with less capacity can be thrown away.
If i have a damaged Large Storage Unit equipped and a Medium Storage Unit in inventory, Auto-equipping a new Large Storage Unit from the ground equips the new Large Storage, places the old Large Storage in inventory, and drops the Medium Storage.
However, in most situations, when i have a Storage Units of lesser capacity, than the one i currently have equipped, it's because i need a backup in case i can no longer support the bigger one (for example, if my only weight-supporting utility gets destroyed) or if i plan on switching to a Storage Unit of lower capacity (transitioning to flight, losing mass to go full combat, and so on).
So, picture me, with a damaged Large Storage Unit, and finding a newer one on the ground. I swap it out with my current Large Storage Unit, effectively "repairing" it. However, i didn't notice that it made me drop the lower-capacity Storage Unit i had in my inventory, which i was safekeeping for later, only to replace it with the now useless damaged Large Storage Unit.
*Later* Now to equip my... Where's my Medium Storage Unit?
This has also happened to me with other parts as well, including weapons (for example, an Enh. Force Rifle i wanted to keep for the positive salvage and high critical chance). Sometimes i notice it, other times not so much.
My suggestion is an option to prevent Part Auto-Replacement from replacing both an equipped item and an inventory item. Or at the very least, add something that warns/notifies the player that an item from their inventory was swapped out.
For example, when autoreplacing a Storage Unit, Storage Units with less capacity can be thrown away.
If i have a damaged Large Storage Unit equipped and a Medium Storage Unit in inventory, Auto-equipping a new Large Storage Unit from the ground equips the new Large Storage, places the old Large Storage in inventory, and drops the Medium Storage.
However, in most situations, when i have a Storage Units of lesser capacity, than the one i currently have equipped, it's because i need a backup in case i can no longer support the bigger one (for example, if my only weight-supporting utility gets destroyed) or if i plan on switching to a Storage Unit of lower capacity (transitioning to flight, losing mass to go full combat, and so on).
So, picture me, with a damaged Large Storage Unit, and finding a newer one on the ground. I swap it out with my current Large Storage Unit, effectively "repairing" it. However, i didn't notice that it made me drop the lower-capacity Storage Unit i had in my inventory, which i was safekeeping for later, only to replace it with the now useless damaged Large Storage Unit.
*Later* Now to equip my... Where's my Medium Storage Unit?
This has also happened to me with other parts as well, including weapons (for example, an Enh. Force Rifle i wanted to keep for the positive salvage and high critical chance). Sometimes i notice it, other times not so much.
My suggestion is an option to prevent Part Auto-Replacement from replacing both an equipped item and an inventory item. Or at the very least, add something that warns/notifies the player that an item from their inventory was swapped out.
14
Fixed Bugs & Non-Bugs / [Beta 13] Scrap Engine weapon doesn't have newly added critical effect
« on: April 12, 2024, 10:54:50 AM »
See attached screenshot. The log clearly states that the Scrap Engine modified my weapon to, among other things, add 4% critical chance (Burn). However, the weapon itself has 0% critical chance with no effect.
15
Fixed Bugs & Non-Bugs / [Beta 13] Gun Armor deletes new Scrap Engine weapon
« on: April 12, 2024, 10:53:09 AM »
I had the Gun Armor equipped, and had non-construct weapons in both slots. I also had the Scam Engine attached and had loaded it with a few weapons. When one of the Gun Armor weapons was destroyed, the Scrap Engine created a new weapon construct for that slot to try to replace the weapon that just broke.
Because the slot ceased to exist, though, the weapon construct never reached my equipped parts and just disappeared.
I had 3 regular weapon slots and two extras when one of the extras was destroyed.
Because the slot ceased to exist, though, the weapon construct never reached my equipped parts and just disappeared.
I had 3 regular weapon slots and two extras when one of the extras was destroyed.
16
Ideas / Showing the depth identified exits lead to
« on: April 10, 2024, 03:14:19 AM »
The suggestion is for identified exits to also show the depth of the area they lead to. I feel like that would be fairly logical, at least with Signal Interpreters.
Before Subcaves were added, the fact that there's no indication as to the depth of where an exit leads to was only relevant when exiting Garrisons.
Now that the Subcaves exist and can lead to Recycling, no matter the depth of Recycling, that becomes a bit more of an issue.
Maybe it's by design, but the fact is that it isn't reliably possible to figure out the depth of Recyling while going to the Subcaves is fairly annoying to me.
I want to go to the Subcaves for what i can find in there, and i also want to go to Recycling for the same reason, but only if it isn't at -9. However, since Subcaves always lead to -8, the only way i can ever go to both in the same run is by either :
-Finding out Recycling's depth thanks to tunnelling, which, with two tunnelling opportunities, would only work out ~20,526315789% of the time, assuming tunnelling can't reveal Mines. And only about a third of that would have Recycling at -9.
-Taking a gamble that recycling will be at -9. If the gamble fails, which it will most of the time, then i miss out on one or both Lower Caves branches. That gamble is not worth it to me.
Before Subcaves were added, the fact that there's no indication as to the depth of where an exit leads to was only relevant when exiting Garrisons.
Now that the Subcaves exist and can lead to Recycling, no matter the depth of Recycling, that becomes a bit more of an issue.
Maybe it's by design, but the fact is that it isn't reliably possible to figure out the depth of Recyling while going to the Subcaves is fairly annoying to me.
I want to go to the Subcaves for what i can find in there, and i also want to go to Recycling for the same reason, but only if it isn't at -9. However, since Subcaves always lead to -8, the only way i can ever go to both in the same run is by either :
-Finding out Recycling's depth thanks to tunnelling, which, with two tunnelling opportunities, would only work out ~20,526315789% of the time, assuming tunnelling can't reveal Mines. And only about a third of that would have Recycling at -9.
-Taking a gamble that recycling will be at -9. If the gamble fails, which it will most of the time, then i miss out on one or both Lower Caves branches. That gamble is not worth it to me.
17
Ideas / Auto-overload propuslion when melee attacking with momentum
« on: April 07, 2024, 02:35:18 AM »
There's an option to automatically switch to threads when firing ranged weapons then switch back automatically to previously used propulsion when moving.
My suggestion is something similar for melee weaponry :
If you have any momentum and are attacking with a melee volley, automatically overload all possible propulsion units when attacking, then stop overloading the propulsion units that overloaded because of this immediately at the start of the player's next "turn".
-Melee damage gets a boost from momentum and also speed when you do have momentum, and overloading makes you go faster (in the vast majority of cases, at least), meaning you deal more damage.
-There's no drawback from attacking with overloaded propulsion units, since all negatives come from movement.
-It is quite tedious to overload all propulsion units one by one every time you want to attack, then stop overloading them to move, then overload them again.
My suggestion is something similar for melee weaponry :
If you have any momentum and are attacking with a melee volley, automatically overload all possible propulsion units when attacking, then stop overloading the propulsion units that overloaded because of this immediately at the start of the player's next "turn".
-Melee damage gets a boost from momentum and also speed when you do have momentum, and overloading makes you go faster (in the vast majority of cases, at least), meaning you deal more damage.
-There's no drawback from attacking with overloaded propulsion units, since all negatives come from movement.
-It is quite tedious to overload all propulsion units one by one every time you want to attack, then stop overloading them to move, then overload them again.
18
Fixed Bugs & Non-Bugs / [Beta 13] Moving inventory item with a part description window open
« on: April 07, 2024, 02:19:48 AM »
Non-modal UI.
I accidentally both left-clicked and right-clicked an item in my inventory at (almost?) the same time, which caused the part description window to appear, and i was also holding the item in my mouse cursor, which could then used like normal, without removing the part description window. (Dropping it on the ground, swapping it with equipped parts...)
The bug is that i could move an inventory part around with the mouse while its description window was active, which is normally impossible. This also means it's possible to take time-based actions with a part window active, which i don't think is also normally possible?
(I wonder if there are more bugs that can result from this, like by dropping an item that then gets damaged/destroyed by for instance explosives, all while its description window is still open?)
I accidentally both left-clicked and right-clicked an item in my inventory at (almost?) the same time, which caused the part description window to appear, and i was also holding the item in my mouse cursor, which could then used like normal, without removing the part description window. (Dropping it on the ground, swapping it with equipped parts...)
The bug is that i could move an inventory part around with the mouse while its description window was active, which is normally impossible. This also means it's possible to take time-based actions with a part window active, which i don't think is also normally possible?
(I wonder if there are more bugs that can result from this, like by dropping an item that then gets damaged/destroyed by for instance explosives, all while its description window is still open?)
19
Fixed Bugs & Non-Bugs / [Beta 13] (Spoilers) Inventory item labels appear briefly near attached parts
« on: March 30, 2024, 11:24:39 AM »
Spoiler warning for the location and related things. (Relatively big spoilers)
Non-modal UI
As visible in the video and screenshot, the names of some items in my inventory appear briefly next to some of my attached items, despite the fact that i did nothing that should trigger that.
The names are specifically those of the last items i'd swapped into my inventory, and they are next to the very parts i swapped them with!
I don't know much about auto-repair or whatever that feature is called, but it's probably related?
One last potentially relevant thing : When i flew past the Fortress, the only thing that got hit was my Sigix Broadsword, which was inactive then. I did lose propulsion integrity from burnout both before and after, though.
I don't have a video editing software, so the method i used to make the video of specifically those seven seconds was to re-record part of the longer video i had. (This is why some pixels appear at the bottom-right corner of the screen on the last frame.)
Non-modal UI
As visible in the video and screenshot, the names of some items in my inventory appear briefly next to some of my attached items, despite the fact that i did nothing that should trigger that.
The names are specifically those of the last items i'd swapped into my inventory, and they are next to the very parts i swapped them with!
I don't know much about auto-repair or whatever that feature is called, but it's probably related?
One last potentially relevant thing : When i flew past the Fortress, the only thing that got hit was my Sigix Broadsword, which was inactive then. I did lose propulsion integrity from burnout both before and after, though.
I don't have a video editing software, so the method i used to make the video of specifically those seven seconds was to re-record part of the longer video i had. (This is why some pixels appear at the bottom-right corner of the screen on the last frame.)
20
Confirmed Bugs / [Beta 13] Outdated W-44 Eye analysis
« on: March 30, 2024, 03:44:14 AM »
W-44 Eyes have a visual range of 20 "with a greater visual range than any other class". H-81 Overseers have a visual range of 22 (and H-71 Marshals a range of 20, which Eyes are still not above). (And Executioners have a range of 23, but i'm not sure they qualify as a class in that sense?)
I actually noticed this a long while ago (probably by relying on that intel then getting shot by an Overseer) but for some reason it didn't occur to me to report it.
I actually noticed this a long while ago (probably by relying on that intel then getting shot by an Overseer) but for some reason it didn't occur to me to report it.
21
Fixed Bugs & Non-Bugs / [Beta 13] (Spoilers) Momentum melee modifier isn't applied accurately
« on: March 28, 2024, 12:03:29 PM »
As visible in the attached screenshot, i have 3 momentum and am moving at a speed of 22 (454,545454...%), which means my melee modifier should be ((3 * 454 / 1200) * 40) = 45.4%, which caps to 40%, which means this can't be some issue where the value would be 39.99 and then be visually rounded up in Cogmind's stats.
Despite having a 40% melee modifier, my 50-100 melee weapon only goes up to 69-139 instead of 70-140.
Despite having a 40% melee modifier, my 50-100 melee weapon only goes up to 69-139 instead of 70-140.
22
Confirmed Bugs / [Beta 13] Melee Specialist achievement has too much text to display
« on: March 28, 2024, 11:29:46 AM »
Non-modal UI. (I'd have written this information in the topic title, had i not ironically ran out of characters.)
As visible in the attached screenshot, the new Melee Specialist achievement description has too much text for all of it to fit, and some ends up not displaying as a result.
As visible in the attached screenshot, the new Melee Specialist achievement description has too much text for all of it to fit, and some ends up not displaying as a result.
23
Confirmed Bugs / [Beta 13] (big spoilers) Exit mouseover animation starts appearing to the side
« on: March 28, 2024, 11:22:16 AM »
(The spoiler warning is for the area in which the videos showing the bug were taken.)
Non-modal UI.
As visible in the attached videos, the rectangle that's supposed to appear around exits when hovering the mouse over them starts to appear on the side.
As far as i can see, this happens when the exit is far enough to the right of the screen that [the name of the area it leads to] has to be written on the exit's left instead of to its right.
Non-modal UI.
As visible in the attached videos, the rectangle that's supposed to appear around exits when hovering the mouse over them starts to appear on the side.
As far as i can see, this happens when the exit is far enough to the right of the screen that [the name of the area it leads to] has to be written on the exit's left instead of to its right.
24
Confirmed Bugs / [Beta 13] Outdated Lightnting analysis
« on: March 28, 2024, 11:14:47 AM »
In my current run, i saw some Lightnings on my sensors, which used to be impossible.
After seeing i didn't have the Lightning analysis (and no prototype analyses at all, as i forgot to get Zh's), i checked Cog-Minder.
The Lightning analysis states that it "remains completely undetectable by any known non-visual sensors", but its scan cloak was lowered to 4, which is detectable with an Exp. Signal Interpreter.
After seeing i didn't have the Lightning analysis (and no prototype analyses at all, as i forgot to get Zh's), i checked Cog-Minder.
The Lightning analysis states that it "remains completely undetectable by any known non-visual sensors", but its scan cloak was lowered to 4, which is detectable with an Exp. Signal Interpreter.
25
Fixed Bugs & Non-Bugs / [Beta 13] Isn't the "inventory autosorting" option now useless?
« on: March 23, 2024, 11:21:22 AM »
Now that items autosort into your inventory, isn't the "inventory autosorting" option now useless?
I turned it off and noticed no differences.
(Option menu, Interface section, lowercase q)
I turned it off and noticed no differences.
(Option menu, Interface section, lowercase q)