Friday Facts #242 - Offensive programming

Regular reports on Factorio development.

Friday Facts #242 - Offensive programming

Postby Klonan » Fri May 11, 2018 5:57 pm

User avatar
Klonan
Factorio Staff
Factorio Staff
 
Posts: 3103
Joined: Sun Jan 11, 2015 2:09 pm

Re: Friday Facts #242 - Offensive programming

Postby Gergely » Fri May 11, 2018 6:01 pm

kovarex wrote:Hello, this post is going to be more technical than usual, yet it might still be interesting to know the background of the process for some people.

Indeed it is.
User avatar
Gergely
Filter Inserter
Filter Inserter
 
Posts: 314
Joined: Sun Apr 10, 2016 8:31 pm

Re: Friday Facts #242 - Offensive programming

Postby Meddleman » Fri May 11, 2018 6:15 pm

I like the idea of using offensive programming because its essentially like using mines to rough-up an incoming wave of biters before turrets finish them off, instead of expecting turrets to deal with full HP behemoths.
Essentially, much like a crumple zone in a car, you want the game to crash at times that are safer than times it would be worse/harder to figure out what exactly went wrong.

As usual, FFF's from the coding-devs are always a fun read. :D
Meddleman
Inserter
Inserter
 
Posts: 32
Joined: Mon Jun 26, 2017 7:39 pm

Re: Friday Facts #242 - Offensive programming

Postby Philip017 » Fri May 11, 2018 6:18 pm

regarding the consistency check, i have noticed that there are times my game loads the save bar to full, but then takes forever to actually load into the game, with no indication as to what is happening, my guess here is that the game is doing a consistency check, it would be really nice if i knew that was happening, perhaps a loading/progress bar that would give me an idea of how much longer i have to wait for it to finish, and some text to let me know it's checking this. i believe that in most cases the consistency check is not needed, and perhaps it could be checked optionally should a save file fail to load. with it checking each version transition, as each time a mod is updated, or changed while being developed, another consistency check is done with the agonizingly long loading time. my two cents as a long time player. thanks again for creating this wonderful game.
User avatar
Philip017
Fast Inserter
Fast Inserter
 
Posts: 183
Joined: Thu Sep 01, 2016 11:21 pm

Re: Friday Facts #242 - Offensive programming

Postby Kamuchi » Fri May 11, 2018 6:24 pm

Interesting post as it never occured to me to that some game crashes might be on purpose to get a specific problem reported back if it would ever fail :)

I do have one question though now that this deconstructing and ghosting is brough up as some times it makes you pull your hair out when doing large prints, like solar arrays and skipping 1 tile by accident or moving large blueprints in general.
Why are drones dispatched with the new item befor the deconstrected item is picked up?

The issue is that when doing it from your personal roboport, most of the drones get stuck waiting for the deconstructed item to be picked up, having only a few drones this process can take awhile.
The problem stacks as the waiting drones still use energy and will return to recharge, which makes the drones that are doing pickup wait in line.
Is there a chance that you guys could look if adding a priority check over picking up an item when a drone is dispatched to place an item and if that tile is not clear, change the drone assignment from placing to pickup?
There might be a bit more cpu overhead if it has to do a check in the drone dispatch code, but better then having most drones waiting on the spot for it to be cleared to speed up the build and less blaming the poor drones for being trolls trying to place items while they can't :geek:

Awesome game, keep up the great work 8-)
Kamuchi
Burner Inserter
Burner Inserter
 
Posts: 19
Joined: Thu Aug 10, 2017 4:32 pm

Re: Friday Facts #242 - Offensive programming

Postby Rseding91 » Fri May 11, 2018 6:24 pm

Philip017 wrote:regarding the consistency check, i have noticed that there are times my game loads the save bar to full, but then takes forever to actually load into the game, with no indication as to what is happening, my guess here is that the game is doing a consistency check, it would be really nice if i knew that was happening, perhaps a loading/progress bar that would give me an idea of how much longer i have to wait for it to finish, and some text to let me know it's checking this. i believe that in most cases the consistency check is not needed, and perhaps it could be checked optionally should a save file fail to load. with it checking each version transition, as each time a mod is updated, or changed while being developed, another consistency check is done with the agonizingly long loading time. my two cents as a long time player. thanks again for creating this wonderful game.


If people could give me saves that reproduce that long wait time I can look into adding a progress bar to the logic.

I don't want to just add progress bars in without first knowing what part is taking the time up as every additional thing adds complexity and possible bugs :)
If you want to get ahold of me I'm almost always on IRC and Discord.
Rseding91
Factorio Staff
Factorio Staff
 
Posts: 7376
Joined: Wed Jun 11, 2014 5:23 am

Re: Friday Facts #242 - Offensive programming

Postby Treahblade » Fri May 11, 2018 6:25 pm

