Friday Facts #36

[Kanthes]

I am probably in minority but i dont care that much about multiplayer in games like this (no one will touch my resources or my perfectly planned factory layout ), and would much more like if the huge time invested in making mutiplayer work to be invested in the game it self and new content/mechanics.

More people playing at the same game = Bigger Factories

Its called Cooperative.

You know what I'm looking forward to? Versus. Imagine 4 players starting off in 4 separate corners (probably separated by a number of biter nests?), building up their base over the next couple of hours.. And finally? Remote controlled battle bots.

[therapist]

Therapist:
There will be bugs with 0.10, no doubt about that. They decided to postpone it because a bug was so big that was unplayable. Also, multiplayer it is not expected for this version, thats a few months away.

Yeah I hadn't checked the roadmap and the friday facts got me excited talking about multiplayer, see the post above yours. Also, I'm not A therapist. I'm THE rapist. Alot of people have made that mistake.

Honestly 0.10.0 is just a chance to test the internal logic rewrites and the replay functions so it's basically just alpha testing the functions necessary for multiplay to work properly. Poop sucks. Can't wait for multiplayer, although I do think we need to pressure kovarex to make a green player model to go with the red blue and yellow ones. It will be so interesting to finally have enemies who can employ strategies like running past laser turrets, running out power storages at night, cutting fuel sources or electrical infrastructure, etc. The whole game is going to change and I hope the devs remain agile about developing in-game solutions to player generated problems.

[Tami]

Will the annoying bug for the construction bots gets fixed? I mean this one:

Iam a construction bot, i have thousands of repair packs, but i dont want to use THEM for repairing ... I only want freshly produced repairpacks onyl.

I ask because it isnt noted as fixed for next patch and it was something gamebreaking in my opinion xD.

[jorgenRe]

I understand not realy the complete message, but interesting.
I hope my savegames are still working?

bg

Your save game is always as safe as possible, and with the release delayed you will probably have a less of a chance to loose your save

[GewaltSam]

Well, multiplayer will be ready with v0.12. Not v0.10. For now they try to make the replay work.

And to the promised release shifting: I don't think, that v0.10 has many for the player visible of new stuff. The most things are under the hood.

Isn't it 0.11? At least an early version of multiplayer afaik. I am counting on that, I can barely wait for co-oping Factorio with my mates

[jeroon]

Will the annoying bug for the construction bots gets fixed? I mean this one:

Iam a construction bot, i have thousands of repair packs, but i dont want to use THEM for repairing ... I only want freshly produced repairpacks onyl.

I ask because it isnt noted as fixed for next patch and it was something gamebreaking in my opinion xD.

Have you created a bug report for this?

Are the repair packs in the closest Roboport to the object that needs repairing? If not, the robots will only take Repair Packs from a logical chest, not from a neighboring Roboport (that might be a bug, but hardly game-breaking imo..).

[Tami]

They also dont use RepPacks inside the RobPort the Robs are located at. Afaik it is a known bug, but it will not get fixed afaik.

[GewaltSam]

By the way, if time doesn't allow for more circuit logic like you already hinted at, will there be a bit more content in 0.10.x? I really like a few more options for my designs while I wait for 0.11 and multiplayer

[Aedaeum]

They also dont use RepPacks inside the RobPort the Robs are located at. Afaik it is a known bug, but it will not get fixed afaik.

I had not problem with my bots auto-repairing my walls with the provided reppacks inside the robo port....

[der.Schtefan]

Not sure if you evaluated this, but CRlibm provides correctly (=> deterministically) rounded math functions (all the C99 ones).

CRlibm is LGPL and thus a licencing problem might occur. You might want to use the original FDlibm from http://www.netlib.org/fdlibm which is freely available and the base for the portable JAVA specs. use the s_ versions for SIN and the or the e_ versions for SINH.

[sillyfly]

The fact that it is LGPL (and not GPL) probably means there will not be license problems. LGPL means* you can freely use the library in any application, including commercial use, without having to make your own code open (i.e. - it is non-contagious). Only if you make changes to the library itself - those changes must be open source.

