Fixing data stage spam

[eradicator]

Instead of making life harder on responsible authors add a way to get rid of crappy mods. Could be as simple as adding a thumbs up/down button in the portal and in game so we can vote badly written mods out.

And open the doors for internet lynch mobs? No thank you. The lifetime-download-count based ranking is biased enough already. And even Steam™ has a hard time dealing with review-bombing problems. Besides players don't care about log sizes. They most certainly wouldn't downvote mods because of data stage log spam.
_____
@Qon: To log a table you still have to make it printable. And yea, i know log() is shorter obviously. What i didn't know is that there are apparently people who don't care about the "decoration" any log entry has vs plain print().

The real question is...what kind and amount of data stage logging @Rsed still considers "ok". I don't like the idea of having to design my logging facilities about the preferences of someone else.
____
@Darkfrei: Only if the default is reversed. log(text) writes to a seperate file and log(text,{badly_undocumented_option=true}) logs to factorio-current.log.

[steinio]

Looks like there is nothing to fix here.

- the majority of players don't even know what the log is
- disk space (10MB) is cheap and plenty
- the spam problem is, excluding some few exceptions, no spam problem
- openly communicate with affected mod creators about the unwanted mod behaviour
- maybe Wube does some quality control of uploaded mods (Farming Sim only publishes tested and quality approved mods on their portal - downside: causes huge delay between upload and publishing)

[Deadlock989]

Looks like there is nothing to fix here.

- the majority of players don't even know what the log is
- disk space (10MB) is cheap and plenty
- the spam problem is, excluding some few exceptions, no spam problem
- openly communicate with affected mod creators about the unwanted mod behaviour
- maybe Wube does some quality control of uploaded mods (Farming Sim only publishes tested and quality approved mods on their portal - downside: causes huge delay between upload and publishing)

It's not really about the disk space though. It's about uploading files for bug reports, and then having to wade neck-deep through spam to find what you want. Lots of people are still on asymmetric broadband - my upload speed is 1/40th of my download speed for example, and that's not changing this decade.

With quality control of mods, or the previous suggestion for voting mods off the portal with a thumbs up thumbs down system, I have mixed feelings. On the one hand, there is a ton of crap and it just makes the good stuff harder to find. There is one individual who has uploaded about 150 mods, 125 of which should have been strangled at birth.

On the other hand, we already have a situation where mob mentality keeps the some old mods at the top of the list - the addition of the "trending" section was a good idea but it doesn't account for people spamming minor updates every day and the people that are redownloading tiny changes. All of this results in a feedback loop which keeps the same old same old in not necessarily deserving pole positions. Adding voting on top of that would probably make it even worse. And I expect there is zero chance of Wube employing a mod-approver. You couldn't stop people from publishing mods on another platform, e.g. these forums, anyway.

Also, there is a difference between mods which are seriously niche interest but made well, and mods which are just written badly and spam the logs or screw other mods up thoughtlessly. I don't trust Joe Public to vote stuff down because it was coded badly. Just look at Brexit, for Christ's sake.

Personally I would be very happy with one dedicated log file for all mods so I don't have to tire my eyes out on DirectX and data path messages that are of no use or interest to me.

[Cadde]

To complement my earlier post, here are some solutions to the problem.

• If file size matters
  • Limit how much each mod can log...
  • ... or automatically compress the log file
  • Have a dump_data_raw() function which writes to a separate file, prohibit dumping of data.raw in log() either through recognition or through limiting size as per point above.
• Categorize logging in the log file. Adding [factorio] and [<mod-name>] before each entry, have users reviewing logs do a regex replace to filter out unwanted log entries...
• ... or turn the log into a csv and replace any commas in log() output with semicolons. Or use semicolons as the delimiter and do the other replacement. Then one can either use a spreadsheet or some log viewer and filter out on certain entries.
• Log each mods output in separate files, automatically add all log files to a zip archive and have users upload that. Modders that want to see both log outputs at the same time can do so with a capable text editor like notepad++.

As for the command line option, i do agree with other posters. It's just going to end up being permanently on as per mod author request to their users.
Perhaps have a "boot menu" as you start the game. Pressing F8 during loading brings up a menu with:

• Normal mode
• Fail safe mode (no mods, temporary default settings)
• Debug mode (full logging enabled)

Thus, users have to explicitly enable this mode on each launch.

Or, you could write a factorio-current.log and a factorio-current-full.log file. No log() output ends up in factorio-current.log.

[mrvn]

Looks like there is nothing to fix here.

- the majority of players don't even know what the log is
- disk space (10MB) is cheap and plenty
- the spam problem is, excluding some few exceptions, no spam problem
- openly communicate with affected mod creators about the unwanted mod behaviour
- maybe Wube does some quality control of uploaded mods (Farming Sim only publishes tested and quality approved mods on their portal - downside: causes huge delay between upload and publishing)

