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

[magico13]

B.R.O.K.E.

Banking Resources, Overheads & Kerbal Economy

B.R.O.K.E. is a WIP framework for the creation and implementation of mods that center around regular funding adjustments (known as Funding Modifiers, or FMs), such as Kerbal salaries (see the Payroll FM) or cheques from the Kerbin Government (see the ReputationFunding FM). It is designed to make the creation of new FMs fast and easy, requiring far less work than writing a traditional plugin. B.R.O.K.E. handles the loading and processing of FMs automatically, all you have to do is define a few functions.

Not interested in developing new FMs but want to play with some instead? B.R.O.K.E. comes with several "Default FMs" such as Payroll and ReputationFunding. As the B.R.O.K.E. core code gets finalized, we'll be shifting our attention over to creating new Default FMs and refining the existing ones.

B.R.O.K.E. is a continuation in spirit of the Kerbanomics mod by johnqevil. Some code, images, and ideas are taken from Kerbanomics, with permission.

Downloads

Latest Release on GitHub

Screenshots

 

Active developers:

@magico13

@jkortech

@johnqevil

 

Our thanks go out to DivisionByZero and ObsessedWithKSP who both made contributions to Kerbanomics, the mod that inspired the creation of B.R.O.K.E. (and whose toolbar icon we have borrowed)

All code is licensed with the MIT license. Source code for B.R.O.K.E. may be accessed through this GitHub repository. Source code for the default FMs can be accessed through this GitHub repository. The absolute latest builds can be acquired from the build server (temporarily out of service), but the latest stable releases are on the Releases page on the B.R.O.K.E. repository.

Edited May 27, 2016 by magico13
Beta 4

[Doughy]

needs to be compatible with State Funding tho that mod is awesome

[Rokanov]

Sounds great, excited for this!

A couple of naming (though Kerbanomics is great, a variation of that perhaps?):

Kerbal Kapitalism

Kerbal Spending Program

[nightingale]

Sounds to me like it and KCT should just be one mod... Kerbal Space Agency Simulator! (Sounds dreadfully boring).

Anyway, some of my thoughts:

• You mention possibly not gaining back access to probes if you don't assign enough flight budget. But I'd stay away from anything probability based. Maybe just give a restart cost for spinning the program back up that increases the longer things have been dormant.
  
