Factorio Forums

Klonan, what is the difference between this two calculations:

ssilk wrote:The problem is the timing of all the moving stuff, like inserters, belts with gaps of items etc.

That's still all calculation stuff, for double speed they move twice as fast. items on belts move twice as far, etc.

ssilk wrote:Klonan, what is the difference between this two calculations:

Code: Select all

+1 * 1 * 1

Code: Select all

+1 * 2 * 0.5
+1 * 2 * 0.5

The second one forces a float type variable!

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

Surely there are some things that a mod wouldn't be able to do very well, EG, when it comes to reporting variables, if you half production speed, factories would report (Assuming something takes 5s normally) only a 2.5s time instead of the default 5s, when it still actually takes 5s to make, because the game speed is halved. Also liquids "Become unstable" and bounce back and forth along a pipe if you try to increase the flow beyond water defaults. And we also still have issues that with some mods, modules can increase some production cycles to and beyond 1 cycle per tick (and same again for productivity bonus), they still act strange when you're trying to make factories work that fast.

bobingabout wrote:That's still all calculation stuff, for double speed they move twice as fast. items on belts move twice as far, etc.

Well, it sounds possible, I want to point out, that the game is then not the same anymore.
What I mean is: The game-physic changes more or less significantly.

For example:
Before: Items moves about 0.1 tiles per update
After: Items moves about 0.2 tiles per update.
When an item is only about 0.2 tiles long this is a significant change, which might lead to situations, where an inserter cannot fetch an item anymore.

But fetches without problem without the speedup. Or vice versa?

ssilk wrote:

bobingabout wrote:That's still all calculation stuff, for double speed they move twice as fast. items on belts move twice as far, etc.

Well, it sounds possible, I want to point out, that the game is then not the same anymore.
What I mean is: The game-physic changes more or less significantly.

For example:
Before: Items moves about 0.1 tiles per update
After: Items moves about 0.2 tiles per update.
When an item is only about 0.2 tiles long this is a significant change, which might lead to situations, where an inserter cannot fetch an item anymore.

But fetches without problem without the speedup. Or vice versa?

I don't think its an issue... there are many many many mods which more than double the speed of things, belts, inserters, assembling machines, and they all work without issue, and this mod would just effectively be speeding everything up by a factor of 2. And besides, nobody expects it to be a perfect solution, but for the people who need it, those issues are completely minor.

but... well we will see... for me it's clear, that the physical behavior of Factorio changes then in more or less details and especially at points, where the timing was important. But if someone is able to adapt that changes and change his playstyle, why not?

Interesting links:

https://forums.factorio.com/forum/viewtop ... =5&t=17501 Performance optimization - post your saves
--> Post saves of slow performing Factories here.

https://forums.factorio.com/forum/vie ... =5&t=17782 Performance test: basic belts vs underground belts
Some quotes from Kovarex out of there:

But yes, optimising is always fun just to prove myself that I can push it further

There are still possibilities to make Factorio run MUCH faster than now. The question is, is it worth to spend time on it now? Are there more just then very few people building big enough factories? The time can be also spent on different kind of improvements and features.

https://forums.factorio.com/forum/viewtop ... 39#p119139 Performance comparison for different computer setups

If you ran the game for a minute in normal speed or 30s in double "speed", you wouldn't be guaranteed to end up in the same state.

HanziQ wrote:If you ran the game for a minute in normal speed or 30s in double "speed", you wouldn't be guaranteed to end up in the same state.

But a game running at 30UPS across all clients will be guaranteed to be the same, just the same way any clients running at 60UPS will have the same game state

Changing the game rate in the middle of an active world would be quite a trick. Running a game at 30UPS means you only process the "even" ticks in the game, so anything that happens at an "odd" tick in normal time is now an automatic desync.

Weapons that fire close to the game's frame rate would need to be reconsidered, since 30 shots per second is going to naturally misbehave at something like 20UPS.

As long as every client is synced to switch speed modes at the same time, and the in-game recording is aware of these changes, it shouldn't be insurmountable.

I think the short answer is: none of the game logic is coded to handle such a change.

If it was, it would automatically mean replays would be limited to the game speed at the point in time the replay was created. You couldn't "fast forward" anymore. That small thing aside it would be a massive amount of time to re-work everything to work with such a system.

ssilk wrote:

bobingabout wrote:That's still all calculation stuff, for double speed they move twice as fast. items on belts move twice as far, etc.

Well, it sounds possible, I want to point out, that the game is then not the same anymore.
What I mean is: The game-physic changes more or less significantly.

For example:
Before: Items moves about 0.1 tiles per update
After: Items moves about 0.2 tiles per update.
When an item is only about 0.2 tiles long this is a significant change, which might lead to situations, where an inserter cannot fetch an item anymore.

But fetches without problem without the speedup. Or vice versa?

Even worse if the item was moving 0.75 tiles per update at normal speed and then is moving 1.5 tiles with reduced update rate. Then it would skip some tiles. Afaik there was a problem with the trains moving very fast, that they sometimes skipped red signals.

Considering movement of things on known paths, the game could be run without fixed update rate. If you think of a billard game, it makes no sense to simulate it frame by frame (except for displaying the ball movement). Instead you need to know when the next collision is happening (which can be calculated), update the ball positions for that time, calculate the collision effects and then calculate the next collision from there.

As far as I know the smoke isn't really simulated anymore at every update. It's just sprites which have a starting position, a certain age and are displaced by the global wind depending on their age. Because smoke doesn't interact with anything once it's created, it's very efficient this way. Many entities which interact may become a problem when predicting the next interaction and using an update rate approximates the interaction time (which makes the timing imprecise) but delivers a solid performance.

The timing jitter imposed by the update rate is what makes the problems. It adds a pseudorandom timing offset to each interaction and (if too coarse) some interactions are missed alltogether.