Friday Facts #242 - Offensive programming
Re: Friday Facts #242 - Offensive programming
Indeed it is.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.
Re: Friday Facts #242 - Offensive programming
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.
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.
Other Crazy Suggestions:
| Circuit Network Information 2.0 - Open Your World | "Each" Signal Choice as Stack Size Control Signal |
| Circuit Network Information 2.0 - Open Your World | "Each" Signal Choice as Stack Size Control Signal |
Re: Friday Facts #242 - Offensive programming
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
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
Awesome game, keep up the great work
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
Awesome game, keep up the great work
Re: Friday Facts #242 - Offensive programming
If people could give me saves that reproduce that long wait time I can look into adding a progress bar to the logic.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.
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.
-
- Manual Inserter
- Posts: 3
- Joined: Mon Feb 19, 2018 10:37 pm
- Contact:
- thereaverofdarkness
- Filter Inserter
- Posts: 558
- Joined: Wed Jun 01, 2016 5:07 am
- Contact:
Re: Friday Facts #242 - Offensive programming
Kovarex I love you so much! Also that was a great read and I'm not a programmer but I want to hear more!
You guys are amazing!
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.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
You guys are amazing!
Last edited by thereaverofdarkness on Fri May 11, 2018 6:52 pm, edited 2 times in total.
Re: Friday Facts #242 - Offensive programming
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!
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
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
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.
- thereaverofdarkness
- Filter Inserter
- Posts: 558
- Joined: Wed Jun 01, 2016 5:07 am
- Contact:
Re: Friday Facts #242 - Offensive programming
That's "frustrated programming" and is usually what happens in an office that doesn't use "offensive programming".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?
Re: Friday Facts #242 - Offensive programming
After reading the title I was worried that you had troubles with social justice warriors...
-
- Filter Inserter
- Posts: 345
- Joined: Thu Apr 27, 2017 4:31 pm
- Contact:
Re: Friday Facts #242 - Offensive programming
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.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.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.
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
Allyn Malventano
---
Want to improve fluid flow between pumps / across longer distances? Try my Manifolds mod.
---
Want to improve fluid flow between pumps / across longer distances? Try my Manifolds mod.
Re: Friday Facts #242 - Offensive programming
Does it occur when you remain on the same version, or does it only occur during migrations?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.
There are 10 types of people: those who get this joke and those who don't.
Re: Friday Facts #242 - Offensive programming
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.
Use this advatntage wisely.
Re: Friday Facts #242 - Offensive programming
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.
Re: Friday Facts #242 - Offensive programming
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
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.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.
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/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?
Re: Friday Facts #242 - Offensive programming
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!
Check out my mod "Realistic Ores" and my other mods!