Image
Treahblade
Manual Inserter
Manual Inserter
 
Posts: 3
Joined: Mon Feb 19, 2018 10:37 pm

Re: Friday Facts #242 - Offensive programming

Postby thereaverofdarkness » Fri May 11, 2018 6:33 pm

Kovarex I love you so much! Also that was a great read and I'm not a programmer but I want to hear more!

Rseding91 wrote:If people could give me saves that reproduce that long wait time I can look into adding a progress bar to the logic.

I don't want to just add progress bars in without first knowing what part is taking the time up as every additional thing adds complexity and possible bugs :)

Might I say that the game loading progress bar is fine work, please keep up the good work! I have had a few progress bar bugs myself, and it is the great pleasure I experience in all that properly-working progress bar that highlights the rare failures to me.

You guys are amazing!
Last edited by thereaverofdarkness on Fri May 11, 2018 6:52 pm, edited 2 times in total.
User avatar
thereaverofdarkness
Filter Inserter
Filter Inserter
 
Posts: 401
Joined: Wed Jun 01, 2016 5:07 am

Re: Friday Facts #242 - Offensive programming

Postby TfGuy44 » Fri May 11, 2018 6:44 pm

Experimental is there to experiment with.
I don't care if things break as long as it's making the game better.
Keep up the good work!
TfGuy44
Manual Inserter
Manual Inserter
 
Posts: 2
Joined: Tue Nov 22, 2016 11:28 pm

Re: Friday Facts #242 - Offensive programming

Postby ledow » Fri May 11, 2018 6:58 pm

Isn't "offensive programming" when you can't find the f***ing, sh***y, b*****d bug that's c***king everything up?
User avatar
ledow
Long Handed Inserter
Long Handed Inserter
 
Posts: 59
Joined: Sat Sep 24, 2016 3:00 pm

Re: Friday Facts #242 - Offensive programming

Postby falizure » Fri May 11, 2018 7:06 pm

I know this is slightly off topic but not exactly fully, however having been playing cooperatively with someone on a .34 build i noticed a issue that i know is in part due to my potato of a computer but i wonder if theirs hope that it could be improved in the game as well, we were starting to progress to the megabase stage, hadn't even brought on our new smelting yet and we were starting to look for good reactor blueprints to run everything, this lead me to a couple online, 1 that was super long and tilable and another that was simply like 24 reactors and their equipment, after importing the strings i found that merely looking at ether blueprint even in preview would lag my to the point i would become locked in place, even game restarts and reverting saves would not help as the moment i entered the game i would enter with the blueprint still open and still be stick, in the end we resolved it by having them run me over with a train and letting the blueprints decay on my body but it leads me to wonder could more work be done to blueprint performance? especially when its only in preview mode, and failing that could their at least be a way to ensure that you do not reenter a game with a blueprint still open, that would make it slightly easier to remove them if they are too intensive for a persons computer.
falizure
Burner Inserter
Burner Inserter
 
Posts: 6
Joined: Sun May 21, 2017 5:54 am

Re: Friday Facts #242 - Offensive programming

Postby thereaverofdarkness » Fri May 11, 2018 7:06 pm

ledow wrote:Isn't "offensive programming" when you can't find the f***ing, sh***y, b*****d bug that's c***king everything up?

That's "frustrated programming" and is usually what happens in an office that doesn't use "offensive programming".
User avatar
thereaverofdarkness
Filter Inserter
Filter Inserter
 
Posts: 401
Joined: Wed Jun 01, 2016 5:07 am

Re: Friday Facts #242 - Offensive programming

Postby Syriusz » Fri May 11, 2018 7:10 pm

After reading the title I was worried that you had troubles with social justice warriors...
Syriusz
Inserter
Inserter
 
Posts: 30
Joined: Thu May 07, 2015 12:34 pm
Location: Poland Wrocław

Re: Friday Facts #242 - Offensive programming

Postby malventano » Fri May 11, 2018 7:24 pm

Rseding91 wrote:
Philip017 wrote:regarding the consistency check, i have noticed that there are times my game loads the save bar to full, but then takes forever to actually load into the game, with no indication as to what is happening, my guess here is that the game is doing a consistency check, it would be really nice if i knew that was happening, perhaps a loading/progress bar that would give me an idea of how much longer i have to wait for it to finish, and some text to let me know it's checking this. i believe that in most cases the consistency check is not needed, and perhaps it could be checked optionally should a save file fail to load. with it checking each version transition, as each time a mod is updated, or changed while being developed, another consistency check is done with the agonizingly long loading time. my two cents as a long time player. thanks again for creating this wonderful game.


If people could give me saves that reproduce that long wait time I can look into adding a progress bar to the logic.

I don't want to just add progress bars in without first knowing what part is taking the time up as every additional thing adds complexity and possible bugs :)


