We have a sleep/wakeup mechanism in the game since version 0.9 and it goes like this: Inserters taking from belts may become inactive when there is nothing happening on both transport lines to save UPS. While groups merging has to be done immediately (having multiple groups being able to interact with each other would create race conditions), splitting does not.īy far the largest issue we faced was that the transport lines aren't entirely independent. The opposite is also true: the player is able to remove some connections making the group contain multiple components which can be extracted to separate groups. Maintaining those groups in itself was a challenge: when a player builds or rotates a transport belt, underground belt, or splitter, transport lines will change their connections and some groups may now be connected, and they need to be merged. So he decided to just add it, and prevented the flip problems by just disallowing flipping blueprints that wouldn't flip properly. Due to these asymmetries, if you flipped a blueprint with these entities, the result would be non-functional in the best case, and cause complete chaos in others.īut then kovarex was playing and really really wanted to just copy and flip his train unloading setup (just your typical Inserters, chests, and belts). The reason being, well not everything can flip, things like oil recipes, rail signals, pumpjacks etc. It was requested a lot over the years, and we always said no. More about that next week!įor now, we want to go over some of the features of the 1.1 that you might have missed until now if you've been sticking with stable 1.0. Its like cleaning the kitchen properly, so you can start cooking something fresh. So I'm pretty thrilled to finally get to the point, where we actually have 0 known issues and 0 active bug reports on the forums. But it proved to be a mistake wording it this way, since some media picked up on it and presented it as a "fairly bugged release". In other words, it was quite reasonably stable, which normally goes without saying when it comes to Factorio stable versions. These were obviously minor issues, things hard to reproduce or very rare problems. Not sure at what point too many blueprints begins to affect load/save times, but it certainly does eventually.When we were releasing the 1.0 FFF-360, we actually stated that there were "around 150 bugs on the forums and around 80 internal tasks to be solved". Instead of copying in the years worth of misc blueprints I'd collected, I only saved back a handful of must have blueprints. And it ALSO made my existing saved games, that took soooo long to load and save before, now load instantly!! Saves super quick now also!įinally I loaded back up the "backup blueprints" game I'd earlier saved. Result - Well as you can imagine, it reset me back to 0 saved blueprints. Then I deleted blueprint-storage.dat file (don't worry the game will recreate an empty one). Then I copied all my blueprints into the inventory of the hero and saved a game called "backup blueprints".Įxit game. In my case this had grown to 160mb (I had tons of blueprints). They are found in the file blueprint-storage.dat found in %appdata%/Factorio. Turned out to be that I had way too many blueprints.
#FACTORIO TRAIN LOADING FULL#
A lot of the slowdown is likely caused by the lua/c interface combined with lua being interpreted (slow), and none of that is really fixable without either making sandboxing really difficult to do reliable (say via luajit, that can remove both the interpreting slowdown since it JITs and the lua/c interface as it can call C code directly, but that would likely break the API to switch to that), or would just outright break the API in full (say using a wasm JIT to run mods in with api to map the C memory in as appropriate for the right calls, much larger work). Now add in that some mods edit prototypes, or walk all the prototypes, and this time gets *huge*.
#FACTORIO TRAIN LOADING MOD#
An example with round values to make it clear: Say the vanilla game takes 5s as per the prior post (faster for me but linux/ssd/etc), and say you add a single simple mod, it will increase the loading time by 10ms or so, now add mods to get up to 10 simple QoL non-prototype-editing mods, you'd think it would scale up to 10*10ms for 100ms slower, but instead it causes each mod to take about 5*10ms per extra mod added, so with 10 mods each mod now takes about 50ms to load, so it's now 50ms*10 for 500ms, and this keeps compounding. Something I've noticed and mentioned somewhere before is that I did testing and found that for each additional mod added, even tiny QoL mods that don't adjust prototypes, increases the time for every mod to load. Vanilla factorio loads almost instantly, it's mods that slow it down.
0 kommentar(er)
