Why isnt there a setting for changing default UPS?

[Virenz]

When playing this game on big worlds, i notice the UPS drops, meaning the game speed gets decreased. I dont, however, understand why there cant be a setting to set the default UPS for which the game runs at normal speed. I know there is game.speed but if you set that to game.speed = 0.5 it sets the default UPS to 30, but the games actual speed is also halved. I program in c#, so i know that this is a pretty easy task. If the player sets the default UPS to 30, the game does a ONE-TIME calculation to work out the variables needed, and then does 30 updates per second. For example, if a a bar on a assembly machine increases 1.5% a second (this not how you really write code):

Void UPSChanged()
{
SetUPS = input.value;
x = 1.5 * (60/SetUPS);
FixedUpdate.updatespersec = SetUPS;
}

Void FixedUpdate()
{
progressbar.percent = progressbar.percent + x
}

So, essentially, instead of progressbar.percent + 1, and then progressbar.percent + 1, you are doing progressbar.percent + 2 in the equal amount of time. People making megabases are already running at a UPS of about 20, so if they set there default UPS to 20 all it would do is put them back up the normal speed.

[ssilk]

Interesting idea...

I think the problem is, that not all tasks begin or end at even ticks (if you double the speed - I think that is the most simplest case).

How will you handle those?

[Virenz]

I thought everything is based on the UPS, because UPS is just the fixedupdate rate assigned to a void function (i.e: the update rate of the code in certain voids) , could you give some examples?

[ssilk]

For example a belt where an item is only 1 tick away from the end of a belt.
If you just double the speed, the item will be shifted one tick too long. The item would be moved over the end.

[Zeblote]

For example a belt where an item is only 1 tick away from the end of a belt.
If you just double the speed, the item will be shifted one tick too long. The item would be moved over the end.

That's not really a problem, you're doing a collision check anyways. If it can only move 0.1 tiles to the end, that's how far the whole belt moves.

I can imagine other things not working well with a lower tick rate, though. Like inserters picking up things from belts. If you increase the time between ticks, you also degrade the quality of the simulation.

[ssilk]

For example a belt where an item is only 1 tick away from the end of a belt.
If you just double the speed, the item will be shifted one tick too long. The item would be moved over the end.

That's not really a problem, you're doing a collision check anyways. If it can only move 0.1 tiles to the end, that's how far the whole belt moves.

With the side-effect, that an inserter also can insert only at even ticks.
Or - much uglier - the inserter won't insert, cause he "oversees" the gap of items in a belt, cause it was just one odd tick visible to him.

I can imagine other things not working well with a lower tick rate, though. Like inserters picking up things from belts. If you increase the time between ticks, you also degrade the quality of the simulation.

