[1.1.2] B.R.O.K.E. - Beta 4 - 05/26/2016 - Now with gameplay!

[jkortech]

I wasn't even aware loans were implemented yet (I haven't worked on that code at all), nor am I aware of how to even take out a loan. That doesn't sound intentional though, so hopefully jkortech sees this and can confirm. Consider loans to be very WIP at the moment.

There is no UI for loans. Any way of issuing loans is by creating a plugin that interfaces with BROKE and creating a loan or reverse-engineering our use of the ConfigNode format for it to create one. There are some places where I don't do sanity checks, but I'll take a look.

I believe loans are being handled as normal Invoices, in which case you don't pay them off separately. Negative numbers in the payment field currently are implemented as "Pay the maximum possible". We should add the option to pay off some of the remaining balance on a loan above and beyond the required payment, so I'll make sure that's included somewhere. Loans will likely have their own GUI in addition to the main BROKE GUI.

One change I put in slightly changed this behavior and broke it a little. By entering a negative amount, you are able to withdraw revenue and not have it automatically go into expenses. It isn't documented, and I may have left out a logic check in there that enables this problem. I'll go fix that one quickly as well.

Edit: These issues (not the lack of loan UI, but the logic bugs) have been fixed!

Edited October 22, 2015 by jkortech

[theonegalen]

Has anyone tested this with 1.0.5 yet? Should I do that or do you have an update coming, magico?

[magico13]

[quote name='theonegalen']Has anyone tested this with 1.0.5 yet? Should I do that or do you have an update coming, magico?[/QUOTE]

Sorry, progress hasn't happened much lately so no new updates as of yet. I briefly tested a recompiled version against 1.0.5 and it was fine (in fact, nothing needed fixed), but I had issues with my other mods when using the old ones. If you test it out and notice any issues let me know (log not necessary) and I'll get a recompiled update out.

[JeffreyCor]

Tested in 1.0.5 as well, no errors found.

[theonegalen]

It appears to be working in my game as well.

[theonegalen]

Continuing to play with BROKE, it seems the most difficult part is going to be balancing contract rewards, government funding, and salaries.

[magico13]

50 minutes ago, theonegalen said:

Continuing to play with BROKE, it seems the most difficult part is going to be balancing contract rewards, government funding, and salaries.

There are several other Funding Modifiers I have planned that will take funds as well, so balance will end up being a goal for after those are written. It'll be especially difficult since you can disable or remove any Funding Modifier at any time without affecting the others. Also keep in mind the FMs shipped with BROKE are just the "defaults" and I'm hoping people will write their own.

 

I haven't forgotten about this. I'm working on a small project for fun at the moment and will be focusing on BROKE after that (before switching back over to KCT/SR again). If I don't get it finished by 1.1 I'll be sad

[jkortech]

I just put a little work into BROKE earlier today to add a punishment for unpaid payroll. (and fix some bugs in the BROKE core)

 

I'll work on a loan UI next.

[JeffreyCor]

Will be looking for it so stick it in the game and see if it blows up

[Probus]

@magico13 is it possible to configure this mod so that the amount paid to the KSC is variable dependent on date?  I am working on a historical tech tree and I was thinking it would be cool if I could integrate NASA's budget for each year/quarter.

[magico13]

53 minutes ago, Probus said:

@magico13 is it possible to configure this mod so that the amount paid to the KSC is variable dependent on date?  I am working on a historical tech tree and I was thinking it would be cool if I could integrate NASA's budget for each year/quarter.

The default Funding Modifiers don't have a way to configure it like that, but you could pretty easily write a custom Funding Modifier to do that. You'd just have to set up the ProcessQuarterly and/or ProcessYearly to give how ever many funds you should get at that time.

 

public InvoiceItem ProcessQuarterly()
{
	double QuarterlyBudget = NASABudgetForUT(Planetarium.GetUniversalTime());
	var invoice = new InvoiceItem(this, QuarterlyBudget, 0);
	return invoice;
}

public InvoiceItem ProcessYearly()
{
	double YearlyBudget = NASABudgetForUT(Planetarium.GetUniversalTime());
	var invoice = new InvoiceItem(this, YearlyBudget, 0);
	return invoice;
}

 

[jkortech]

Loans are implemented!  Now you can create general loan templates (which are turned into procedurally generated loans), take out loans, and pay them back over time.

[JeffreyCor]

Nice! Will grab it and start putting it through its paces as soon as the update link updates

[jkortech]

Pull down the files from the CI server.  I don't think we're actually going to make another release quite yet.

[JeffreyCor]

hummm, well looks like won't be trying it so soon after all

[NathanKell]

@magico13 the discussion over on the other thread reminded me about this. One FM I'd love to see--and I think I may have mentioned this before on KCT's repo? Can't recall--is an upkeep cost based on the number of KCT upgrade points invested. That's because RP-0 effectively treats the point total as your space program workforce, and workers gotta be paid. That might, however, also require an ability in KCT to remove upgrade point. Same with a general facility-tier based upkeep system.

