Friday Facts #108 - Unexpected Features

Regular reports on Factorio development.
chris13524
Fast Inserter
Fast Inserter
Posts: 197
Joined: Thu Jun 04, 2015 12:20 am
Contact:

Re: Friday Facts #108 - Unexpected Features

Post by chris13524 » Sat Oct 17, 2015 1:58 am

I really like the blueprint book. Renaming it is great! The blueprints them selves should be renamable as well. What we need now is some way to rename power armour. One for fighting, one for building.

rkfg
Long Handed Inserter
Long Handed Inserter
Posts: 52
Joined: Thu Jan 15, 2015 11:11 pm
Contact:

Re: Friday Facts #108 - Unexpected Features

Post by rkfg » Sat Oct 17, 2015 2:14 am

ratchetfreak wrote:bandwidth savings and rubberbanding are the benefits
Hmm, that could do. But rubberbanding usually appears on high latency connections and deterministic engines still need some synchronization and lag compensation mechanisms in order for players to see the same picture. And bandwidth, I don't see how the lack of snapshots would help. The server should send all the data to everyone so each client computes the outcome individually. With snapshots it's much more efficient if the server is implemented right (== more complex than a straightforward implementation). Server could only send the data that's relevant for each player, i.e. you only receive what you can actually see. It also prevents cheating like wallhacking, the client just doesn't have the data to see the invisible. However, that's applicable to FPS but not RTSes I guess. And Factorio is kinda RTS, I see that snapshotting, for example, each material piece on a belt and then broadcasting this entire world to everyone even at 30 ticks/sec would choke almost any connection. But for RTS like Starcraft that means that every player has all the data about the enemy and the client just doesn't draw the things that are under fog of war. I always thought that you don't have any data about what enemy does in RTSes.

Found an interesting read btw. With that technique considered, my first statements in this comment aren't that convincing. Hashing and placing the commands in future is a nice solution, that explains lags between an action and visible result. But I still don't get why one would use floats in an RTS-like game when you can happily live with fixed point. Floats are known for their quirks though they're unavoidable in 3D graphics. But for a game like Factorio? Is it lack of libraries?

User avatar
DaveMcW
Smart Inserter
Smart Inserter
Posts: 2994
Joined: Tue May 13, 2014 11:06 am
Contact:

Re: Friday Facts #108 - Unexpected Features

Post by DaveMcW » Sat Oct 17, 2015 2:26 am

rkfg wrote:But I still don't get why one would use floats in an RTS-like game when you can happily live with fixed point. Floats are known for their quirks though they're unavoidable in 3D graphics. But for a game like Factorio? Is it lack of libraries?
More like, the stupidity of libraries. The standard lua library uses floats, and relies on the operating system library to implement them.

rkfg
Long Handed Inserter
Long Handed Inserter
Posts: 52
Joined: Thu Jan 15, 2015 11:11 pm
Contact:

Re: Friday Facts #108 - Unexpected Features

Post by rkfg » Sat Oct 17, 2015 2:38 am

DaveMcW wrote:More like, the stupidity of libraries. The standard lua library uses floats, and relies on the operating system library to implement them.
And there's no way to write one from scratch or find a replacement? I doubt making a fixed precision math library would be too hard, there's no (visible) physics and stuff just basic arithmetics. Four operators. The problem may arise with Lua but then again why not to use just bigger integers? That would be the same but simpler. If we want 4 digits precision let's multiply everything by 10000 and round it up so Lua part works with 10000 instead of 1 and 20568 instead of 2.0568. Of course, as always there may be hidden problems with this approach, like, we can't just move an entity by 1 unit anymore, we should get that scale first. What if the game starts requiring higher precision and now everything is multiplied by 10^6? And so on. But maybe it's still less evil than floating point math that's so tied to platforms and compilers. It's a leaked abstraction at its finest and man I hate leaking abstractions.

User avatar
DaveMcW
Smart Inserter
Smart Inserter
Posts: 2994
Joined: Tue May 13, 2014 11:06 am
Contact:

Re: Friday Facts #108 - Unexpected Features

Post by DaveMcW » Sat Oct 17, 2015 2:56 am

Using big fixed point numbers is certainly an option for internal unit movement. Though if you have never done it before, it might be easier just to standardize your float library.

But that still doesn't solve the issue brought up in this FFF, anyone who types: /c game.local_player.print(0.00001) will cause a desync.

AssaultRaven
Inserter
Inserter
Posts: 48
Joined: Sun Jun 08, 2014 4:00 am
Contact:

Re: Friday Facts #108 - Unexpected Features