Everything is related to this.
And maybe there is also a big misunderstanding: AFAIK (I'm really not so sure about it) the assembly for example doesn't update it's state every tick. It calculates at the start: How long will it take to assemble this? An event is then programmed in the future. The assembly will wake up at the time outputs items, inputs items, recalculate needed time. And only then or when you change something on that assembly.

[Virenz]

Considering the people with megabsases are already running at 20 UPS, if they set there default UPS to 20, it wouldnt make a difference to the simulation, just make the game run a lot faster. And if the time for a assembly machine is pre-calculated, what does it matter? You just change the time it takes in code according to the UPS. And with the inserters, it calculates before an item goes near it, what it will have to pick up, by scanning the belts around it.

[ssilk]

Can you show me that kind of pre-calculation if an item is in range in (pseudo-)code, please?

edit: Please consider also, that there could be two inserters looking onto the same tile of belt and you have then to decide correctly, which one of the inserters is in that moment in the future the right one. Please consider, that the inserters could currently be moving in the moment of calculation, so you need to think forward, which one might e faster. Consider also, that this algorithm needs to be absolutely deterministic, otherwise multiplayer won't work. And lastly: Please consider that the power might fail at every tick, so even if you have pre-calculated all that stuff, you need to check in the moment you have calculated, that the inserter still has enough power to grab the item.

[Zeblote]

I'd like to run factorio at 144 fps though. Now that would actually be interesting!

[bobucles]

Can you show me that kind of pre-calculation if an item is in range in (pseudo-)code, please?

Well that's easy.

Multiply all pipe capacities and pumping rates by 2.
Double energy generation, consumption, factory production, mining values
Double all moving component speeds, day/night cycle
Double all player/vehicle/actor spawn rates/attack rates/movement

Bam. I just made a 30UPS mod. I'm so cool.

[ssilk]

And the considerations? Where are the considerations?

[bobucles]

I considered there may be practical issues that screw up the game in unforeseen ways, and disregarded them.

Triple everything for a 20UPS mod.

[Zeblote]

Anyways what's the point? Why would you want to play at terrible 30 fps?

That time is better spent optimizing it to make your mega factory run at 60 ups.

[aka13]

Anyways what's the point? Why would you want to play at terrible 30 fps?

That time is better spent optimizing it to make your mega factory run at 60 ups.

That doesnt necessary have any direct connection to fps at all.

[Zeblote]

Anyways what's the point? Why would you want to play at terrible 30 fps?

That time is better spent optimizing it to make your mega factory run at 60 ups.

That doesnt necessary have any direct connection to fps at all.

The game can't have higher fps than ups, if the simulation runs at 30 ups that'll also be your framerate.

[ratchetfreak]

Anyways what's the point? Why would you want to play at terrible 30 fps?

That time is better spent optimizing it to make your mega factory run at 60 ups.

That doesnt necessary have any direct connection to fps at all.

The game can't have higher fps than ups, if the simulation runs at 30 ups that'll also be your framerate.

technically you could have a 60 fps framerate on a 20 ups game if you decouple the render from the physics and do some "gpu-side prediction" (akin to client side prediction but on the gpu) where you also pass the speed of the entity and the frame time offset from the physics frame the render is based on and then do pos + speed*time in the vertex shader.

[ssilk]

Well, this idea goes more into the direction I would like to see.

My current opinion is: It is much, much easier to optimize the game for 60 fps (doing the "real stuff"), instead of doing such relatively complex "simulation" of what might happen. Kovarex also said that some times, he said (more or less correct quoted): "the game can be optimized A LOT". The complexity to correctly pre-calculate the steps between the simulation is in my eyes as complex as using two CPUs for the updates.

For me as moderator is just the question open: Should I close this suggestion as "will not implemented" or not: See first sentence!

[bobingabout]

This idea is reminiscent of the old "Day length modifier" patch for OTTD I pioneered back when I was active on the forums over there (Even though I never actually coded it, a friend of mine coded the initial version at my house.)

Basically... Factorio is very closely tied to it's Ticks, Ticks being game updates. 60 updates a second was set as the universal, but this means the game is not friendly for refresh rates other than this also, as the frames per second is tied to updates per second.

In this case, the length of a tick is associated with some hard values, how much of something is produced in this tick, therefore reducing the number of UPS also reduces the game speed.

If a new option for different tick lengths (Currently 1/60th of a second) is introduced, most of what is hard-written would need to be a formula instead. Fortunately most of these are formulae now, EG, Power generated from a solar panel is P/60 (P is power in Watts), the formula would simply change to P/UPS (UPS obviously being how many update ticks per second, rather than being hardcoded to 60)

Overall this change would mostly just be a lot of sifting through code and making minor changes here and there, tedious but not hard work.


One of the advantages (Other than just large factories) would be for multiplayer, A smaller number of ticks per second means less updates per second being transmited on your internet line. Now I haven't yet attempted playing a multiplayer game since multiplayer was first introduced back in 0.11 (or was it 0.10? I forget), and trying to play with someone in Australia was neigh unplayable, A lot of the time we were actually getting approximately 1 update every few seconds, I'm sure the game has been improved a fair ways since then though, but when you have an expected minimum ping in the high 300ms, (I think our latency settings were about 500ms to be safe), with an average transfer speed similar to that of a 56k dial up modem, an option to reduce the number of updates per second would be useful. (As would a centralised non-player "Server" client that we both connect to somewhere between the two of us, say, America, to reduce the latency)

[ssilk]

A) You haven't read the thread. Replacing the formulaes isn't the problem. The problem is the timing of all the moving stuff, like inserters, belts with gaps of items etc. You cannot foresee, if there will be a powerfail for example. I would say changing the code like so is not worth the time.
B) Even with a 56 k modem and one living on the moon (minimum 2 secs for the connection delay) it would be possible to play Factorio with 60 ups, unless you move much around with your character; once the two clients are synchronized they need the connection only to keep the game synchronous and to transfer the movements of the characters.

[Klonan]

I believe this is very possible,
And it is so much so that you only need to write a mod to do this,

The mod would first call up every recipe, entity etc, and change any tick dependant time to its value multiplied by the game speed modifier, lets say 0.5 (for 30 UPS).
so for recipes energy required would be like

Code: Select all

recipe["energy_required"] = recipe["energy_required"] * 0.5

for something like player/biter walking speed

Code: Select all

player["movement_speed"] = player["movement_speed"]/0.5

and so on for all tick dependent operations, inserter speed, steam engine usage per tick, belt speed, solar panel output... a lot of stuff...

But after that, i don't forsee any problems, you won't need to do any inter-tick calculations, it should just work fine.
In this way the modifier could also be set to a positive value, say 2.4 (for 144hz UPS/FPS) and it would work in the same way.