And here are the data http://aprilboy.e404.sk/anno2070/list_of_buildings_v0.2.json - the production ones are a bit duplicated, which ones to delete? --DeathApril 23:05, December 14, 2011 (UTC)
- Oooooh, influence radii. Methinks I shall add that to the building pages soon-like. --Cphoenix (talk) 00:58, December 15, 2011 (UTC)
- I like how you've actually documented the model. I had skipped that step, but it makes perfect sense.
- As for RawNeeded1TonsPerMinute and milliseconds vs. seconds etc: I like the converted values because they are what I am ultimately interested in. This way they only have to be calculated once, instead of in every place they're needed. However, storing the calculated result will introduce small rounding errors, so the model becomes slightly impure. Which is possibly why the game designers store the values like this in the first place. What was your idea?
- Can you explain the duplication comment? I don't see it. --Grilse 05:26, December 15, 2011 (UTC)
- Same here. I'm not seeing the duplication (though there are plenty of incomplete entries and things that simply aren't used in the game, as far as I can tell *mutters incoherently about key errors*). --Cphoenix (talk) 06:12, December 15, 2011 (UTC)
- As for the "incomplete entries": it's important to realise that there is a default value for each property. If no value is specified, then the default value is in effect. For example, "Production.RawMaterial1" defaults to "NoProduct". These defaults may depend on the template. --Grilse 07:46, December 15, 2011 (UTC)
- Yes, yes. That makes plenty of sense. I was thinking about the odd entries at the bottom that have
'Eng1' : [GUIDNAME BlahNumbersBlah]. Though now that I look at them again they also have
'Faction' : 'third party', so they probably don't need a name anyway. (tl;dr, disregard my silliness; didn't see what was there properly until I bothered to format the JSON data into something more readable) Also, I checked the Name and Eng1 keys, and there don't seem to be any duplicates (none that don't make sense to find in Eng1 anyway). So...yeah...totally lost on the duplication bit. >.> --Cphoenix (talk) 09:16, December 15, 2011 (UTC)
Duplication: I meant that (1) Production.RawNeeded1TonsPerMinute gives no new information, but i guess i'll keep it so we have both exact numbers and easy-to-draw-production-chains info. And (2) I already deleted FarmField.BuildBlocker.x and z properties which were duplicate properties of other building (the farmfield) - if someone needs them for convenience, i'll add them.
Key errors: This model requires checkig for non-existance of a key instead of checking b["Production.RawMaterial1"] == "NoProduct". I used default values only for ProductionTime, ..., when there is any actual Product and for RawNeeded* when there is any actual RawMaterial*. I have no idea what default values there are for other fields, e.g. FarmField.Count or MaxResidentCount. If you'd prefere to have every property for every building, what default values should I use? String "null", empty string or what?
Documentation: I use the model to validate keys in data + for others to understand the data ;) I decided to create it after havind a headache from studying your (Grilse's) php files.. By the way, why is the IconIndex +1 (i spent 10 minutes debugging why my icon file names are not correct) ?!? --DeathApril 14:59, December 15, 2011 (UTC)
- Duplication: aha, I get it now. I call that redundancy, so that's why I didn't get it when you said duplication.
- Key errors: any of those approaches are fine to me. Pick one, be explicit about it and use it consistently. Are there any missing defaults that matter?
- Documentation: ouch, I'm sorry to hear that. That's what I get for writing code with only myself in mind. I get paid to write software, so I really should know better. I'll fix it. The +1 is your typical off-by-one-error: the game starts counting at zero, while the program I used to create the icons and their names starts counting at one. --Grilse 15:40, December 15, 2011 (UTC)
- I think I should spend a bit of time to batch rename them all, so this doesn't keep popping up. --Grilse 15:45, December 15, 2011 (UTC)
Key errors: non-existence of keys is consistent - there is 1 difference from the game files in Production.* properties that use tonnes, kilograms and time, because this are the only defaults for buildings I know, but this does not create inconsistency within the data model.. i'll state this explicitly in the model v0.3
Icons: just let us all know when you are going to rename them so we don't end up with typical -1 off-by-one-error ;) --deathApril 19:00, December 15, 2011 (UTC)
- The "duplication" makes more sense. "Redundancy" is what I think of too. It might be advisable to leave the table as-in regarding KeyErrors. I was just joking around earlier. Exceptions/errors should be easily handled why whatever one is using to interpret the file, and then it's easy for the programmer to give any null values whatever value they want when the errors show up (or just ignore the error and keep going). Padding it with null data seems to be extra bloat for little reward. What if someone doesn't want the null value to be 'null' but 'No Value'? They'll still have to write something along the lines of
if b['key'] == 'null': key = 'No Value' else: key = b['key']
- Whatever you do with it doesn't terribly matter. Like Grilse said, just pick one way and stick to it, to prevent others' heads from explodimafying.
- As for icons, I took the liberty of renaming all the files in your icon.zip by their ending number -1. (Barring human error. It is early, and I need breakfast.) Here. --Cphoenix (talk) 19:11, December 15, 2011 (UTC)
- Finally!: I found the place where we can discuss ;) Back to topic:
- Non-existing-keys: I would prefer to leave out keys for which you don't have data, filling these with "null" or similar unnecessarily increases size of the json file. Either way, parsing the JSON data with .NET languages is very very easy.
- Online data: My idea was to create a database with all the building information, be it a 'real' DB or a static json file, and host it somewhere so that external tools could access it. Completing this json file and putting it on a webserver somewhere would totally be sufficient, at least for the AnnoDesigner. One thing to keep in mind if we make it this far is to be very cautious with breaking changes to the data. I think I will always include a copy of the data as fallback with the AnnoDesigner even if there is an online version. So if accessing the online version fails for whatever reason it would still work.
- AnnoDesigner Web-Version: I did a small test some days ago and had to realise that porting a WPF-application to silverlight isn't that easy.. It might be possible but it is definately more than just changing the project-type to silverlight :-/
- Icons: I added all the icons to the AnnoDesigner and didn't change their filenames because I didn't want to change the json data, but is there a reason why we don't use readable filenames like "building_modules.png" instead of "icon_123_123.png"? Currently the AnnoDesigner contains both. Otherwise you wouldn't be able to manually select an icon without actually seeing it. --ZackSchneider 20:20, December 15, 2011 (UTC)
Source files: Sooner or later i hope to upload this to github, but since i'm lazy, see here: list_of_buildings.py.
Icons: Readable filenames can be easily accessed throught Name property, but I didn't know we have these ;) Should I remove IconFileName or change it to represent IconIndex without +1. Or should i replace it with Icon.IconFileID and Icon.IconIndex instead? --DeathApril 21:02, December 15, 2011 (UTC)
- Icons: The reason for icon numbers instead of names are these:
- Each product, building, unit etc. has a GUID. These GUIDs are linked to an icon-map file and an icon number within that map. One icon can be used by many GUIDs, so there is no 1-to-1 mapping from icons to names of product/building/etc. The same icon would get multiple names. That isn't to that say we shouldn't create named copies of the icons, it's just why I haven't done it yet. I only did that for products.
- Numbered copies are good for scripts. Given a GUID, it can simply look up the icon number and load the file. Named copies are good for humans.
- I have taken CPhoenix's zip and updated the icons-folder. The off-by-one-error has been removed. Please stop your scripts from compensating for it. --Grilse 21:57, December 15, 2011 (UTC)
- It occurred to me it might be more convenient to have a zip of the named building icons as they are on the Icons page. I renamed them before this loverly JSON file, so they don't correspond to any keys. I uploaded them here. (Icons page is also updated.) --Cphoenix (talk) 22:49, December 15, 2011 (UTC)
- You guys might also want to consider organizing these conversations into a page or group of pages on the wiki. Grilse's talk page seems a little...out of place. Possibly starting at External Tools and linking from there to discussion pages. If you want to get someone's attention, post on their talk page and point there (the page/section where the main discussion can happen). That way we'd all have a single hub of sorts to check (and the information discussed and decisions made will be more accessible to others in future, say, a year from now). --Cphoenix (talk) 23:47, December 15, 2011 (UTC)
Not only buildings: When i finish v0.3 today (with all the IconFileName numbering, BuildinCost.*, MaintenanceCost.* and CSV dump), i'd like to continue with non-building data, e.g. balancing data for ascension rights. Should i put all data to 1 JSON or to multiple files? (CSV will have to be in separate files or if i figure out spreadsheets in python, i might use an .XLS or .ODS with multiple sheets)
Versioning: For 0.x versions i did and i will change the model without backward compatibility. Once 1.0 of JSON and CSV is released (i hope January 2012), next versions (1.x) should be backward compatible. But i'm not planning to delete old versions from http://aprilboy.e404.sk/anno2070 so don't worry (only if Ubisoft will contact me to delete all of it, i won't fight them).
Named Icons: The named icons from wikia need to be mapped to Name or GUID property before i can add them. I'll have a look at it if i can do it myself or it would be too much :)) the new property key will probably be Icon.WikiaFile and value "File:Bio_drinks.png" - what do you think?? --deathApril 14:07, December 16, 2011 (UTC)
- Multi Files: From my POV, multiple files is a bit more helpful. (Fewer for b in weeee, for x in b, for ... when one wants to do a bit of simple formatting. Unless I'm being silly and there's an easier way to dig down those nested dicts/arrays.)
- Writing XLSX: (if you actually put them in XLS I'll fish-slap you :-p ) openpyxl looks like it might do what you need. (I only skimmed it, but it looks like it will help you write XLSX files.) Also, if Ubi chases after you...fish-slap them. Then remove the files.
- Named Icons: I like it. Just without the period: IconWikiaFile . Still, this strikes me as something that will have to be largely done by hand. You might use the current...ohhhh, what was that key *opens JSON file* IconFileName to insert the data with a script. You'll still have to tell it what each one should be (I see a looooooong list of elif in thine future), given a value for IconFileName . Something like this:
for building in JSONArray: if 'IconFileName' in building: if 'IconFileName' == 'icon_27_0.png': building['WikiaFileName'] = 'Wood.png' elif 'IconFileName' == 'icon_27_1.png': building['WikiaFileName'] = 'Tools.png' ... else: print('You messed-up. Go eat something, come back, and try to write a proper script.')
- The elif can just be copy/pasted a bajillion times, then you/we need to fill-in the data. Maybe you or Grilse has a better idea. (I've only been looking at Python documentation for two...three days now, with little programming knowledge prior to that. Though it's a testament to the quality of the language that it's so easy for a total newbie to pick-up. Yeepers.)