Post by AssaultRaven » Sat Oct 17, 2015 3:58 am

This reminds me of something minor I've been thinking for a while: I think the vapor coming out of the steam engines should look much cleaner, like a puffy white cloud, to reflect that they are only emitting steam and do not themselves produce any pollution.

User avatar
MightyMane
Manual Inserter
Manual Inserter
Posts: 4
Joined: Sun Oct 04, 2015 10:00 pm
Contact:

Re: Friday Facts #108 - Unexpected Features

Post by MightyMane » Sat Oct 17, 2015 5:28 am

Cool stuff!

BlackLight
Burner Inserter
Burner Inserter
Posts: 17
Joined: Sat Sep 12, 2015 11:01 am
Contact:

Re: Friday Facts #108 - Unexpected Features

Post by BlackLight » Sat Oct 17, 2015 6:54 am

mbritb wrote:BLUEPRINT BOOK!!!! Rseding you are AWESOME!!! Can NOT wait for this!! .13 is gonna be awesome with just that one feature alone! <3
Indeed, shut up and take my money! ;) I always have about 10 blueprints in my inventory and more stored away. I can't wait for this either!

transportman
Inserter
Inserter
Posts: 34
Joined: Thu Jun 26, 2014 2:13 pm
Contact:

Re: Friday Facts #108 - Unexpected Features

Post by transportman » Sat Oct 17, 2015 7:22 am

Looks good, just one comment that I would like to make with the breaking of mods. Once you have released on Steam, you should either reduce the number of compatibility breaks or have a system that automatically grabs updated versions for the mod. Currently it is a lot of hassle to start Factorio after an update that breaks mods, as there is no indication which mods are broken (error is just thrown for one mod upon starting the game, while all of them might be broken), and there is no real central download at this moment (scheduled for 0.13) so people have to search where they got a mod and update it. I think most people here will not have a big problem with that, but the general public on Steam might be less tech-savvy and is already used to easy availability and automatic updates of mods through the Steam Workshop.

Another question/suggestion that is along that line: Why is everything stored in AppData/Roaming/Factorio instead of the default Users/<User>/Documents (or something configurable)? If I were a regular person that needs to backup my computer, I would like to backup my saves and stuff, but I would only look in Documents and folders I manually made to store files, but AppData would not be on my list.

sillyfly
Smart Inserter
Smart Inserter
Posts: 1099
Joined: Sun May 04, 2014 11:29 am
Contact:

Re: Friday Facts #108 - Unexpected Features

Post by sillyfly » Sat Oct 17, 2015 7:29 am

To be honest, I still don't understand why the display should be synchronized/deterministic - it should not concern the game engine if one player sees 1e-05 and another sees 1e-005 - that's just the view layer - the data model should not be affected by this.
What am I missing here?

Flux Faraday
Long Handed Inserter
Long Handed Inserter
Posts: 66
Joined: Sat May 10, 2014 8:48 am
Contact:

Re: Friday Facts #108 - Unexpected Features

Post by Flux Faraday » Sat Oct 17, 2015 8:31 am

sillyfly wrote:To be honest, I still don't understand why the display should be synchronized/deterministic - it should not concern the game engine if one player sees 1e-05 and another sees 1e-005 - that's just the view layer - the data model should not be affected by this.
What am I missing here?
Isn't the problem in Lua? That's not just display. Suppose I write a mod that does a computation, then writes a recipe based on that computation. Now we have different platforms with different recipes. Even if the value is the same, the text representation isn't which can cause subtle differences in the data model. I don't know if this is what you meant, but I hope it helps...

^^Blueprint book. Awesome add. Thank you!

Zool
Long Handed Inserter
Long Handed Inserter
Posts: 99
Joined: Fri Jul 10, 2015 6:55 pm
Contact:

Re: Friday Facts #108 - Unexpected Features

Post by Zool » Sat Oct 17, 2015 10:46 am

mbritb wrote:BLUEPRINT BOOK!!!! Rseding you are AWESOME!!! Can NOT wait for this!! .13 is gonna be awesome with just that one feature alone! <3
... and now an option to take your blueprints from one game to another ...

kovarex
Factorio Staff
Factorio Staff
Posts: 7424
Joined: Wed Feb 06, 2013 12:00 am
Contact:

Re: Friday Facts #108 - Unexpected Features

Post by kovarex » Sat Oct 17, 2015 12:03 pm

