Friday Facts #231 - Belt compression & Crash log uploading

Regular reports on Factorio development.

Re: Re:

Postby brunzenstein » Sat Feb 24, 2018 9:49 am

Rseding91 wrote:
TigBits wrote:All the sperging out over uploading crash logs is less about privacy and more about piracy. Thieves don't like it when their stolen goods phone home.

Aside from that, anyone whining about privacy and sill using chrome/google/facebook on a daily basis is a hypocrite and an idiot.


It is fun to see crash logs where the person clearly pirated it :D But I don't really care. If it helps us fix a bug then they're helping us make the game better.

:D
User avatar
brunzenstein
Filter Inserter
Filter Inserter
 
Posts: 792
Joined: Tue Mar 01, 2016 2:27 pm
Location: Vienna

Re: Friday Facts #231 - Belt compression & Crash log uploading

Postby Yinan » Sat Feb 24, 2018 11:02 am

Why not make it opt-in in the sense of giving a prompt at the start of the game for the first time after it is implemented where it explains what it does and where you then add buttons at the bottom where you can either send in the future (no more prompts) or not send at all (also no more prompts).

Since it's only a single time that this prompt is shown, it won't disrupt anyone, you get the "opt-in" which is always better than the "opt-out" and a lot more people will send you reports.
Yinan
Fast Inserter
Fast Inserter
 
Posts: 125
Joined: Sun Feb 14, 2016 2:40 pm

Re: Friday Facts #231 - Belt compression & Crash log uploading

Postby mathturtle » Sat Feb 24, 2018 12:05 pm

I admit I was skeptical about the crash logs at first. But I think you have convinced me. I will trust your personal data remover and the EU privacy laws (which are much better than here in the US).

About belt compression: THANK YOU!!!!! I did wonder when the whole belts/bots debate started why you were talking about it after giving belts such a huge nerf by removing compression. It really did feel like belts did a "one step forward, two steps back" thing by being optimized but becoming so much harder to use in .16. I'm glad belt compression is fixed and I will now consider building a large belt base :D
mathturtle
Inserter
Inserter
 
Posts: 36
Joined: Sat Jan 21, 2017 8:19 pm

Re: Friday Facts #231 - Belt compression & Crash log uploading

Postby toydarian » Sat Feb 24, 2018 12:54 pm

Thanks for addressing the "privacy issue"! I usually opt out immediately from those features wherever I can, but for you, I'm going to turn it on again the next time, I launch the game.

Concerning the Ryzen thingy:
I have such a processor myself (Ryzen 7 1700X, and I'm really happy with it btw.) and I never experienced a crash as described by you. Have those crashes appeared on Windows as well as Linux Systems?
If you should ever want to try out a safegame or something like that, you can contact me, I'd be happy to help you. (I have a masters in Computer Science, so you won't need to explain too much.)

I have another weired issue. Till now, I was sure, that it was my fault, that's why I never reported it, but maybe it has something to do with the Ryzen CPU.
From time to time, I get FPS/UPS drops to exactly 30/30. Those drops happen in vanilla as well as in heavily modded games, in the beginning, where I mine coal manually as well as in big bases. Sometimes the drops last for a second and sometimes they last 10-20 seconds, sometimes I play for hours without an issue and sometimes I experience five drops during one hour. Everything seems very random and not reproducable to me.
I blamed Windows at first, but I can't find a process using too much CPU time.
The funny thing is, that the "Wait for Update", "Flip" and "Sleep" values increase, but the Update time does not. If I had to guess, I'd say the rendering engine waits for an update that is already present.
If you are interested in this, I'd be happy to file a bug and provide additional information (screenshots etc.).
toydarian
Manual Inserter
Manual Inserter
 
Posts: 3
Joined: Fri Jul 29, 2016 8:21 am

Re: Friday Facts #231 - Belt compression & Crash log uploading

Postby unobtanium » Sat Feb 24, 2018 1:09 pm

Jap2.0 wrote:
    1. I'm going to upload it here anyway
    2. I can provide much more information on the forum than a single log
    3. There are many bugs that don't involve crashes, and in those cases a log won't get sent
    4. In the hypothetical case I try to reproduce a crash and in the process the game crashes 10 times, you have no way of knowing that 10 different people didn't suddenly have the same crash


