Friday Facts #242 - Offensive programming

Regular reports on Factorio development.
User avatar
Gergely
Filter Inserter
Filter Inserter
Posts: 616
Joined: Sun Apr 10, 2016 8:31 pm
Contact:

Re: Friday Facts #242 - Offensive programming

Post by Gergely »

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.
Meddleman
Long Handed Inserter
Long Handed Inserter
Posts: 51
Joined: Mon Jun 26, 2017 7:39 pm
Contact:

Re: Friday Facts #242 - Offensive programming

Post by Meddleman »

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
User avatar
Philip017
Filter Inserter
Filter Inserter
Posts: 360
Joined: Thu Sep 01, 2016 11:21 pm
Contact:

Re: Friday Facts #242 - Offensive programming

Post by Philip017 »

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.
Kamuchi
Inserter
Inserter
Posts: 20
Joined: Thu Aug 10, 2017 4:32 pm
Contact:

Re: Friday Facts #242 - Offensive programming

Post by Kamuchi »

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-)
Rseding91
Factorio Staff
Factorio Staff
Posts: 14341
Joined: Wed Jun 11, 2014 5:23 am
Contact:

Re: Friday Facts #242 - Offensive programming

Post by Rseding91 »

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 Discord.
Treahblade
Manual Inserter
Manual Inserter
Posts: 3
Joined: Mon Feb 19, 2018 10:37 pm
Contact:

Re: Friday Facts #242 - Offensive programming

Post by Treahblade »

Image
User avatar
thereaverofdarkness
Filter Inserter
Filter Inserter
Posts: 558
Joined: Wed Jun 01, 2016 5:07 am
Contact:

Re: Friday Facts #242 - Offensive programming

Post by thereaverofdarkness »

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.
TfGuy44
Manual Inserter
Manual Inserter
Posts: 3
Joined: Tue Nov 22, 2016 11:28 pm
Contact:

Re: Friday Facts #242 - Offensive programming

Post by TfGuy44 »

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!
User avatar
ledow
Fast Inserter
Fast Inserter
Posts: 102
Joined: Sat Sep 24, 2016 3:00 pm
Contact:

Re: Friday Facts #242 - Offensive programming

Post by ledow »

Isn't "offensive programming" when you can't find the f***ing, sh***y, b*****d bug that's c***king everything up?
falizure
Burner Inserter
Burner Inserter
Posts: 7
Joined: Sun May 21, 2017 5:54 am
Contact:

Re: Friday Facts #242 - Offensive programming

Post by falizure »

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.
User avatar
thereaverofdarkness
Filter Inserter
Filter Inserter
Posts: 558
Joined: Wed Jun 01, 2016 5:07 am
Contact:

Re: Friday Facts #242 - Offensive programming

Post by thereaverofdarkness »

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".
Syriusz
Long Handed Inserter
Long Handed Inserter
Posts: 61
Joined: Thu May 07, 2015 12:34 pm
Contact:

Re: Friday Facts #242 - Offensive programming

Post by Syriusz »

After reading the title I was worried that you had troubles with social justice warriors...
malventano
Filter Inserter
Filter Inserter
Posts: 345
Joined: Thu Apr 27, 2017 4:31 pm
Contact:

Re: Friday Facts #242 - Offensive programming

Post by malventano »

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
---
Want to improve fluid flow between pumps / across longer distances? Try my Manifolds mod.
Jap2.0
Smart Inserter
Smart Inserter
Posts: 2379
Joined: Tue Jun 20, 2017 12:02 am
Contact:

Re: Friday Facts #242 - Offensive programming

Post by Jap2.0 »

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.
User avatar
DeathMers
Inserter
Inserter
Posts: 39
Joined: Sun Sep 18, 2016 1:30 pm
Contact:

Re: Friday Facts #242 - Offensive programming

Post by DeathMers »

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.
Jap2.0
Smart Inserter
Smart Inserter
Posts: 2379
Joined: Tue Jun 20, 2017 12:02 am
Contact:

Re: Friday Facts #242 - Offensive programming

Post by Jap2.0 »

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.
bobucles
Smart Inserter
Smart Inserter
Posts: 1708
Joined: Wed Jun 10, 2015 10:37 pm
Contact:

Re: Friday Facts #242 - Offensive programming

Post by bobucles »

It's always nice when players spill their salt when they discover why "beta testing" is called "beta testing".
kovarex
Factorio Staff
Factorio Staff
Posts: 8207
Joined: Wed Feb 06, 2013 12:00 am
Contact:

Re: Friday Facts #242 - Offensive programming

Post by kovarex »

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/
User avatar
<NO_NAME>
Filter Inserter
Filter Inserter
Posts: 295
Joined: Tue Aug 02, 2016 9:52 am
Contact:

Re: Friday Facts #242 - Offensive programming

Post by <NO_NAME> »

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 did you do for Factorio?
Check out my mod "Realistic Ores" and my other mods!
Post Reply

Return to “News”