Home Artists Posts Import Register

Content

Hello everyone and welcome to a quite important development blog.

Over the past weeks we were wondering if we made the right decision back in the day to keep everything independent, and we have now came to a conclusion we really didn't.

To put it into perspective - we have spent weeks writing a very complex code for the Cuisine mods - Cooking and Brewing, allowing us to make complex production chains easily - which in turn keeps the game interesting for you, and easy to mod for us!

Problem is, when we started working on mead for Vanilla Factions Expanded - Vikings, we noticed that if we simply duplicate this code it will cause a cascade of performance issues, slowing your game to a halt. Some code just cannot be duplicated.

How do we fix that? By creating our own framework. To make it easier for you, we decided to turn Vanilla Factions Expanded - Core into Vanilla Expanded Framework, meaning if you are already a subscriber to any of our faction mods, you don't need to do anything else. To those who are not subscribed to Vanilla Factions Expanded - Core, you will notice that some mods will now require it.




You probably heard rumors that Vanilla Factions Expanded - Core is bad for performance. Well, it was, but we have now invested several hours into fixing any performance issues - it runs smoother than vanilla now!

On day one, following mods will require Vanilla Expanded Framework:

Vanilla Factions Expanded - Medieval

Vanilla Factions Expanded - Settlers

Vanilla Factions Expanded - Insectoids

Vanilla Cooking Expanded

Vanilla Brewing Expanded

Vanilla Hair Expanded

Over the course of the coming months we will slowly move all the important code from other mods into this framework as well. I'd like you to know that this process takes an extraordinary amount of time and work from many developers you might already know, and I'd like to take this moment to introduce them:

So in the future if you see us releasing a mod, and the description will have this graphic:

It means you need to have the framework running for it to work.

I hope the reason for this move that I've stated is sufficient for you. I was always against using frameworks, as it's an extra thing you need to subscribe to, and I want to keep it as simple as possible, but in this case if you want quality mods in the future, this is the way.

Comments

Anonymous

Makes sense. The effort and time you guys spend on the series keeps amazing me.

Anonymous

Makes sense, especially with all the great content that is being released and how each mod interacts with each other. Great to see guys. Great work.

Anonymous

All for it if it means better performance and keeping the awesome mods coming!

Anonymous

If it makes it easier and better performance no one should complain.

Anonymous

Nice! Thank you all for your amazing work!!

Anonymous

Will this make new mods easier to make? And quicker?

oskarpotocki

Yes and no. It will mean we can reuse the code we already have written. For example I can easily add facial paint mechanic to Vikings using the same code we use to generate beards without duplicating code.

Anonymous

This is the way

Anonymous

Hope we can get Space Module updated, as well as link sink with Heligen gas stove with this Framework unity

Anonymous

Yeah, well. If you maded just a few would make sense not to make a framework, or if you used just xml's We use a lot of your mods so, it's better this way now. Was something fixable anycase, just a minor setback. :D

Anonymous

Hope it doesn't halt mod development much

Anonymous

Happening concurrently, mostly migrating code into the framework and away from the individual mods. Largely already done!

Andy Burchett

Good decision. 100% support.