A bubblegum fix would be the ability to set a skill to desired rank in the character edit menu. Not perfect (especially if you would have taken ranks after getting the exploit), but it gets the skill to the character view.In the future, I'd love to handle all of the boons that exploits can give to skills, money, carrying capacity, weight etc. I chose to keep things simple for now so I wouldn't get trapped in development limbo and never release anything. It's been in the back of my mind, but I don't want to promise anything on that yet!
Oh, definitely if you're going to work on a GUI, this is less important of an issue. Currently it is mostly an issue because the only way to see an exploit's description in the program itself is to pick the exploit and then accept or decline it.I agree in some cases. I could add a prompt afterward to let the user pick what menu to go back to. This is something that would presumably be a nonissue with a GUI. Since I'm starting to see more and more UX issues that are exacerbated by the limited text interface, I may freeze the current interface tweaks so that I can focus on getting a GUI out.
I would suggest using an exploit's internal name (IIRC, your code did not have that be the same as the exploit's display name), though that does mean you need to at some point have the program check that there are no duplicate internal names for multiple exploits. Which is quite possible with some career exploits duplicating universal exploits with different requirements.This is a good point. I can explain my train of thought here! My original idea was storing just an index of what exploit was chosen, like you suggested. I refrained, however, because I chose to sort the exploit lists by the exploit name. If new exploits were ever added to these lists, then the index might change and then cause some errors.
Talking it out with you, though, I can think of a couple of better ways to handle this and implement what you're talking about. Either I can just sort the lists visually but without associating their "choice number" with their index or I can do a different search based on exploit name. I'll chew on that one for a bit.
I'm going to disagree a bit with Morrus here. Hiding all normally unavailable choices means the program is now unable to handle house rules like having free choice of your trait.Yes, absolutely. I will admit to you that the traits portion was done at the very end. I was getting super anxious about release and was on a coding binge for far too long at that point. This is something I intended on tweaking in the future.
Then again, a GUI will probably handle this issue as well.