1. That goes for you, but as the blog post statistically has proven, most players dont post and upload anything on the forums.
2. I doubt that. Even if you can provide the same and more information it will be in a different format compared to the crash log. You kind of have to think about the person accually having to resolve your issue. It is much easier when the person is able to work with their/his own standard instead of having individual crash reports from different people. It requires more work on the receiving end.
3. It is a crash log, not a bug log. Hence its name. Of course a CRASH log wont help with a bug...
4. This hypothetical case fails when the crash is very rare or even random and therefore not reproducable. Even if you are able to reproduce the crash and the game crashes 10 times in a row with the same error message, the log will provide enough information to determine that it comes from the same person. The log probably provides a timestamp, the computer parts and other unique computer identifier. Therefore, you can easily filter the same crashes from the same player.

Furthermore, as the blog post already recommends: You can still post and explain your crash log with a forum post. Just because you opt in the log upload, doesnt mean you have to stop posting on the forums.
unobtanium
Inserter
Inserter
 
Posts: 25
Joined: Fri Nov 04, 2016 11:58 am

Re: Friday Facts #231 - Belt compression & Crash log uploading

Postby unobtanium » Sat Feb 24, 2018 1:18 pm

Ás the blog post already said, having it turned off wont create useful data. People wont even know about its excitance, and if they do, they will leave it off, because they dont trust it ("why is it off on default. thats might be fishy, i will leave it off.").

Having the player ask on installation or first startup will lead to the same result. People will turn it off without further thinking about it.

A way to resolve this, would be turning it on on installation or first startup a little message pops up, which would inform the player about the crash log. Then (instead of providing a button to turn it off right there) you just tell them how to turn it off in the settings. Most people will be either too lazy, dont read the message, just want to play the game or forget about it within the next minutes. Without providing an easy way for the player to turn it off "in the moment", it requires the player to do additional steps to turn it off, which would result in less people turning it off. You still kindly explain them that it exists and what it is for and how/where to turn it off.
unobtanium
Inserter
Inserter
 
Posts: 25
Joined: Fri Nov 04, 2016 11:58 am

Re: Friday Facts #231 - Belt compression & Crash log uploading

Postby Drury » Sat Feb 24, 2018 1:46 pm

I've played the game a lot on my Ryzen, never crashed... Now I kinda hope I do so you can get more data on this problem ;)

toydarian wrote:I have another weired issue. Till now, I was sure, that it was my fault, that's why I never reported it, but maybe it has something to do with the Ryzen CPU.
From time to time, I get FPS/UPS drops to exactly 30/30. Those drops happen in vanilla as well as in heavily modded games, in the beginning, where I mine coal manually as well as in big bases. Sometimes the drops last for a second and sometimes they last 10-20 seconds, sometimes I play for hours without an issue and sometimes I experience five drops during one hour. Everything seems very random and not reproducable to me.
I blamed Windows at first, but I can't find a process using too much CPU time.
The funny thing is, that the "Wait for Update", "Flip" and "Sleep" values increase, but the Update time does not. If I had to guess, I'd say the rendering engine waits for an update that is already present.
If you are interested in this, I'd be happy to file a bug and provide additional information (screenshots etc.).


FWIW I never get this with my 1500X.
Image
User avatar
Drury
Filter Inserter
Filter Inserter
 
Posts: 654
Joined: Tue Mar 25, 2014 8:01 pm
Location: Slovakia

Re: Friday Facts #231 - Belt compression & Crash log uploading

Postby Dev-iL » Sat Feb 24, 2018 2:15 pm

I've been wondering something regarding the automatic logs... There's another setting there that says "verbose logging". Does that affect the contents of the logs being auto-uploaded?
Leading Hebrew translator of Factorio.
User avatar
Dev-iL
Fast Inserter
Fast Inserter
 
Posts: 186
Joined: Thu Jul 02, 2015 2:48 pm
Location: Israel

Re: Re:

Postby roidal » Sat Feb 24, 2018 2:18 pm

Rseding91 wrote:It is fun to see crash logs where the person clearly pirated it

This is a interessting point. How do you distinguish between a "good" and a "bad" copy of the DRM-free version? :D
Or are there really cracked versions of the game used from steam?
roidal
Inserter
Inserter
 
Posts: 22
Joined: Mon Mar 07, 2016 9:49 pm

Re: Friday Facts #231 - Belt compression & Crash log uploading

Postby basementjack » Sat Feb 24, 2018 2:33 pm

Hey I think you just robbed gameplayers of a great opportunity.

Belt compression should have been a technology upgrade, and a new "belt compressor" entity would have been the result of the entity, this would have been a 1x1 tile pass through device would be put on a map in place of a single belt tile

Something like this: _ _ _ [] _ _ _