• I like reputation decay for the penalties, but they have the problem of not being visible/important enough to the players. They really only affect what contracts are offered (unless they'll play a more important role in you mod).
  
• I personally haven't played Kerbonomics, so I don't know the nitty gritty details. But I think having a quarterly (or annual) balance sheet popup would be a nice touch (and a fairly common thing for "tycoon" type games). You could then spell out the various costs and incoming funds for the period, as well as having a good place to detail out the reputation loss/gain for activity (if that's where you choose to go).
  

[magico13]

needs to be compatible with State Funding tho that mod is awesome

No promises. There's a good chance there will be too much overlap for it to be sensible.

Sounds to me like it and KCT should just be one mod... Kerbal Space Agency Simulator! (Sounds dreadfully boring).

While I would love that, I think there are enough people who wouldn't that I'm gonna keep things separate

Probability based things are definitely a touchy situation. If/when that feature gets added then there will likely be more discussion on what's ok, but I'll keep in mind that probability is generally not a great idea. An increased cost seems reasonable (pay $10000 a year to keep a skeleton crew, or cut that out entirely and pay $40000 in 3 years when you need to reactivate the probe. You pay more overall, but less up front.)

In Kerbanomics as-is reputation controls the interest rate on loans and the amount of funds you receive each cycle (default is quarters). Currently you get a message saying how much you earn, and how much you spend on Crew costs. I'd like to expand that to maybe provide total costs for everything (including KSC upgrades and launches) during that quarter, with an optional window to show totals and/or history. If I keep pay tied to reputation, then reputation decay also equates to pay decay, which is what I ultimately want. Gaining any rep could reset the decay "grace period" so you have to keep doing things to keep earning money.

I do want to increase the management aspect, since KCT already adds some elements of that and this mod can then handle the funds side of that.

Jebediah Kerman's Race Into Space Crippling Debt

[autumnalequinox]

Magico, I love u I didn't even know something like this existed. I've been so busy lately haven't worked on my mod but I have been wanting something like this desperately. I run something similiar on top of my careers with manual editing and some formulas.

Thank you for resurrecting this. I'm going to check it out and report back!

- - - Updated - - -

(will this be safe to install on top of a KCT career game in progress?)

[Rokanov]

How about some kind of dynamic private/state funding scale? A state focus would provide funding and take care of some maintenance costs but would have occasional compulsory contracts, whereas with a private focus you'd have to take care of all costs, but contracts payoff better. Either as binary option, slider, or dynamic based on how you play.

Also, don't know if you're into acronyms but:

Banking Resources, Overheards & Kerbal Employment (B.R.O.K.E.)

[autumnalequinox]

OMG: With a system like this, it would be awesome to run the program as either a private, commercial agency (Space-X) or a governmental agency (everyone else). Modifying the way the money flows, capital availability, etc. I'm a nerd I play different career games as either private or public, with different settings/house rules.

[JWS]

Great to see that you are working on the idea. I like the idea of government funding, but there are also several other mods which provide alternative income routes. Ippo's Science Funding or several Contract packs which use the nightingale's Contract Configurator, etc. By installing these mods, you can customize your income sources as you want.

And about the new name, how about Kerbal Financial Times?

[blackrack]

Sounds great, excited for this!

A couple of naming (though Kerbanomics is great, a variation of that perhaps?):

Kerbal Kapitalism

Kerbal Spending Program

Seconding Kerbal Spending Program

[mysteriosmind]

Oh yes please!

Adding building maintenance costs seems like a neat thing and a good way to counter timewarp to win. Would be even cooler if you also had to hire workers (mechanics, scientists, control center staff). That way you could sack workers in case of a funding cut or if you fail an important contract. Control center staff would influence how many active missions you can have. Scientists and mechanics might only make sense in Kerbal construction time though (influencing research und build times). Maybe you would have to have a certain size of workforce to actually use the benefits that building upgrades provide? Workforce could be as simple as a slider of how many people you employ or as complex as individual kerbals with skills (high skilled kerbals would provide more benefits but require higher wages and you can only recruit them rarely).

funding could work that way that the government offers you funding packages for a certain time period like option 1: "we will pay you 50.000 funds per month for 2 years and expect you to complete 4 government missions and reap in 800 science points" or option 2: "we will pay you 70.000 funds per month and expect you to complete 6 government missions and reap in 1200 science points". You pick one and when the time is over you get new offers based on your performance (did you reach the set goals/how many government contracts did you fail/Reputation).

A system like that would stand for leading budget negotiations and give players flexibility in their play style.

As for a name I really like "Kerbal Spending Program" too, but it might be a bit confusing to have a KSP mod that has KSP as an acronym. Maybe make it something like "Kerbal Spending Sim" or "Kerbal Spending Time"

[magico13]

(will this be safe to install on top of a KCT career game in progress?)

It should be, just know that when I start making the big changes the data from the current version might not be carried over. It shouldn't damage any saves though.

How about some kind of dynamic private/state funding scale? A state focus would provide funding and take care of some maintenance costs but would have occasional compulsory contracts, whereas with a private focus you'd have to take care of all costs, but contracts payoff better. Either as binary option, slider, or dynamic based on how you play.

Also, don't know if you're into acronyms but:

Banking Resources, Overheards & Kerbal Employment (B.R.O.K.E.)

I do like the idea of private vs government funded. I might do that more along the lines of what mysteriosmind brings up, but I definitely want to provide options for the player to either use contracts only or completely ignore contracts, or anything in-between. Ideally you'll be able to completely ignore contracts if you want. If you don't want government help, I'd probably just recommend increasing the funds reward setting for that save (I might provide a way to change that in an existing game).

Also, I really like B.R.O.K.E.

Great to see that you are working on the idea. I like the idea of government funding, but there are also several other mods which provide alternative income routes. Ippo's Science Funding or several Contract packs which use the nightingale's Contract Configurator, etc. By installing these mods, you can customize your income sources as you want.

And about the new name, how about Kerbal Financial Times?

I like that there are multiple ways of getting funding, since I like tailoring my game to play how I want it to, so I'm glad you also seem to feel the same way. Options are wonderful things

I think I want to avoid anything with Kerbal in the name, just in case that becomes an issue later on down the line if Squad for whatever reason needs to tighten up their IP rules. I didn't name Kerbal Construction Time originally, but I already have the backup name of "Some Assembly Required" if I find myself needing to rename.

Adding building maintenance costs seems like a neat thing and a good way to counter timewarp to win. Would be even cooler if you also had to hire workers (mechanics, scientists, control center staff).

funding could work that way that the government offers you funding packages for a certain time period

As for a name I really like "Kerbal Spending Program" too, but it might be a bit confusing to have a KSP mod that has KSP as an acronym. Maybe make it something like "Kerbal Spending Sim" or "Kerbal Spending Time"

Same issue as above with names, I'd prefer to steer away from including Kerbal in the name (but am not completely opposed to it). KSP as the acronym would likely just make things confusing unfortunately :/

However I really like the other ideas you have. I'm not sure that I'll go so far as to have you hire explicit workers, but I can definitely see having any scientists/engineers hanging out at KSC (aka not on a mission) reducing the running costs for certain buildings (and reducing them more based on the Kerbal's level). So you might hire a scientist and train him to make the R&D center cost less each period (I'm not sure how I'd want to balance it, but I might make it cost effective to leave a scientist or two on Kerbin [aka, the cost reductions in the building's costs outweighs the cost of the kerbal], but if you have too many than you end up paying more in salaries than it's worth). That makes it so you can hire crew and not have it totally bankrupt you.

I like the idea of several offers, with different requirements associated with them. It might be a little too close to the contracts system and it might make more sense just to offer special "Government Contracts", so I'll have to think about how I want to do that. At the very least there will be a minimal "We'll give you this much money based on your reputation (and maybe current funds)" which should be sustainable if you don't hire every Kerbal ever and don't launch 28 missions a quarter (it should be enough to cover a crew of maybe, a few moderate sized launches, and one or two fully funded active flights). Big missions would require you to save up money over multiple quarters or take out extra contracts to fund them right away. I think I still want some sort of reputation decay system so you can't timewarp your way into riches.

I'll likely start playing around with some things this weekend. I've already got the name for the first Loan Provider: "Jebediah Kerman's Junkyard and Loan". The second would be something along the lines of "Kerb Town Bank" (a small, local bank) and the third would be a big name thing like "Kerman Sachs". Obviously those names aren't finalized yet, so if you've got other suggestions let me know

[Rokanov]

Workforce could be as simple as a slider of how many people you employ.

Could a workforce expand/replace build point upgrades in KCT? They could essentially be the same thing I guess, but instead of adding arbitrary rates you add a worker, who adds an arbitrary rate. That would just feel nice

As for a name I really like "Kerbal Spending Program" too, but it might be a bit confusing to have a KSP mod that has KSP as an acronym. Maybe make it something like "Kerbal Spending Sim" or "Kerbal Spending Time"

Yeah I thought that as I was writing it, 'KSP... the mod' would be too confusing, but it made me giggle

Love the rest of the ideas, especially running costs and a tycoon-style ins/outs financial review.

Obligatory name suggestion :

Kommonwealth (or Kermanwealth) Bank of Kerbin (after Commonwealth Bank of Australia)

Edit: Oh and if you had a workforce they could go on vacation (e.g. at Kristmas) or go on strike because Jeb keeps leaving the toilet seat up!

Edited August 14, 2015 by Rokanov

[autumnalequinox]

At the very least there will be a minimal "We'll give you this much money based on your reputation (and maybe current funds)"

In my government career games, I use a simple formula: rep x 1000 funds per annum. Just enough to keep things afloat if I have a bad streak of luck (I play no revert unless bug, although KCT sims are ok). As launch costs increase it seems to balance well. Of course now I will be able to do away with another house rule, which is sweeet.

- - - Updated - - -

One more thing: while not eliminating contracts, this could be the thing that can finally bring some balance to them. Combined with KCT, MCE, and contract configuator, there just might be a good career game in there now. Something that has seemed to elusive to me I've started 3 new games since 1.0.4 game out and make my own rules and systems that I run in WordPad. But enough with the giddy gushing..

- - - Updated - - -

How about some kind of dynamic private/state funding scale? A state focus would provide funding and take care of some maintenance costs but would have occasional compulsory contracts, whereas with a private focus you'd have to take care of all costs, but contracts payoff better. Either as binary option, slider, or dynamic based on how you play.

oh and didn't realize we both brought this up like 10 mins apart

[Corax]

Awesome to see this taken up and continued.

An idea I had for government funding was to simulate election cycles, ie. depending on which "party" has the upper hand, your program would get more or less funding over the next election cycle, the idea being that you have a budget you can rely on and maybe even overspend, but don't know how much resources you will have available in the next cycle.

Of course "election results" would just be something like 20/20/60 chance for high/low/average funding levels.

Knowing magico13, there would certainly be configuration settings for the exact values/formulas, so everything from broke micronations to prosperous world empires, direct democracy with weekly polls to one-party state with twenty-year plans, and the occasional revolution, would be possible

[CalculusWarrior]

This is a very good idea, great job for continuing Kerbonomics! I'm also a fan of the B.R.O.K.E. acronym.

[autumnalequinox]

Knowing magico13, there would certainly be configuration settings for the exact values/formulas, so everything from broke micronations to prosperous world empires, direct democracy with weekly polls to one-party state with twenty-year plans, and the occasional revolution, would be possible

Give us the configs and we will produce the presets. It could be as simple as introducing some randomness to funding, some conditions (complete x contracts per period, or gather x science), and maintenance costs. We can then play with the values and build a variety of scenerios we can swap and share. Whether it's a corporate board or the senate, in the end it's just math

[magico13]

So I didn't get a chance to do any work on this over the weekend unfortunately, but I've written some of my ideas down in a notebook and have started planning. Whereas KCT grew from a tiny mod into something much larger and lacked a clear goal, I'm try to avoid that this time around and have most things planned ahead of time. You all know I love configurability, so I'm planning on trying to either make things configurable through text files or at the very least make it easy to add new functionality with code.

At first I just want to get things working, though, and extra configurability will likely come down the line once I know what people need/want to modify (doesn't make sense to spend a lot of time making something super configurable if no one will ever change it from the defaults. Which is part of the reason I made the Presets in KCT, to make it easier to modify things)

Some examples (obviously, no code is in place yet):

Loan providers will be defined in a config file. I'll probably try to go so far as to add support for modifying the config with ModuleManager. That means you can easily add or alter the loan providers so that they have different max loan amounts/loan lengths, or require different building/reputation levels, and most likely I'll add options to offer higher/lower interest rates than "standard". We'll figure out what all to make configurable for loan providers when we get there, but at minimum you'll be able to make new ones that act like the default ones.

Funding and expense sources will all share a common Interface. This is entirely an internal code-related aspect, but it should make it really really easy to create new funding sources and expense sources, and if anyone ever wants to add new ones they should be able to really easily with a companion mod. What I'll likely use as inspiration for this is Contract Configurator's behaviours, which make it really easy to extend things.

I also plan on using TriggerAu's addon framework from the beginning, which means the GUIs hopefully will look better and the whole thing will be cleaner. Ironically the last post in that thread is by johnqevil, so he may have been planning on switching to it as well before he disappeared.

There is a decent chance I'll provide ways to tweak any formulas themselves, since I can easily adapt the MathParser out of KCT (which is itself adapted out of a math parser I wrote for a project at work, though the one for KCT is more featured).

[JWS]

Funding and expense sources will all share a common Interface. This is entirely an internal code-related aspect, but it should make it really really easy to create new funding sources and expense sources, and if anyone ever wants to add new ones they should be able to really easily with a companion mod. What I'll likely use as inspiration for this is Contract Configurator's behaviours, which make it really easy to extend things.

Nice approach. Like various contract packs out there, there can be several other mod packs which emphsize different aspects of funding and expense. Also it will provide its own customized strategies without any dependency on other mods. I'll look forward to it.

[ThatOneBritishGuy...]

Funding and expense sources will all share a common Interface. This is entirely an internal code-related aspect, but it should make it really really easy to create new funding sources and expense sources, and if anyone ever wants to add new ones they should be able to really easily with a companion mod. What I'll likely use as inspiration for this is Contract Configurator's behaviours, which make it really easy to extend things.

So I'd just like to pitch in the fact that B.R.O.K.E. sounds great to me as well, and I'll also 2nd what JWS said.

Keep it up Magico!

Edited August 21, 2015 by ThatOneBritishGuy...

[magico13]

Just a quick update, I haven't forgotten about this but I've just been working on it slowly when not working on other things. I've officially decided to go for B.R.O.K.E. (pun intended), since I like that name and if for some reason the "Kerbal" aspect needed to be removed in the future, it can easily keep the same name. Though I'm using "Economy" instead of "Employment" as it's a bit more general, resulting in "Banking Resources, Overheads & Kerbal Economy (B.R.O.K.E.)", so thank you to Rokanov for the suggestion!

I don't have anything working quite yet as I'm still finalizing the core. It's really, really easy to add new Funding Modifiers (things that trigger each quarter or year and either add funds or remove them). It does require referencing the core BROKE dll, but you don't have to register anything in BROKE and you don't even have to use a MonoBehaviour. A simple .dll with a class that implements BROKE.IFundingModifier is all that's needed (plus an implementation of all the methods defined in that interface). BROKE finds every class that implements IFundingModifier and handles them itself. There are even functions to define some GUIs to show additional information or to provide configuration options. Hopefully it makes creating new sources of funding, or new things to pay for, very easy to do, even for new programmers. I might even be able to distill it into a reduced form suitable for definition in a config file.

To see an example Funding Modifier, here is the test one I've been using for testing things: https://github.com/magico13/BROKE/blob/master/BROKE/FundingModTest.cs

If it wasn't obvious, I've got the GitHub set up and you are free to take a look and offer some suggestions. Things are still very WIP at the moment, and now is a good time for feature requests (maybe do them as new Issues please, so I don't lose track of them).

I've also set up a Jenkins project for BROKE on my build server where you can grab the latest builds as they get pushed to GitHub.

Depending on my schedule this week, I'd maybe like to get the core finalized and start working on the first of the Funding Modifiers (things like government funding and kerbal payroll right off the bat, then adding in building maintenance costs, active flight crew costs, etc. later on down the line).

Edit: Super, duper, early screenshots which are subject to MUCH change:

With the Funding Modifier's MainGUI not drawn:

And with the Funding Modifier's MainGUI drawn (BROKE core puts it inside a Vertical and its own ScrollView):

Edited August 31, 2015 by magico13

[nightingale]

DLL dependencies suck in KSP (but I don't have a better suggestion, as any other method than the interface would be way uglier). Keeping that in mind though, there's a couple things you may want to do differently in your AssemblyInfo.cs:

I always leave the AssemblyVersion alone at 1.0. Otherwise if you change it, it forces someone who compiled against you DLL to recompile. In other words, every time you release, you break everyone else's DLLs, which is obviously bad.

[assembly: AssemblyVersion("1.0")]

I set this to the same thing as AssemblyFileVersion. There was a good reason (DMagic told me to), but I can't remember what the reason was. I think it made code for checking a version easier/better/more reliable.

[assembly: AssemblyInformationalVersion("1.7.2")]

This will allow others to do a KSPAssemblyDependency() on you, which means you don't have to do silly things with the alphabetical load order and name your mod aaa_BROKE. Again, don't touch the version, because there's a bug in KSP where the version number comparisons are done wrong (see #3995).

[assembly: KSPAssembly("ContractConfigurator", 1, 0)]

[magico13]

I always leave the AssemblyVersion alone at 1.0. Otherwise if you change it, it forces someone who compiled against you DLL to recompile. In other words, every time you release, you break everyone else's DLLs, which is obviously bad.

Just don't do a strong reference and it won't care about version numbers at all (see here and here). So that should take care of version checking, and I can always write up a really simple piece of code that checks if BROKE is installed and returns the version number that people can use if they want, since that's ridiculously easy to do using reflection. So I think it'll be OK on that front

Load order shouldn't matter I think, because BROKE handles creating the instances of the classes that extend IFundingModifier. Since C# doesn't error due to a missing reference until runtime, and only if that reference is directly needed (aka, calling a function that uses another function in the referenced .dll), it actually should act as a soft dependency. BROKE initializes everything in Start(), so by that time all other .dlls should be loaded, and as long as the other mods don't initialize the IFundingModifiers themselves (which is wrong) then the reference to BROKE should never be explicitly needed. Which should hopefully mean you can build with a hard dependency, but it'll still work just fine even if BROKE's not installed

Basically what it boils down to is that I'm gonna touch the version because it drives me absolutely nuts when I'm debugging things and the version numbers are all 1.0.0.0

Note: I haven't tested all of this yet. I'll let you know what ends up actually happening when I do test it. I am making the assumption that all .dlls get loaded, even ones that don't include a monobehaviour. If so, you'll be able to have addons for BROKE that aren't even fully developed "mods" perse, which would be cool for some reason.

Edited August 31, 2015 by magico13

[nightingale]

Just don't do a strong reference and it won't care about version numbers at all (see here and here). So that should take care of version checking, and I can always write up a really simple piece of code that checks if BROKE is installed and returns the version number that people can use if they want, since that's ridiculously easy to do using reflection. So I think it'll be OK on that front

From reading the SO page you linked to, the Specific Version is only for the compile time check (so if I am project DependentOnBROKE which depends on BROKE, and BROKE changes version, it'll affect whether it refuses to compile without me updating the version in the properties). At run-time it will always look for the version of BROKE that matches what DependentOnBROKE was compiled against. The same SO page talks about getting around this with the App.config - which when building a mod DLL isn't something we can play with (as far as I'm aware).

Load order shouldn't matter I think, because BROKE handles creating the instances of the classes that extend IFundingModifier. Since C# doesn't error due to a missing reference until runtime, and only if that reference is directly needed (aka, calling a function that uses another function in the referenced .dll), it actually should act as a soft dependency. BROKE initializes everything in Start(), so by that time all other .dlls should be loaded, and as long as the other mods don't initialize the IFundingModifiers themselves (which is wrong) then the reference to BROKE should never be explicitly needed. Which should hopefully mean you can build with a hard dependency, but it'll still work just fine even if BROKE's not installed

I don't know enough of the details about what happens on load of .NET assemblies. If it loads an assembly with a class that implements BROKE.IFundingModifier before BROKE is loaded, I have no idea if it will be a problem. It may be that it won't cause a problem unless said class gets instantiated before BROKE is loaded, which wouldn't happen. Either way, the answer will come out when you test it.

Basically what it boils down to is that I'm gonna touch the version because it drives me absolutely nuts when I'm debugging things and the version numbers are all 1.0.0.0

100% agree - which is why I still set the AssemblyFileVersion and AssemblyInformationalVersion to something sane.

Oh, and feel free to have a look at my version check code - I use it for doing version checks against a number of different mods that all capture the version number differently (SCANsat, RemoteTech, ModuleManager), so it tries a number of different ways to get a version. Obviously if you're just using it for checking against BROKE you can just use the appropriate check from there.

Note: I haven't tested all of this yet. I'll let you know what ends up actually happening when I do test it. I am making the assumption that all .dlls get loaded, even ones that don't include a monobehaviour. If so, you'll be able to have addons for BROKE that aren't even fully developed "mods" perse, which would be cool for some reason.

That assumption is definitely correct - works the same way for Contract Configurator stuff (ie. the internal CC_RemoteTech that has the RemoteTech code, but has no MonoBehaviours).

[magico13]

From reading the SO page you linked to, the Specific Version is only for the compile time check (so if I am project DependentOnBROKE which depends on BROKE, and BROKE changes version, it'll affect whether it refuses to compile without me updating the version in the properties). At run-time it will always look for the version of BROKE that matches what DependentOnBROKE was compiled against. The same SO page talks about getting around this with the App.config - which when building a mod DLL isn't something we can play with (as far as I'm aware).

Hmm, I was linking those from mobile without reading through entirely. I'm looking into it more now (though I should be working ). If it's true that it requires a specific version, then that is a problem.

I'll test this tonight and let you know if it is indeed a problem. If it is, then I'll need to think of a workaround (which might just be to keep the version number the same, as you said). Thankfully, the BROKE core shouldn't need to change except for KSP updates once I get it set up, since most features will actually just be Funding Modifiers.

Edit: I did find this snippet on the actual msdn website, which might lead to something useful.

The runtime distinguishes between regular and strong-named assemblies for the purposes of versioning. Version checking only occurs with strong-named assemblies.

Edi2: Everything I'm reading about strong-named assemblies makes it sound like you have to very deliberately make a strong-named assembly (with a private key and manually running some things). I don't recall ever doing this and it doesn't look like Visual Studio does by default. So maybe it won't be an issue?... It's very unclear to me at the moment. I'll do some testing when I get home and report back. If I can ignore version checking then it will make life much, much easier. I do believe you're correct in that we can't do version redirection as we don't have access to the appropriate configuration files. Plus then anyone wanting to reference BROKE would have to make those changes, at which point it's easier just to do our own informal versioning and just keep the assembly at 1.0.

Edited August 31, 2015 by magico13