Mod Ren'Py Onhold Space Journey - Gameplay Mod for SJ1.20.11 - Version 1.20f

[OhWee]

OK, slowly easing my way into the SJx code again. I felt the need to combine two screens...



Lots more to do mod wise, but it's a start!

 

[Bobloblaw1234]

OK, slowly easing my way into the SJx code again. I felt the need to combine two screens...

View attachment 4331086

Lots more to do mod wise, but it's a start!

Lets gooooo
Glad your working on this
Good luck

 

[OhWee]

Lets gooooo
Glad your working on this
Good luck

Yes I am! Slowly making progress!

Unfortunately there are a lot of code interactions under the hood, so it takes me a while to work out, write and test the changes I'm making...


Like this one...



The abbreviations for the ship components annoy me, hence the change, IMHO this helps ID the associated component a bit easier, Shields instead of SH as an example. The torpedo loadout slots ARE clickable, so you can order Khelara to unload/reload the specified torp slot.

I'm currently thinking that Khelara has to be in the engine room to do this (you call her over the intercom), or else you'll have to do it. Or maybe BB does it for you instead. This is mainly a dialogue thing, although I'm also pondering an option to 'skip' the dialogue after it's happened a few times. Y'all's thoughts on this would be very much appreciated!

I also sorta kinda reverted the 'buy all' button to how it worked before (with an added 5x option as well as the 10x option), and moved the 'smart buy' function over to the contracted amount row. Just click on the contracted amount (instead of the smart button which has 'reverted' to it's older functionality) to buy up as much as you can to fulfill the contract.



This gives you more buying options when you have a contracted cargo mission. Also, cargo mission amounts are now color coded (yellow/orange/green based on how much cargo you have on hand for said mission).

The other main change on this screen is that the scroll bar disappears when it's not needed (this is true for all screens), and I reduced the row heights and nudged the listing up a bit and nudged a few things around, so that more items can fit on the screen at once.

I need to tackle the base warehouse on Tenaris next. The Missions being listed at the upper right of the mission selection screen is already done on my end, it looks pretty much the same as before so no need for a new screenshot.

Back to it!

 

[OhWee]

Still slowly plugging away at stuff...

I added ship stats to the system map. You can hide/show the ship stats by clicking ship stats. I don't think the upper left corner of the info bar gets used otherwise, if so I can nudge the stats down below the bar.



Lots more to do, so back to it!

 

[OhWee]

More sort options!



Getting closer! Still a fair bit more to do though, your patience is very much appreciated!

 

[OhWee]

So, I should talk about what's taking me so long to get my mod updated...


There's been a few 'to do' things that I wanted to add the next time I tackled this mod. Specifically, one item that regularly annoys me is having to go into the captains quarters and access the computer screen to look over the list of currently contracted and potential missions.

So I added the missions icon to the upper left corner of the ship interior nav screens, like so:



Mousing over the Missions icon will show the list of currently contracted missions, and clicking on the icon will bring up the missions selection screen (similar to what happens when you access the captain's quarters computer screen). The 'gameplay logic' here is that you are accessing the missions manager via your p.d.a., but without needing to go through the 'pda icon (P) routine' simply to access the missions manager. Essentially saving you a click or two...

My goal with such things is to reduce the number of clicks required to check on stuff and possibly perform routine actions. Yes, clicking on the PDA icon, or moving to the captain's quarters to access the computer screen will access you the mission list or manager in 2-3 clicks, but this way you don't have to access a new screen just to see how many missions you currently have contracts for.

It's the same intent r.e. showing more information about the ship on the interior navigation screens (i.e. torp loadout) and on the system map, so that you don't have to keep entering (if on system map) and/or move about the ship interior screens just to check on torpedo loadouts and such.

Of course, since Ren'Py still isn't my jam, I often have to research bits of code, and go poking around under the hood to find the relevant code examples for SJx, so each change takes me a while to implement. I'm also a bit anal about aligning things, so things like squeezing in the improved parts storage sort options take me a while to work out, as I keep reloading the game (auto-reload) as I nudge the numbers and save the modifications, which I then have to check.

And of course, I need to playtest my changes, and sometimes find better ways to write the associated code routines. As an example, I already found a way to better code the Engineering System Management screen systems carousel so that the components 'scroll' in the proper order when using the 'prev/next' buttons.

And of course, yv0751 has made a number of changes and improvements to the game and under the hood since the last time I tackled this mod. There are a LOT of moving parts under the hood for SJx, and I have to modify a bunch of my mod code to conform with the latest SJx version, it's not just a 'cut and paste' affair.

So yeah, apologies for taking so long, y'alls patience is very much appreciated. Soon... give me a couple more days...

 

[yv0751]

Good idea with the mission.

On a side note: Small preview from 2.00 as it might be relevant

 

[OhWee]

Boring code talk time. yv0751 and maybe a couple others here might be interested in such things, otherwise, nothing to see here, move along!

Python is definitely NOT my jam, so I'm sure a few of you will find my migraines that manifest when trying to figure out such things amusing...


So, something was annoying me about the bot parts sorting...

Essentially, the parts grades (subpar, basic, advanced, military grade, elite) weren't sorting in order within each generation of a given part, So I probably spent waaaaay too much time today researching Python stuff, and was finally able to get things to sort within each Gen (1,2,3) by grade in ascending order. There was a 'nuance' that was preventing me to do this, until I figured out that a unique number was being attached at the end of each part ID, which was influencing the sorting...

Here's the code string I came up with:


$ GAME.lab.parts.sort(key = lambda x : (x.ID.split('-')[0], prefsort.index(x.pref), x.kind, x.price))

The prefsort.index thing references this list variable that I've added elsewhere, to determine the desired sort order:

default prefsort = ["subpar", "basic", "advanced", "military grade", "elite"]

and x.ID.split('-')[0] is the thing that splits the part ID string at the point that the unique index number is added (i.e. ignores everything at/after the dash in the x.ID string).

The end result is this:



Hopefully this saves everyone a tiny bit of time when reviewing the parts list. This sort routine code thingie is also being added to the 'add part to bot' parts list, so that you don't have to keep scrolling up and down to find say the Gen 2 Mil Grade parts while keeping the other grades in the 'sorted list'... Yes, you could just 'uncheck everything but the 'Mil Grade' sort options, the point here is that I personally would prefer to have the full list presorted by grade within each gen to begin with...

Back to it!

 

[sweetit]

Boring code talk time. yv0751 and maybe a couple others here might be interested in such things, otherwise, nothing to see here, move along!

Python is definitely NOT my jam, so I'm sure a few of you will find my migraines that manifest when trying to figure out such things amusing...


So, something was annoying me about the bot parts sorting...

Essentially, the parts grades (subpar, basic, advanced, military grade, elite) weren't sorting in order within each generation of a given part, So I probably spent waaaaay too much time today researching Python stuff, and was finally able to get things to sort within each Gen (1,2,3) by grade in ascending order. There was a 'nuance' that was preventing me to do this, until I figured out that a unique number was being attached at the end of each part ID, which was influencing the sorting...

Here's the code string I came up with:


$ GAME.lab.parts.sort(key = lambda x : (x.ID.split('-')[0], prefsort.index(x.pref), x.kind, x.price))

The prefsort.index thing references this list variable that I've added elsewhere, to determine the desired sort order:

default prefsort = ["subpar", "basic", "advanced", "military grade", "elite"]

and x.ID.split('-')[0] is the thing that splits the part ID string at the point that the unique index number is added (i.e. ignores everything at/after the dash in the x.ID string).

The end result is this:

View attachment 4349537

Hopefully this saves everyone a tiny bit of time when reviewing the parts list. This sort routine code thingie is also being added to the 'add part to bot' parts list, so that you don't have to keep scrolling up and down to find say the Gen 2 Mil Grade parts while keeping the other grades in the 'sorted list'... Yes, you could just 'uncheck everything but the 'Mil Grade' sort options, the point here is that I personally would prefer to have the full list presorted by grade within each gen to begin with...

Back to it!

next game you 2 should collab you both seem to work together quite well

 

[yv0751]

Boring code talk time. yv0751 and maybe a couple others here might be interested in such things, otherwise, nothing to see here, move along!

Python is definitely NOT my jam, so I'm sure a few of you will find my migraines that manifest when trying to figure out such things amusing...


So, something was annoying me about the bot parts sorting...

Essentially, the parts grades (subpar, basic, advanced, military grade, elite) weren't sorting in order within each generation of a given part, So I probably spent waaaaay too much time today researching Python stuff, and was finally able to get things to sort within each Gen (1,2,3) by grade in ascending order. There was a 'nuance' that was preventing me to do this, until I figured out that a unique number was being attached at the end of each part ID, which was influencing the sorting...

Here's the code string I came up with:


$ GAME.lab.parts.sort(key = lambda x : (x.ID.split('-')[0], prefsort.index(x.pref), x.kind, x.price))

The prefsort.index thing references this list variable that I've added elsewhere, to determine the desired sort order:

default prefsort = ["subpar", "basic", "advanced", "military grade", "elite"]

and x.ID.split('-')[0] is the thing that splits the part ID string at the point that the unique index number is added (i.e. ignores everything at/after the dash in the x.ID string).

The end result is this:

View attachment 4349537

Hopefully this saves everyone a tiny bit of time when reviewing the parts list. This sort routine code thingie is also being added to the 'add part to bot' parts list, so that you don't have to keep scrolling up and down to find say the Gen 2 Mil Grade parts while keeping the other grades in the 'sorted list'... Yes, you could just 'uncheck everything but the 'Mil Grade' sort options, the point here is that I personally would prefer to have the full list presorted by grade within each gen to begin with...

Back to it!

List is definitely more informative...

My syntax OCD kicks in here: Using a tuple is the certainly the right way for a hierarchical sorting. Would have used x.attr['BaseID'] instead of the splitting orgy though...
And I am still cursing that when I devised the whole unique instances scheme I didn't add a baseID attribute to the Parts Object...

 

[OhWee]

List is definitely more informative...

My syntax OCD kicks in here: Using a tuple is the certainly the right way for a hierarchical sorting. Would have used x.attr['BaseID'] instead of the splitting orgy though...
And I am still cursing that when I devised the whole unique instances scheme I didn't add a baseID attribute to the Parts Object...

The other thing that is kind of frustrating for me atm is the fact that sorting the IDs alphabetically, well I'd rather sort per the order that I have the added sort options (Anal, Bondage, Oral, Special, Vaginal, Perversion, IQ, Immobilizer). My reasoning here is that the first five are 'alphabetically ordered' and affect only one attribute, Perversion Amps affect all five attributes. IQ is less useful IMHO, and is the last module type that I consider currently. Immobilizers last, to round out the sort routine/list/easy to spot in the sort options buttons if at the end

I also did the 'alphabetical ordered' thing for the QC button in my mod, and in a couple of other places. As for adding a 'Base ID' attribute, I suppose that could be appended to the parts declaration, with a 'if BaseID not present, append'. I did something similar to earlier versions of my mod, I'd have to go back and dig to see what syntax I used. My goal is always save compatibility, which now seems to be part of your mission statement as well (finally...).


It might be more useful to 'force' a sort order' using one of the existing fields. Something I don't quite understand is what the 'A' is for...

["SBPAddOnPER3", "Perversion Amp", "A", "sexbot addons", "addon", 3 , "A module, which improves all of a bot's talents", 10000, [],{"LVL": 8}], # CR-0543

It looks like all parts have the "A" regardless of type, so I'm not understanding it's purpose. If it otherwise has none, it'd be easy enough to write a check routine that replaces it with some sort of heirarchal descriptor instead that lends itself to an alphabetical sort if used, say:

A Cortex
AP Precursor Cortex #(maybe, just sorting by cortex grade is enough for me, as precursor is already included in the description text listing if present)
B Head
C Torso
D Arms
E Legs
F Shell
G Anal Module
H Bondage Module
I Special Module
J Vaginal Module
K Perversion Module
L IQ Module
M Immobilizer Module
N Cube Attitude
O Cube Personality
P Cube Traits


If you wanted to get more fancy, you could do this (and eliminate the need for a separate .cat sort)
A1 Cortex Gen 1
A2 Cortex Gen 2
A3 Cortex Gen 3
B1 Head Gen 1

and so on and so on. The main idea here is to repurpose the 'A' slot to set up a heirarchal sort order that spits out the desired sort order with a simple sort.


My reasoning for the above listing including the name descriptor, is mainly so that you know what each letter is assigned to without having to reference a separate list somewhere else to figure out, say what L1 references, and also so that you can do a:
if "A" and i.ID contains Cortex1, replace "A" with "A1 Cortex
check when a specific pre-existing part is referenced, with the proper syntax of course! 'Cuz existing save compatability and all that...

This COULD be accomplished via a label after_load, so that the GAME.lab.parts find/replace if needed check is just done once - i.e when a save is loaded. New games would already reference the new and improved partsdata[] with the new sort field data already included.


I don't think I'd put grade in this (A3 Cortex Gen 3), as there's another way to sort by grade (as I detailed in my last post, the prefsort.index thing), and the grade sort should be secondary to the main heirarchal sort in any case.

Anyways, yeah just a random thought, I have no idea what the 'A' is for so it seems like an interesting opportunity...

Or, as I noted, you could just append a new value to the SexbotPart() Class using a length check of some sort, that references a new list... as I noted I was adding a new attribute to the sexbot parts in a previous version of my mod, so I know that this is possible... it's better to do this at the start of course, but there are a LOT of saves out there with the current parts list, and it'd be better to just add a new attribute at the end, if not replacing the "A"...

I remember now, it was how I was adding the sixth slot for shells. You've since made the 'shell' slot part of vanilla SJx, but yeah that'd be a way to go about it. I think having a 'replace A with new value' check would be cleaner though.

Just thinking out loud here...

 

[yv0751]

The other thing that is kind of frustrating for me atm is the fact that sorting the IDs alphabetically, well I'd rather sort per the order that I have the added sort options (Anal, Bondage, Oral, Special, Vaginal, Perversion, IQ, Immobilizer). My reasoning here is that the first five are 'alphabetically ordered' and affect only one attribute, Perversion Amps affect all five attributes. IQ is less useful IMHO, and is the last module type that I consider currently. Immobilizers last, to round out the sort routine/list/easy to spot in the sort options buttons if at the end

I also did the 'alphabetical ordered' thing for the QC button in my mod, and in a couple of other places. As for adding a 'Base ID' attribute, I suppose that could be appended to the parts declaration, with a 'if BaseID not present, append'. I did something similar to earlier versions of my mod, I'd have to go back and dig to see what syntax I used. My goal is always save compatibility, which now seems to be part of your mission statement as well (finally...).


It might be more useful to 'force' a sort order' using one of the existing fields. Something I don't quite understand is what the 'A' is for...

["SBPAddOnPER3", "Perversion Amp", "A", "sexbot addons", "addon", 3 , "A module, which improves all of a bot's talents", 10000, [],{"LVL": 8}], # CR-0543

It looks like all parts have the "A" regardless of type, so I'm not understanding it's purpose. If it otherwise has none, it'd be easy enough to write a check routine that replaces it with some sort of heirarchal descriptor instead that lends itself to an alphabetical sort if used, say:

A Cortex
AP Precursor Cortex #(maybe, just sorting by cortex grade is enough for me, as precursor is already included in the description text listing if present)
B Head
C Torso
D Arms
E Legs
F Shell
G Anal Module
H Bondage Module
I Special Module
J Vaginal Module
K Perversion Module
L IQ Module
M Immobilizer Module
N Cube Attitude
O Cube Personality
P Cube Traits


If you wanted to get more fancy, you could do this (and eliminate the need for a separate .cat sort)
A1 Cortex Gen 1
A2 Cortex Gen 2
A3 Cortex Gen 3
B1 Head Gen 1

and so on and so on. The main idea here is to repurpose the 'A' slot to set up a heirarchal sort order that spits out the desired sort order with a simple sort.


My reasoning for the above listing including the name descriptor, is mainly so that you know what each letter is assigned to without having to reference a separate list somewhere else to figure out say what L1 references, and also so that you can do a:
if "A" and i.ID contains Cortex1, replace "A" with "A1 Cortex
check when a specific pre-existing part is referenced, with the proper syntax of course! 'Cuz existing save compatability and all that...

This COULD be accomplished via a label after_load, so that the GAME.lab.parts find/replace if needed check is just done once - i.e when a save is loaded. New games would already reference the new and improved partsdata[] with the new sort field data already included.


I don't think I'd put grade in this (A3 Cortex Gen 3), as there's another way to sort by grade (as I detailed in my last post, the prefsort.index thing), and the grade sort should be secondary to the main heirarchal sort in any case.

Anyways, yeah just a random thought, I have no idea what the 'A' is for so it seems like an interesting opportunity...

Or, as I noted, you could just append a new value to the SexbotPart() Class using a length check of some sort, that references a new list... as I noted I was adding a new attribute to the sexbot parts in a previous version of my mod, so I know that this is possible... it's better to do this at the start of course, but there are a LOT of saves out there with the current parts list, and it'd be better to just add a new attribute at the end.

I remember now, it was how I was adding the sixth slot for shells. You've since made the 'shell' slot part of vanilla SJx, but yeah that'd be a way to go about it. I think having a 'replace A with new value' check would be cleaner though.

Just thinking out loud here...

Let me solve the mystery: a neutron cannon, an area of effect module

 

[OhWee]

Let me solve the mystery: a neutron cannon, an area of effect module

If that is the case, it might not make a lot of sense for say an Attitude cube to have a Neutron Cannon...

And, since said devices haven't been introduced yet, incorporating these into my idea is rather easy:
WN1 Neutron Cannon Gen 1
XM1 Area Affect Module Gen 1

if whatever variable that references the "A" position (i'm guessing art(?) based on the partdata order) contains "W" then it's a weapon... Otherwise just append a new value as I noted...

 

[yv0751]

If that is the case, it might not make a lot of sense for say an Attitude cube to have a Neutron Cannon...

And, since said devices haven't been introduced yet, incorporating these into my idea is rather easy:
WN1 Neutron Cannon Gen 1
XM1 Area Affect Module Gen 1

if whatever variable that references the "A" position (i'm guessing art(?) based on the partdata order) contains "W" then it's a weapon... Otherwise just append a new value as I noted...

Yes, tags that can be used as easy sorting keys would make sense assuming sort order should not be flexible.

for use in sorting lambda tuples I added stuff like "kind" "cat", "pref", ...

So its a matter of philosophy. The latter can be mapped to the former though its a bit more effort.

 

[OhWee]

Yes, tags that can be used as easy sorting keys would make sense assuming sort order should not be flexible.

for use in sorting lambda tuples I added stuff like "kind" "cat", "pref", ...

So its a matter of philosophy. The latter can be mapped to the former though its a bit more effort.

The tuples are definitely useful and said fields are also being used in other contexts say if cat 3 then higher IQ boost value. I'm just looking at ways that don't require a rewrite of a bunch of partsdata, say IDs, in order to accomodate an alphabetical sort in a more 'make sense' order. The "A" field seems like an opportunity... or as I said, a new field could be appended...

I'm just cautious about appending values because of Multiverse pods.

Still thinking out loud here...

 

[OhWee]

yv0751

I was able to accomplish the sort order I wanted without altering the i.art fields

default basesort = [
            "SBPCortex1", "SBPCortex2", "SBPCortex3", "SBPCortexPre",
            "SBPHead1", "SBPHead2", "SBPHead3",
            "SBPTorso1","SBPTorso2", "SBPTorso3",
            "SBPArms1", "SBPArms2", "SBPArms3",
            "SBPLegs1", "SBPLegs2", "SBPLegs3",
            "SBPShell1TypeC", "SBPShell2TypeC", "SBPShell3TypeC",
            "SBPShell1TypeG", "SBPShell2TypeG", "SBPShell3TypeG",
            "SBPShell1TypeI", "SBPShell2TypeI", "SBPShell3TypeI",
            "SBPShell1TypeJ", "SBPShell2TypeJ", "SBPShell3TypeJ",
            "SBPShell1TypeK", "SBPShell2TypeK", "SBPShell3TypeK",
            "SBPShell1TypeL", "SBPShell2TypeL", "SBPShell3TypeL",
            "SBPShell1TypeN", "SBPShell2TypeN", "SBPShell3TypeN",
            "SBPShell1TypeP", "SBPShell2TypeP", "SBPShell3TypeP",
            "SBPShell1TypeV", "SBPShell2TypeV", "SBPShell3TypeV",
            "SBPCubeAttitude", "SBPCubePersonality", "SBPCubeTraits",
            "SBPAddOnSkillANA", "SBPAddOnSkillANA2", "SBPAddOnSkillANA3",
            "SBPAddOnSkillBON", "SBPAddOnSkillBON2", "SBPAddOnSkillBON3",
            "SBPAddOnSkillORA", "SBPAddOnSkillORA2", "SBPAddOnSkillORA3",
            "SBPAddOnSkillSPE", "SBPAddOnSkillSPE2", "SBPAddOnSkillSPE3",
            "SBPAddOnSkillVAG", "SBPAddOnSkillVAG2", "SBPAddOnSkillVAG3",
            "SBPAddOnPER", "SBPAddOnPER2", "SBPAddOnPER3",
            "SBPAddOnIQ", "SBPAddOnIQ2", "SBPAddOnIQ3",
            "SBPAddOnImmo", "SBPAddOnImmo2", "SBPAddOnImmo3"
            ]


default prefsort = ["subpar", "basic", "advanced", "military grade", "elite"]

along with:

$ GAME.lab.parts.sort(key = lambda x : (basesort.index(x.ID.split('-')[0]), prefsort.index(x.pref), x.kind, x.price))

x.kind and x.price probably aren't needed here actually, but it's in the original code hence why they are still here.

This way the partsdata[] list doesn't need any modification. I know that this aspect is extremely minor in the grand scheme of things, but then that's why my mod exists. I.E. to make minor adjustments here and there to improve the gameplay experience!

Back to it!

 

[Bobloblaw1234]

I would not think a porn game would be so complicated lol
Thanks for all your hard work.

 

[OhWee]

Getting close...

So, a few things. First off, I made a few minor tweaks to the Bot Config screen again:



I'm not a fan of covering yv0751's cool looking icons with text, so I moved the Grade text out of the part boxes. As for cat/gen, well the backgrounds are already color coded: blue fade for Gen 1, Green for Gen 2 and Orange for Gen 3, so once you realize this, yeah having text for part gen is kind of redundant...

Note that I re-added the modifiers for Add-On Modules. The modules are all pretty much the same shape, so I can get away with sneaking the numbers inside of the add on boxes while only barely overlaying the cool icons. These icons do not come with background fades, but it's easy enough to overlay the icons on top of the 'Gen' color fades, as you see above.

I also moved the bio/energy/nano icons to the second row in the upper right, to put them next to the associated bars, and tweaked the Hyper-Train On text (you'll now see how many 'boosts' you have left when hyper training).

Note: I've modified the routine for this slightly (half the hyper train bonus, but double the number of 'boosts), and also did my 'store 400% bio/nano/energy instead of just 100% thing under the hood, 'cuz I think it makes things more interesting r.e. the bio/enery/nano pod economy...

One thing I'm pondering atm is this. Here's a screenshot of this screen from the previous versions of my mod:

Essentially the grade text next to the boxes was color coded (green if higher grade part available) and the ! and arrow icons indicated if higher gen parts were available. It's a bit more complicated than that, and SJx 1.50.11 has an upgrade up arrow icon now to increase part gen if you have the necessary nano pods and spools if gen 2>3.

Anyways, I don't know how many people liked having the 'part availability' icons, so yeah atm I'm pondering if I should add them in again or not.

I also added more sort options to the Parts Inventory screen (renamed this to eliminate confusion with the other Parts Storage manager screen):



I debated creating modified sort options for the cubes. They are all Gen 3 to begin with, so I could replace Gen buttons with Cube Type buttons in the sort options. But there aren't that many cubes to begin with. It's easy enough to do, just wondering if anyone wants this.

One other thing. I previously added this screen to the Sexbot Arcade tab via an 'Analyzer' button:

I think it looks cooler, so this time around, I'm planning to give the 'Bot Manager' and 'Sexbot Arcade' screens two modes. The first mode is what you see ingame now, and the second mode will use the above layout with minor tweaks - i.e. buttons for 'Send to Arcade' and 'Pack for Sale' when viewing the Bot Manager screen. Basically, I think this looks a lot prettier than just a bunch of text, and it shows off the awesome Sexbots in their full glory, not just via a tiny icon...

My thought here is that there will be a 'Screen Mode' button just above the 'Exit (X)' button, which will display the player's preferred mode. If you like the text list better, choose that mode and that mode will remain until such time as you decide to switch modes, same if you like the above layout more instead. And of course you'll be able switch back and forth via the added 'screen mode' button whenever you are viewing said screens.

The Income Bonus thing I'll probably re-implement, as it's easy enough to do (code is already worked out). The idea here is that if you mix up your personality types and shell types in the Sexbot Arcade, you get income bonuses, which gives you incentive to 'collect them all' r.e. shells for the Sexbot Arcade.

Anyways, yeah that's where I'm at right now. Most of the other screens are done, just need to tweak a couple more screens and this should be ready for prime time. I was hoping to have things ready by yesterday, but I need to take the time to do things right, and I can only stand staring at code for so long before I need to switch gears and come back to it later...

Back to it!

 

[G'Kar]

Thank you for your work!
QoL-features make the difference between a good game and a great game.

As the " 'part availability' icons " are concerned:
Since you managed to work out the sorting of the components, it should be easy and quick to determine if there is a better part available. In this case, I personally would not need the extra info.
It may also give the player a feeling that the bot is "unfinished" when on the other side an explicit decision by the player for a specific part was already made.

But you have a good sense for what seems to be useful and what not.
I'll be waiting for your mod to finish to give the new update a try,
Godspeed

 

[OhWee]

Another day, another rabbit hole...

So, for some reason, in my current test build I haven't trained Nimhe enough to give her stuff, so I ran into an issue where I could select "Build Exotic Shell" without actually have given Nimhe any exotic shells... so of course later in the day I receive the popup message "Nimhe can't build any Exotic shells"...

This is just asinine IMHO, and it's also annoying when the game gives you the option to build a shell only to find out you don't have enough of the associated bot crates in storage...

So, after a few hours of searching through Python code using google searches, and then modifying said code by trial and error a few times, I accomplished this:



Note that the Craft Exotic Shell option is no longer appearing 'cuz Nimhe hasn't been given any of those, and that the Craft Simple Shell option is now in red with a footnote, 'cuz I didn't have enough Bot Crates in storage...

The red text is no longer clickable so you won't be able to assign that option, which is why the 'requires 3 bot crates' footnote is there.

Anyways, yeah since you can't check on your crate inventory once you enter this screen, yeah I felt the need to do this.

So yeah, time to get back to coding stuff...