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

[magico13]

Nope, you're right. I only got a chance to do a quick test, but changing the version of the .dll did in fact break it. Looks like I'll just keep the core .dll at 1.0 and use an alternative versioning setup. I'll look at your version check code to see if there's a particular way I should do it so that it works with Contract Configurator right out of the box (or with minimal changes)

[nightingale]

Nope, you're right. I only got a chance to do a quick test, but changing the version of the .dll did in fact break it. Looks like I'll just keep the core .dll at 1.0 and use an alternative versioning setup. I'll look at your version check code to see if there's a particular way I should do it so that it works with Contract Configurator right out of the box (or with minimal changes)

AssemblyInformationalVersion is the ideal one. Anything else is gravy. This is what I set in Contract Configurator:

[assembly: AssemblyVersion("1.0")]
[assembly: AssemblyFileVersion("1.7.2")]
[assembly: AssemblyInformationalVersion("1.7.2")]
[assembly: KSPAssembly("ContractConfigurator", 1, 0)]

[magico13]

I got a chance to do some work on this again today and got the GUI to a working state, along with persistence saving and loading. The great news is that I think BROKE core is developed enough that the only real thing to do to get this to a playable state is writing up some Funding Modifiers!

BROKE has been set up to make it easy to write new "Funding Modifiers" (things that modify the funds level, like funding from the government [a positive modification] or Kerbal salaries [a negative modification], on a regular interval). I've written an example Funding Modifier that should hopefully make it pretty clear what you have to do. Just compile it as a .dll and place the .dll next to the BROKE.dll in the GameData/BROKE folder, and BROKE will handle loading it and calling all the methods at the right times. I'll probably write up a tutorial for it some time, to make it even clearer, but until then please ask questions if you have them!

So if you can think of something that should adjust a player's funds on a quarterly or yearly basis, either write up a Funding Modifier, or at least mention it here and maybe I or someone else will write it up. I have several "default" ones I'm planning on writing (income based on rep, kerbal salaries, building maintenance, active mission expenses).

Get the pre-release from GitHub, which comes with a very simple example Funding Modifier.

License is MIT for BROKE, to make it nice and clean for people to build mods that work with it

[johnqevil]

Wow, I log in for the first time in nearly a year to find someone has taken this over and done some wonderful things with it! Magico13, I'm glad you saved Kerbanomics. I'm pretty sure it would be dead entirely if you hadn't, and that would make me sad XD

[magico13]

Wow, I log in for the first time in nearly a year to find someone has taken this over and done some wonderful things with it! Magico13, I'm glad you saved Kerbanomics. I'm pretty sure it would be dead entirely if you hadn't, and that would make me sad XD

The development of BROKE is very Kerbanomics inspired, but is more of a "spiritual successor" than a continuation. Once 1.1 comes out I probably won't update the current fix, so sadly Kerbanomics will likely be no more at that point But, if you find the time, I'd absolutely love to have you write part of BROKE. It's designed to be modular, so you could write one (or more) of the default modules if you wanted. If not, that's totally OK too, but I figured I'd extend the invitation in case you still wanted to be involved

[johnqevil]

The development of BROKE is very Kerbanomics inspired, but is more of a "spiritual successor" than a continuation. Once 1.1 comes out I probably won't update the current fix, so sadly Kerbanomics will likely be no more at that point But, if you find the time, I'd absolutely love to have you write part of BROKE. It's designed to be modular, so you could write one (or more) of the default modules if you wanted. If not, that's totally OK too, but I figured I'd extend the invitation in case you still wanted to be involved

I'm down for that. Anything in particular?

[magico13]

I'm down for that. Anything in particular?

Well, currently there are no modules written at all, so any of them are up for grabs. The two that I think should be done first, which might even be the simplest, would be the funding based on reputation and the kerbal payroll modules (each should be a separate .dll). I'm trying to think of the best way to set up the repository for those, since the KerbalStuff download will have the BROKE core + the default modules, but on CKAN they'll be separate.

I think the easiest way to do it would be to have the default modules be one github repo (with one visual studio solution but separate projects for each .dll) while the core stays a separate repo. I can very easily integrate that with my build server then, which will make doing releases pretty straightforward.

I'm at work for the next 7-8 hours, but I can set that up tonight. I'll probably just make it so you can commit to it directly rather than requiring pull requests. If you happen to start working on things before then, note that there's a rather large change between the pre-release and the current build because of some excellent additions by the Extensive Engineer Report developer, who is working on loans. You can always grab a build of the absolute latest code from my build server: here.

