Friday Facts #108 - Unexpected Features
-
- Fast Inserter
- Posts: 207
- Joined: Thu Jun 04, 2015 12:20 am
- Contact:
Re: Friday Facts #108 - Unexpected Features
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.
Re: Friday Facts #108 - Unexpected Features
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.ratchetfreak wrote:bandwidth savings and rubberbanding are the benefits
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?
Re: Friday Facts #108 - Unexpected Features
More like, the stupidity of libraries. The standard lua library uses floats, and relies on the operating system library to implement them.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?
Re: Friday Facts #108 - Unexpected Features
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.DaveMcW wrote:More like, the stupidity of libraries. The standard lua library uses floats, and relies on the operating system library to implement them.
Re: Friday Facts #108 - Unexpected Features
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.
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.
-
- Long Handed Inserter
- Posts: 57
- Joined: Sun Jun 08, 2014 4:00 am
- Contact:
Re: Friday Facts #108 - Unexpected Features
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.
- MightyMane
- Manual Inserter
- Posts: 4
- Joined: Sun Oct 04, 2015 10:00 pm
- Contact:
Re: Friday Facts #108 - Unexpected Features
Cool stuff!
-
- Burner Inserter
- Posts: 17
- Joined: Sat Sep 12, 2015 11:01 am
- Contact:
Re: Friday Facts #108 - Unexpected Features
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!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
-
- Inserter
- Posts: 34
- Joined: Thu Jun 26, 2014 2:13 pm
- Contact:
Re: Friday Facts #108 - Unexpected Features
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.
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.
Re: Friday Facts #108 - Unexpected Features
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?
What am I missing here?
-
- Long Handed Inserter
- Posts: 66
- Joined: Sat May 10, 2014 8:48 am
- Contact:
Re: Friday Facts #108 - Unexpected Features
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...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?
^^Blueprint book. Awesome add. Thank you!
Re: Friday Facts #108 - Unexpected Features
... and now an option to take your blueprints from one game to another ...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
Re: Friday Facts #108 - Unexpected Features
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.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?
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
Re: Friday Facts #108 - Unexpected Features
The icon for unused slot in the blueprint book looks like a toilet.
Re: Friday Facts #108 - Unexpected Features
Use LuaJIT
Re: Friday Facts #108 - Unexpected Features
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.
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.
Re: Friday Facts #108 - Unexpected Features
Yes! I'm not the only one!Kayser wrote:The icon for unused slot in the blueprint book looks like a toilet.
-
- Long Handed Inserter
- Posts: 97
- Joined: Tue Oct 28, 2014 3:33 pm
- Contact:
Re: Friday Facts #108 - Unexpected Features
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.
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.
Re: Friday Facts #108 - Unexpected Features
Maybe the smoke sprites themselves are just white and it's possible to re-color them for different things? That'd be fantastic.
Re: Friday Facts #108 - Unexpected Features
Ah, I see, thanks for the clarification.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.
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.kovarex wrote: And also, you can write something like this:This will obviously make a desync.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
The infrastructure should probably protect the modder to some extent, but covering all pitfalls sounds... impossible.