This modpack bundles all of the Factorio HD Age mods for the Base Game and the Space Age DLC. It doesn't contain any content itself. It only references to the other Factorio HD Age mods as required dependencies. A total of at least 13 GB of VRAM is recommended.
Collections of mods with tweaks to make them work together.
Transportation of the player, be it vehicles or teleporters.
Augmented or new ways of transporting materials - belts, inserters, pipes!
Trains are great, but what if they could do even more?
New ways to deal with enemies, be it attack or defense.
Armors or armor equipment.
Changes to enemies or entirely new enemies to deal with.
Map generation and terrain modification.
New Ores and resources as well as machines.
Things related to oil and other fluids.
Related to roboports and logistic robots.
Entities which interact with the circuit network.
Changes to power production and distribution.
More than just chests.
Hello!
After the update, loading mods began to take an indecently long time.
In total, I have 21 HD mods installed, that is, the entire collection, and their loading time is more than 15 minutes.
The collection "hd_age_space_age_" takes the longest to load:
262.267 Loading mod factorio_hd_age_space_age_base 1.0.8 (data-final-fixes.lua)
335.195 Loading mod factorio_hd_age_space_age_decorative 1.0.9 (data-final-fixes.lua)
397.614 Loading mod factorio_hd_age_space_age_enemies_gleba 1.0.6 (data-final-fixes.lua)
466.539 Loading mod factorio_hd_age_space_age_enemies_vulcanus 1.0.4 (data-final-fixes.lua)
537.390 Loading mod factorio_hd_age_space_age_logistics 1.0.11 (data-final-fixes.lua)
601.313 Loading mod factorio_hd_age_space_age_military 1.0.5 (data-final-fixes.lua)
669.599 Loading mod factorio_hd_age_space_age_production 1.0.12 (data-final-fixes.lua)
744.532 Loading mod factorio_hd_age_space_age_terrain_aquilo 1.0.5 (data-final-fixes.lua)
809.201 Loading mod factorio_hd_age_space_age_terrain_fulgora 1.0.5 (data-final-fixes.lua)
879.897 Loading mod factorio_hd_age_space_age_terrain_gleba 1.0.6 (data-final-fixes.lua)
953.372 Loading mod factorio_hd_age_space_age_terrain_vulcanus 1.0.5 (data-final-fixes.lua)
1020.578 Loading mod filter-combinator-improved 3.8.0 (data-final-fixes.lua)
It takes 758 seconds (12.5 minutes) to load.
What could be the problem?
Hi,
That shouldn't be the case. It takes me about 70 seconds to start the game with all my HD mods.
Could you please start the game with only my HD mods to see if the problem is with the mods themselves or with the combination with other mods?
Sensei!
Yes, it's a combination of all the mods.
Loading all HD mods, with the rest of the mods disabled, takes only 31 seconds.
Any ideas why this is? How can I try to do something?
Maybe it's because HD mods are loaded somewhere in the middle of the list (if other mods are enabled, lots of mods), and it somehow goes through the list and replaces them, or something like that?
Is it possible for testing to make HD mods load first, i.e. put the loading queue at the very beginning? Is this even possible for mods?
Do all your other mods add many tertextures?
Do all your other mods add many tertextures?
I can't say for sure, but most likely yes, since the total list of mods is 450+
But there they rather add something than replace textures, but there are also various mods like "https://mods.factorio.com/mod/alien-biomes", if that means anything.
The update only changed the textures themselves, not how they are integrated.
I optimized only the transparent areas of the textures. First, I removed non-transparent or slightly transparent artifacts from large transparent areas. Second, I set the color saved to transparent pixels to RGB=0,0,0.
The goal was to improve texture cropping, reduce VRAM usage, and enhance performance.
I wonder why this causes problems for you when used with other mods.
With your long list of mods, it's difficult to determine which one is causing the problem.
The quickest method I can think of is to gradually activate half of your mods, along with mine, and see if the problem persists. If the problem occurs, then halve that group again and again ... to see which mod is causing the problem.
Theoretically, with 512 mods, you should be able to identify the problematic mod in 10 to 19 attempts.
Well, I'll try to find this mod, and I'll hope that it's the only one :)
It will take some time, most likely not today, but I'll definitely write back.
The time required for troubleshooting tends to increase with the rarity of the fault.
Don't worry. I'll wait for your result and answer.
Overall, my experiments didn't lead to anything. It seems that with the increase of mods using graphics (which are then replaced by HD), the loading time of mods simply increases linearly.
That is, I simply disabled half of the mods, and loading took about 7 minutes. In different variations and with different mods - the picture is approximately the same.
Then it seemed to me that the answer may be that HD is used in the file "data-final-fixes.lua", since, as I understand it, any changes contained in this file are loaded last, and since other mods use graphics, HD can then go through these mods, according to the list, and somehow either replaces them, or tries to replace them, or does something else, and that's why it takes so long. In the end, I renamed all the files to "data.lua", and as a result, it even seemed to load faster on the clean version. If you enable other mods, then, as expected, some of them have errors where the graphics do not match.
By the way, I encountered this error on my own, although the file corresponds to the required size.
The given sprite rectangle (left_top=0x0, right_bottom=314x314) is outside the actual sprite size (left_top=0x0, right_bottom=314x230).
See the log file for more information.: __factorio_hd_age_space_age_decorative__/data/space-age/graphics/decorative/fulgora-rock/big-fulgora-rock-09.png
The "y" side is specified as an "x" dimension, when it should be specified as "y". Is it possible that somewhere in the code, instead of "height" or "y", "width" or "x" is specified?
Answer First message:
This is a result, but it wasn't a problem before I updated the textures.
I can't explain why it has an influence on the loading times, as it actually reduced the loading times for me.
Yes, I intentionally included my code in the final data fixes because, at this point, the algorithm checks to see which original textures are remaining. Then, it replaces them so that other mods can adjust the textures without mine overwriting them. This is especially important since my mods adjust the scaling factor for rendering as well.
Answer second Massage:
I cannot reproduce this error message. Does the error occur after you have changed data final fixes to data or afterwards?
Does the error also occur when you activate the HD mod alone?
I can't explain why it has an influence on the loading times, as it actually reduced the loading times for me.
On the clean version without other mods, the loading became less? Or with other mods enabled (not HD mods) it also loads without problems?
I cannot reproduce this error message. Does the error occur after you have changed data final fixes to data or afterwards?
Does the error also occur when you activate the HD mod alone?
Yes, if you change "data final fixes to data" in HD-mod, then the error occurs on the clean version (that is, without enabling other mods).
Sorry, I didn't take into account the translation features.
If only HD mods are enabled (the entire collection), and everywhere in them the file "data-final-fixes.lua" is renamed to "data.lua", then this error occurs. Any third-party mods are disabled.
If only "factorio_hd_age_space_age_decorative" is enabled, also with a renamed file, then everything is ok.
Which is strange in itself :)
Have you excluded any textures via my mod settings?
No, I didn’t specify anything in the settings at all, and I didn’t even look there.
Here's another thing, if you disable "factorio_hd_age_space_age_decorative" from the collection, another error appears:
The given sprite rectangle (left_top=0x0, right_bottom=198x198) is outside the actual sprite size (left_top=0x0, right_bottom=198x153).
See the log file for more information.: __space-age__/graphics/decorative/fulgora-rock/big-fulgora-rock-10.png
If you disable the "factorio_hd_age_base_game_decorative", then everything is ok, nothing interferes with loading.
So once again for me to follow:
-If you load all HD mods in their original state, everything works.
- after changing from data final fixes to data the error message appears when loading the Fulgora-rock (You did this because it reduces loading times for you?)
- If you deactivate the decorative package of both, the base game and space age in the modified state, the error no longer occurs?
-If you load all HD mods in their original state, everything works.
Yes, everything works if you don't enable third-party mods, with third-party mods the loading time increases depending on their number.
- after changing from data final fixes to data the error message appears when loading the Fulgora-rock (You did this because it reduces loading times for you?)
Yes, I changed "data final fixes" to "data", hoping that it would reduce loading times with third-party mods enabled. It helped, loading times decreased significantly, but third-party mods caused errors with different sprites. Then I disabled all third-party mods and launched only the entire HD mod collection (with renamed files) - an error with Fulgora-rock appeared.
- If you deactivate the decorative package of both, the base game and space age in the modified state, the error no longer occurs?
That's right, the error no longer occurs, all other HD mods work without problems, all graphics in the game are changed, everything is fine. Only decorative changes are missing, as they are disabled.
Ok, I'll try to recreate it tomorrow.
Sensei! :))))))
If you turn off only "factorio_hd_age_base_game_decorative", and leave "factorio_hd_age_space_age_decorative" on, then no errors occur either :))))
for me it's all very complicated :))))
Thank you! See you tomorrow!
Hi,
I figured out what the problem is. The Space Age DLC is loaded into Factorio like a mod and goes through the same steps as all the other mods. Since my mod comes before the DLC in name order, the Nauvis stones have already been changed. Then, the DLC tries to use them as the basis for the Fulgora stones. However, this fails because the scaling and sizes are incorrect.
It's possible that changing Data-final-fixes.lua in data.lua causes the DLC to overwrite the textures, causing the game to load the normal SD textures instead of the HD textures, which speeds up the loading time.
Hmm.. I thought that in theory if I loaded the mod at the very end the error should be fixed, i.e. after the "Space Age" DLC, and renamed the mod and all the corresponding paths to "zzz_" at the beginning of the mod name, but apparently the problem is still due to the wrong size, as now another sprite gives the error:
The given sprite rectangle (left_top=0x0, right_bottom=140x140) is outside the actual sprite size (left_top=0x0, right_bottom=140x74).
See the log file for more information.: __zzz_factorio_hd_age_space_age_decorative__/data/space-age/graphics/decorative/fulgora-rock/small-fulgora-rock-13.png
Now I'll try to upload from the very beginning, changing the names to "000_"
I'm not a modder, unfortunately, for me it's all very complicated, and I can only do some experiments by trial and error.
:)
The given sprite rectangle (left_top=0x0, right_bottom=396x396) is outside the actual sprite size (left_top=0x0, right_bottom=396x306).
See the log file for more information.: __000_factorio_hd_age_space_age_decorative__/data/space-age/graphics/decorative/fulgora-rock/big-fulgora-rock-10.png
This is if you load the mod at the very beginning.
Now I'll try to rename all the files to "data-update"
Sensei, tell me, are the sprite sizes set correctly everywhere?
With the "data-updates" files, loading is generally fine, but as expected, errors occur again...
The given sprite rectangle (left_top=0x0, right_bottom=1024x1024) is outside the actual sprite size (left_top=0x0, right_bottom=4096x512).
See the log file for more information.: __Dectorio__/graphics/terrain/concrete/defect-right/hr-concrete.png
Perhaps there is a size mismatch for the sprite side somewhere in the code? Or is it not about the sprite sizes?
There is a very slight feeling that somewhere in the code there is a possible inconsistency...
I can't check this right now as I'm not at my PC, but you have to rename my mod so that it appears after the Space Age DLC in alphabetical order. Remember to change both the folder name and the file name.
I'm sure the code is correct; it's due to the data lifecycle.
Have you also checked whether the other HD Age Space Age mods take effect when run with data.lua?
So, I renamed all mod names (and all paths in all files) to "zzz_factorio_hd_age_..." and tried several options:
1. With "data" files - gives an error with stones.
2. With "data-updates" files - launches without errors, but only if third-party mods are not enabled. If third-party mods are enabled, then the launch time is about 120 seconds, and with various third-party mods it gives an error.
3. With "data-final-fix" files - loads without errors, but without third-party mods. If third-party mods are enabled, there are no errors, but the launch takes about 15 minutes (the game crashed a couple of times).
I wonder if anyone else has tried to launch HD mods with a lot of third-party mods? Am I the only one so lucky that I have such problems with launching, or are there other lucky people? :)
In option #2, I excluded several mods that caused a conflict. Loading goes fine, but occasionally, when the sprite loading stage starts, the game just closes (very similar to a lack of memory or something else).
I tested the second option a little and was satisfied: in general, all textures are in HD quality, but there are exceptions. As far as I understand, if any mod loads its textures at the last stage via "data-final-fix", then they become simple quality.
Unfortunately, because of this, some decorative plants, most trees and some ground surface are in simple quality, but this is not so critical, the vast majority is still in HD. At least you can live with this :)
It only remains to somehow solve the conflicting mods so that they can also be used.
Well, thanks for the help, I will not bother you anymore :)
So, I renamed all mod names (and all paths in all files) to "zzz_factorio_hd_age_..." and tried several options:
1. With "data" files - gives an error with stones.
Is the mod displayed in the game with "zzz_factorio_hd_age_..." in the mod list? If not, the name has not yet been changed everywhere corectly.
- With "data-updates" files - launches without errors, but only if third-party mods are not enabled. If third-party mods are enabled, then the launch time is about 120 seconds, and with various third-party mods it gives an error.
Even if the stone problem did not exist, many mods would cause errors when using the data.lua in my mod.
That is why I program everything in data-final-fixes.lua. The reason is explained further below.
- With "data-final-fix" files - loads without errors, but without third-party mods. If third-party mods are enabled, there are no errors, but the launch takes about 15 minutes (the game crashed a couple of times).
In option #2, I excluded several mods that caused a conflict. Loading goes fine, but occasionally, when the sprite loading stage starts, the game just closes (very similar to a lack of memory or something else).
Could your PC's VRAM be too small for all these mods, causing it to take a long time to load because it has to write a lot to the swap memory?
I wonder if anyone else has tried to launch HD mods with a lot of third-party mods? Am I the only one so lucky that I have such problems with launching, or are there other lucky people? :)
So far, you are the only one who has contacted me about such difficulties.
I tested the second option a little and was satisfied: in general, all textures are in HD quality, but there are exceptions. As far as I understand, if any mod loads its textures at the last stage via "data-final-fix", then they become simple quality.
Unfortunately, because of this, some decorative plants, most trees and some ground surface are in simple quality, but this is not so critical, the vast majority is still in HD. At least you can live with this :)
It only remains to somehow solve the conflicting mods so that they can also be used.
Most modders choose data.lua, data-updates.lua, or data-final-fixes.lua for compatibility reasons, so you will probably have to do this yourself.
A simplified summary:
- Data.lua: Load data from data.raw or add new data to it.
- Data-updates.lua: Change data in data.raw, load previously added data in data.raw, or add further data to data.raw.
- Data-final-fixes.lua: Change data from previously added data in data.raw and adds further data to data.raw.
Based on this, it only makes sense to write my HD mods in data-final-fixes.lua. This allows other mods to access the unchanged data (data.lua). Other mods could also change the base game textures in the data-updates.lua. This way, my mods in data-final-fixes.lua can replace all the unchanged textures with HD textures in the final step.
Well, thanks for the help, I will not bother you anymore :)
I was glad to help and you're not bothering me. You're just getting to the point where I can't help you anymore with what you want to achieve by changing other mods.
Is the mod displayed in the game with "zzz_factorio_hd_age_..." in the mod list? If not, the name has not yet been changed everywhere corectly.
Yeah, it shows up, I double checked all the names.
Could your PC's VRAM be too small for all these mods, causing it to take a long time to load because it has to write a lot to the swap memory?
No, I'm sure of it, even considering all this volume of sprites, it is not related to loading video memory. In case of problems with video memory, then sprites would load the same in all 3 cases, with "data", with "data-update", with "data-final-fix", but long loading only in the last case, or it goes through this stage several times.
A simplified summary:
- Data.lua: Load data from data.raw or add new data to it.
- Data-updates.lua: Change data in data.raw, load previously added data in data.raw, or add further data to data.raw.
- Data-final-fixes.lua: Change data from previously added data in data.raw and adds further data to data.raw.
Based on this, it only makes sense to write my HD mods in data-final-fixes.lua. This allows other mods to access the unchanged data (data.lua). Other mods could also change the base game textures in the data-updates.lua. This way, my mods in data-final-fixes.lua can replace all the unchanged textures with HD textures in the final step.
I don't fully understand the loading stages, or rather, I understand them in general terms and imagine how they go, but I don't understand why in the case of the third option the loading takes a long time, that is, the mod somehow interacts with all the previously loaded mods. As I understand it, some mods load their data at all stages, and at the very end (after all, it is loaded last because of the name and the last stage) the HD mod should go through all the necessary files and simply replace them, but something else happens, that is, it looks at not only the necessary files from the base game or DLC, but perhaps looks at all the files in all the mods, or I don't know why.
I was glad to help and you're not bothering me. You're just getting to the point where I can't help you anymore with what you want to achieve by changing other mods.
I tried to understand the logic in the mod code, but with my knowledge it is difficult, but I tried to understand some points.
For example, I get this error:
The specified sprite rectangle (left_top=0x0, right_bottom=426x426) is outside the actual sprite size (left_top=0x0, right_bottom=426x282).
For more details, see the log file: __color-coded-pipes__/graphics/storage-tank/overlay-storage-tank-remnants.png
Overlay is a mask for redrawing the surface of an object. I double-checked all the images this image is linked to, they are all 426x282, as well as in the HD mod it loads. This means that the code expects a square sprite, takes the "size" and since it specifies one number, 426, applies it to the height, getting a square sprite, and then waits for it. If "width" and "height" are explicitly specified, then there is no problem. But why it expects a square sprite, I still don't understand, since according to the files with specified sizes, both the width and height for this image are explicitly specified there. Again, it follows that perhaps somewhere else the size for this sprite is specified, overwriting the width and height with "size", but I only load 3 mods, and the third one is not related to this image, it adds new pipes. There is nothing like "storage-tank" in there. Or here is another example. I get this error:
The specified sprite rectangle (left_top=0x0, right_bottom=244x240) is outside the actual sprite size (left_top=0x0, right_bottom=122x480).
See the log file for more details: __color-coded-pipes__/graphics/pipe/overlay-pipe-remnants.png
This completely confuses me, why does it expect width * 2, and height / 2 :) My brain hasn't been boiling like this for a long time :))))
But, sensei, this is not the main question. The main question concerns the third option: why does "data -final-fix" cause a long loading time.
Sensei, tell me, is it possible to add logging somewhere in the code to understand which files the mod is viewing or trying to change at this stage? That is, to get data on why the loading stage takes so long, and what the mod is doing at that moment.
Apparently this is the reason, I don’t understand what it is yet, but it’s definitely connected to this, maybe... :)
{
type = "corpse",
name = "pipe-remnants",
...
animation = make_rotated_animation_variations_from_sheet(2,
{
filename = "__base__/graphics/entity/pipe/remnants/pipe-remnants.png",
width = 122,
height = 120,
line_length = 1,
direction_count = 2,
shift = util.by_pixel(1.5, 2.5), -- -0,5
scale = 0.5
})
}
Perhaps I should rest for a couple of days, otherwise I can't think of any ideas :)
In general, as they say, "if the mountain won't come to the man, then the man will come to the mountain " - the issue was resolved, but I went the other way, creating HD graphics for the conflicting mods, and now I just have more of it :)
All this eats up a gigantic amount of memory, the peak consumption reached 24+ GB :)
Hi,
you are not alone. I too have the same exact issue with long loading times when the HD mods are enabled. (Also with many other mods. :D)
Since I only have 12GB of VRAM I guess your "workaround" won't be an option for me. :D
This might be placebo, and I don't know if that is possible: When I just did the test of disabling all your mods to see if loading time decreases, after re-enabling them Ioading time are significantly shorter. Not short, still 1-2 minutes, but shorter. Is it possible that disabling and enabling changes load order of mods?
Hi!
How much RAM do you have?
How many mods do you have, and how long does it take to load with all mods enabled?
12 GB VRAM
32 GB RAM
Just timed it at 4 minutes. While doing that I saw my RAM hit its limit. So in my case it really might be an issue of memory swapping to the page file, which would also explain my system lags during loading process. I think I might just have underestimated the memory usage of this mod. :D Usually I am not used to see these kind of usages, so I did not even think in this direction.
Well, 4 minutes is still bearable, I had 15 minutes, but a lot of mods are installed.
Yes, you need to increase the swap file so that there are no errors at maximum use.
And yes, most likely my option will suit you, and will reduce the time to a minute most likely, but problems may arise if one of the mods conflicts with the graphics from HD mods.
I can drop the modified HD mods on Google Drive, you can download them, disable simple HD mods, and check if it helped, and how long the download will take (unless of course there are errors)
I think I will stay with the standard HD mods. Since I know now what probably the issue is I can work with that. I only need to make sure that I don't have any other RAM hungry apps running during loading process. That seems to help a lot.
Please let me know later if this method helped :)
It definitly does. But I think it is because I am sitting on some kind of sweet spot with my 32 GB RAM + 17 GB Page File. so that, if I have no big other things running, the swap to the page file seems minimal and therefore the loading process much faster. Yesterday I had chrome and 2-3 bambu labs in the background and the loading process was long and the other programs, especially youtube videos, started to get laggy, which usually tells me that swapping is done in an unhealthy amount. :D
In case you are using the mod wide chests / merging chest: try removing that and. Its variations. I found out that this mod has a massive loading problem with custom settings, and somehow that problem escalates with the HD mods active, probably due to its sheer size. When you increase the max area of chests even just to 20x20 loading times increase exponentially.
Can you send me your "mod-list.json" file, it lists the mods you have and which are currently enabled.
I'm curious how many mods you have and want to try loading with these mods to compare loading times.
I spent some time this week trying to narrow down the problem.
I only changed the textures with the update and didn't modify my program code.
Therefore, I conclude that the longer loading times are not related to my program code because the other mods and my program code were already there before.
What effect could adjusting my textures have?
I optimized the transparent areas of the textures. I removed non-transparent or slightly transparent artifacts from large transparent areas. Then, I set the color stored for transparent pixels to RGB=0,0,0. This allows Factorio to better crop the textures to the content and thus reduce VRAM requirements.
As you've discovered, the problem doesn't occur if you load my mods earlier in the data lifecycle, or if you only load my mods. You also noticed that loading times increase with the number of mods.
From what I understand, my update requires the graphics card to crop many more textures. Combined with all the other mods, this greatly increases loading times if your VRAM is maxed out.
In other words, if your graphics card's VRAM is maxed out while or before one or more of my mods loads, the loading time will increase significantly.
The cropping process slows down considerably when it has to access external memory instead of VRAM.
The only solution I can see at the moment is to load my mods earlier in the data lifecycle, which is what you are trying to implement.
Unfortunately, at this point, I have to consider what will provide the best user experience for the majority of users. For this reason, I will not implement this solution, as it would cause significant compatibility issues for many users.
I may come up with another idea later, or perhaps you have some suggestions. Otherwise, I'll put this topic aside for now.
You might want to try the following:
Start your game, hold ctrl+alt and click on Settings, this should open the hidden options menu called "The rest", open it up. Search for "cache", it should show you 4 options, enable "cache-sprite-atlas". This should reduce the startup time after your first load.
IMPORTANT: Once enabled, the game will load slowly on startup one time. Afterwards the game will load significantly faster.
If the game is modified by for example being updated or modified (changed or probably updated installed mods), the game will load slowly one time, but consecutively it will load fast again.
Thanks. This helped a bit, but not too much. At the end the loading process got a little faster during the "Loading sprites" phase, but most of the time goes by on 9-11% where the mods themselves are loadad.
However, just to be clear. The textures very much are worth the additional loading times. Thank you for your hard work. :)
Wait, does the problem occur at the beginning of the mod loading phase, around the 9 percent mark? Then it's not a cropping issue and I completely misunderstood that.
I'm completely at a loss as to what the cause is. As I said, I haven't changed anything in the program code, and it didn't cause any problems before the texture update. From what I know about the loading process, changing the textures shouldn't have any impact at this stage.
One more idea: please disable all mods whose update date is after July 1, 2025, except for mine, of course. To find out the update date, please sort the zip files of the mods in the mod folder by update date.
Yes, at least for me most of the time is around 9%. I tried to clock the phases and times a bit more detailed:
~00:00 / ~00% ... Start
~00:09 / ~09% ... The first HD mod name comes up in the progress.
~03:28 / ~09% ... End of the HD mods in progress;
~03:35 / ~50% ... Cropping Bitmaps phase start (Jump to 50% pretty fast)
~03:48 / ~60% ... Loading sprite phase
~03:54 / 100% ... Complete
This is with the setting you proposed earlier. So the last two phases would have taken a bit longer before.
Maybe Hoochie should try this as well. He had the much more severe loading times. Maybe his problem is other than mine focused on the latter phases of the loading process.
If I disable all mods with update date >= July 1, 2025 it reduces loading times by around a minute. But this takes out quite a chunk of content as well:
~00:00 / ~00% ... Start
~00:05 / ~09% ... The first HD mod name comes up in the progress.
~02:54 / ~09% ... End of the HD mods in progress;
~03:05 / ~50% ... Cropping Bitmaps phase start (Jump to 50% pretty fast)
~03:11 / ~60% ... Loading sprite phase
~03:15 / 100% ... Complete
The mods I deactivated:
- Lignumis
- Corrundum
- Metal and Stars
- Muluna, Moon of Nauvis
- Secretas & Frozeta
- Tenebris Prime
- Astroponics
- Behemoth Enemies Mod
- Bio processing group
- Burning Cargo Pods
- Cerys
- Display Plates . Ground Signs & Map Markers - Forked
- Factory Planner
- Hard Aquilo
- Hard Cerys
- Hard Fulgora
- Hard Gleba
- Hard Vulcanus
- Hellmod: Assistant for planning your factory
- Janus
- Lane Filtered Loaders
- Maraxis
- Muluna Graphics
- PlanetsLib
- PlanetsLib: Tiers
- Pollution as surface property
- Random colors
- Space Age Hard Mode (Beta)
- Starmap: Nexus
- Wooden Cerys: Lunaponics
And here, just as a frame of reference the loading times with ONLY the HD mods active:
~00:00 / ~00% ... Start
~00:01 / ~09% ... The first HD mod name comes up in the progress.
~00:38 / ~09% ... End of the HD mods in progress;
~00:39 / ~50% ... Cropping Bitmaps phase start (Jump to 50% pretty fast)
~00:44 / ~60% ... Loading sprite phase
~00:50 / 100% ... Complete
... and with ALL BUT the HD mods active:
~00:00 / ~00% ... Start
~00:13 / ~09% ... Loading mods finished
~00:15 / ~50% ... Cropping Bitmaps phase start (Jump to 50% pretty fast)
~00:19 / ~60% ... Loading sprite phase
~00:23 / 100% ... Complete
Okay, at this point, I think we need to distinguish between two things.
Paktai: I consider a loading time of 3:15, or approximately four minutes, to be normal, given the number of mods.
Hoochie: your loading time of 15 minutes is not normal, especially since your log entries show that it is explicitly caused by my mods. Please try the following as well:
One more idea: please disable all mods whose update date is after July 1, 2025, except for mine, of course. To find out the update date, please sort the zip files of the mods in the mod folder by update date.
Hello!
Sorry for the delay, just got home from a trip.
Okay, now I'll try to disable mods with an update date after July 1, 2025, I have 127 mods (but I assume that for the sake of the experiment, I need to download the original versions of HD mods, and not the ones I've modified).
Well, the long loading of mods for me is precisely at the stage of loading mods, that is, this is due to the code (stages of loading changes), and not textures.
So... funny, it works :)
But what does that mean, sensei? :) What is the difference between mods before July 1st and after July 1st?
Loading time for HD mods became 114 seconds, that is almost 2 minutes, which is just really cool.
12.374 Loading mod factorio_hd_age_base_game_base 1.0.8 (data-final-fixes.lua)
19.772 Loading mod factorio_hd_age_base_game_decorative 1.0.4 (data-final-fixes.lua)
24.958 Loading mod factorio_hd_age_base_game_enemies_nauvis 1.0.7 (data-final-fixes.lua)
30.605 Loading mod factorio_hd_age_base_game_logistics 1.0.9 (data-final-fixes.lua)
42.609 Loading mod factorio_hd_age_base_game_military 1.0.9 (data-final-fixes.lua)
48.497 Loading mod factorio_hd_age_base_game_production 1.0.4 (data-final-fixes.lua)
54.448 Loading mod factorio_hd_age_base_game_railway 1.1.0 (data-final-fixes.lua)
59.402 Loading mod factorio_hd_age_base_game_terrain_nauvis 1.1.0 (data-final-fixes.lua)
64.145 Loading mod fiber-optics 1.2.1 (data-final-fixes.lua)
.....
77.857 Loading mod factorio_hd_age_space_age_base 1.0.8 (data-final-fixes.lua)
84.808 Loading mod factorio_hd_age_space_age_decorative 1.0.9 (data-final-fixes.lua)
91.493 Loading mod factorio_hd_age_space_age_enemies_gleba 1.1.0 (data-final-fixes.lua)
96.594 Loading mod factorio_hd_age_space_age_enemies_vulcanus 1.0.4 (data-final-fixes.lua)
102.063 Loading mod factorio_hd_age_space_age_logistics 1.0.12 (data-final-fixes.lua)
107.593 Loading mod factorio_hd_age_space_age_military 1.0.5 (data-final-fixes.lua)
113.083 Loading mod factorio_hd_age_space_age_production 1.0.12 (data-final-fixes.lua)
119.137 Loading mod factorio_hd_age_space_age_terrain_aquilo 1.0.5 (data-final-fixes.lua)
124.226 Loading mod factorio_hd_age_space_age_terrain_fulgora 1.0.5 (data-final-fixes.lua)
129.699 Loading mod factorio_hd_age_space_age_terrain_gleba 1.0.6 (data-final-fixes.lua)
135.150 Loading mod factorio_hd_age_space_age_terrain_vulcanus 1.0.5 (data-final-fixes.lua)
140.634 Loading mod fish-traps 0.1.0 (data-final-fixes.lua)
For comparison, I enabled 2 mods "color-coded-pipes" and "color-coded-pipe-planner" - colored pipes and for painting pipes.
The loading time of "factorio_hd_age_base_game_logistics" increased from 12 seconds to 26 seconds, and in principle the time of all HD mods increased to 223 seconds ((((
This means that one or more mods updated since July 1 has increased the number of data.raw entries significantly. Since each of my mods searches these entries individually for changed graphics, the loading time has increased significantly.
Why July 1st?
Is it possible to bypass this condition of searching for each entry? Maybe at least locally for a separate copy of the mod? Or is this the basis of the mod itself?
This means that one or more mods updated since July 1 has increased the number of data.raw entries significantly. Since each of my mods searches these entries individually for changed graphics, the loading time has increased significantly.
Hmm... I don't even know where to look yet, because it doesn't fit into my thoughts yet.
400 mods load in 114 seconds, but if you enable the 2 mods that I mentioned above, the loading time increases almost 2 times, and if you enable all the other 127 mods, the time will be 15 minutes.
Why July 1st?
I began updating my HD Age mods after July 10, 2025. I factored in a generous grace period for when the other mods must have changed to create the impression that the change was due to my mod updates. You are welcome to test this again with a later date, e.g., July 7, 2025.
Is it possible to bypass this condition of searching for each entry? Maybe at least locally for a separate copy of the mod? Or is this the basis of the mod itself?
Unfortunately, this is the core component of the mods and was not originally created by me (TextureBase).
It is designed so that textures from the base game or other mods can be replaced.
400 mods load in 114 seconds, but if you enable the 2 mods that I mentioned above, the loading time increases almost 2 times, and if you enable all the other 127 mods, the time will be 15 minutes.
Are there any other mods among the 127 mods that contain a lot of textures?
Yes, almost every mod adds textures, and only 20-30 change some mechanics. The total size of textures (mods) is slightly more than 1.23 gigabytes.
The size in GB is irrelevant. The important question is how many textures have been added since July 1, 2025 by this Mods.
You can read through the changelogs for these mods to see if there is anything noticeable in terms of new textures or significant changes to the code.
Uh, well, I'll play with the modified mods for now, there are some minor issues, but nothing too critical.
Well, at least there are only two of us who wrote about this problem, although it's possible that we were the only ones who wrote about it, others could have simply disabled HD mods because of the long loading time, considering it normal.
About the size, I mean that a regular image doesn't weigh much, and a large number of them will fit in 1 GB. For example, here is "https://mods.factorio.com/mod/ev-assets" - it contains about 1000 images, or maybe a little more.
You two are not the only ones who have reported loading times so far. Everyone else, including Paktai, experienced loading times between one and four minutes. As I mentioned earlier, I consider this to be normal and realistic given the number of mods.
You, Hoochie, are the first to report extremely long loading times of 12 to 15 minutes.
And why am I so unlucky :))))) Apparently somewhere I ruined my karma, being that one and only :)))))