Items would go into the compressor with uneven spaces between them, and come out with either no space, or a space big enough for another item to be inserted.

This would be a fun thing for players to use, as the 1x1 size isn't a pain, and it just replaces a regular belt section.
basementjack
Long Handed Inserter
Long Handed Inserter
 
Posts: 64
Joined: Sun Sep 25, 2016 11:31 pm

Re: Friday Facts #231 - Belt compression & Crash log uploading

Postby Jap2.0 » Sat Feb 24, 2018 3:14 pm

wren6991 wrote:
In just 2 days Rseding fixed about 12 crashes


Isn't this normal for Rseding :D


Yes.

Rseding91 wrote:
TigBits wrote:All the sperging out over uploading crash logs is less about privacy and more about piracy. Thieves don't like it when their stolen goods phone home.

Aside from that, anyone whining about privacy and sill using chrome/google/facebook on a daily basis is a hypocrite and an idiot.


It is fun to see crash logs where the person clearly pirated it :D But I don't really care. If it helps us fix a bug then they're helping us make the game better.


How can you tell that they pirated it?

toydarian wrote:Thanks for addressing the "privacy issue"! I usually opt out immediately from those features wherever I can, but for you, I'm going to turn it on again the next time, I launch the game.

Concerning the Ryzen thingy:
I have such a processor myself (Ryzen 7 1700X, and I'm really happy with it btw.) and I never experienced a crash as described by you. Have those crashes appeared on Windows as well as Linux Systems?
If you should ever want to try out a safegame or something like that, you can contact me, I'd be happy to help you. (I have a masters in Computer Science, so you won't need to explain too much.)

I have another weired issue. Till now, I was sure, that it was my fault, that's why I never reported it, but maybe it has something to do with the Ryzen CPU.
From time to time, I get FPS/UPS drops to exactly 30/30. Those drops happen in vanilla as well as in heavily modded games, in the beginning, where I mine coal manually as well as in big bases. Sometimes the drops last for a second and sometimes they last 10-20 seconds, sometimes I play for hours without an issue and sometimes I experience five drops during one hour. Everything seems very random and not reproducable to me.
I blamed Windows at first, but I can't find a process using too much CPU time.
The funny thing is, that the "Wait for Update", "Flip" and "Sleep" values increase, but the Update time does not. If I had to guess, I'd say the rendering engine waits for an update that is already present.
If you are interested in this, I'd be happy to file a bug and provide additional information (screenshots etc.).


Try turning Vsync off - it tries to force FPS down to exactly 60 or 30.
unobtanium wrote:
Jap2.0 wrote:
    1. I'm going to upload it here anyway
    2. I can provide much more information on the forum than a single log
    3. There are many bugs that don't involve crashes, and in those cases a log won't get sent
    4. In the hypothetical case I try to reproduce a crash and in the process the game crashes 10 times, you have no way of knowing that 10 different people didn't suddenly have the same crash


1. That goes for you, but as the blog post statistically has proven, most players dont post and upload anything on the forums.
2. I doubt that. Even if you can provide the same and more information it will be in a different format compared to the crash log. You kind of have to think about the person accually having to resolve your issue. It is much easier when the person is able to work with their/his own standard instead of having individual crash reports from different people. It requires more work on the receiving end.
3. It is a crash log, not a bug log. Hence its name. Of course a CRASH log wont help with a bug...
4. This hypothetical case fails when the crash is very rare or even random and therefore not reproducable. Even if you are able to reproduce the crash and the game crashes 10 times in a row with the same error message, the log will provide enough information to determine that it comes from the same person. The log probably provides a timestamp, the computer parts and other unique computer identifier. Therefore, you can easily filter the same crashes from the same player.

Furthermore, as the blog post already recommends: You can still post and explain your crash log with a forum post. Just because you opt in the log upload, doesnt mean you have to stop posting on the forums.


1. I know, that's why I'm fine with this being a thing - as I said in the rest of my post.
2. Save(s), mods (if applicable), steps to reproduce (if known), easy contact, and the log, as always. I don't see how this would make it any harder for a dev.
3. I know - actually it's just a log, but anyway this point is somewhat irrelevant.
4. Fair enough - although they may misintepert how bad of a problem it is for me.
5. I want to know what happens to my bugs and crashes - if I post here, I know when it's resolved, needs more info, etc., and if they fix it via an uploaded log they would only do that if they discover my post is the same bug (I don't know if they look for similarr things on the forum - if they do, great).
There are 10 types of people: those who get this joke and those who don't.
Jap2.0
Smart Inserter
Smart Inserter
 
