yv0751
This is what I mean by 'different repair material costs based on condition':
Here's what I think is the associated code from 760_sexbot_lab.rpy starting at around line 2146, if I'm understanding things correctly:
Code:
elif "repair" in _return:
$ slot = _return[1]
$ repairMatReq = {"cortex": "bio", "torso": "nano", "legs": "nano", "arms": "nano", "head": "nano" }
$ mat = repairMatReq[slot]
$ bot = GAME.lab.current
if GAME.lab.status[mat] >= 20:
queue sound "audio/install.wav"
$ bot.parts[slot].wear = 0.0
$ GAME.lab.status[mat] = max(0, GAME.lab.status[mat]-20)
else:
queue sound "audio/tech_fail.wav"
call simple_notify("CONFIGURATOR", "20% {} required.".format(mat.title()), ["Continue"]) from _call_simple_notify_35
So the $ Game.lab.status[mat] = max(0, GAME.lab.status[mat]-20) line and the if GAME.lab.status[mat] >= 20:
I'm proposing (if I'm understanding things correctly):
$x = int(bot.parts[slot].wear * 40) + 1
#this is more than 20, go with me here...
if GAME.lab.status[mat] >= x:
#do you have enough material for this repair?
(snip)
$GAME.lab.status[mat] -= x
#not sure why you need a max here, do what you think is best, the point is to deduct x from the materials total.
So the idea here is that parts with higher wear cost more to repair in materials.
The reason I went with 40 instead of 20 is because 20 is an 'average' value, i.e. a wear state of 0.99 would cost 40 materials to repair, whereas a wear state of 0.01 would cost just 1 material to repair, this is what the + 1 is for, as int rounds down.
So you'd spend an average of 20-21 materials but may spend as little as 1 material if wear is negligible, or 40 if the part barely functions.
This makes the wear states of parts a bit more meaningful, giving you incentive to sell off the really worn parts while picking and repairing the parts with less wear to build your bot. Which is how it should work I would think...
Another suggestion 'while you are here' might be to allow players to accumulate up to 200 materials instead of 100, with a pod still replenishing 100 materials each time. This would allow players to replenish before the material total reaches 0, without losing the fractional amounts... testing this now on my end.
Another idea here might be to quadruple the material requirements for cortex/bio using an 'if' statement, as the other four part categories use nano, to 'balance' the need for bio pods vs nano pods.
That's my suggestion in a nutshell. You can probably code this better than me, should you like this idea...
Edit: Here are the code snippets I used in 760_sexbot_lab.rpy to get this idea working. Note that I'm allowing over 200% storage of bio/energy/nano materials, due to the Cortex needing up to 160 materials to repair...
Code:
line 276-ish:
def charge(self,itemID):
pod = itemID[6:].lower() # strip common ID item prefix
GAME.lab.status[pod] += 100
GAME.ship.unloadWare(itemID)
return()
#only change here was = 100 to += 100
line 1721-ish:
for k in ["Bio","Energy", "Nano"]:
frame xsize 340 ysize 50 background Solid("#ffffff22"):
text "{}".format(k) size FSIZE yalign 0.5 xpos 20
text "{}".format(percentColorized(GAME.lab.status[k.lower()])) size FSIZE yalign 0.5 xpos 160 xalign 1.0
$ item = GAME.items["ITMPod{}".format(k)]
$ pods = GAME.ship.cargo.count(item)
if pods > 0:
frame xsize 120 ysize 30 xpos 200 background Solid("#0099ccff") yalign 0.5:
text "Cargo {}x".format(pods) xalign 0.5 yalign 0.5 size FSIZE_MED
button:
if GAME.lab.status[k.lower()] < 160:
action Return(["charge", item.ID])
else:
action NullAction()
#main change here was adding the 'if less than 160 check, otherwise return NullAction()
line 2150-ish:
elif "repair" in _return:
$ slot = _return[1]
$ repairMatReq = {"cortex": "bio", "torso": "nano", "legs": "nano", "arms": "nano", "head": "nano" }
$ mat = repairMatReq[slot]
$ bot = GAME.lab.current
$rmc = int(bot.parts[slot].wear * 40) + 1
if mat == "bio":
$rmc = rmc * 4
if GAME.lab.status[mat] >= rmc:
queue sound "audio/install.wav"
$ bot.parts[slot].wear = 0.0
#$ GAME.lab.status[mat] = max(0, GAME.lab.status[mat]-20)
$ GAME.lab.status[mat] -= rmc
else:
queue sound "audio/tech_fail.wav"
call simple_notify("CONFIGURATOR", "[rmc]% {} required.".format(mat.title()), ["Continue"]) from _call_simple_notify_35
#this section replaces the 20 with the variable rmc of course!
This has a bit of a downside in that you can have up to 260% of materials, but that you can't max out materials to 260 (this could be coded, but the idea here is to maximize use of pods), but the upside would be freeing up a couple of extra tons of cargo by 'overcharging' your materials over 100%. I don't think that this is a bad thing, but the 'over 100% thing' is a bit odd. You could remove the percentage by making a new definition for def percentColorized that doesn't include the '%' character, and maybe allow up to 300 points of material storage with a 'if over 300, max at 300' check with the excess material being wasted as before, but yeah.
The other option here would be to reduce the recharge from +100 to + 50, reduce the training energy cost increment from 10 to 5, reduce the 'max repair multiplier' from 40 to 20, and still set the max storage to say 100 (so essentially the same as it was before). This would mean that you'd need 80% if bio to repair a cortex at 1%, which is less than 100. Trying this on my end.
I tested this in my 0.6.0 game, it works, so it's up to you if you like this idea!
Edit 2: Here's my 'revised' code going with my 'halve the values' idea incorporated:
Code:
#first off, recharge reduced from 100% to 50% per pod, with a 'max 100%' routine added:
#line 276-ish:
def charge(self,itemID):
pod = itemID[6:].lower() # strip common ID item prefix
GAME.lab.status[pod] += 50
if GAME.lab.status[pod] > 100:
GAME.lab.status[pod] = 100
#next, this may actually not be a needed change now, essentially it just adds a NullAction if the material level is already at 100.
#line 1724-ish
for k in ["Bio","Energy", "Nano"]:
frame xsize 340 ysize 50 background Solid("#ffffff22"):
text "{}".format(k) size FSIZE yalign 0.5 xpos 20
text "{}".format(percentColorized(GAME.lab.status[k.lower()])) size FSIZE yalign 0.5 xpos 160 xalign 1.0
$ item = GAME.items["ITMPod{}".format(k)]
$ pods = GAME.ship.cargo.count(item)
if pods > 0:
frame xsize 120 ysize 30 xpos 200 background Solid("#0099ccff") yalign 0.5:
text "Cargo {}x".format(pods) xalign 0.5 yalign 0.5 size FSIZE_MED
button:
if GAME.lab.status[k.lower()] < 100:
action Return(["charge", item.ID])
else:
action NullAction()
#Next, reduce training cost from 10 energy to 5, so that double the energy can be stored for training, which will help reduce the number of times you need to mouse back and forth between the training bars and recharging the energy storage:
#line 2200-ish:
elif "train" in _return:
$ skill = _return[1]
$ bot = GAME.lab.current
if not bot.isComplete():
queue sound "audio/beep.wav"
call simple_notify("CONFIGURATOR", "Complete configuration first.", ["Continue"]) from _call_simple_notify_37
elif GAME.lab.status["energy"] >= 5:
(snip)
#and finally, the changes to the repair cost code, note that I increased the increment from 20 to 25, 'cuz I like the idea of repairing a cortex that is at 1-4% condition requiring two entire bio pods, but you could just reduce this to 20, which would put that at 80% biomass required if a cortex is at 1-4% instead of 100% biomass...
#line 2153-ish
elif "repair" in _return:
$ slot = _return[1]
$ repairMatReq = {"cortex": "bio", "torso": "nano", "legs": "nano", "arms": "nano", "head": "nano" }
$ mat = repairMatReq[slot]
$ bot = GAME.lab.current
$rmc = int(bot.parts[slot].wear * 25) + 1
if mat == "bio":
$rmc = rmc * 4
if GAME.lab.status[mat] >= rmc:
queue sound "audio/install.wav"
$ bot.parts[slot].wear = 0.0
#$ GAME.lab.status[mat] = max(0, GAME.lab.status[mat]-20)
$ GAME.lab.status[mat] -= rmc
else:
queue sound "audio/tech_fail.wav"
call simple_notify("CONFIGURATOR", "[rmc]% {} required.".format(mat.title()), ["Continue"]) from _call_simple_notify_35
Again, this is just a suggestion! Use or modify or ignore as you see fit!
