"updated nightly"

[narc0tiq]

From the front page of http://cdda-trunk.estilofusion.com/, the following paragraph (emphasis mine):

On the top bar, there are two links, stable and development, each one points to a copy of the database for the latest stable release and an up-to-date git master copy (updated nightly), respectively.

Given that the item browser's last update was 0.C-11261-g75886c0 and CDDA is currently at 0.C-12973-g5234160, perhaps a change in verbiage is in order? "Updated infrequently", or something to that effect?

[Sheco]

That's definitely not the idea, it should be updated nightly.

I've just taken a look and it's not rebuilding the nightly database because of a change in the data files structure, something about ammo_type not being available.

This will be fixed in a few minutes.

[Sheco]

Alright, with this patch, I forced a database update and the item browser should not need to be changed to display "rarely ever updated" as the nightly process should be able to automatically update it without a problem.

Thank you for your report.

[narc0tiq]

Heh, sorry, man, it's just that the JSON format does seem to shift once in a while without anyone noticing. No emails from your auto-updater when it fails?

Later edit: Oh, right, the item browser is being impacted by the current drive to remove default values from the JSONs; sadly, I don't think those are described in any actual JSON -- so you'll have to treat them as unknowns and/or possibly hard-code the defaults somewhere.

In any case, I'll make sure to give you another poke if it seems like the IB is falling behind again. Thanks for the fix!

[Sheco]

Yes, it's not the first time some small details break the indexer, I haven't been followed the game in a long time so I am completely out of the loop so I miss these kinds of things.

Would you mind checking why the mosin44's object is incomplete? is that the way that it's expected to be?

I definitely appreciate being updated when these kinds of things fall back, even when I am not entirely involved anymore, I am more than happy to update the item browser if people need it.

Thanks!

[narc0tiq]

Incomplete in what way? It should be valid JSON; it may be missing some expected fields, as mentioned in my edit -- there's currently a big operation going on to remove default values from the JSON objects, under the theory that it's redundant to specify values that are just the same as they would be if left out (example: CleverRaven/Cataclysm-DDA#15776). Looks like @Cyrano7's been doing the bulk of that work .

[Sheco]

Yes, the JSON is perfectly valid, but those missing expected fields make the indexer in Item.php exit unexpectedly.

For example, I assume AMMO objects always have an ammo_type attribute. (Line 178)

If the data files start omitting these values, I would have to either ignore the objects or define a sensible default.

What do you think?

[narc0tiq]

Defining the defaults is the right idea, though you may get oddities if the
defaults ever change (mind, that would probably be a problem for Cata, too,
at this point). I wish I could think of a way to obtain them
programatically, but they're defined in the save loading code, so not
really easily parsable.

There's going to be a jq script to check for redundant defaults, but we
don't have that yet AFAIK. I think @mugling was working on that? In any
case, that would have all the defaults in one place with no other crap in
the way.

On Thu, Apr 14, 2016, 19:49 Sergio Duran notifications@github.com wrote:

Yes, the JSON is perfectly valid, but those missing expected fields make
the indexer in Item.php
http://../blob/master/src/app/models/Repositories/Indexers/Item.php
exit unexpectedly.

For example, I assume AMMO objects always have an ammo_type attribute.
(Line 178)

If the data files start omitting these values, I would have to either
ignore the objects or define a sensible default.

What do you think?

—
You are receiving this because you modified the open/close state.
Reply to this email directly or view it on GitHub
#18 (comment)

[mugling]

Would you mind checking why the mosin44's object is incomplete? is that the way that it's expected to be?

I suspect it's the copy-from syntax. You might be interested in the --dump-stats option I've added to the binary and this could be further extended if you want to switch to using this

If the data files start omitting these values, I would have to either ignore the objects or define a sensible default.

Most of the defaults can be found in the itype.h header but keeping them in-step with the game will be difficult

[mightyagrippa]

Sorry to necro this, but it seems relevant. Development browser is showing current version 0.C-12973-g5234160 which suggests that it hasn't updated in the five months since this issue.