Page 1 of 3

Friday Facts #242 - Offensive programming

Posted: Fri May 11, 2018 5:57 pm
by Klonan

Re: Friday Facts #242 - Offensive programming

Posted: Fri May 11, 2018 6:01 pm
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.

Re: Friday Facts #242 - Offensive programming

Posted: Fri May 11, 2018 6:15 pm
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

Re: Friday Facts #242 - Offensive programming

Posted: Fri May 11, 2018 6:18 pm
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.

Re: Friday Facts #242 - Offensive programming

Posted: Fri May 11, 2018 6:24 pm
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-)

Re: Friday Facts #242 - Offensive programming

Posted: Fri May 11, 2018 6:24 pm
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 :)

Re: Friday Facts #242 - Offensive programming

Posted: Fri May 11, 2018 6:25 pm
by Treahblade
Image

Re: Friday Facts #242 - Offensive programming

Posted: Fri May 11, 2018 6:33 pm
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!

Re: Friday Facts #242 - Offensive programming

Posted: Fri May 11, 2018 6:44 pm
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!

Re: Friday Facts #242 - Offensive programming

Posted: Fri May 11, 2018 6:58 pm
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?

Re: Friday Facts #242 - Offensive programming

Posted: Fri May 11, 2018 7:06 pm
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.

Re: Friday Facts #242 - Offensive programming

Posted: Fri May 11, 2018 7:06 pm
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".

Re: Friday Facts #242 - Offensive programming

Posted: Fri May 11, 2018 7:10 pm
by Syriusz
After reading the title I was worried that you had troubles with social justice warriors...

Re: Friday Facts #242 - Offensive programming

Posted: Fri May 11, 2018 7:24 pm
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.

Re: Friday Facts #242 - Offensive programming

Posted: Fri May 11, 2018 7:27 pm
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?

Re: Friday Facts #242 - Offensive programming

Posted: Fri May 11, 2018 7:33 pm
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.

Re: Friday Facts #242 - Offensive programming

Posted: Fri May 11, 2018 7:43 pm
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?

Re: Friday Facts #242 - Offensive programming

Posted: Fri May 11, 2018 8:11 pm
by bobucles
It's always nice when players spill their salt when they discover why "beta testing" is called "beta testing".

Re: Friday Facts #242 - Offensive programming

Posted: Fri May 11, 2018 8:17 pm
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/

Re: Friday Facts #242 - Offensive programming

Posted: Fri May 11, 2018 8:23 pm
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.