Posts: 1476
Joined: Tue Jun 20, 2017 12:02 am

Re: Friday Facts #231 - Belt compression & Crash log uploading

Postby Aki7 » Sat Feb 24, 2018 3:48 pm

I would be alright with the bug reports being opt-out, and where you opt out of the auto bug report uploads, there is an opt-in option for your email address to allow devs to contact you.

Code: Select all
[x] Automatically upload bug reports
[ ] Include my email addess with bug reports: [example@gmail.com]
Aki7
Burner Inserter
Burner Inserter
 
Posts: 5
Joined: Wed May 17, 2017 3:22 pm

Re: Friday Facts #231 - Belt compression & Crash log uploading

Postby Alice3173 » Sat Feb 24, 2018 6:25 pm

Gergely wrote:Thank you for finally addressing privacy. I have been dealing with log files myself and I can't help but wonder why people still feel unsafe about it. OR/AND worry about those who do not even care.

I still recommend not even making this an option though.

I disagree with not making it an option. There's a lot of people concerned about privacy who would go out of their way to prevent it out of spite because their choice in the matter was removed. And I don't blame them seeing as I'm one of them. Give me the choice (opt-out or opt-in, doesn't matter to me) and I'm far more likely to allow it, especially if they're transparent about what's being sent like it seems they are here. (As an example, in Firefox I have all the telemetry options, including the one disabled by default, enabled because they not only gave me a choice in the matter but I was able to look over the exact data being sent myself and decided I was fine with sharing that data, especially since they are giving me the choice whether to share or not.)
steinio wrote:Why not connect the uploaded crash log with the logged in user credentials and in the user area there is a overview of my own crash logs with a case number which i can quote in the forum?

I agree but that should definitely be an option rather than enforced. It'd also provide the devs with a way to contact a user about a given log. Though maybe just giving the option to attach an email address to the log for contact reasons might be better in that regard.
Programmdude wrote:I own windows 10 and factorio, I hate it that windows 10 has mandatory tracking, because I don't trust microsoft. However I don't mind factorio uploading crash logs for three reasons, I trust them as a company, crash logs dont monitor all my PC usage, just when I am playing factorio, and lastly, they are in the EU, which has much saner privacy laws.

I went out of my way to completely gut Windows 10's ability to send any form of telemetry. (And in the process found out exactly how much Windows cares about permissions. Which is to say not at all. I replaced their shitty Cortana executable with a blank one because it was running even after disabling it then set all accounts to deny all access to it and the OS still replaced it and still runs it in the background.) They try to remove your choice and they're not remotely transparent about what data they're after in the slightest. So they can simply make do without that data regardless of how innocuous it might have actually been.
User avatar
Alice3173
Long Handed Inserter
Long Handed Inserter
 
Posts: 95
Joined: Sun Apr 24, 2016 11:35 pm

Re: Friday Facts #231 - Belt compression & Crash log uploading

Postby ske » Sat Feb 24, 2018 7:36 pm

I feel like the privacy issue is kind of a slippery slope. Sure, you're not evil and I trust you very much but this may change in the future. Why not collect a bit more data? Why not send telemetry every now and then? It surely will improve the game if you know what options, maps and features players actually use.

In my opinion the default option should be: No sending of any data.

No telemetry. Not even checking for updates as this implies communication.

But you could collect crashdumps and store them. (They are not that big?) Wait until the player opts in to send them and then send them all at once. Make opting in easy and transparent.

Code: Select all
Options:
[ ] check for updates (Button: check now)
[ ] send crash reports (Button: send now)
[ ] send telemetry


Thanks for being very transparent about this now (even though you started it before asking us). Do the right thing.
ske
Filter Inserter
Filter Inserter
 
Posts: 303
Joined: Sat Oct 17, 2015 8:00 am

Re: Friday Facts #231 - Belt compression & Crash log uploading

Postby milo christiansen » Sun Feb 25, 2018 1:16 am

IMHO crash reports are missing one simple thing: A GUID that is added to the sent data AND displayed to the user as a way to link a specific crash report to a forum bug report. When the game crashes, the report is sent, and the user is told "If you want to report more details about what happened, feel free to do so on the forum, and use this ID in your post."

This way sent and forum reports can be linked to each other (if the user wants) in a quick and simple way.
milo christiansen
Long Handed Inserter
Long Handed Inserter
 
Posts: 99
Joined: Thu Jul 30, 2015 7:11 pm

