Thanks for these!
In the manual, this is what is says about having a hack fully traced back:
* Feedback: Once traced, the system is permanently locked and may attempt to counterattack the source of the unauthorized access, which either causes system corruption or disables connected hackware.
By now, I've been fully traced back dozens of times, but I've never experienced any negative effects aside from the terminal permanently locking itself out - I've never had hackware disabled or gained system corruption. (which is why I let myself get fully traced so much!)
Perhaps you've just been lucky. The chance of feedback is not too high, especially on low-security machines. However, I just tested it real quick on a high-security terminal and got corrupted on my first trace
(which is why I let myself get fully traced so much!)
There are drawbacks other than just feedback, by the way
Also, an unrelated question/possible bug: in the score sheet, it lists all the corruption effects and how many times you experienced each effect. Below Data Loss (map) is one I've never seen - Data Loss (database) - but according to the score sheet I experienced it dozens of times. What does that effect do, and is it not supposed to show up in the log? Is it bugged?
It isn't differentiated in the log messages--both map and database info losses are called the same thing--but you're right! I was getting curious why I wasn't seeing that effect in my own longer runs... and perhaps I didn't explore it because the effect can be
really annoying
Apparently I broke this back before even releasing Alpha 1! It used to work in the 7DRL, but during some later refactoring I forgot to add the line that makes the change to your database :/ (the other two dozen lines that calculate the loss are just fine
)
Anyway, I fixed it now, and also tuned down its effect a good bit. Still, prepare to be annoyed.
Lastly, a very small thing: in the score sheet it shows me that I had a Guided Micro-Nuke Launcher in my inventory, and it appears in the list of my identified prototypes - but in the game, I never identified the part, all I knew was that it was a prototype launcher. (now I'm a bit bummed I didn't risk attaching it =P )
Very good catch! As with most roguelikes, Cogmind identifies any unknown contents of your inventory at the end of a run, but apparently because the inventory list is reported before the prototypes list, the latter assumes you identified it because the code to list your inventory automatically identifies everything for you. Oops. Fixed it for the next release, thanks.
Also, I always identify launchers ASAP because they have a chance of being super awesome
EDIT: Ok, just one more: not a bug I think, but why does the Misfire corruption effect put all your other weapons offline? It just seems like busy-work because your next move is to turn them all on again.
This is due to how firing is implemented internally. The player firing system was designed (a very long ago) completely based on the parts UI status, and there was no easy workaround, so I partially faked the effect by forcing player input, which required deactivating non-firing weapons to make sure all other systems interpret the volley correctly.
Misfires ended up being a surprisingly long and involved piece of code, so I didn't go the extra mile on that one, but a solution here is to remember which weapons were active before the misfire and (if they still exist), reactivate them once it's complete. I'll look into it.