XML option browser
-
@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.
-
XOB sounds ok to me, nice and short.
As the search goes, it should be a search of all information in the right pane for maximum usefulness. The left pane has two sorting modes so that piece is more manageable from search standpoint. If you could replicate the common find or find next methods where it only searches up or down from current cursor location. That would be ideal because one can just bypass a lot of the stuff they know they don't want as results. In this case the cursor position being whatever is highlighted in the left pane, but I think it would need to recognize if the left pane is currently in alphabetical or hierarchal modes during the search to function well.
I vote for XOB if it comes down to a choice of one or the other as it applies to maintenance.
-
@lafayette Having the JSON based in/on the source code comments would be ideal. If the developers update those comments when changes are made.
It may be a lot of work to get the data into those comments in the first place though.
The HTML page is pretty straight forward. Could be maintained by anyone with HTML. I could do it for now.
But I think the most important thing is getting the data in a portable format.
-
@LaFayette I don't want to put the comments in the engine source code as then no one but developers would ever maintain it. Its better in a place that map makers can also contribute to.
-
@redrum I just realized he may have meant the POS2 file.
But... once the data was up to date. there should be no need to add to it unless the engine is being modified.
I do not know how you go about change approvals, but who ever approves the code change should update the data at the same time (document the change)
-
@mahks Possibly but that's not how I understood his comments.
In theory, that's true but having the flexibility for non-developers to add more hints/info/corrections I think would always be beneficial.
Today, when a developer makes a code change that influences the XML then we update the POS2 XML with an example and comment. If we moved to a different way to store that info like JSON in a repo that would be fine as well and in theory work the same way. I just don't want to have multiple places to update.
-
@redrum I would surely not remove the PoS2 stuff. To reduce overhead, it may be acceptable to have the practice to update primarily this thing only, as mandatory for anyone making any changes, letting PoS2 up to personal initiative to keep it updated, just like any regular maps (most likely it won't happen, or with averagely year long delays, I imagine).
I'm surely not a sponsor of the principle of having to update multiple things, but stuff being inside the xml itself I think it is really the easiest way to use, for fairly experienced mapmakers, that already know about everything (and just need some memory refresh and copy-paste). -
@redrum I agree that people that make changes should be obliged to update no more than 1 place, and possibly an easy one to manage. Reducing overhead and confusion is of paramount importance.
Just I would not delete the PoS2 bible, but making a clear mention that this is not the main reference, a link to the main reference, and telling people that everyone is free to pull updates to PoS2, if they find something not in line. Likely, people reading PoS2 will read that, so you won't get too many bug reports about PoS2 being wrong, but just possibly people pulling changes to it, in case.
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login