[johnqevil]

Well, currently there are no modules written at all, so any of them are up for grabs. The two that I think should be done first, which might even be the simplest, would be the funding based on reputation and the kerbal payroll modules (each should be a separate .dll). I'm trying to think of the best way to set up the repository for those, since the KerbalStuff download will have the BROKE core + the default modules, but on CKAN they'll be separate.

I think the easiest way to do it would be to have the default modules be one github repo (with one visual studio solution but separate projects for each .dll) while the core stays a separate repo. I can very easily integrate that with my build server then, which will make doing releases pretty straightforward.

I'm at work for the next 7-8 hours, but I can set that up tonight. I'll probably just make it so you can commit to it directly rather than requiring pull requests. If you happen to start working on things before then, note that there's a rather large change between the pre-release and the current build because of some excellent additions by the Extensive Engineer Report developer, who is working on loans. You can always grab a build of the absolute latest code from my build server: here.

Both of those were present and working in Kerbanomics back in Beta, so I should be able to get those ported over right quick. I'm at work til 9pm PT myself, so likely tomorrow.

[magico13]

Both of those were present and working in Kerbanomics back in Beta, so I should be able to get those ported over right quick. I'm at work til 9pm PT myself, so likely tomorrow.

Yep, you know those systems better than I do and I was just planning on taking what Kerbanomics had and modifying it for this, so I figured those would be easy for you to do. I'll get that repo set up tonight and maybe set up the projects but leave them mostly blank.

The funds from rep module should take advantage of the Settings GUI to allow the user to adjust the funds to reputation ratio, and the payroll module should use the Settings GUI to define payroll rates and the Main GUI to display the Kerbal and how much they were paid that quarter. The settings themselves for both can either be saved to the persistence through the SaveData/LoadData functions, or can be saved to a separate file, or both (save the defaults to a separate file, but still allow it to be changed per save-game).

