Strange crash with Whistle Stop. Also reported to them.

https://i.imgur.com/KU5Q3HZ.png

Looks like this was an issue in the Whistle Stop mod. I'm fixing it on my end and will have this fixed in the next update.

Cheers, thanks very much!

I just found the same issue with Vehicle Wagon and asked them to fix it. (Assigning created_entity instead of entity in the script_raised_built event.) It might be smart for Disco Science to check "if entity and entity.valid" before acting on an event, just so you're not the cause of a crash due to someone else's mistake.

Think they did that as of my other crash report here, robot.
https://mods.factorio.com/mod/DiscoScience/discussion/5c9a93e12e429f000c42a35b

No, that is a different bug, where a mod was not triggering script_raised_built This one is when the other mod does trigger a script_raised_built event, but with a malformed/nil payload entity. It's definitely not fixed in 0.0.5. It seems like a stupid thing to have to catch, but the API doesn't stop mods from raising events with missing parameters.

Hey, thanks for the report. I guess the question is whether there is a standard, more graceful way to report the problem to the user than a fatal error. It’s relatively easy for me to check for nil or ignore mismatched events, but the result will still be untracked labs.

Maybe if I throw up a warning dialog the first time it happens? This way users such as yourselves will be able to report the issue, but people can keep playing with a couple relatively harmless missing lab animations.

By the way, any missing animations should be fixed by saving and reloading a game, since the first thing DiscoScience does when it runs is an expensive, one-time search for all existing labs.

Ok, 0.0.6 now shows a warning once per session if it can't get the entity from script event, or if it gets a mismatched lab deletion event.

That's a much better solution. Most of these errors are not from labs at all, and I'd hate to have to uninstall Disco while waiting for another mod to fix a bug (that clearly didn't bother them any other way yet). Thanks!

Yeah, the issues are unlikely to cause problems for other mods themselves, but fixing them should improve mod compatibility in general. So DiscoScience is just being a Good Samaritan now, instead of a killjoy.

(Double post)

Loving it DB. <3

Yeah, I also decided to start triggering script_raised_built with {entity=entity, created_entity=entity} which seems like a good safety measure, which lets my mod work with ones that need either entity or created_entity.

That is a good defensive approach. It seems like it would be good if Factorio enforced consistency when these APIs are called. I’ll ask about that in the forum.

Avongard, It's an annoying CYA workaround, because those mods reading the wrong parameter will still miss events triggered by the create_entity function itself when if it works with yours. I appreciate Disco's approach because otherwise it would have me much longer to debug my own mods.

That's a good point. Issuing the event with redundant fields means it's harder for mod owners to realise they've made a mistake in the first place. In the worst case, it could also perpetuate an alternative standard and lead to a situation where everyone has to program defensively in order to ensure compatibility.

I really think that this should be solved on the engine side, though: the API is quite clear about which fields to expect in an event. It should be an error to deviate from the API.

Here's my request on the issue: https://forums.factorio.com/viewtopic.php?f=28&p=419372#p419372