It's not really about the disk space though. It's about uploading files for bug reports, and then having to wade neck-deep through spam to find what you want. Lots of people are still on asymmetric broadband - my upload speed is 1/40th of my download speed for example, and that's not changing this decade.

Savegame: 90MiB (compressed)
Mods in use: 217MiB (compressed)
Logfile: 10MiB (uncompressed, highly compressable)

Wouldn't compressing the log for upload make that consideration irrelevant? I already feel like 10MiB out of 300MiB one should include in a bug report is pointless to worry about.

[mrudat]

Edit: nevermind, my post was option 2 from the original post.

Would it help to have something like log4j (log4lua?), so log messages have consistent formatting to make search easier.

Perhaps stuff things straight into a sqlite db, or perhaps just a csv file? That way you can load it into most modern spreadsheets, and slice-and-dice the data almost as well as using a database to do it.

[kizrak]

Per: LuaGameScript.write_file during data.lua

I would like the ability to write to a separate file so I don't have to sort through the exact opposite problem of @Rseding91. I don't want my mod's text cluttered with base-game log items and decorations. (Sometimes I want temporal data, so having a non-buffered mixed log is also an important option so I hope mod devs continue to have access to it.)

For example, only about 1/3 of this message is what I might care about (situational, sometimes I really do care about the other stuff):

Code: Select all

   1.654 Script @__vonNeumann__/prototypes/character.lua:109: STUFF I WANT TO SEE

Also, often during dev of a mod, I do need to display (log) truck loads of large prototypes because it is the best way I know to understand them. I would love to be able to blahblah.write_file("modname",serpent.block( some_prototype )) so that it isn't in the main-logs. As an added bonus, if I issue it multiple times during startup (say during difference phases), only the last one remains (old trash is auto-cleaned up by overwriting itself). (This would often be a benefit to me.)

I'm sure I'm not the only mod dev that would gladly get their "logging" out of log(). So even if LuaGameScript.write_file during data.lua does not completely solve @Rseding91's problem, maybe it could alleviate it.

I hope whatever the final change is, it continues to allow log() as-is and is solved by giving mod devs additional alternative options so they aren't forced to use the one tool they have. If all we have is a hammer, we are going to hammer everything!

Thanks!

[moon69]

For those (re)visiting this topic, please also consider justarandomgeek's debugger as highlighted in FFF - good stuff!
Friday Facts #337 - Statistics GUI and Mod Debugger

[Bilka]

Also, often during dev of a mod, I do need to display (log) truck loads of large prototypes because it is the best way I know to understand them. I would love to be able to blahblah.write_file("modname",serpent.block( some_prototype )) so that it isn't in the main-logs. As an added bonus, if I issue it multiple times during startup (say during difference phases), only the last one remains (old trash is auto-cleaned up by overwriting itself). (This would often be a benefit to me.)

I'm sure I'm not the only mod dev that would gladly get their "logging" out of log(). So even if LuaGameScript.write_file during data.lua does not completely solve @Rseding91's problem, maybe it could alleviate it.

I have some good news for you: 0.18.23 adds the "prototype explorer GUI" which allows you to look at the prototypes in-game. It should allow you to debug your prototypes without having to print/log them somewhere. You can open the GUI with the following key combinations:

Modding

• Added the Prototypes GUI (ctrl + shift + E).
• Added the Prototype Explorer GUI (mouse over most anything + ctrl + shift + F).

[Pi-C]

Also, often during dev of a mod, I do need to display (log) truck loads of large prototypes because it is the best way I know to understand them.

Wrap log() in a local function that outputs log messages only to the log file if some other mod that exists only locally (give it an obscure name like "my-mod_allow_debug" or similar) is active. You will get all the log messages without spamming others' log files.

[Optera]

Also, often during dev of a mod, I do need to display (log) truck loads of large prototypes because it is the best way I know to understand them.

Wrap log() in a local function that outputs log messages only to the log file if some other mod that exists only locally (give it an obscure name like "my-mod_allow_debug" or similar) is active. You will get all the log messages without spamming others' log files.

For development debugger is the way to go.
However often I need logs from a users environment, so mod settings are a lot more helpful to me than an obscure mod.

[kizrak]

Thank you so much for the feedback @moon69, @Bilka, @Pi-C and @Optera !

I'm curious, is there a way to get the Prototype Explorer GUI if my prototypes don't even make it past the loading screen? Maybe I'm really bad at prototyping, but I feel like I spend most of my time working against the validation checker (like if an entity has an item, it does not need an order, but if it doesn't, it does ).

Thanks!
-Kizrak

[slippycheeze]

Ever since log() was made available during the data stage in Factorio modding mods have been spamming log files. It's so bad that log files end up 10s of thousands of lines adding up to several megabytes worth of useless nothing.