(* - of course - you should read the license to make sure. Don't take my advice for granted, as I am by no means an expert on this!)

[naryl]

You also have to make sure users can always replace the LGPL code with its newer version if it doesn't break ABI which for proprietary software like Factorio means linking dynamically.

Shouldn't be a problem but of course it's for the devs to decide.

[manpapper]

When the updated 0.10 will be avaible?

[Nova]

Maybe today, maybe not. We have to wait.

[cube]

When the updated 0.10 will be avaible?

[manpapper]

that's great

[krelbel]

Determinism

Kovarex's quest for making the game fully deterministic has seen an interesting twist last week. The replay functionality is working quite well (still now and then there is desynchronization but it is a work in progress). But when we tried to load the replay on a machine with different operating system it desynchronized immediately. It turned out that in C++ basic trigonometric functions (sin, cos, asin, atan, etc.) are not guaranteed to give same results across different platforms. We are not talking about precision here, it is about getting the same (though possibly imprecise) outcomes. Even more surprisingly there is not that much discussion / solutions for this on the web. So Kovarex reminded himself of his student years and wrote our custom implementations of these that give the same results on Win, OSX and Linux. It sounds like a strange thing to do, but without this the multiplayer for players with different operating systems wouldn't work. We were considering an alternative solution where we would have three "rooms" - one for Windows, one for OSX and one for Linux players and you could only play with people having the same system as you:D. Joking aside, it is suspected that cross platform determinism issues are not over yet...

Sorry to revive an old thread, and sorry if this isn't the correct place for this, but I sincerely hope (for the sake of this feature ever working and making it in to the game) that you abandon the attempt to get deterministic peer-to-peer networking working, and switch to a client-server model if at all possible. It's not just non-guaranteed cross-platform identical results for trigonometric functions you have to worry about, you're likely going to run into subtle differences between platforms regarding floating point calculations, compiler bugs, and many more.

Since one single calculation going wrong can result in a total desynchronization of game state across clients, it can be notoriously difficult to track down the root cause of a desynchronization (one solution I've heard of is hashing the game state every tick and comparing that between clients in debug mode every tick, to narrow down exactly which command caused the desync). Most developers I've heard mention this approach to multiplayer agreed that it was an absolute nightmare to implement and debug.

Sorry to question your judgement here; I'm not speaking from great authority here (never published a game myself, though I have run into this problem while working on a cross-platform peer to peer lockstep networked multiplayer game before, where we never did nail down all the desynchronization issues) but I love this game too much to let you go down this potentially disastrous path without saying anything. If you're already well aware of this issue, then sorry for the rambling post. If it helps, plenty of other game developers have posted about these issues; here are a couple decent blog posts on the subject:

http://www.altdev.co/2011/07/09/synchro ... f-desyncs/ (see the comments in particular for many tales from many different game devs about their huge difficulties with this approach)
http://gafferongames.com/networking-for ... etworking/

[slpwnd]

Thanks for the warning. We are aware of this. We have thought about it a lot. There is no other path. Just too many calculations. Think tens of thousands to hundreds of thousands objects moving every tick. Calculating this in the central point (some server) would be a nightmare as well.

We intend to use some sort of game state hashing to nail down problems with desynchronization. And yes it will be a lot of work. So thanks for the links to other people battling this, they will be useful.

[krelbel]

Thanks for the warning. We are aware of this. We have thought about it a lot. There is no other path. Just too many calculations. Think tens of thousands to hundreds of thousands objects moving every tick. Calculating this in the central point (some server) would be a nightmare as well.

We intend to use some sort of game state hashing to nail down problems with desynchronization. And yes it will be a lot of work. So thanks for the links to other people battling this, they will be useful.

I have full confidence in your ability to figure it out, just wanted to share their experiences, especially with regards to uninitialized variables, memory alignment + SSE and several other floating point issues, along with the other pitfalls mentioned in those blog posts and comments. It's a big challenge (it's terrifying to think that a single uninitialized variable anywhere in your game engine can lead to intermittent desyncs that can take months to track down, especially if they're shy and go away when you enable your debug hash dumps) but I'm sure you're up to the task

If you can, and if (when) you run into more difficult desync problems, I'd advise talking to other game devs that have either implemented synchronous lock-step peer to peer multiplayer, and/or found efficient ways to solve the problem of efficiently communicating complex game state in the client-server model. In the first case, they might know of common pitfalls not mentioned in the blog posts on the subject. In the second case, they might be able to offer a solution to the seemingly insurmountable problem of having too many objects in the game state to make the client-server model work.

Fortunately, you're in the position where you've still got a fantastic single player game on your hands, already well worth the asking price IMO, so you've got a pretty good advantage there Good luck!

[kovarex]

Thanks for the warning. We are aware of this. We have thought about it a lot. There is no other path. Just too many calculations. Think tens of thousands to hundreds of thousands objects moving every tick. Calculating this in the central point (some server) would be a nightmare as well.

We intend to use some sort of game state hashing to nail down problems with desynchronization. And yes it will be a lot of work. So thanks for the links to other people battling this, they will be useful.

I have full confidence in your ability to figure it out, just wanted to share their experiences, especially with regards to uninitialized variables, memory alignment + SSE and several other floating point issues, along with the other pitfalls mentioned in those blog posts and comments. It's a big challenge (it's terrifying to think that a single uninitialized variable anywhere in your game engine can lead to intermittent desyncs that can take months to track down, especially if they're shy and go away when you enable your debug hash dumps) but I'm sure you're up to the task

If you can, and if (when) you run into more difficult desync problems, I'd advise talking to other game devs that have either implemented synchronous lock-step peer to peer multiplayer, and/or found efficient ways to solve the problem of efficiently communicating complex game state in the client-server model. In the first case, they might know of common pitfalls not mentioned in the blog posts on the subject. In the second case, they might be able to offer a solution to the seemingly insurmountable problem of having too many objects in the game state to make the client-server model work.

Fortunately, you're in the position where you've still got a fantastic single player game on your hands, already well worth the asking price IMO, so you've got a pretty good advantage there Good luck!

I have a game mode there, for a long time, that saves the game state every tick, then I start it as replay and hunt for any desynchronisations. I have fixed many and many of desynchronisation problems already (and learnt a lot on the way), there are still some little problems, but I believe we are not so far from achieving the goal.

Yes, uninitialised variables, using pointers for order operators, and mainly serialisation/deserialisation problems changing orders of data in some of the structures were found.
For uninitialised values the valgrind was always helpful, so it is not months

We like challenges, so it is a good thing that it is not easy