SFOverhaul - Core

Overall changes.

• Fixed Security Force Naming-Colonel and securityForceTradeShow.
• Renaming/reworking some variables and called files.
• Updating Security Force Proposal.
• Convert some story variables into temp.
• Another diplomancy option.
• Cost rebalancing.
• More toggle usage.
• Targeting report reflow.
• SubsidyActive varible is now in use.
• A new upgrade option.

changed the description

Immediately I don't like things like $GiantRobot. At least consider $secForce.giantRobot or something like that to make it descriptive as to what it is a port of.

Also shouldn't the mod variables not need to check for the mod to be active if they can only exist IF the mod is turned on? I'm not a fan of being able to enable it mid-game, but I can see reasons to allow it and I figure that's why you have the combined check.

Also merge conflicts.

I'l go make the names more descriptive.

Also shouldn't the mod variables not need to check for the mod to be active if they can only exist IF the mod is turned on?

I would rather be safer than sorry and it doesn't make sense to me that the toggle should exist but it was used in four places (options,introSummary,storyinit and once in nonRandomEvent) which personally makes it being a toggle useless as with it off the content is still present even though isn't the whole point of a toggle is to control viewing of it. I know there is good chance I am wasiting my time, is there a chance that the mod could become cannon seeing as it been made slightly more realisitic (even though the game is set in 2038). If FCDev wanted to make writing lore/content easy, why have a large disconnect between the date (24+ years) actively techonlogy (<= 10 years)?

I know merge conflicts exist however as I have said ITT "<<<<" doesn't have any hits.

git stash save * src/pregmod/SecForceEX/securityForceTradeShow.tw: needs merge src/pregmod/SecForceEX/securityForceTradeShow.tw: needs merge src/pregmod/SecForceEX/securityForceTradeShow.tw: unmerged (9b2365b00248053e227e768e8ddd188b5fa3723d) src/pregmod/SecForceEX/securityForceTradeShow.tw: unmerged (c3037fc70415e49ab243fc179de9e842391cfcf0)

I strongly discourage changing active variables as well. But little can be helped there it seems.

Also I'd prefer to not add another tier of arcology upgrade like that, if you don't mind, especially one mod locked like that.

Since I glossed over the question, that will entirely depend on what you do with it. I will still be proceeding forward as if it may not be present, though.

Also it is less the tech you get than the sheer arsenal you accumulate.

I have BC all setup to handle converting over active variables and it's probably time I nuke and start over once more.

Do I mind not that it matters at all as it isn't my repo in the end. There goes one idea I enjoyed, oh well.

What is wrong with having a large arsenal is espcially in the unlickley event FCDev continues the story?

Because it largely limits what one can do with the story. Consider just how overpowering the SF makes you become.

Simply SF.var causes a massive implosion of is undefined. If I follow the layout of ndef $arcologyUpgrade however that would make the conversion code worthless. - or _ is out of the question as well, so cammel case or such it is then.

changed the description

added 1 commit

• ac670573 - Drop upgrade.

Compare with previous version

added 18 commits

• ac670573...796d19ac - 15 commits from branch pregmodfan:pregmod-master
• ca0c1741 - Inital code
• e5c7bd94 - Drop upgrade.
• aa31ec8d - Merge branch 'SFOverhaulInitalRelease' of ssh.gitgud.io:Blank/fc-pregmod into…

Compare with previous version

marked as a Work In Progress

added 1 commit

• 1faa7e29 - SF subsidy fixes

Compare with previous version

It would be something like <<if ndef $SF>><<set $SF = {var: x, var2: y... wouldn't it?

Yes however I am not shure how it would handle some values already existing.

My money is on it either overwriting them or bugging out. Would <<set SF.push{NewVar} = OldVar>> even work?

Hopefully it would carry the existing value over without having to specify.

What would that even do? $SF isn't an array, so you can't push to it and you are mixing sets which can't possibly end well.

I'd think <<set $SF = {newVar: oldVar ...}

Math clamp decided now was the time to give me greif on "oceanic""marine" terrain the other check works as expected, just what I wanted. In better news your suggestion is working in testing.