Another plan (by Bilka): record everything sent through log() during the data stage and if an error is triggered during the data stage or by scenarios then actually write it to the log file. This would also have the --enable-data-log option to force everything to be written instead of buffered.

If I may suggest a couple of things that I'd prefer because they would make my life easier, and I think would still achieve your goal of eliminating spam for most people:

If you only write log output for *unpacked* mods, that'd make it automatically show up (many?) developers. Unpacked mods are far easier to go through the edit/reload/test cycle with, and that is also the time you are most likely to need to poke around debugging in the data stage.

Instead, or as well, if you captured that data temporarily, and wrote it out as part of a "crash dump" log when a mod failed, that'd solve the "authors need to see their data stage debugging information to fix / reproduce user problems" thing as well.

A per-mod data stage log, or shared data/control stage logs, plus any fatal exception stack trace, would also keep main log size down, and also make it easy for developers to get the information they needed in a single "please upload the crash file ..." request. Fancy people could even add a workflow to mods.factorio.com that'd prompt the user to upload that alongside their bug report...

Also, a scenario where data-stage logs are used for good (if a little spammy) purposes: "Alien Biomes" creates a very large number of tiles (197-ish?), and having it installed with a couple other mods that add tiles in volume such as Asphalt Roads (55-ish, IIRC) can overflow the tile table.

Alien Biomes logs a message about that during the data phase, along with a list of all the defined tile types (including the ones past the limit) which makes it much easier to go through and figure out what the issue is.

I think it is important to make that debuggable, especially since a couple other mod authors commented that their crash could only happen when there were too many tiles, "probably because alien biomes", which is kind of true (but not exactly Alien Biomes fault.)

That said... I was thinking about how to communicate that fact from the data stage to the runtime stage so that I could send a patch (or add a mod) that'd display the error when I loaded into a game. That way I'd have a warning that didn't involve a mod fatal exception and checking the logs to (a) find why, and (b) figure out if I had cut enough tiles out to get below the cap.

So perhaps that'd be a good thing to have. Maybe even in the Factorio core, so that it'd show up at the time the main menu displayed, and could give a summary of how many tiles each mod added? That'd be the best instant debug/fix choice for getting that in front of everyone.

Anyway, thanks for letting me talk so much, and thank you for working to address this issue. It definitely does cause some annoyance having to skip over spammy messages to find, eg, where Alien Biomes is explaining how to fix the crash I brought on myself.

[Optera]

This morning I accidentally discovered cache-prototype-data=true stops data spam entirely.
It seems to skip over all setting and data stages, only executing them when checksums for settings or mods changed?

[Rseding91]

This morning I accidentally discovered cache-prototype-data=true stops data spam entirely.
It seems to skip over all setting and data stages, only executing them when checksums for settings or mods changed?

Correct.

[moon69]

It seems there has always been reluctance to allow write_file during data stage - what are the reasons preventing it?

[kizrak]

This morning I accidentally discovered cache-prototype-data=true stops data spam entirely.
It seems to skip over all setting and data stages, only executing them when checksums for settings or mods changed?

Correct.

ZOMGZ!

Is there any official documentation for cache-prototype-data?

At the time, Google just brings up viewtopic.php?f=3&t=85145&start=20 and https://mods.factorio.com/mod/deadlock_ ... 000db4cc97

ALSO SUPER-DOUBLE_ZOMGZ for Control + Alt + Click the settings button on the menu to access the hidden settings.

[mrudat]

Is this a horrible idea, now that we can run Factorio under a debugger? =)

Code: Select all

  if mods['debugadapter'] then
    log("Creating " .. new_item_name)
  end

Actually, would it be possible to do something like have a `debug_log` function that only gets turned on when Factorio has failed to load, and on the error dialog, you get given an option to turn on debug logging to see if the log messages give you an idea of what's going wrong?

[justarandomgeek]

Is this a horrible idea, now that we can run Factorio under a debugger? =)

Code: Select all

  if mods['debugadapter'] then
    log("Creating " .. new_item_name)
  end

Actually, would it be possible to do something like have a `debug_log` function that only gets turned on when Factorio has failed to load, and on the error dialog, you get given an option to turn on debug logging to see if the log messages give you an idea of what's going wrong?

Or, ya'know, you could print to the debug console directly:

Code: Select all

if __DebugAdapter then
  __DebugAdapter.print("Creating " .. new_item_name)
end

It takes LocalisedStrings, or string interpolation for expressions in {}, or it'll describe other objects the same way they appear in other parts of the debugger.

[Adamo]

I hate spamming the log file, but I need to know what's going on in a clear way as my mods explore through other people's mod data and try to hook into and adjust them. I would greatly appreciate the availability of an output file during data stage. It would also be easier to search.