Another good FM, and I'm pinging @Peppie23 here, would be Remotetech groundstation upkeep costs. Now, that would ideally require an ability in RemoteTech to purchase-unlock new groundstations, which IIRC has been planned for a while but is not, AIUI, done yet?--since otherwise it would just be a fixed cost per year for everybody. Or until that point, maybe base RT stations available on tracking station level, and the FM base on that. I am reminded of that because I love the idea discussed in the OP of simulating real life's "dish time" issues and the expense of continuing a mission based off DSN use. That said, I think that the dish time concern needs a counterpart: capcom time, as it were. Human spaceflight missions require far more in the way of communications (and other groundside support) than uncrewed missions, and that should be reflected in the mission costs.

[jkortech]

16 hours ago, NathanKell said:

@magico13 the discussion over on the other thread reminded me about this. One FM I'd love to see--and I think I may have mentioned this before on KCT's repo? Can't recall--is an upkeep cost based on the number of KCT upgrade points invested. That's because RP-0 effectively treats the point total as your space program workforce, and workers gotta be paid. That might, however, also require an ability in KCT to remove upgrade point. Same with a general facility-tier based upkeep system.

I was thinking of the same type of thing.  I'm all up for adding this, but since KCT is all @magico13 and he works on this mod as well, I want his feedback before I code it.

[magico13]

1 hour ago, jkortech said:

I was thinking of the same type of thing.  I'm all up for adding this, but since KCT is all @magico13 and he works on this mod as well, I want his feedback before I code it.

I think it'd be better to wait until KCT's API gets written, but I'm not really sure when that's going to end up happening. If you want to do it now, all you should need to grab is the result from KCT_Utilities.TotalUpgradePoints() (which is a "public static int" here, should be easy to execute through Reflection or directly).

Rather than including it in the BROKE default FMs, it might be better to include with KCT directly. That way if BROKE isn't installed it won't do anything, if KCT isn't installed then it won't do anything either (since it won't exist) but if the two are installed then it will work and you don't have to worry about any hard dependency issues. If it's included with BROKE then there might be dependency issues when BROKE tries to load it. Plus FMs are supposed to be packaged with the mod they integrate with, which is why the loader in BROKE was written the way it was.

@jkortech if you end up writing that, feel free to submit a PR to the KCT repo (preferably the "development" branch) with the FM. I can tweak the build server to build it and package it with KCT automatically.

[jkortech]

Ok.  FYI if/when I get a chance to do it, it'll be in a new dll because of the hard dependency on BROKE (since we have to use the interfaces).

[magico13]

14 minutes ago, jkortech said:

Ok.  FYI if/when I get a chance to do it, it'll be in a new dll because of the hard dependency on BROKE (since we have to use the interfaces).

Sounds good. FMs should generally be their own dlls anyway for that reason (and to make them easy/safe to uninstall), though since no code in the file would be called without BROKE installed it actually shouldn't cause any issues if it were added to the main dll.

[jkortech]

Just now, magico13 said:

Sounds good. FMs should generally be their own dlls anyway for that reason (and to make them easy/safe to uninstall), though since no code in the file would be called without BROKE installed it actually shouldn't cause any issues if it were added to the main dll.

Actually, because it is implementing the interface on a type it actually causes the dll to fail to load correctly (with a TypeInitializationException) if BROKE isn't installed (or if it is loaded before BROKE loads).  I ran into that problem when working on the payroll updates.  This commit shows what I had to add to fix the problem.

[magico13]

1 minute ago, jkortech said:

Actually, because it is implementing the interface on a type it actually causes the dll to fail to load correctly (with a TypeInitializationException) if BROKE isn't installed (or if it is loaded before BROKE loads).  I ran into that problem when working on the payroll updates.  This commit shows what I had to add to fix the problem.

Oh, that's annoying. Thank you for coming up with a fix for that (and everything else you've been doing)! Though we should encourage keeping FMs as separate dlls if anyone asks.

[jkortech]

Just now, magico13 said:

Oh, that's annoying. Thank you for coming up with a fix for that (and everything else you've been doing)! Though we should encourage keeping FMs as separate dlls if anyone asks.

Not a problem!  Just had some free time and decided to get back to BROKE (now that EER v0.5 is out).

[JeffreyCor]

It seems the update to MKS-Lite / UKS broke BROKE. After the update to MKS-Lite all kinds of sadness happened such as not being able to exit the research center. After sifting though one at a time I finally found the having either MKS-Lite or UKS (installed it for testing after finding the problem with MKS-Lite) and BROKE in at the same time resulted in the problem.

[jkortech]

3 minutes ago, JeffreyCor said:

It seems the update to MKS-Lite / UKS broke BROKE. After the update to MKS-Lite all kinds of sadness happened such as not being able to exit the research center. After sifting though one at a time I finally found the having either MKS-Lite or UKS (installed it for testing after finding the problem with MKS-Lite) and BROKE in at the same time resulted in the problem.

Can you post a log file?  It'll make it a lot easier to figure out what happened.