[MOD 2.0] Global Tick Time Scale - Change the UPS/FPS of Factorio without changing the game pace.

[Zanthra]

Title: Global Tick Time Scale
Short Desc: Change the base UPS/FPS of Factorio without changing the game pace. Allows almost-normal gameplay at 120hz.
Factorio Version: 2.0
Mod State: Stable
Dependencies: Base
Author: Zanthra
Downloads: https://mods.factorio.com/mods/Zanthra/GTTS
Source: https://github.com/Zanthra/GTTS

GTTS 1.7.4 2024-10-27
=====================

The Mod should be updated for Space Age now, although there will be more polishing to do.

This mod changes all available prototype speeds and durations to effectively change the duration of one game tick. This allows players to speed up slow factories by increasing the amount of time the game has to calculate the tick without having to delay the game, or allows the game to be played at higher framerates for players that have high refresh rate monitors.

Due to item locations on belts being quantized to 1/256 of a tile, accurate item movement on belts requires a UPS value of 480/x. Suggested UPS for belt accuracy are:

480, 240, 160, 120, 96, 80, 60, 48, 40, 32, 30, 24, 20, 19.2, 16, 15 and 12

The mod is somewhat limited in what it can change, so references to speeds or rates will be incorrect based on the ratio between the target UPS and the base 60 UPS. If for example a boiler lists it's energy consumption as 7.2 MW it effectively means that it will use 7.2 MJ in 60 ticks. At 30 UPS this will take 2 seconds in wall time, which matches with the normal rate of 3.6 MW at 60 UPS. Because all production and consumption rates are adjusted equally, everything balances out to work at the original Factorio ratios. Unfortunately train schedules are going to be incorrect as well, as they are again based on 1 second being equal to 60 ticks.

Some of the changes this mod makes are saved in the game file. By default this is limited to only the game speed, so a simple "/c game.speed = 1" command on the console can return the game speed of a modded save to the original 60 UPS. However you can also use the "Reset Game Speed" map specific option to immediately reset the game speed to 60 UPS, as well as disable any other save game stored adjustments like hand crafting speed before saving the game so that the mod can be disabled with minimal disruption.

In safe mode no runtime events are added, meaning the mod can make no changes beyond those made to prototypes when factorio loads. Game Speed must be adjusted manually, along with any hand crafting speeds.

Useful console Commands:

/c game.speed = {target-ups} / 60
/c game.player.character.character_crafting_speed_modifier = 60 / {target-ups} - 1

Zanthra (zanthra+factoriogtts@gmail.com)

Factorio Mod Portal: https://mods.factorio.com/mods/Zanthra/GTTS
Factorio Forums: viewtopic.php?f=144&t=50281

[keyboardhack]

Someone finally made this mod!
Haven't tried it yet but this will also solve the issue of slow mega bases. If your base runs at ~20 ups then this mod can change the default game update rate to 20 which will make the game run at normal speed.

BTW looked at the code and it looks really nice

[Zanthra]

I had not thought a lot about the reverse use for it, although I see how it could be useful. Be careful of the reduced fluid flow rates if you go down in UPS, it could break normally balanced chemical and power operations. It may also break some belt compression techniques if the belts are moving too far in one tick for the game to load the items into place properly.

[Patashu]

For fluid flow rate, I think it's related to pressure_to_speed_ratio, flow_to_energy_ratio, max_push_amount and/or ratio_to_push. I don't think you can get a perfect slowed down/sped up simulation just because fluids will still be moving at a rate of one pipe/tick, but I think you can make it so the amount pushed is 2x, 3x, 1/2x, etc. as much of what it used to be.

http://lua-api.factorio.com/latest/LuaF ... otype.html

[Zanthra]

Yeah, the problem with fluid flow is that the math behind those values is rather obscure, and I can't think of a good way to reliably test that any changes I make have the desired effect. I went ahead and added a checkbox in the settings to enable a wild guess at a fluid adjustment, which simply modifies the pressure_to_speed_ratio by the gtts_time_scale . I have also moved everything into the data-final-fixes instead of data-updates since some mods like Angel's were adjusting Bob's chemical plants after my mod adjusted the crafting speeds. Final Fixes is likely to have less incompatibilities than updates, although problems could crop up.

[Kayanor]

Moved from Non-Game-Changing on Creator's request.

[Zanthra]

Added a prototype type exclusion and added "god-controller" to that exclusion list to fix compatibility with Factorio 0.15.26 .

[Zanthra]

I am thinking of rereleasing this mod as a 1.0 stable release since I have been playing with it enabled and everything looks fairly good. I also want to update the description to be more useful given that if someone runs across it in the mod list in game that's all they see.

Is anyone using this mod, and if so in what way? Are you using it how I do to increase FPS on high refresh rate displays, or do you use it to reduce calculations in slow factories? If the later, how does it perform, and do you end up with trouble with belt compression or the like? I am thinking if people are more using to to target a framerate below 60fps, I should change how I present it from focusing on 120hz and the like to being more generic time scale mod.

