TODO tweaking
Continuation of #1115 (closed)
@Pregmodder I am aware of the memory reason, I meant it more in the case of user visible text as it currently stands.
I'll need to review randomNonindividualEvent myself.
I have a few quick changes that might be of use (mainly switching over to switch and removing duplicate conditions)
Activity
I'll put my idea's on hold. Personally lines 233 - 284, have a few minor annoyances (mainly the if/else chain and the three nearly identical
<<if (($slaves[$i].anus > 0 && canDoAnal($slaves[$i])) || ($slaves[$i].vagina > 0 && canDoVaginal($slaves[$i])) && $slaves[$i].belly < 30000)>>.-
<<elseif ($slaves[$i].fetish == "submissive")>> <<if ($subID == 0)>> <<if (($slaves[$i].anus > 0 && canDoAnal($slaves[$i])) || ($slaves[$i].vagina > 0 && canDoVaginal($slaves[$i])) && $slaves[$i].belly < 30000)>> <<set $subID = $slaves[$i].ID>> <</if>> <</if>> <<elseif ($slaves[$i].fetish == "humiliation")>> <<if (($slaves[$i].anus > 0 && canDoAnal($slaves[$i])) || ($slaves[$i].vagina > 0 && canDoVaginal($slaves[$i])) && $slaves[$i].belly < 30000)>> <<if ($humiliationID == 0)>> <<set $humiliationID = $slaves[$i].ID>> <</if>> <</if>> ..... <<elseif ($slaves[$i].fetish == "masochist")>> <<if ($masochistID == 0)>> <<if ($slaves[$i].anus > 0 && canDoAnal($slaves[$i])) || ($slaves[$i].vagina > 0 && canDoVaginal($slaves[$i]))>> <<set $masochistID = $slaves[$i].ID>> <</if>>Some screen shots of (none final) changes I have currently made to slaveStats:
Edited by Blank_Alt -
@Pregmodder
I have made further changes, how do you want to see them?
Here is the branch https://gitgud.io/Blank/fc-pregmod/tree/TODO-tweaking
Would it be worth while grouping lose slave object varaibles into their own objects?Edited by Blank_Alt -
One freeshly baked MR: !5409 (merged)
Do not mess with the slave object.
Jus to be absoutely clear is that a never or wait untill a few months after the last change and only work on a few varaibles at a time? Modifing the player object is likely to provide the same issues (mainly a loaded save is unable to reach BC and thus is likely to cause issues untill it can be reached). If it was possbily to provide a means to add functions to be called while loading that could be very useful.
-
My are to only re-organise so the chance of a logical conflict should ideally be quite low. Also of the open MR's that seem to modify the slave object (so !5337 (merged), !4904, !4701 (closed), !4574, !4409, !4363 (closed) (which is as I understand it already merged in pregmod-master over time as a several sub MR's), !3897, !3329 and !340.
All of them have been out of sync/touched for three weeks to a year and unforunately some of the modders have become MIA (Missing In Action).
Given the above I don't see any reason why not, however if my idea does occour it will only happen after completion of both current projects. Now, speaking of !4574 I would not be opposed to someone cleaning things up so that I may consider manually merging.
-
@Pregmodder
Ready for review. It appears thatactiveSlave.deathis not located anywhere but in SlaveStats.tw,$activeSlave.cumis N/A on my save and running BC does not fix it.I'd still rather to manage it personally at that point.
Fair enough, however some times one has to deligate the small tasks rather than attempt to do everything by oneself, converting them over can probably be considered a small task because it can be for the most part be easily done via a editor that supports directory wide find and replace.
For what little it is worth I might a well dump at least some of my ideas:
activeSlave.lactation->activeSlave.lactation.activeactiveSlave.lactationDuration->activeSlave.lactation.durationactiveSlave.induceLactation- >activeSlave.lactation.inducedactiveSlave.lactationAdaptation->activeSlave.lactation.adaptationactiveSlave.lactationRules- >activeSlave.lactation.rulesactiveSlave.currentRules->activeSlave.rules.currentactiveSlave.livingRules->activeSlave.rules.livingactiveSlave.speechRules->activeSlave.rules.speechactiveSlave.releaseRules->activeSlave.rules.releaseactiveSlave.actualAge->activeSlave.age.actualactiveSlave.visualAge->activeSlave.age.visualactiveSlave.physicalAge->activeSlave.age.physicalactiveSlave.ageAdjust->activeSlave.age.adjustactiveSlave.pubertyAgeXX->activeSlave.age.pubertyXXactiveSlave.pubertyAgeXY->activeSlave.age.pubertyXYactiveSlave.pornFeed->activeSlave.porn.feedactiveSlave.pornFame->activeSlave.porn.fameactiveSlave.pornFameSpending->activeSlave.porn.fameSpendingactiveSlave.pornPrestige->activeSlave.porn.prestigeactiveSlave.pornPrestigeDesc->activeSlave.porn.prestigeDescactiveSlave.*Implant->activeSlave.implant.*activeSlave.*Piercing->activeSlave.piercing.*activeSlave.*Tat->activeSlave.tattoo.* -
.cum may be intended to be .cumTotal?
.cumTotal does not seem to exist in the current slave object
counter.cumseems to be the desired variable.
Is there a limit of what type varaibles to display? There are several null/not null varaibles and the current version does not seem to contain several variables such as abortion tats or custom.image.Also once a slave is dead would it not make sense to reduce their object down to the smallest possible? E.g. name, cause of death, relationships.
Edited by Blank_Alt -
@Pregmodder I have gone through and cleaned out most of the flags already present while also updating the changelog since the 2.9.0 tag.
Edited by Blank_Alt
mentioned in merge request !5409 (merged)
activeSlave.*Piercing->activeSlave.piercing.*
activeSlave.*Tat->activeSlave.tattoo.*Please hold off on this as I would like to migrate piercings and tattoos to their respective body part objects where possible. Or do it yourself if you're feeling fancy. Basically the goal is to use the same system that brands and scars use now.
Edited by lowercasedonkeyPlease don't encourage him to do it. I'm trying to avoid another secExp variable system disaster.
Speaking of which, how is that coming along anyway?
-
@lowercasedonkey I'll stay clear of those sections.
I'm trying to avoid another secExp variable system disaster.
Fair enough and hense why I've said if it happens that it will only be after everything else thus far.
I know this is very likely hard to belive, however I have learnt from that (mainly proper planning upfront is critical and that there it is possible to split a task into too small chunks).
I've also done a lot more dog fooding than before.Speaking of which, how is that coming along anyway?
Good thanks, finised inital conversion and I only need to; fix
secExp.js's indenation that got meesed up due to an IDE (which on longer exists on my system and only a very small part of it was really useful) and chosen options, merge-in the current HEAD, add a mod changelog and a cleaner update check on main then do yet more dog fooding before releasing an RC to the thread. -
I don't know what dog fooding means.
It is really just a "fancy" say of saying, "I am/my businesses is the first to use our product/service before it is released to a wider audience".
Any luck with getting the old account back?
Not yet. After the inital bursts of communication, it has been around 23 days since the last email.
The main issue I have is that the sign up email is set as the login/password reset email and making an other email your primary one via the account GUI (mainly the Main and Emails tabs) does not change this.
In my case the inital email was via fake email generator or a similar service if memory serves, which effectively means it does not exist anymore and it all went well unitll the first forced pasword reset which was resloved very quickly (this current lock out is becuase I used the gitgud rather than the saphire password reset page, just a heads up so you don't have the same fate).
closed via merge request !5409 (merged)
mentioned in commit 0c5bf1d3
mentioned in issue #1138 (closed)
