Fixing data stage spam

Place to post guides, observations, things related to modding that are not mods themselves.
User avatar
eradicator
Smart Inserter
Smart Inserter
Posts: 4051
Joined: Tue Jul 12, 2016 9:03 am
Contact:

Re: Fixing data stage spam

Post by eradicator »

Optera wrote:
Wed Jun 05, 2019 10:13 am
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.
Author of: Hand Crank Generator, Screenshot Hotkey 2.0, /sudo
Mod support languages: 日本語, Deutsch, English
My code in the post above is dedicated to the public domain under CC0.

User avatar
steinio
Smart Inserter
Smart Inserter
Posts: 2442
Joined: Sat Mar 12, 2016 4:19 pm
Contact:

Re: Fixing data stage spam

Post by 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)
Image
Transport Belt Repair Man
My little mods: Link | My favourite mods: Even Distribution | Yuoki Railway Core | Logistic Train Network | Krastorio 2
Factorio Cheat Sheet by Denis Zholob

View unread Posts

User avatar
Deadlock989
Smart Inserter
Smart Inserter
Posts: 1944
Joined: Fri Nov 06, 2015 7:41 pm

Re: Fixing data stage spam

Post by Deadlock989 »

steinio wrote:
Wed Jun 05, 2019 2:55 pm
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
Fast Inserter
Fast Inserter
Posts: 148
Joined: Tue Oct 02, 2018 5:44 pm
Contact:

Re: Fixing data stage spam

Post by 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
Smart Inserter
Smart Inserter
Posts: 4050
Joined: Mon Sep 05, 2016 9:10 am
Contact:

Re: Fixing data stage spam

Post by mrvn »

Deadlock989 wrote:
Wed Jun 05, 2019 3:06 pm
steinio wrote:
Wed Jun 05, 2019 2:55 pm
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.

User avatar
mrudat
Fast Inserter
Fast Inserter
Posts: 170
Joined: Fri Feb 16, 2018 5:21 am
Contact:

Re: Fixing data stage spam

Post by 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.

User avatar
kizrak
Inserter
Inserter
Posts: 46
Joined: Thu Jul 19, 2018 1:27 am
Contact:

Re: Fixing data stage spam

Post by 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!

User avatar
moon69
Fast Inserter
Fast Inserter
Posts: 134
Joined: Sun Sep 18, 2016 6:53 pm
Contact:

Re: Fixing data stage spam

Post by 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
Factorio Staff
Factorio Staff
Posts: 2481
Joined: Sat Aug 13, 2016 9:20 am
Contact:

Re: Fixing data stage spam

Post by Bilka »

kizrak wrote:
Sat May 16, 2020 11:45 pm
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:
FactorioBot wrote:
Tue May 12, 2020 12:09 pm
Modding
  • Added the Prototypes GUI (ctrl + shift + E).
  • Added the Prototype Explorer GUI (mouse over most anything + ctrl + shift + F).
I'm an admin over at https://wiki.factorio.com. Feel free to contact me if there's anything wrong (or right) with it.

Pi-C
Filter Inserter
Filter Inserter
Posts: 747
Joined: Sun Oct 14, 2018 8:13 am
Contact:

Re: Fixing data stage spam

Post by Pi-C »

kizrak wrote:
Sat May 16, 2020 11:45 pm
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. :-)
A good mod deserves a good changelog. Here's a tutorial (WIP) about Factorio's way too strict changelog syntax!

User avatar
Optera
Smart Inserter
Smart Inserter
Posts: 2612
Joined: Sat Jun 11, 2016 6:41 am
Contact:

Re: Fixing data stage spam

Post by Optera »

Pi-C wrote:
Mon May 18, 2020 3:23 pm
kizrak wrote:
Sat May 16, 2020 11:45 pm
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.

User avatar
kizrak
Inserter
Inserter
Posts: 46
Joined: Thu Jul 19, 2018 1:27 am
Contact:

Re: Fixing data stage spam

Post by kizrak »

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

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
Filter Inserter
Filter Inserter
Posts: 578
Joined: Sun Jun 09, 2019 10:40 pm
Contact:

Re: Fixing data stage spam

Post by slippycheeze »

Rseding91 wrote:
Sun Jun 02, 2019 10:28 pm
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.

User avatar
Optera
Smart Inserter
Smart Inserter
Posts: 2612
Joined: Sat Jun 11, 2016 6:41 am
Contact:

Re: Fixing data stage spam

Post by 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
Factorio Staff
Factorio Staff
Posts: 10789
Joined: Wed Jun 11, 2014 5:23 am
Contact:

Re: Fixing data stage spam

Post by Rseding91 »

Optera wrote:
Mon Jun 01, 2020 5:21 am
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.
If you want to get ahold of me I'm almost always on Discord.

User avatar
moon69
Fast Inserter
Fast Inserter
Posts: 134
Joined: Sun Sep 18, 2016 6:53 pm
Contact:

Re: Fixing data stage spam

Post by moon69 »

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

User avatar
kizrak
Inserter
Inserter
Posts: 46
Joined: Thu Jul 19, 2018 1:27 am
Contact:

cache-prototype-data and hidden settings

Post by kizrak »

Rseding91 wrote:
Mon Jun 01, 2020 5:11 pm
Optera wrote:
Mon Jun 01, 2020 5:21 am
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! :o

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 :idea: SUPER-DOUBLE_ZOMGZ :shock: for Control + Alt + Click the settings button on the menu to access the hidden settings.

Post Reply

Return to “Modding discussion”

Who is online

Users browsing this forum: No registered users