Obviously, if you have questions let me know. If you find you need something added to the core code to get it to work (you shouldn't though), either add it and submit a pull request or tell me and I can add it. I haven't gotten a chance to seriously review the recent addition of Invoices, so I don't know exactly how they work yet. jkortech added the Invoices, so he would know more about them than I do at the moment.

Edited October 2, 2015 by magico13

[JorusAton]

Yep, you know those systems better than I do and I was just planning on taking what Kerbanomics had and modifying it for this, so I figured those would be easy for you to do. I'll get that repo set up tonight and maybe set up the projects but leave them mostly blank.

The funds from rep module should take advantage of the Settings GUI to allow the user to adjust the funds to reputation ratio, and the payroll module should use the Settings GUI to define payroll rates and the Main GUI to display the Kerbal and how much they were paid that quarter. The settings themselves for both can either be saved to the persistence through the SaveData/LoadData functions, or can be saved to a separate file, or both (save the defaults to a separate file, but still allow it to be changed per save-game).

Obviously, if you have questions let me know. If you find you need something added to the core code to get it to work (you shouldn't though), either add it and submit a pull request or tell me and I can add it. I haven't gotten a chance to seriously review the recent addition of Invoices, so I don't know exactly how they work yet. jkortech added the Invoices, so he would know more about them than I do at the moment.

*happy clapping*

So glad to see this mod being worked on, and for two mod developers to be cooperating so nicely - it's nice to see

Looking forward to what's in store for the future!

[johnqevil]

I anticipate having enough ported over for testing tonight or tomorrow morning. There was more spaghetti in my original code than I expected.

[jkortech]

Yep, you know those systems better than I do and I was just planning on taking what Kerbanomics had and modifying it for this, so I figured those would be easy for you to do. I'll get that repo set up tonight and maybe set up the projects but leave them mostly blank.

The funds from rep module should take advantage of the Settings GUI to allow the user to adjust the funds to reputation ratio, and the payroll module should use the Settings GUI to define payroll rates and the Main GUI to display the Kerbal and how much they were paid that quarter. The settings themselves for both can either be saved to the persistence through the SaveData/LoadData functions, or can be saved to a separate file, or both (save the defaults to a separate file, but still allow it to be changed per save-game).

Obviously, if you have questions let me know. If you find you need something added to the core code to get it to work (you shouldn't though), either add it and submit a pull request or tell me and I can add it. I haven't gotten a chance to seriously review the recent addition of Invoices, so I don't know exactly how they work yet. jkortech added the Invoices, so he would know more about them than I do at the moment.

I anticipate having enough ported over for testing tonight or tomorrow morning. There was more spaghetti in my original code than I expected.

Just found this thread again so I thought I should chime in. If you have any questions about InvoiceItems or any of that infrastructure let me know. Also, the IMultiFundingModifier is perfectly suited for the Crew Payroll. It allows you to create multiple InvoiceItems per quarter, so you can create one for each employed Kerbal. That way we can easily show the entries separately on the Main GUI for each item. (I'm in the process of adding that feature as a built-in. Goal is by end of week.)

[magico13]

So glad to see this mod being worked on, and for two mod developers to be cooperating so nicely - it's nice to see

Correction: three Currently there's jkortech, johnqevil, and me working on various things when we get the chance. Johnqevil is going to port over some of the previous features of the original Kerbanomics, jkortech is writing up loans and doing some work on the core plugin, and I'm working on the core plugin and developing some of the other modules that I want to include.

I anticipate having enough ported over for testing tonight or tomorrow morning. There was more spaghetti in my original code than I expected.

Great! There's no rush at all, so don't worry too much about that.

Assuming I've set the build server up properly, as soon as there's a push to the Default Modifiers repo it should build those, and as soon as there's a push to the main BROKE repo it should build both BROKE and the Default Modifiers.

I might try to write up the code for handling mission control and/or building maintenance in the next few days.

EDIT:

Also, the IMultiFundingModifier is perfectly suited for the Crew Payroll. It allows you to create multiple InvoiceItems per quarter, so you can create one for each employed Kerbal. That way we can easily show the entries separately on the Main GUI for each item. (I'm in the process of adding that feature as a built-in. Goal is by end of week.)

I haven't gotten a chance to look at those too much, but it sounds like it'd be really easy to set it up so a Kerbal will quit if they're not paid after a quarter. Invoice comes in for each kerbal, you decide not to pay some of them, next quarter rolls around and they've got an unpaid invoice, they quit and have to be rehired.

Not sure how that would work for kerbals who are out in the field. Could set them to be tourists, then they refuse to do work. I'm not sure how you'd rehire them though, perhaps something could be added in the Astronaut Complex GUI, but that might require a plugin in addition to the IFundingModifier (although you can subscribe to events within an IFundingModifier so you could do it without a full MonoBehaviour)

Edited October 5, 2015 by magico13

[jkortech]

I haven't gotten a chance to look at those too much, but it sounds like it'd be really easy to set it up so a Kerbal will quit if they're not paid after a quarter. Invoice comes in for each kerbal, you decide not to pay some of them, next quarter rolls around and they've got an unpaid invoice, they quit and have to be rehired.

Not sure how that would work for kerbals who are out in the field. Could set them to be tourists, then they refuse to do work. I'm not sure how you'd rehire them though, perhaps something could be added in the Astronaut Complex GUI, but that might require a plugin in addition to the IFundingModifier (although you can subscribe to events within an IFundingModifier so you could do it without a full MonoBehaviour)

What about Game.CrewRoster.SackAvailable(ProtoCrewMember)? I think it might work. It just makes a Kerbal an applicant again. I would think that most of the processes and actions that require at least one non-tourist kerbal would check that they are crew (since tourist isn't a trait like "Pilot" or "Engineer" but a KerbalType like "Crew").

[magico13]

What happens if you sack a Kerbal who is currently assigned to a vessel? Do they disappear? Does it just fail to fire them? I absolutely think that's what it should do for kerbals who are at the astronaut complex, but I don't expect it would work for assigned kerbals.

Setting those kerbals to be tourists then prevents them from doing work while not making them disappear, giving you a chance to rehire them and not totally losing a mission or having kerbals vanish. When the ship gets recovered we can set them to be applicants again (probably).

[jkortech]

It sets their KerbalType to Applicant instead of crew. I don't think it deletes them from the ship, but I'll have to run some tests to see exactly how it functions.

[johnqevil]

Quick update on Payroll and Funding: both are ported over and working, with basic configuration menus.

[magico13]

Beta 2 is now available, and this one includes actual gameplay! Included with the B.R.O.K.E. download are two modules that johnqevil has ported over from the original Kerbanomics: Payroll and ReputationFunding. The first, Payroll, adds a configurable daily salary based on a Kerbal's level. ReputationFunding provides funds each quarter based on the total reputation of the player. Both can be configured in-game or even disabled in-game. To completely disable them, just remove the .dlls from the GameData/BROKE/Modules directory.

It appears that you have to click the "pay" button to receive the money each quarter. That will likely change in the future, in addition to options to automatically pay any debts. For now, it doesn't appear we've added a penalty for not paying your Kerbals their salary, but in the future they will quit if you don't pay them!

If you have questions, or wish to contribute (bug reports or even entire Funding Modifiers) please don't hesitate to post here in the forum or on one of the two GitHub repos we're using. We're currently deciding on a roadmap to 1.0, so expect some more work in the near future.

[AdmiralTigerclaw]

Here's a question:

Would it be possible to set up a market system with this mod along side a part to facilitate the sale of resources in exchange for funds?

In example, set up a surface base, extract and refine a resource, and then 'sell' said resource through an interaction menu, rather than having to either recover a vessel full of it. With modifiers in value that depend on where the material is sold from.

I desire this mechanic over hand-flying or even automated flying mainly because a fully kitted and modded game of KSP pushes the envelope of what can be run without either becoming horrifically unstable, or so part intensive that the PC can't keep the physics straight.

[magico13]

Where this mod is designed to excel is for things that happen periodically in time, such as every quarter or year. You, or someone else, could certainly set up a Funding Modifier that's used alongside a part mod or alongside a plugin where you give up resources and in exchange you get funds every quarter. If you want just a plain exchange, it might be simpler just to write a mod that gives you X funds for every Y fuel you sell (with some modifier M), ignoring any periodic time elements. I might be able to write up a very basic modlet for that, if you'd like.

Something I've been considering writing up for BROKE (as an optional FM) is a full stock market where you can buy and sell shares of each of the major Corporations and/or resources. The more Rockomax parts you use without blowing them up, the more their shares go up, but if you blow up a few rockets that use those parts then shares drop. Each quarter you receive dividends, and you can always buy low and sell high to make some cash. Daily fluctuations would probably be random. Could be fun to come up with some "events" that happen randomly to cause jumps (up or down) in share price.

[AdmiralTigerclaw]

Where this mod is designed to excel is for things that happen periodically in time, such as every quarter or year. You, or someone else, could certainly set up a Funding Modifier that's used alongside a part mod or alongside a plugin where you give up resources and in exchange you get funds every quarter. If you want just a plain exchange, it might be simpler just to write a mod that gives you X funds for every Y fuel you sell (with some modifier M), ignoring any periodic time elements. I might be able to write up a very basic modlet for that, if you'd like.

Something I've been considering writing up for BROKE (as an optional FM) is a full stock market where you can buy and sell shares of each of the major Corporations and/or resources. The more Rockomax parts you use without blowing them up, the more their shares go up, but if you blow up a few rockets that use those parts then shares drop. Each quarter you receive dividends, and you can always buy low and sell high to make some cash. Daily fluctuations would probably be random. Could be fun to come up with some "events" that happen randomly to cause jumps (up or down) in share price.

I'm not much of a programmer myself. When it comes to technical, I'm more hands on 'solder this, test that' in terms of tech management. But I'm familiar with programming enough to dabble if I don't have to sit down and work with things when they're in plaintext English. For example, I'm tinkering with some new templates for Angel's pathfinder mod along side values for real ISRU. In short, I'm working with the two mods to create a kind of on-site deployable manufacturing facility. There's actually a LOT of potential available with the template switching system he has.

Now, in regards to your market, I actually have an idea sitting in the general thread about the market system idea. If you'd be willing to peruse it, if only to get another angle on the idea, I'd appreciate it.

http://forum.kerbalspaceprogram.com/threads/135272-Orbital-Trading-Post

As I mention in post, I'm partially inspired by Offworld trading company.

[The_Sea_Four]

You can currently enter negative values for loan amounts. I ran timewarp for a while and I think it processes it like you would expect a normal loan to, e.g. doesn't end early/pays out positive returns. Is this intentional?

[magico13]

You can currently enter negative values for loan amounts. I ran timewarp for a while and I think it processes it like you would expect a normal loan to, e.g. doesn't end early/pays out positive returns. Is this intentional?

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.

[baldamundo]

In the original mod there was also the bug where if you typed in a negative number to the repayment field, you'd get free money - so may want to check for that as well

[magico13]

In the original mod there was also the bug where if you typed in a negative number to the repayment field, you'd get free money - so may want to check for that as well

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.