Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Factorio – Statistics improvements, Linux adventures

factorio.com

Post reply on HN
Print view View original

51–57 of 57 posts

Re: Factorio – Statistics improvements, Linux adventures

#51

Post by seba_dos1 »

nh2 wrote: post #47
gizmo686 wrote: post #45

Earlier quoted context omitted.

In principle, using a thread for saving the game state is a much more difficult problem, since the game state itself will mutate. You need to be extremely careful to assure that the state you serialize is consistent and is at least a plausible game state (even if there is a bit of wiggle room to allow for game states that technically never existed). This complexity invades every aspect of game logic; and bugs here te…

How do you know that the game state is in a consistent state in the child? A stopped thread may be in the middle of mutating an array or struct.

Because you forked while being in a consistent state?

Re: Factorio – Statistics improvements, Linux adventures

#52

Post by lupusreal »

raiguard wrote: post #35
lupusreal wrote: post #4

If they drop X11 support that will finally be the end of my cracktorio addiction.

Apparently I didn't word that section very well, because many people took away this impression. My apologies. Factorio will continue to support X11 for as long as SDL does, in other words, essentially forever. The only change here is that X11 is no longer required for the game to launch at all. SDL will load whichever video driver is available at runtime, or if you have both, you can choose which one to use in the gr…

Excellent news, thank you for the clarification and all of your work!

Re: Factorio – Statistics improvements, Linux adventures

#53

Post by AndrewOMartin »

For anyone who hasn't played this before, you should know that the references to addiction are not jokes (for many people, at least). I played for a while, and had a blast doing so, but after I had achieved the simplest nominal 'victory' and noticed I was still compelled to disposed of a couple of good weekends towards meeting some self imposed challenged I felt it was time to stop.

I didn't have the discipline to just play occasionally, but I did have the discipline to delete the game and all my saves and blueprints one day, and I'm very glad I did. I recommend any player at least consider whether they should do the same.

Repeat, I had a great time, the community is great too, but the only way I could sustainably stop myself from turning that into a big waste of time was to delete the game.

Re: Factorio – Statistics improvements, Linux adventures

#55

Post by kelnos »

nh2 wrote: post #47
gizmo686 wrote: post #45

Earlier quoted context omitted.

In principle, using a thread for saving the game state is a much more difficult problem, since the game state itself will mutate. You need to be extremely careful to assure that the state you serialize is consistent and is at least a plausible game state (even if there is a bit of wiggle room to allow for game states that technically never existed). This complexity invades every aspect of game logic; and bugs here te…

How do you know that the game state is in a consistent state in the child? A stopped thread may be in the middle of mutating an array or struct.

If they have the ability to pause the entire game in a consistent state while its state is being saved (in the foreground save case), then they certainly have the ability to pause the entire game in a consistent state so they can fork. Just the latter pause will be much much shorter.

Re: Factorio – Statistics improvements, Linux adventures

#56

Post by runiq »

lpribis wrote: post #54
IAmLiterallyAB wrote: post #10

Mandatory CSD was always a bad idea imo and this is yet another reason

Sorry, what is CSD? I can't find any reference to this acronym.

Client-side decorations: The title bar, the min-max-close buttons, and the window border.

Re: Factorio – Statistics improvements, Linux adventures

#57

Post by nh2 »

seba_dos1 wrote: post #51
nh2 wrote: post #47

Earlier quoted context omitted.

How do you know that the game state is in a consistent state in the child? A stopped thread may be in the middle of mutating an array or struct.

Because you forked while being in a consistent state?

Ah, I see. I was assuming that the achievement of consistent state must somehow be achieved in the child.

If the parent can achieve consistent state (e.g. doing the equivalent of pressing "pause"), why not do the following instead:

While paused, memcpy the current memory to a buffer, then simultaneously {resume game, spawn thread to write the buffer to disk}. In C++ the memcpy might be even more convenient with the copy constructor.

This will introduce a short delay for the copy, at the speed of RAM bandwidth.

But that copy will need to be done anyway, straight away, as the parent poster says:

> that [copy] overhead will likely be spent in the first frame

With fork() it just happens in the kernel instead of in userspace, thus likely slower (1000s of individual sequential page faults, instead of a single contiguous allocation).

So if the fork() approach can somehow do it faster, I'd be curious via what mechanics.

Post reply on HN