sillyfly wrote:To be honest, I still don't understand why the display should be synchronized/deterministic - it should not concern the game engine if one player sees 1e-05 and another sees 1e-005 - that's just the view layer - the data model should not be affected by this.
What am I missing here?
It is not just a display. The console history is contained in the save, so suddenly two saves are not identical even when they should be.
Yes, in this case, it would probably not cause any problem, but our checking mechanisms just blindly compare all data to check that the game is deterministic, so we have to fix even small issues, so the mechanism is still usable to find other issues that might be more important.

And also, you can write something like this:

Code: Select all

if tostring(0.00001) == "1e-005" then
  game.players[1].printf("You are on windows")
  game.players[1].insert{name="power-armor-mk2", count=1}
end
This will obviously make a desync.

Kayser
Long Handed Inserter
Long Handed Inserter
Posts: 82
Joined: Mon Aug 10, 2015 9:43 am
Contact:

Re: Friday Facts #108 - Unexpected Features

Post by Kayser » Sat Oct 17, 2015 12:20 pm

The icon for unused slot in the blueprint book looks like a toilet.

Zeblote
Filter Inserter
Filter Inserter
Posts: 972
Joined: Fri Oct 31, 2014 11:55 am
Contact:

Re: Friday Facts #108 - Unexpected Features

Post by Zeblote » Sat Oct 17, 2015 12:20 pm

Use LuaJIT :D

ske
Filter Inserter
Filter Inserter
Posts: 388
Joined: Sat Oct 17, 2015 8:00 am
Contact:

Re: Friday Facts #108 - Unexpected Features

Post by ske » Sat Oct 17, 2015 12:49 pm

Shouldn't the "smoke" from the engines actually be white water vapor? Instead, the boilers should produce grey-black smoke depending on what (and how clean) they are burning stuff.

I didn't expect the smoke from the furnace to go "poofpoof", instead I'd expect something like black smoke going white during the smelting process.

woytaz
Burner Inserter
Burner Inserter
Posts: 7
Joined: Fri Aug 28, 2015 7:20 pm
Contact:

Re: Friday Facts #108 - Unexpected Features

Post by woytaz » Sat Oct 17, 2015 1:09 pm

Kayser wrote:The icon for unused slot in the blueprint book looks like a toilet.
Yes! I'm not the only one!

The Lone Wolfling
Long Handed Inserter
Long Handed Inserter
Posts: 97
Joined: Tue Oct 28, 2014 3:33 pm
Contact:

Re: Friday Facts #108 - Unexpected Features

Post by The Lone Wolfling » Sat Oct 17, 2015 1:16 pm

I don't like that smoke. Or rather, I should qualify. For anything that either is actually putting out steam (steam engines, for instance), or burns relatively clean, it works. But having white smoke coming out of a burner inserter burning coal? That makes no sense. To me, it changes the atmosphere of the game, and not in a good way. (No pun intended.)

It'd be neat to change the color of the smoke depending on how much pollution it was emitting, though. And/or change the color of smoke and/or pollution emissions based on what something was burning. But if you're going to have one and only one color of smoke, I prefer the old smoke.

Zeblote
Filter Inserter
Filter Inserter
Posts: 972
Joined: Fri Oct 31, 2014 11:55 am
Contact:

Re: Friday Facts #108 - Unexpected Features

Post by Zeblote » Sat Oct 17, 2015 1:18 pm

Maybe the smoke sprites themselves are just white and it's possible to re-color them for different things? That'd be fantastic.

sillyfly
Smart Inserter
Smart Inserter
Posts: 1099
Joined: Sun May 04, 2014 11:29 am
Contact:

Re: Friday Facts #108 - Unexpected Features

Post by sillyfly » Sat Oct 17, 2015 1:41 pm

kovarex wrote: It is not just a display. The console history is contained in the save, so suddenly two saves are not identical even when they should be.
Yes, in this case, it would probably not cause any problem, but our checking mechanisms just blindly compare all data to check that the game is deterministic, so we have to fix even small issues, so the mechanism is still usable to find other issues that might be more important.
Ah, I see, thanks for the clarification.
kovarex wrote: And also, you can write something like this:

Code: Select all

if tostring(0.00001) == "1e-005" then
  game.players[1].printf("You are on windows")
  game.players[1].insert{name="power-armor-mk2", count=1}
end
This will obviously make a desync.
It will probably always be possible to cause a desync through modding, won't it? A malicious (or simply unaware) modder could always compare against some locally-available information to affect game data.
The infrastructure should probably protect the modder to some extent, but covering all pitfalls sounds... impossible.

Post Reply

Return to “News”

Who is online

Users browsing this forum: PacifyerGrey, rizmage