Re: Friday Facts #231 - Belt compression & Crash log uploading

Postby Faerindel » Sun Feb 25, 2018 2:58 am

It's funny.

For years I have been pressing "Nope" when any kind of crash report dialog asking to be sent shows. Not because of any privacy concern, but because I've always thought they were useless, utterly ignored and not even worth the bit of bandwidth. Seems as if Wube thought of people like me when implementing this. :D

Reading this FF has been enlightening and will start pressing Yes when Unreal engine shits itself. And I'm totally fine with the current option of sending as default. We users are lazy bastards.
Faerindel
Burner Inserter
Burner Inserter
 
Posts: 7
Joined: Fri Dec 04, 2015 4:45 pm

Re: Friday Facts #231 - Belt compression & Crash log uploading

Postby henke37 » Sun Feb 25, 2018 9:54 am

In the paraphrased words of a Microsoft engineer: each crash dump is a vote for the bug. And in my words again: it is your civic duty to vote for the bugs you want fixed.
henke37
Long Handed Inserter
Long Handed Inserter
 
Posts: 77
Joined: Mon Jul 18, 2016 5:43 pm

Re: Friday Facts #231 - Belt compression & Crash log uploading

Postby sowieso » Sun Feb 25, 2018 10:41 am

I understand that crash logs are a very useful instrument on fixing bugs, but nevertheless you should be polite and ask. You can make it easy for the user to press yes, just use a bit psychology:

»We would like to upload a crash report to our servers to be able to handle this bug. This crash log is stripped of *any* personal information and solely used for fixing game bugs. *Please keep in mind that if you don't report this error, it will probably not be fixed.* You can always change this behaviour later in the options menu.«
[Don't upload][Upload][Always upload without asking]

I bet most people would click on the last option, which could be preselected and made visually more attractive (i.e. green background instead of red). In the options menu, users should be able to select: ["Always upload", "Never upload", "Always Ask"], where "Always ask" should be the default.

In my opinion, software that phones back to their developers without asking me before is always suspicious. I trust you, but if I was new to the game, I'd be suspicious. Keep on being the good guys, please! Also, I don't know how the legal status will be when the new European privacy policy becomes active in May. It's motto is privacy by *default*.
sowieso
Burner Inserter
Burner Inserter
 
Posts: 5
Joined: Sat May 06, 2017 3:21 am

Re: Friday Facts #231 - Belt compression & Crash log uploa

Postby meganothing » Sun Feb 25, 2018 12:45 pm

Light wrote:
Programmdude wrote:I own windows 10 and factorio, I hate it that windows 10 has mandatory tracking, because I don't trust microsoft.

It's not mandatory, you just didn't bother to look into your available options to turn it off. Options have always existed to disable telemetry since WinXP and haven't gotten any harder to disable since then.


That is very wrong, sorry. The (german) university where I work had to advise staff not to use the first windows10 version because some invasive options could not be turned off, not even with registry hacking (and in the menues privacy options were distributed like a jigsaw puzzle, so you could never be sure you found everything). Only after much pressure (don't remember, from germany or EU) did Microsoft make everything selectable. BUT: The interesting bit: Microsoft only made the professional version able to turn off all invasive options, I.e. companies usually can do it, private users of windows are out of luck if they want total privacy. Even now an EU agency is asking Microsoft in vain to give out information (under NDA naturally) of the last secret bits of telemetry that Windows10 sends home.

Regarding Factorio, I also think there should be a question box either at the first start or the first possible upload. Default on is absolutely fine for the checkbox because crash reports and even some telemetry about usage is a justified request/wish in the Early Access situation.
meganothing
Long Handed Inserter
Long Handed Inserter
 
Posts: 76
Joined: Thu Sep 15, 2016 3:04 pm

Re: Friday Facts #231 - Belt compression & Crash log uploading

Postby mathturtle » Sun Feb 25, 2018 12:53 pm

milo christiansen wrote:IMHO crash reports are missing one simple thing: A GUID that is added to the sent data AND displayed to the user as a way to link a specific crash report to a forum bug report. When the game crashes, the report is sent, and the user is told "If you want to report more details about what happened, feel free to do so on the forum, and use this ID in your post."

This way sent and forum reports can be linked to each other (if the user wants) in a quick and simple way.


Good idea. Devs, please can you add this?
mathturtle
Inserter
Inserter
 
Posts: 36
Joined: Sat Jan 21, 2017 8:19 pm

PreviousNext

Return to News

Who is online

Users browsing this forum: No registered users and 9 guests