Page 2 of 3

Re: Friday Facts #242 - Offensive programming

Posted: Fri May 11, 2018 8:24 pm
by Rseding91
malventano wrote: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.
But I don't. That's why I asked for example saves because the ones I test with don't have this problem.

Re: Friday Facts #242 - Offensive programming

Posted: Fri May 11, 2018 8:27 pm
by Jap2.0
kovarex wrote:
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/
Ah, okay, thanks for the explanation.

Re: Friday Facts #242 - Offensive programming

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

Re: Friday Facts #242 - Offensive programming

Posted: Fri May 11, 2018 9:04 pm
by Avezo
Yeah, so, it doesn't really belong here, but here's the idea for pipes:
Make it a network like power entities and then instead of calculating fluid box for each entity every tick, just calculate distances between inputs and outputs and set some throughtput variable only at that point(s). These variables won't change during game ticks, they would change only when 'pipe network' changes, like then you add more pipes or something. Better for UPS I think overally than separate fluid box for each entity constantly updating.

Re: Friday Facts #242 - Offensive programming

Posted: Fri May 11, 2018 9:36 pm
by Ohz
I send you all my love for your amazing work, devs.
TfGuy44 wrote: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!
Can't agree more.

Re: Friday Facts #242 - Offensive programming

Posted: Fri May 11, 2018 10:25 pm
by dasiro
Rseding91 wrote:
malventano wrote: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.
But I don't. That's why I asked for example saves because the ones I test with don't have this problem.
I had this while loading my seablock save from 15.40 in a vanilla 16.41 (so all mods disabled). I knew it was migrating because of this very reason, but it took like half an hour or so to remove all modded content

Re: Friday Facts #242 - Offensive programming

Posted: Fri May 11, 2018 11:10 pm
by Light
I chuckled at the toddler crying over the train explosions. Then I laughed when the father put him through it again.

Tough love is great.

Re: Friday Facts #242 - Offensive programming

Posted: Fri May 11, 2018 11:13 pm
by QGamer
Wow, this FFF was a great read. It's nice to know that you are paving the way for a future Factorio that has fewer bugs. :)
However, earlier today (before I read your FFF) I discovered that if I used my deconstruction planner on a wall, it could walk through it easily without needing a gate. Then I could just cancel deconstruction and the wall would return to normal. This sounds to me like an exploit, although I'm not sure what the best course of action is.

Re: Friday Facts #242 - Offensive programming

Posted: Sat May 12, 2018 12:35 am
by Avezo
So, is it safe to disable experimental version access without screwing save files? Will they migrate back to stable version?

Re: Friday Facts #242 - Offensive programming

Posted: Sat May 12, 2018 1:25 am
by Jap2.0
Avezo wrote:So, is it safe to disable experimental version access without screwing save files? Will they migrate back to stable version?
Generally they only migrate forward - I don't know if the opposite would work, but I know it's not technically supported.

Re: Friday Facts #242 - Offensive programming

Posted: Sat May 12, 2018 1:41 am
by ManaUser
Annoying.

Re: Friday Facts #242 - Offensive programming

Posted: Sat May 12, 2018 1:49 am
by jackthesmack
I love how the dad was loving it, only to notice his kid crying.

Re: Friday Facts #242 - Offensive programming

Posted: Sat May 12, 2018 2:27 am
by zebediah49
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 :)
Is there some kind of centralized "Save bounty" location? I, at least, have managed to cause quite a few weird things over the years, but usually ignore it as "probably my fault", likely due to some interaction with dozens of mods held together with shoestrings and version hacks. It would be interesting to look over a list of undiagnosed bugs, so if I manage to accidentally repro one of them I can post the example.
The checks take quite some time to perform, so calling it on every save/load would affect the game too much, so we decided to call it only on version transition, which includes also transition of any version of any mod.
Would it make sense to do this in a completely separate thread? That is, if Factorio detects you have the extra cores to spare for it, spawn a low priority thread that runs a consistency check in the background?

Alternatively, is it possible to only check part of the save's consistency? So, for example, could you randomly choose 1% of the tests, or only part of the entities? By making it much faster, that would make it potentially acceptable to run it more often.

Re: Friday Facts #242 - Offensive programming

Posted: Sat May 12, 2018 2:34 am
by Jap2.0
zebediah49 wrote:
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 :)
Is there some kind of centralized "Save bounty" location? I, at least, have managed to cause quite a few weird things over the years, but usually ignore it as "probably my fault", likely due to some interaction with dozens of mods held together with shoestrings and version hacks. It would be interesting to look over a list of undiagnosed bugs, so if I manage to accidentally repro one of them I can post the example.
Thread for posting saves for optimization
Undiagnosed bugs are usually in pending.

If all else fails, just post a bug report.

Re: Friday Facts #242 - Offensive programming

Posted: Sat May 12, 2018 4:02 am
by Zavian
Jap2.0 wrote:Undiagnosed bugs are usually in pending.
New bug reports should be in Bugs viewforum.php?f=7 . Pending is used for reports that are waiting on more detailed information.
Make sure you read viewtopic.php?f=7&t=3638 .

Re: Friday Facts #242 - Offensive programming

Posted: Sat May 12, 2018 4:31 am
by Tricorius
Light wrote:I chuckled at the toddler crying over the train explosions. Then I laughed when the father put him through it again.

Tough love is great.
This is known as “offensive parenting”. ;)

And it should be performed often. Modern kids are way too soft! :D

Re: Friday Facts #242 - Offensive programming

Posted: Sat May 12, 2018 7:43 am
by joni65
<NO_NAME> wrote:So you basically fixing the game by breaking it. I cannot wait for the time when Bethesda have finished their consistency checks.
So Funny! As an avid fan of Bethesda this really made me chuckle. Man, the day they release a game that isn’t buggy as hell, I will probably pass out. I love/hate/love/hate/love Bethesda!

Re: Friday Facts #242 - Offensive programming

Posted: Sat May 12, 2018 9:18 am
by ske
Your offensive programming sounds like test-driven development or simply assertions that make the program fail early before it develops strange effects which are hard to debug. While it looks like "you made the program fail to load" you actually prevented it corrupting everything due to undefined behavior. I consider this to be a very good move.

One thing I'm not so sure about, though, is how blueprints affect the game. One one hand they are very powerful but on the other hand they are too powerful and may even prevent the player from developing their own creative solutions to the problems. When you don't have construction robots you can still place down blueprints and build everyting accordingly by hand. In multiplayer games this leads to making the same building blocks over and over for each new game.

I don't remember where I've read this but somewhere it was written that randomizing the recipies to some extent would take away a lot of the power of blueprints because the ideal ratios are different for every game. Does anyone know if something like that is already in place on some multiplayer servers?

Re: Friday Facts #242 - Offensive programming

Posted: Sat May 12, 2018 12:38 pm
by mathturtle
Rseding91 wrote: But I don't. That's why I asked for example saves because the ones I test with don't have this problem.
Rseding91, you should have a save now, I uploaded it in the performance optimizations thread.

Re: Friday Facts #242 - Offensive programming

Posted: Sat May 12, 2018 3:33 pm
by Jap2.0
Zavian wrote:
Jap2.0 wrote:Undiagnosed bugs are usually in pending.
New bug reports should be in Bugs viewforum.php?f=7 . Pending is used for reports that are waiting on more detailed information.
Make sure you read viewtopic.php?f=7&t=3638 .
Yes, that's a very important topic to read as well. I put pending there because context made it sound like he wanted bugs that had been reported, but they needed more information to fix. In many cases, a new report is a better idea.