Corp to object

This MR attempts to add support for the corporation by moving it's variables into a single object, $corp, and thus shielding it from the BC. This will allow it to leave pieces unset if doing so is needed for proper function.

A couple of problems at the moment, but a main one is a recursion error in App.Update.cleanUp(), likely findNaN(). No idea what's causing it, but working on that now.

Secondarily TypeError: App.Corporate.Backcompat is not a function and setUpvars.tw runs before I can set $corp = {}, but I'm hoping a second bc will clear it once the recursion issue is solved.

edit: found the recursion, lol.

added 1 commit

• 0b9bfab0 - fix recursion

Compare with previous version

Full stop.

I am getting nonstop error reports over slaveInteract. Practically everything is not working properly and I'm out of patience.

We may have to consider rolling back to the SC version, unless we can link the problems to the addition of the tab system, which may be the case. Either way, things are at the point where a revert must be considered.

Respectfully, the problem this MR is trying to solve cause permanent data loss when BC is run, and thus seem much more serious to me than the slaveInteract problems (which, while annoying, just mean you have to repeat your action later).

Stuck between a rock and a hard place to say the least. Some things are just flat out not working out of slaveInteract, instead of the prior failure to stick problems.

@lowercasedonkey

Very well, carry on. Though the slaveInteract issues must be sorted out ASAP.

Working on it. This is almost done, I just can't figure out why Backcompat disappears from App.Corporate.

I can see it on master in console, but not this mr and so an error is thrown.

Help?

App.Corporate.Backcompat is created by App.Corporate.Init, so setupVars needs to run (successfully) first.

Just found that as well, I'm just going to set corp there if it's ndef. Ready for merge, if no objections.

I don't really like the corp.specX stuff, wouldn't corp.spec.X flow better?

That is absolutely true and I 11000000% wish it was designed that way, but I'd rather just get this out the door before more data is lost.

I'd put the $corp init code into App.Corporate.Init instead of setupVars.tw.

How do I do that with this and classes. I agree in principle I just have no idea where to stuff the damn thing.

App.Corporate.Init isn't in a class, it's just a normal function. Just scroll down a ways until you're past the ledger and the rest of it. Look for the call to App.Corporate.InitConstants...at that point you can just stick a if (!V.corp) { V.corp = {}; } or similar in.

I think it just needs to be done before the property loop (around line 480). If it needs to be done before the divisions are initialized, just move it up before App.Corporate.Init_DivisionBase.

Seems to work fine in App.Corporate.InitConstants

It's not a constant either. Keep it in .Init(), just around that area.

Like so?

Yes, exactly. Thanks. Sorry to be so picky.

Good to merge?

Where is the code that actually performs the BC (moving from $corpX to $corp.X)? I might just be blind but I don't see that anywhere.

Ah, nope, I see it. Just me being blind. Looks good to me.

And no not picky, your calls made sense to me. Just needed to get it right. Thanks so much for the help.

added 1 commit

• 5147b715 - got it

Compare with previous version

unmarked as a Work In Progress

added 1 commit

• 7a1dbd4f - move corp init

Compare with previous version

added 1 commit

• 51914550 - move again

Compare with previous version

mentioned in commit c9abbc42

merged