XML option browser
-
I started to build a tool to help me untangle the attachment options and their relations with the game properties. I thought that by building the tool I would also learn all about the options available.
My first inclination was to create a database for it all. But then I realized that it would be good to have it in a format that could be used easily by others. I settled on creating a JSON object, as that can be converted to most any other format. It also can be used within an HTML page, so would not need server access to load the data.
It is by no means finished, but I have the unit and territory attachments done.
If found some discrepancies and have some questions on some things, any help would be appreciated.
-
@mahks That's awesome, you the Man! I would give you more up votes if I could.
-
That's really awesome!
I've always been searching for something easily accessible like that.
I wonder how the internal JSON structure looks like, if it turns out to work really good, we could even consider incorporating that into our official website if you want. -
Press F12 to view the dev tools in your browser.
In the console tab type data [Enter]
You will see the JSON object (click arrows to expand)OR
You can look at the Debugger tab, I see it is there too but fully expanded
-
@mahks Impressive.
Tho this would require updating both pos2 and this thing when a change is made.
-
@mahks Regarding cases like "Units Can Load In Hostile Sea Zones", that are missing in Wiki, I don't believe the Wiki is really official, so when something new is made or something is changed is likely that the developers will not update the Wiki (I don't believe Veqryn necessarily did, either; tho I'm not sure), updating it being up to anyone willing.
In this case, anyone can contribute anytime adding this property to the Wiki.Personally, I tend to think that this thing you are doing should be better than the Wiki, and I would rather remove the Wiki totally if this gets finished (less multiple things to update all the same), made somewhat official (up to the developers?), and it would be made as easy to update for anyone as the Wiki (no clue if possible).
Regarding "Produce fighters on carriers", I don't know why you are asking if it is deprecated, and sadly I don't believe there is a full updated list of everything deprecated, so only a developer could look at the code and maybe say that or, preferably, making this full list of all current deprecates. Anyways, I can't see any reasons for this property to be deprecated, so I guess it is not.
Anyways, the name of the property is not very good, as it should rather be "Produce fighters on new carriers" (strictly, it should actually be "Place fighters on new carriers" or "Place fighters together with carriers", as it means you can place on the carriers only as long as those (new) carriers are getting placed at the same time).
Sadly, there are a lot of properties that are not very well named. I don't even think this is one of the worst ones. With the 1.9 a few of the very bad ones have been renamed (per my suggestions), but the old entries are still in the Wiki, for example:
http://axisandallies.wikia.com/wiki/Battleships_repair_at_beginning_of_round
(this is wrong, both because it applies to any units with hitpoints 2 or more, not just battleships, and because it is at start turn, not at start round, and actually at start of the Combat Move phase or any phase having the related repair step true (so, even my currently in use suggestion of telling that it is start turn is not strictly correct, but factually working as if true for the games having the traditional phase order)).
Personally, I'm not a big fan of the Wiki (and I don't use it; I just use pos2), because it is just more stuff that would need updating (so, more overhead), so I think having only "pos2", as reference, might be better, even tho this thing you are building up surely looks more professional that reading either through a game xml or in a Wiki. Only question would be its sustainability once you, eventually, stop caring for it yourself (these things are really useful only if always up to date). -
@Mahks Ahh it's a purely client-side base approach then. Looks good, I have to make a single correction though:
It's currently possible to omit package names for Attachments, but this feature isn't available for delegates yet due to naming conflicts.
See https://forums.triplea-game.org/topic/595/short-attachment-names for more information.
I have an idea about a possible solution for this problem though, so this might change as well in the near future. -
@roiex I wanted the tool to be usable off-line, so that is the reason for the format. If you wanted to use the data or the tool in the website, that is fine with me.
-
@cernel Regarding replacing the wiki: I feel it is the POS2 that needs replacing. Having all that valuable information locked up in code comments that is not easily readable or portable does not make sense to me. Whereas the wiki has much more info than what my tool was intended to provide (it has non XML related topics). Also the wiki is accessible to even casual observers in a common format. It is also easily updated by a group.
That said, in the not too distant future there will many new technologies (AR being one) that will require data in new formats. It would make sense that all new work is in a portable data format.
My tool (should we call it TASOB?) currently has the same problem as the POS2 file in regards to updating and version management. If the community wants to adopt it (or at least the data format) we need to discuss how to deal with that.
-
As I work on TASOB, I am finding things that need better definitions, discrepancy resolution and confirmations of my interpretations. I would like direction from the admins on how best to deal with these. My inclination would be to select a forum (Bug Reports maybe?) and create a separate thread for each item. That way I can revise the title with "Resolved". If that is OK I will spam that forum with several dozen questions I have accumulated. Please advise...
-
I would suggest creating a sub category (via admin) in this "Map Making" category. Then you can create separate topics within that category and spam it as much as you need.
What exactly does TASOB stand for? I would suggest just calling the category "XML Options Browser" as this topic is currently.
Edit: I see, "s" is for scenario. So it is triplea scenario option browser. Personally I would just exchange scenario for xml. TAXOB
-
I created the sub category as mentioned above, so you can begin creating new topics there. And others can confirm each point.
-
I think the only true advantage that the POS2 would maintain is that it showcases a lot of the code in complete context. But TASOB blows it away in every other way. If we maintain only one database, I would vote for this new one. Thus leaving POS2 with a prominent note indicating the date of last update and to refer to new database for most current information.
-
@mahks I disagree; being already in an xml makes POS2 much easier to be used than searching a Wiki (I never use). With the move to GitHub, POS2 can really fairly easily be updated by anyone, and the developers just need to accept the pull. While the Wiki is easier to maintain, it uses to remain unupdated for years, so letting anyone doing it is not really a reliable practice, since very few people would do it, no matter how easy to. At the end, it is needed to have 1 or at most 2 official references that are mandatory to be updated as soon as any changes are made (likely by the developers doing the changes). Another advantage of POS2 is that if you make mass changes in the repository, they will apply there too.
I agree that having the main reference inside a game xml looks akward at first glance, but not a big deal, since it works well. -
@mahks Up to the admins, but I've the feeling those would be better in mapmaking, or maybe a special subsection of mapmaking.
-
A find, find next or search function would be beneficial to TASOB. One that would search through not only the lists on the left and their descriptions, but also through the examples and their contexts.
-
@general_zod Yes, search function ... I have been pondering that. The question is this; If it is only a left hand search then you miss many references to mid string stuff ie; a search for "sneak" would miss "Defending Subs Sneak Attack". But if you do a full string search it would be very easy to get a huge list of references. I thought I could do the latter and only return a unique link for each, not sure how helpful that would be. Still pondering...
-
@general_zod said :
I see, "s" is for scenario. So it is triplea scenario option browser. Personally I would just exchange scenario for xml. TAXOB
How about just XOB?
-
Very nice work.
We could do a special commentary syntax in the source code where attachments are defined. On each build we could fire up a script that then scrapes these comments and produces a JSON that is then delivered to a 'data' section of the website and would then be available as a javascript variable. This is pretty similar to how the maps page is populated: http://triplea-game.org/maps-list/maps/
@Mahks if you can handle the front-end part, with jekyll, and assume you have such a JSON variable, I could do the backend scraping and deliver the JSON. https://github.com/triplea-game/triplea-game.github.io
Thoughts?
-
Interesting. So I think the real question here is do we have general consensus on replacing POS2 XML with this approach? As I don't think we want to try and maintain both.
