@jables @masterdigital There's an error with your JSON parser, I recieved a HARD crash in the lobby from the faction server mod when testing to see if a new unit went in game... So I made a mistake in one of the unit spec JSONs (it's a new unit for the faction mod) and forgot to put quotes at the end of a line: Code: "fired": { "audio_cue": "/SE/Weapons/veh/tank_T2_leveler", "effect_spec": "/pa/effects/specs/tank_muzzle_flash.pfx socket_muzzle }, Socket muzzle was missing the quotes at the end so the json didn't parse correctly but this time the lobby crashed instantly when I tried to test. Usually that will either crash the game when the unit is built or remove it from the UI since the JSON is bad. I looked in the log and was directed to this: http://crashes.uberent.com/report/index/c36c60be-2b4b-49ec-a6de-279f92150622 This pointed to the UnitTypeDB::loadUnitSpecs() error so I searched for the error in GitHub and found the code above to be missing the " . Anyway the log didn't say anything about the specific unit json parsing incorrectly so isn't this an issue with your parser? Thx
It depends on what you define to be a error. From my guts feeling I would assume that the JSON for effect_spec should look like this: Code: "fired": { "audio_cue": "/SE/Weapons/veh/tank_T2_leveler", "effect_spec": "/pa/effects/specs/tank_muzzle_flash.pfx socket_muzzle" }, If you look at the actual specification of JSON you will see that a string starts with a " and accepts any character except \ until it reaches the next " (which may be several lines down from where you started). By leaving out the closing quote the JSON parser used everything following as string as well (the effect_spec string would look like this: Code: /pa/effects/specs/tank_muzzle_flash.pfx socket_muzzle }, ... The problem here is that the closing curly bracket is now within a string and therefore is no longer interpreted as a structure element. This will completely mess up everything that comes after that string, but from the stand point of the JSON parser and the specification it still might by a correct JSON file. If you look at the crash dump you see that the last function that was called was something like readObject. My guess is that this function tries to load all the effects and unit specs, but due to the missing quote it got something really ugly. Since something really ugly isn't what was expected .. well everything goes south at this point. Usually as a programmer you get taught that you should not trust any user input what-so-ever and always be clear for what you expect and check for it. Crashing on user input is a no-go. But modding files in a directory of the program is somewhere in the grey area. You can debate about if this is still user input or something only insane tech-savvy people would do, which would expect that the program can crash if they do something completely wrong. The JSON specification doesn't make it easier either, because there is no structural definition for single objects, you can write down almost everything and it is most certainly valid (this is usually a good thing, because it gives you a lot of flexibility). But if you expect something specifically, you have to check it from hand which is really cumbersome. TL;DR: Adding those checks afterwards is really cumbersome and a real time sink for fixing an error state that normal users will never encounter - and those who encounter it should know what they are doing (or else stop doing what they are doing, anyways). STL;DR: It would be better to not forget your closing quotes!
Missing a quotation mark is a fast way to screw up most types of coding in my experience, as is forgetting to close a 'div' tag in html..... The effects can be quite impressive / horrifying depending on who's project it is haha.
Ideally the JSON parser should fail gracefully and throw a nice exception that allows the following: logged exceptions fail loading of item or entire mod message to host that mod failed to load with details of item, filename, etc
