Friday Facts #228 - High resolution turrets

Regular reports on Factorio development.
User avatar
V453000
Factorio Staff
Factorio Staff
Posts: 274
Joined: Fri Sep 04, 2015 5:51 pm
Contact:

Re: Friday Facts #228 - High resolution turrets

Post by V453000 »

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 ?
You can always set the image resolution to Normal. :)
User avatar
Drury
Filter Inserter
Filter Inserter
Posts: 794
Joined: Tue Mar 25, 2014 8:01 pm
Contact:

Re: Friday Facts #228 - High resolution turrets

Post by Drury »

Are gun turrets going to get better firing visuals too? Some tracers would be lovely.
Caine
Fast Inserter
Fast Inserter
Posts: 213
Joined: Sun Dec 17, 2017 1:46 pm
Contact:

Re: Friday Facts #228 - High resolution turrets

Post by Caine »

FFF 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?)
There are 378 reasons to like this :)
tazdu29
Inserter
Inserter
Posts: 24
Joined: Sat Sep 30, 2017 3:19 pm
Contact:

Re: Friday Facts #228 - High resolution turrets

Post by tazdu29 »

V453000 wrote:
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 ?
You can always set the image resolution to Normal. :)
Lol, my bad, didn't know that there was a option for this x)
chrysos
Manual Inserter
Manual Inserter
Posts: 1
Joined: Fri Feb 02, 2018 8:37 pm
Contact:

Re: Friday Facts #228 - High resolution turrets

Post by chrysos »

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.
posila
Factorio Staff
Factorio Staff
Posts: 5349
Joined: Thu Jun 11, 2015 1:35 pm
Contact:

Re: Friday Facts #228 - High resolution turrets

Post by posila »

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.
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.
pleegwat
Filter Inserter
Filter Inserter
Posts: 278
Joined: Fri May 19, 2017 7:31 pm
Contact:

Re: Friday Facts #228 - High resolution turrets

Post by pleegwat »

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.
Engimage
Smart Inserter
Smart Inserter
Posts: 1069
Joined: Wed Jun 29, 2016 10:02 am
Contact:

Re: Friday Facts #228 - High resolution turrets

Post by Engimage »

Awesome to hear all this! Good job guys!
I really hope belt compression to be resolved before 0.17 as well as map gen issues.

About turrets. Awesome graphics! And I really like you finally bring in laser beams!
Btw I never play without following two mods:
https://mods.factorio.com/mod/Laser_Beam_Turrets
https://mods.factorio.com/mod/bullet-trails

In Klonan's mod laser beams are not that bright and are more transparent. I think it is a good thing compared to your movie. Also lasers having "pulses" looks much more gpaphically pleasant and more realistic as no lasers are actually capable of continuous fire. Also with pulse fire connection point inconsistensies are not that noticable. And I do support previous posters about altering/randomizing connection points for shots.

I would also really like if bullet trains will make it into game as well as it is really visually pleasing to see bullets rip biters. If you would add empty buller casings fly off the turret during fire it would be even more awesome!
posila
Factorio Staff
Factorio Staff
Posts: 5349
Joined: Thu Jun 11, 2015 1:35 pm
Contact:

Re: Friday Facts #228 - High resolution turrets

Post by posila »

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.
Thanks, I read the article before, but forgot about it :)
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.
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 :/
TOGoS
Former Staff
Former Staff
Posts: 97
Joined: Fri Jun 24, 2016 2:29 pm
Contact:

Re: Friday Facts #228 - High resolution turrets

Post by TOGoS »

djtumolo 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?
https://www.factorio.com/blog/post/fff-219
Zavian
Smart Inserter
Smart Inserter
Posts: 1648
Joined: Thu Mar 02, 2017 2:57 am
Contact:

Re: Friday Facts #228 - High resolution turrets

Post by Zavian »

posila wrote:
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.
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 :/
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).
User avatar
Ghoulish
Filter Inserter
Filter Inserter
Posts: 468
Joined: Fri Oct 16, 2015 8:40 am

Re: Friday Facts #228 - High resolution turrets

Post by Ghoulish »

You should name and shame the yellow player in the gif! How dare s/he not help out! Love the new graphics and the beams! Finally :)
See the daily™ struggles with my Factory! :D https://www.twitch.tv/repetitivebeats
draknor
Burner Inserter
Burner Inserter
Posts: 8
Joined: Fri Jul 07, 2017 6:18 pm
Contact:

Re: Friday Facts #228 - High resolution turrets

Post by draknor »

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.
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!

This part I felt was particularly relevant:
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.
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.

Although, as posila posted:
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?
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?
Vex
Manual Inserter
Manual Inserter
Posts: 1
Joined: Fri Feb 02, 2018 9:55 pm
Contact:

Re: Friday Facts #228 - High resolution turrets

Post by Vex »

You know what I'd like to see? RGB laser turrets controlled via the circuit network.

Make it rave when the bugs come.
torham
Fast Inserter
Fast Inserter
Posts: 187
Joined: Sun May 25, 2014 1:40 pm
Contact:

Re: Friday Facts #228 - High resolution turrets

Post by torham »

Laser Beams, HELL YEA!!!!111 :twisted: :twisted: :twisted: :twisted:
User avatar
Stede
Inserter
Inserter
Posts: 26
Joined: Wed May 11, 2016 12:36 pm
Contact:

Re: Friday Facts #228 - High resolution turrets

Post by Stede »

Wait - this update to lasers is potentially huge - will they deal their damage 'continuously' or still deal damage as more discrete pulses?

If this becomes continuous, then laser shooting speed will go away and lasers will essentially no longer have any overkill, which is effectively a huge buff. This isn't just graphical - it's a core mechanics update.
noobhead99
Burner Inserter
Burner Inserter
Posts: 10
Joined: Thu Dec 21, 2017 5:40 pm
Contact:

Re: Friday Facts #228 - High resolution turrets

Post by noobhead99 »

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
posila
Factorio Staff
Factorio Staff
Posts: 5349
Joined: Thu Jun 11, 2015 1:35 pm
Contact:

Re: Friday Facts #228 - High resolution turrets

Post by posila »

noobhead99 wrote:THIS IS SUPPOSED TO BE RELIASTIC!?!?!?
Wait... what?
orzelek
Smart Inserter
Smart Inserter
Posts: 3923
Joined: Fri Apr 03, 2015 10:20 am
Contact:

Re: Friday Facts #228 - High resolution turrets

Post by orzelek »

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
You do realize that laser beams have nothing realistic about them at all? ;)

They do look significantly better then current version.. :D
Zanthra
Fast Inserter
Fast Inserter
Posts: 232
Joined: Fri Mar 25, 2016 8:18 am
Contact:

Re: Friday Facts #228 - High resolution turrets

Post by Zanthra »

Whose Bug is this Anyway is a very good article. When I was reading the FFF I was thinking that these save game bugs are far more likely to be caused by a RAM error due to faulty hardware than to be due to a cosmic ray. The big question is how far out of your way would you want to go to support people who may be running on faulty hardware, and may not consider it a good use of their money to replace it. You can't solve everything in the case that random bits start getting flipped, but in some cases you can identify things that are out of expected sane ranges as you save the file or read it from disk and perhaps notify the user of inconsistent state, and correct for some problems automatically. Of course that takes code and development time that for a system without such errors will be effectively wasted.
Post Reply

Return to “News”