Right now the only change that gets saved into the save game file is the change in game speed. I mention both here and in the mod portal that if the mod is removed, you may have to reset the game speed manually. Is there any good way to avoid this, or to let players know by some notification popup when the game is started? I decided to keep this mod as contained as possible to making changes to the game's prototypes only because I wanted it as easy to stop using as it is to start using it, but if someone misses the notice about resetting the game speed and don't understand why there game is running fast, they could have their save game messed up.

For those same reasons I don't change player hand crafting speeds, (in addition to concerns of compatibility with hand crafting speed research that I use). Should I add another checkbox under options to change hand crafting speeds even if it gets saved to the game file and can cause incompatibility?

I decided not to mess with day length because it seemed way more complex than changing some variable for the length, and there are well known stable mods out there that can be used to double the day length alongside this mod.

Does anyone have any thoughts or suggestions for the mod?

Thanks,
Zanthra

[jonatkins]

I'd been thinking about writing a similar mod, for running the game at 30 UPS, after I'd made this post - viewtopic.php?f=6&t=32003

[jonatkins]

I've been trying this mod on my current game, which is a largely logistics-driven base that runs at around 25-30 FPS/UPS before adding this mod.

I've configured GTTS for a target of 30 FPS, which should get things running to around normal speed again, but had major issues with roboports.

The problem I had is that bots were not entering roboports - they'd end up stuck at the position of the hatch, but the hatch wasn't opening and they were stuck. After a bit of investigation I removed "request_to_open_door_timeout" from prototype_durations, and this seems to have fixed it. Given the default value is 15 and my target FPS would halve such values, perhaps (some?) values need to be rounded up/down specifically?

[jonatkins]

Also, I just noticed the game.speed setting hadn't been applied when loading the existing save, despite the option being ticked.

[Zanthra]

Alright. I have fixed the issue with roboports, and another issue I had with fluid animations by no longer adjusting flow_length_in_ticks and request_to_open_door_timeout (rounding them did not work). Their impact on the game I think is somewhat minor, so it should not be a problem. I will investigate minimum and maximum values for them later. I also changed the event handling for adjusting the game speed to properly update when the mod settings are changed. There is also an option in the per map settings to immediately set the game speed back to 60 UPS (with no change to the prototypes since that's done on startup) useful it you want to save the game before removing the mod.

[Septimus ii]

Does this mod affect power production/consumption? My power network is going haywire and I don't think it's because I need more reactors

[Zanthra]

Yes this mod adjusts both power production and consumption, but it adjusts them in sync such that it should not make an apparent change to gameplay.

What target framerate are you using for this mod, and what other mods are you using? What do you mean by haywire? Is this an issue with the electrical network overview graphs moving extra fast, or is this actually affecting your base? One possible cause is trouble with fluid flow such as steam or water to the power production due to the fluid speed adjustments which you could try turning off in the mod options.

[Septimus ii]

I'm targeting 20 FPS. and my nuclear setup is suddenly a long way short of powering my factory. I think it's producing the same amount of power as before in GW, but my satisfaction is somewhere near 25%. Maybe consumption is trebled when running on this speed, but nuclear reactors are still producing the original amount of heat energy? The reactors are sitting at 600C - 630C, so I don't think it's a problem with the heat pipes

[jonatkins]

I've not had a chance to investigate why, but I saw similar nuclear issues in my game when targeting 30 FPS

With a 4 reactor setup, this runs 48 heat exchangers without GTTS, as expected.

But with GTTS active this stops working correctly. Reactors can't maintain 999 degrees, instead falling to the 700s. Disconnecting half of the heat exchangers from the 4 reactors gets things pretty much working correctly, although heat was struggling to reach the most distant heat exchangers sometimes.

[Zanthra]

I had a lot of trouble pinning this down. I did add "max_transfer" under the "heat_buffer" property of reactors and heat pipes to be adjusted, but the values for those were already so high at 10GW and 1GW that it should not have been the problem. Testing showed it was not the problem. After doing some research, I found that deconstructing and reconstructing the reactor will allow it to heat up properly. It seems there is some variable stored in the reactor based on the power output, so if the reactors were built at 40MW, then are modded to 80/120MW they have problems (I think the Energy Consumption simply stays at the old 40MW). I will see if I can confirm this being a problem then report it as a bug.

I will release another version of the mod with the added "max_transfer" adjustment as well.

[Septimus ii]

That's fixed it. I have power

Has anyone noticed a problem with solar panels? I've started making a solar farm and it feels instinctively like they're producing less than I would expect, but I didn't calculate it out properly.

[jonatkins]

Ditto, thanks! In fact, it seems like you only need to remove/replace half the reactors - enough that the neighbour bonuses are recalculated - hints to what the bug is.

And as for solar, yes, I noticed that after trying this mod again my solar output hasn't doubled in the power usage graphs, unlike the production/consumption for everything else.

[jonatkins]

Also, now my factory wasn't falling apart with power issues, and I've had a chance to monitor it for a while, I noticed more logistics bots were active than expected. Looked like more were waiting to charge than usual, and on checking I saw that roboports "Robot recharge rate" was still 4 x 1MW, as it is without GTTS. Global energy consumption by roboports was also low - hadn't doubled compared to pre-GTTS like everything else.

Adding charging_energy to prototype_power_rates seems to fix the problem.