Grid Sage Forums
- May 12, 2024, 09:38:28 PM
- 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
Confirmed Bugs / Re: [B12] Branch exit might use stair tile instead of door tile
« on: May 03, 2024, 02:58:54 AM »Testing in an actual release build would be the next step to confirm, but that takes even longer and there's also nothing unique about release builds in this regard so is assumed unlikely to turn up anything. To that point, unfortunately by now I've already put waaaaaaaaay too many hours into this for what is a very unimportant issue, so I've decided it will live on forever!That makes sense. I'm actually a bit surprised that you even tested it this much because i thought you'd already said that you wouldn't investigate further in the past.
Anyhow, even if you won't investigate it further, i'm still going to do so as much as i can!
I remembered that you do upload your streams, which i could check to see if you experienced the bug in them. I think i'd done that in the past, but didn't find any occurence.
However, some of your more recent streams involve Garrisons and branches... Okay this one is from a year ago, but you can clearly see the bug happening on your computer at 2:30:25 :
https://youtu.be/3lea1bK5o-s?t=9025
(You get the branch(access) intel in the previous same-floor Factory map at 46:19)
Unless i'm missing another possibility, i think all this is enough to prove that your debug environment is different from a release build in some way.
So even though i've just said i would still try to investigate it as much as i can, i don't think i can do much more. My investigation ends here as well!
2
Confirmed Bugs / Re: [B12] Branch exit might use stair tile instead of door tile
« on: May 02, 2024, 09:35:23 AM »
Given that it happens for me not just sometimes, but always, i think the problem has to lie with a difference between our computers/setups.
The possibilities i see are :
-The bug only happens on Linux, which would mean everyone who has experienced the bug played on Linux. That might easy to verify?
-The bug is due to something less specific than just playing on Linux, which would make it somewhat difficult to identify without asking a bunch of people to try to reproduce the bug.
-The bug is due to something that for some reason doesn't happen in a debug environment. If your tests included using a non-debug version of Cogmind (unlike in the GIF), then you already know the answer to that one.
-The bug is due to something that for some reason doesn't affect specifically your computer. For instance, maybe in the specific scenario of this bug, the game would try to get the stairs sprite from outside the game folder instead of the one already in the game folder¹. Then, upon failure, the game would default to using the stairs sprite instead.
In this scenario, the bug would not occur on your computer because the sprite the game tries to get does exist on your computer, but not on anyone else's.
¹Because of some error like using an absolute path instead of a relative one, for instance. Actually, i could try to verify that specific possibility myself... (even if this specific possibility makes a lot of assumptions about how the game works.)
The possibilities i see are :
-The bug only happens on Linux, which would mean everyone who has experienced the bug played on Linux. That might easy to verify?
-The bug is due to something less specific than just playing on Linux, which would make it somewhat difficult to identify without asking a bunch of people to try to reproduce the bug.
-The bug is due to something that for some reason doesn't happen in a debug environment. If your tests included using a non-debug version of Cogmind (unlike in the GIF), then you already know the answer to that one.
-The bug is due to something that for some reason doesn't affect specifically your computer. For instance, maybe in the specific scenario of this bug, the game would try to get the stairs sprite from outside the game folder instead of the one already in the game folder¹. Then, upon failure, the game would default to using the stairs sprite instead.
In this scenario, the bug would not occur on your computer because the sprite the game tries to get does exist on your computer, but not on anyone else's.
¹Because of some error like using an absolute path instead of a relative one, for instance. Actually, i could try to verify that specific possibility myself... (even if this specific possibility makes a lot of assumptions about how the game works.)
3
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.
4
Fixed Bugs & Non-Bugs / Re: [Beta 13] 0b10 outpost sentry backup request is based on Cogmind's FOV
« on: April 29, 2024, 03:44:16 AM »This isn't a bug, it's just how that particular event is coded.I mean, everything in the game happens because that's how it was coded, including bugs.
I was more reporting the fact that it makes no sense using in-world logic, which is the defining characteristic of a lot of bugs. (It's also somewhat frustrating to figure out how that particular event works : Why would you assume it to be based on your own vision rather than the Sentry's?)
Disable at your own risk!I'm not sure how i'd be disabling my Visual Processing Units with any risk, given that i usually know if there are other hostiles nearby, and that almost every time, i'll prefer missing a few shot against the sentry from not seeing it¹ rather than having tracking reinforcements sent after me.
(¹With traps or a good Sensor Array, i wouldn't even need to shoot in the dark.)
5
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.
6
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.
7
Fixed Bugs & Non-Bugs / Re: [Beta 13] (spoiler) Misleading projectile arc prediction
« on: April 27, 2024, 02:53:45 AM »I mean... explosion predictions are pretty obvious because they have a half-square outline delineating the maximum in each axis direction, which is the more fundamental part of that display--it uses lines in addition to the interior highlight area and not just relying on color like the rest of the targeting interface.It might be intended to be the more fundamental part of that display, but what i automatically check to see if an explosion will occur is the far more obvious highlighted area. I wouldn't be surprised if that was also the case for a good chunk of players.
At some point, i even saw those explosion range line indicators and thought "wait, were those always there?". I might be good at noticing things generally, but apparently i can tunnel vision when i'm not in "parsing the entire screen for information" mode.
8
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?
9
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.
10
Fixed Bugs & Non-Bugs / Re: [Beta 13] (spoiler) Misleading projectile arc prediction
« on: April 26, 2024, 02:31:21 AM »Yeah I'm aware of this behavior, that's how it was built to show you the arc no matter what, since it's helpful to know even if it won't fire, which you'll generally know due to the other differences (in particular the lack of an explosion prediction showing AOE).Maybe the arcs should be made less obvious, at least when combined with explosives, then? The explosion prediction does get hidden pretty well by the arc if you're not firing at close-range targets. (Though that might be due to my SHIFT_HUE... I'll have to check.)
11
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.)
12
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.
13
Ideas / Re: Showing the depth identified exits lead to
« on: April 25, 2024, 02:58:15 AM »What information were you hoping for?How it interacts with multi-slot parts, weapons with special effects and AAs.
I seriously doubt that the Scrap Engine would be compatible with AAs (and i know that it isn't with special weapons like Flamers), but the article makes no mention of that.
By "weapon with special effects", i mean stuff like AWS which fires automatically, YOLO Cannon, PS and PC, which create explosions on the point of impact, and so on. Effects that aren't part of of regular stats, unlike overloading, waypoints, and so on. Even if their effects can't be applied (i don't actually know but assume not), some things like the AWS/Autocannon have extremely good statistics. Can weapons with such special effects still be given to the Scrap Engine?
Multi-slot parts, especially weapons, tend to have better stats that their one-slot counterparts. Do those count as multiple parts? Do they get some kind of negative modifier? Or are they simply that good?
I also noticed some stuff missing and some errors :
-I think the "Broken/Faulty parts" segment title should also mention low-integrity parts in its title, and should also mention corrupted parts in both its title and segment, as those also don't do any.
-The "list of special stats/abilities applicable to constructs mention"
Spoiler (click to show/hide)
-There's no mention of the weapon constructs being immune to misfires (or at least, when you're not attempting to shoot something).
14
Confirmed Bugs / Re: [Beta 13, non-modal UI] Unable to label Operator (and other robots) above part
« on: April 23, 2024, 11:02:00 AM »out of view,I don't know if the bug you fixed also fixed other occurences, but as i mentioned, it also happened with allies in view.
Relevant screenshot attached.
15
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.))
16
Confirmed Bugs / Re: [B12] Branch exit might use stair tile instead of door tile
« on: April 23, 2024, 02:51:03 AM »
To clarify just in case (even if it's marked on the save files' names and wouldn't cause many issues anyway), those are save files for Beta 13.
(I'd forgotten that this topic was created mentioning Beta 12 specifically.)
(I'd forgotten that this topic was created mentioning Beta 12 specifically.)
17
Ideas / Re: Showing the depth identified exits lead to
« on: April 23, 2024, 02:47:57 AM »Recently a guide was created by some on the Discord about the scrap engine.Thanks! It isn't as informative as i hoped, but still very useful.
https://noemica.github.io/cog-minder/wiki.html#Scrap%20Engine
Scrap Engine is actually one of the most powerful items in the game when used properlyI don't doubt its power when used well (and with sensors to avoid constant fights), though i wasn't expecting the "one-shot any bot" part.(people have put together flying builds with massive integrity and weapons that can one-shot any bot in the game--any bot)
After reading the guide lyrabold linked to, i think i can see how to create those "one-shot" weapons, which i think would need to be multi-shot?
18
Fixed Bugs & Non-Bugs / Re: [Beta 13] Mouse auto-pathing goes around repaired/collapsed walls
« on: April 20, 2024, 02:29:53 AM »
Oh, that's so nice! Thank you for that change, I always disliked how autopathing moved me through collapsed tiles, especially when moving long distances.
I'm surprised i didn't notice the auto-avoidance in my first Beta 13 run. Habit of segmenting mouse movements to avoid pathing through collapsed tiles, i suppose. (I mean i did notice it, but only in the very last area, so i thought it was a special case...)
I'm surprised i didn't notice the auto-avoidance in my first Beta 13 run. Habit of segmenting mouse movements to avoid pathing through collapsed tiles, i suppose. (I mean i did notice it, but only in the very last area, so i thought it was a special case...)
19
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.
20
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.
21
Confirmed Bugs / Re: [B12] Branch exit might use stair tile instead of door tile
« on: April 19, 2024, 03:05:43 AM »
I've started a run dedicated to hunting down possible bugs, as well as trying to figure out the exact cause of this bug.
In this run, i managed to make the bug occur every single time i started the session before the area it happens in.
Attached to this post are two save files from that run and the manual save for both.
The unnamed save file starts before the setup for the bug, in -8/Materials.
The "Wastes" file is the save file closest to the bug happening, where the only thing required to witness the bug is to exit the Wastes and go to the western side of the Factory map to visually find one of the two Caves exits (they're both on that side, relatively close to each other).
I tested from that save file and from many other points; The only times the bug didn't occur was when starting the session in the post-Wastes -7/Factory. (Every time, i had previously identified the exit using access(branch).)
I know that this is a very low priority bug, but here's the savefiles anyway for whenever you want to investigate further.
If the bug somehow manages to not occur for you with those savefiles, then there's probably some difference between my Cogmind installation and yours. (I'm still playing on Linux through Proton.)
In this run, i managed to make the bug occur every single time i started the session before the area it happens in.
Attached to this post are two save files from that run and the manual save for both.
The unnamed save file starts before the setup for the bug, in -8/Materials.
The "Wastes" file is the save file closest to the bug happening, where the only thing required to witness the bug is to exit the Wastes and go to the western side of the Factory map to visually find one of the two Caves exits (they're both on that side, relatively close to each other).
I tested from that save file and from many other points; The only times the bug didn't occur was when starting the session in the post-Wastes -7/Factory. (Every time, i had previously identified the exit using access(branch).)
I know that this is a very low priority bug, but here's the savefiles anyway for whenever you want to investigate further.
If the bug somehow manages to not occur for you with those savefiles, then there's probably some difference between my Cogmind installation and yours. (I'm still playing on Linux through Proton.)
22
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.
23
Ideas / Re: Showing the depth identified exits lead to
« on: April 13, 2024, 10:17:09 AM »
Yeah, the way the Scrap Engine is just laying on the ground clearly implies that it isn't its final place in the game world.
I am never taking that gamble again, though. My first experience with it was bad enough. I didn't imagine i would skip a total of four depths to end up in -5.
I was also (and still am) unfamiliar with the Scam Engine (as you might have guesses by the surname i'm giving it), so attempting to make it work alongside with desperately trying to find any infowar went pretty horribly. I ended up getting my first Sensor Array in -3, at which point i discarded the Scam Engine to transition to flight and now the run is going much better.
I am never taking that gamble again, though. My first experience with it was bad enough. I didn't imagine i would skip a total of four depths to end up in -5.
I was also (and still am) unfamiliar with the Scam Engine (as you might have guesses by the surname i'm giving it), so attempting to make it work alongside with desperately trying to find any infowar went pretty horribly. I ended up getting my first Sensor Array in -3, at which point i discarded the Scam Engine to transition to flight and now the run is going much better.
24
Ideas / Re: No ground-to-attached-to-inventory-to-ground auto-replacement option
« on: April 13, 2024, 10:08:36 AM »Yes very specifically the Storage Unit swapping rules were actually changed for a short period during Beta 13 development to make sure that doesn't happen, but it actually lead to even more problems for players, so was switched backI am somewhat curious as to what problems this lead to.
There won't be warnings added for this particular feature, you'll have to swap manually if you don't want automated behavior, which has very few rules and is quite consistent for the very reason that it's easy to predict what will happen if you let the automated system do its thing.I do have to admit that i never actually use the auto-replacement feature to replace items from my inventory, in part because i didn't realize it existed, in part because those situations are rare compared to replacing equipped parts. As a result, swapping a part from the ground to replace an equipped item that then replaces an inventory item is something i almost never really expect.
Maybe i'm actually the only one it wouldn't bother to have the option to prevent the switching of both attached and inventory parts. If that's the case, then there is indeed not much of a reason to make that option!
25
Fixed Bugs & Non-Bugs / Re: [Beta 13] Scrap Engine weapon doesn't have newly added critical effect
« on: April 13, 2024, 09:54:03 AM »
Wouldn't it be more useful and maybe less confusing (at least for some) to show the chance of critical effect, even if useless?
As far as i understand, you can sort-of choose which parts you give the Scrap Engine to modify its stats with some intent, even if inconsistently. This means that hiding the crit chance in this scenario takes away some of the information available to the player.
A player might want to know the existing crit chance when trying to change the crit type, or in the opposite case to add some heat transfer if the chance is high enough.
As far as i understand, you can sort-of choose which parts you give the Scrap Engine to modify its stats with some intent, even if inconsistently. This means that hiding the crit chance in this scenario takes away some of the information available to the player.
A player might want to know the existing crit chance when trying to change the crit type, or in the opposite case to add some heat transfer if the chance is high enough.