XML option browser
-
@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.
-
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)
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