But I don't. That's why I asked for example saves because the ones I test with don't have this problem.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.
Friday Facts #242 - Offensive programming
Re: Friday Facts #242 - Offensive programming
If you want to get ahold of me I'm almost always on Discord.
Re: Friday Facts #242 - Offensive programming
Ah, okay, thanks for the explanation.kovarex wrote: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?
There are 10 types of people: those who get this joke and those who don't.
-
- Burner Inserter
- Posts: 9
- Joined: Fri Apr 27, 2018 6:35 pm
- Contact:
Re: Friday Facts #242 - Offensive programming
^THISbobucles wrote: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
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.
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
I send you all my love for your amazing work, devs.
Can't agree more.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!
I'm not english, sorry for my mistakes
Re: Friday Facts #242 - Offensive programming
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 contentRseding91 wrote:But I don't. That's why I asked for example saves because the ones I test with don't have this problem.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.
Re: Friday Facts #242 - Offensive programming
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.
Tough love is great.
Re: Friday Facts #242 - Offensive programming
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.
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.
"Adam fell that men might be; and men are, that they might have joy."
Re: Friday Facts #242 - Offensive programming
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
Generally they only migrate forward - I don't know if the opposite would work, but I know it's not technically supported.Avezo wrote:So, is it safe to disable experimental version access without screwing save files? Will they migrate back to stable version?
There are 10 types of people: those who get this joke and those who don't.
-
- Inserter
- Posts: 46
- Joined: Sun May 04, 2014 9:46 pm
- Contact:
Re: Friday Facts #242 - Offensive programming
I love how the dad was loving it, only to notice his kid crying.
-
- Fast Inserter
- Posts: 122
- Joined: Fri Jun 17, 2016 8:17 pm
- Contact:
Re: Friday Facts #242 - Offensive programming
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.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
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?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.
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
Thread for posting saves for optimizationzebediah49 wrote: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.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
Undiagnosed bugs are usually in pending.
If all else fails, just post a bug report.
There are 10 types of people: those who get this joke and those who don't.
Re: Friday Facts #242 - Offensive programming
New bug reports should be in Bugs viewforum.php?f=7 . Pending is used for reports that are waiting on more detailed information.Jap2.0 wrote:Undiagnosed bugs are usually in pending.
Make sure you read viewtopic.php?f=7&t=3638 .
Re: Friday Facts #242 - Offensive programming
This is known as “offensive parenting”.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.
And it should be performed often. Modern kids are way too soft!
Re: Friday Facts #242 - Offensive programming
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!<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.
Re: Friday Facts #242 - Offensive programming
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?
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?
-
- Inserter
- Posts: 45
- Joined: Sat Jan 21, 2017 8:19 pm
- Contact:
Re: Friday Facts #242 - Offensive programming
Rseding91, you should have a save now, I uploaded it in the performance optimizations thread.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.
Re: Friday Facts #242 - Offensive programming
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.Zavian wrote:New bug reports should be in Bugs viewforum.php?f=7 . Pending is used for reports that are waiting on more detailed information.Jap2.0 wrote:Undiagnosed bugs are usually in pending.
Make sure you read viewtopic.php?f=7&t=3638 .
There are 10 types of people: those who get this joke and those who don't.