Take any decent sized save that uses some mods, and disable one of the mods that would result in entity removal from the map. Then load the save. You should see a considerably longer (order of magnitude in my experience) wait during the load.
Allyn Malventano
Editor, PC Perspective
---
Want to improve fluid flow between pumps / across longer distances? Try my Manifolds mod.
malventano
Fast Inserter
Fast Inserter
 
Posts: 181
Joined: Thu Apr 27, 2017 4:31 pm

Re: Friday Facts #242 - Offensive programming

Postby Jap2.0 » Fri May 11, 2018 7:27 pm

Philip017 wrote:regarding the consistency check, i have noticed that there are times my game loads the save bar to full, but then takes forever to actually load into the game, with no indication as to what is happening, my guess here is that the game is doing a consistency check, it would be really nice if i knew that was happening, perhaps a loading/progress bar that would give me an idea of how much longer i have to wait for it to finish, and some text to let me know it's checking this. i believe that in most cases the consistency check is not needed, and perhaps it could be checked optionally should a save file fail to load. with it checking each version transition, as each time a mod is updated, or changed while being developed, another consistency check is done with the agonizingly long loading time. my two cents as a long time player. thanks again for creating this wonderful game.


Does it occur when you remain on the same version, or does it only occur during migrations?
There are 10 types of people: those who get this joke and those who don't.
Jap2.0
Smart Inserter
Smart Inserter
 
Posts: 1300
Joined: Tue Jun 20, 2017 12:02 am

Re: Friday Facts #242 - Offensive programming

Postby DeathMers » Fri May 11, 2018 7:33 pm

So basically you fucked up consistency check to crash and crash log experience, together with player experience, to make the game better in future.... Works for me ;) but I think this fff should be made like... pre 16.36.... All that pain, crashes, wasted time searching and posting crash problems, crying kids... You really fucked up this in major way.... Actually I think, if u tell factorio community you plan to do this and that, you would get more crashlogs and outcome from this, because factorio community actually wants to help you with game development.


Use this advatntage wisely.
User avatar
DeathMers
Inserter
Inserter
 
Posts: 38
Joined: Sun Sep 18, 2016 1:30 pm

Re: Friday Facts #242 - Offensive programming

Postby Jap2.0 » Fri May 11, 2018 7:43 pm

In the kindest way possible... couldn't you detect some of these problems (most notable the "all trains crashing one") prior to release by simply leaving a moderately sized base open for a few minutes on the newer version, and making sure that everything continues as normal?
There are 10 types of people: those who get this joke and those who don't.
Jap2.0
Smart Inserter
Smart Inserter
 
Posts: 1300
Joined: Tue Jun 20, 2017 12:02 am

Re: Friday Facts #242 - Offensive programming

Postby bobucles » Fri May 11, 2018 8:11 pm

It's always nice when players spill their salt when they discover why "beta testing" is called "beta testing".
bobucles
Smart Inserter
Smart Inserter
 
Posts: 1138
Joined: Wed Jun 10, 2015 10:37 pm

Re: Friday Facts #242 - Offensive programming

Postby kovarex » Fri May 11, 2018 8:17 pm

DeathMers wrote:So basically you fucked up consistency check to crash and crash log experience, together with player experience, to make the game better in future.... Works for me ;) but I think this fff should be made like... pre 16.36.... All that pain, crashes, wasted time searching and posting crash problems, crying kids... You really fucked up this in major way.... Actually I think, if u tell factorio community you plan to do this and that, you would get more crashlogs and outcome from this, because factorio community actually wants to help you with game development.


Use this advatntage wisely.


Yes, I'm not saying it was done greatly. We started adding a lot of different consistency checks throughout the 0.16 releases, but it somehow almost never triggered.

Jap2.0 wrote:In the kindest way possible... couldn't you detect some of these problems (most notable the "all trains crashing one") prior to release by simply leaving a moderately sized base open for a few minutes on the newer version, and making sure that everything continues as normal?


Well, I did that, but the saves I had (and we even have bunch) didn't crash on those. More in this post: https://www.reddit.com/r/factorio/comme ... 1/dye7r1g/
kovarex
Factorio Staff
Factorio Staff
 
Posts: 6591
Joined: Wed Feb 06, 2013 12:00 am
Location: Prague

Re: Friday Facts #242 - Offensive programming

Postby <NO_NAME> » Fri May 11, 2018 8:23 pm

So you basically fixing the game by breaking it. I cannot wait for the time when Bethesda have finished their consistency checks.
I am a translator. And what you did for Factorio?
Check out my mod "Realistic Ores" and my other mods!
User avatar
<NO_NAME>
Fast Inserter
Fast Inserter
 
Posts: 161
Joined: Tue Aug 02, 2016 9:52 am

Next

Return to News

Who is online

Users browsing this forum: No registered users and 5 guests