www.factorio.com
https://forums.factorio.com/
You can always set the image resolution to Normal.tazdu29 wrote:I was thinking about the latests FFFs and your Vram issues with new HD graphics.
Is it possible to pack all the old textures in a sort of "mod" so Factorio will stil be playable on lower end PC ?
There are 378 reasons to like thisFFF wrote: Since these kind of corruptions seem to be relatively rare, we suspect it might caused by random hardware failures (maybe cosmic ray hitting a transistor and flipping bit somewhere?)
Lol, my bad, didn't know that there was a option for this x)V453000 wrote:You can always set the image resolution to Normal.tazdu29 wrote:I was thinking about the latests FFFs and your Vram issues with new HD graphics.
Is it possible to pack all the old textures in a sort of "mod" so Factorio will stil be playable on lower end PC ?
Yes, that would be good for checking integrity of zip packages on disk, which also sometimes get corrupted probably by Windows not flushing them to disk properly. The type of corruption I was talking about was corrupted game state, and we already check some things that previously caused lot of corruptions - for example the tile corruption in bug report I linked in the FFF was detected during saving and it prevented overwriting good save. But, it still just hides the problem, what I need is find source of the problem ... is it bug in our code? or is it just random HW glitch? Additionally, these checks make the saving longer, so we would like to add as little as possible and even remove existing ones.bman212121 wrote:For the corrupted saves, wouldn't it just make more sense to run it through a verification after it's written to disk? If you see that the save is in fact bad, you should still have the running system to look at and see if you can fix the issue so it doesn't end up in the save. The only time that's not an option is on a desync or a connectivity loss where you are already disconnected from the running game state. But the rest of the time you should be able to fall back and make an attempt to fix so it doesn't go unnoticed until the player tries to load into it again at a later date.
Thanks, I read the article before, but forgot about itchrysos wrote:This is an interesting article about software bugs: https://www.codeofhonor.com/blog/whose- ... his-anyway
Some of it is about detecting bad memory and hardware faults.
Yes, we run our test suite in valgrind, but it doesn't cover all code paths. But last week it helped us to figure out desync issue so many people reported. Testing real game play in it is not really feasible though :/pleegwat wrote:For the corruption issue, I assume you've tried valgrind (or an equivalent windows tool)? Very good at tracking down use of uninitialized variables, though it slows down the program a lot so it's not going to be usable on actual play.
https://www.factorio.com/blog/post/fff-219djtumolo wrote:It looks like there is terrain altitude in that screenshot? That's not something I've seen before, is that something they've talked about?
Any chance that running replays under valgrind might find issues? That is probably more practical than actually playing. With luck some of the bug reports for corrupted game saves/state might have replay data. Alternatively is it feasible to actually save replay data from the last successful save in a memory buffer, and if/when the game detects invalid state whilst saving, write that replay data to disk, (and possibly copy the autosave it was based on as well).posila wrote:Yes, we run our test suite in valgrind, but it doesn't cover all code paths. But last week it helped us to figure out desync issue so many people reported. Testing real game play in it is not really feasible though :/pleegwat wrote:For the corruption issue, I assume you've tried valgrind (or an equivalent windows tool)? Very good at tracking down use of uninitialized variables, though it slows down the program a lot so it's not going to be usable on actual play.
Thank you! I remember reading this a long time ago and wanted to find it to post it, but couldn't remember where it lived!chrysos wrote:This is an interesting article about software bugs: https://www.codeofhonor.com/blog/whose- ... his-anyway
Some of it is about detecting bad memory and hardware faults.
Maybe not the most "efficient" thing to do in Factorio's main processing loop, but certainly an interesting concept - to have some kind of memory validation or checksum? For your tiles, instead of making the structure page-aligned & read-only, maybe just add a CRC or MD5 checksum into the structure. It would be easy to update when something actually changed, and perhaps you could figure out when it makes sense to read & validate against the checksum.Mike O’Brien, one of the co-founders and a crack programmer, eventually came up with the idea that they were related to computer hardware failures rather than programming failures. More importantly he had the bright idea for how to test that hypothesis, which is the mark of an excellent scientist.
He wrote a module (“OsStress”) which would allocate a block of memory, perform calculations in that memory block, and then compare the results of the calculation to a table of known answers. He encoded this stress-test into the main game loop so that the computer would perform this verification step about 30-50 times per second.
On a properly functioning computer this stress test should never fail, but surprisingly we discovered that on about 1% of the computers being used to play Guild Wars it did fail! One percent might not sound like a big deal, but when one million gamers play the game on any given day that means 10,000 would have at least one crash bug. Our programming team could spend weeks researching the bugs for just one day at that rate!
...
While implementing the computer stress test solution seems beyond the call of duty it had a huge payoff: we were able to identify computers that were generating bogus bug reports and ignore their crashes. When millions of people play a game in any given week, even a low defect rate can result in more bug reports than the programming team can field. By focusing our efforts on the bugs that were actually our fault the programming team was able to spend time creating features that players wanted instead of triaging unfixable bugs.
Having some kind of memory checksum/hash in your code - hopefully (!) the codepaths where modifications that would trigger a change to the checksum would be more tightly controlled that you have less risk of introducing a bug; so if there are failures in the checksum validation it's a higher likelihood of end-user hardware corruption than game bug?posila wrote:But, it still just hides the problem, what I need is find source of the problem ... is it bug in our code? or is it just random HW glitch?
Wait... what?noobhead99 wrote:THIS IS SUPPOSED TO BE RELIASTIC!?!?!?
You do realize that laser beams have nothing realistic about them at all?noobhead99 wrote:Actually very decent, when I looked at factorio, I did is looked at the laser turrets, "WHY IS THERE NO LASER BEAMS!?!?!??!, THIS IS SUPPOSED TO BE RELIASTIC!?!?!?" well this is such a coincidence ;p
