As mentioned before, when mobile version of ArmyCalc was under development I found out few missing features and inaccuracies in TWR 2.0 format.
This discussion contains this missing features:
[armycalc.com]

That's why I am considering extending this format and specifying TWR 3.0 before deploying mobile version. This decision is important because TWR 3.0 is not backward compatible with TWR 2.0. This means you will not be able to use new version of software with old files and vice-versa.

Some new ideas and concepts were used and personally I believe that the new format is far more better/flexible than the previous one (and that is why I am doing this). It also has few more advantages that will be described later on. However it is really important to me if the rulesets editors could confirm / deny this statement.

For the last few days I've been working on a brand new online calculator that will support this format.
It is not fully functional yet but you will be able to get the concept.

Test version:
[armycalc.com]
Test version works on a test ruleset witch files are located in:
[armycalc.com]
This files are self-commented so check them out to see how new format works
Sources for new editor are hosted on github:
[github.com]

Quick editor usage instructions:

• click New Army in the top left corner (might have to wait a sec till the ruleset is fully loaded).
• set parameters and click create.
• to add new elements use the top menu
• click on the element and use the LHS panel to resize/move/remove or extend the element with possible sub elements.

And here is the list of most important advantages in comparison to the previous format:

1. JavaScript is used instead of Lua
   Lua is an awesome language, however there is no way to run it in a browser on the client side. JS on the other hand can run flawlessly in a browser. And this gives us ability to implement inline scripting of rulesets!
   Please chcek the shield element in core_units.xml
   

     <element minCount="0" maxCount="1" size="inherit"  afterAppend="that.parent.stat('sta',that.parent.stat('sta')+1);"  beforeRemove="that.parent.stat('sta',that.parent.stat('sta')-1);">  <uid>shield</uid>  <name>Shield</name>  <cost id="pts">1</cost>  </element>

   In this case afterAppend and beforeRemove are examples of 'hooks'. You can define a piece of a JS code that will be executed after element is appended and before it is removed! This piece has access to an interface that will allow you to make anything you want with the army. In this example after adding a shield parent element stamina stat is increased by 1 and decreased prior to shield removal (play with warriors in the calc to see that it actually works).
   
   But this interface will allow you to make much more. It is not fully finished yet, however it will allow you to find / append / remove / disable and change all parameters of every element in the army tree.
   another usage example: Imagine a WFB Dwarfs ruleset that will disable appending a master rune to other elements when it is already assigned elsewhere.
   
   validator script will use same interface and functions that the 'inline hooks'.
2. ability to 'extend' an element
   Please note the heroes.xml file. Hero is a base element and all other custom heroes are extending it. This really helps when editing. You do not have to rewrite repeating items twice. You can also check the equipment.xml file which defines items that can be equipped to any hero.
3. desktop application will use the same engine!
   Switching to JS allowed the calc to be fully independent from the server side scripts!
   That's why I will be able to put the same engine into the desktop application (it will be in fact a small web browser displaying just the calc).
   Leaving the technical mambo jumbo it simply means that the desktop application will look and work exactly the same way as the online calc.
   Simple mechanism will be able to automatic update the engine inside the application so after fixing any bugs and/or extending the format there will be no need to reinstall the application.
4. interface have been simplified
   merging 'unit' and 'bonus' into one - 'element' is one of the things that allowed to make the interface simpler.
   In fact from the user perspective there are only 3 actions that allow to build any army tree:
   
   • append an element to its parent (army is the 'root' element)
   • remove an element
   • resize an element
   And that will give us ability to design a nice and fast interface for the mobile app.
5. few other features
   including: multilanguage rulesets (you can change language 'on the fly'), models, fractional costs, multiple costs (in example twr each unit has its points and gold cost), nested(multi-level) units menu

Please do not worry about the work you did and rulesets you are already using as before publishing new software automatic script will convert all rulesets in our database to 3.0 version (I am working on it at the moment).

Any opinion on the new format is really valuable for me.
I will appreciate any comments.

francio Wrote:
-------------------------------------------------------
> including: multilanguage rulesets (you can change
> language 'on the fly')

Excellent!
I hope change a rulesets to multilanguage rulesets will be easly.
Example of multilanguage data for R-Community
[rcommunity.nazgulworld.com]

--
Dreadaxe
French T³ admin

Dreadaxe Wrote:
-------------------------------------------------------
> Example of multilanguage data for R-Community
> [rcommunity.nazgulworld.com]

Thanks for the link. They are keeping texts for languages in separate files. This might be a good idea if someone will create ruleset with 10 languages.
I will think about implementing this.

I'm really excited to see the TWR3.0 out along with a more unified UI ( EYE, Online Calc and most probably Mobile, having the same codebase)

I noticed some bugs running it on IE7 (labels being displayed as "undefined".
I hope ArmyCalc will also be multi-browser compliant (at least for the major ones ).


Great work there Francio!

At a first glance, it looks very neat. Much easier to work with than TWR 2.0.

One great thing is that we don't have to use unique hash keys any more (I know I could use other ways of generating unique values, but hash keys are very convenient for uniqueness).

But the best thing is the ability to extend objects with other objects. Equipment handling will be MUCH easier to handle!

Keep up the good work! I think you're on to something here!

WilliamWM Wrote:
-------------------------------------------------------
> One great thing is that we don't have to use
> unique hash keys any more (I know I could use
> other ways of generating unique values, but hash
> keys are very convenient for uniqueness).

Not sure if I understand. uids work exactly the same way as in twr2.0. md5 sums were just used in the test ruleset to show that anything can be put there. It just needs to be unique for given ruleset. If you were generating md5s then sorry for the misunderstanding.

Anyhow I am getting back to work on this and hoping to finish beta version and 2to3 convert script as soon as possible.

Quote
francio
If you were generating md5s then sorry for the misunderstanding.

No problem! I understood that they just had to be unique and I used md5 hashes just to make sure they stayed unique.

I will not be using them when upgrading my ruleset to TWR 3.0 though...

francio Wrote:
-------------------------------------------------------
> This might be a good
> idea if someone will create ruleset with 10
> languages.

To my opinion it's the power of the multi-language ruleset to create a collaborate work. It's not someone but some people that work on one ruleset.

Actually the share of rulesets for the development it's impossible. Example of sharing, gestion of works with Google doc.

--
Dreadaxe
French T³ admin