#47 NumberProperties are now Integers

closed-accepted
nobody
None
5
2012-03-12
2011-12-09
No

NumberProperties vere treated as string. This fixes previous error with game option caching.

I beleive the game.dtd should be changed so that omitting type is not allowed.
for instance <property name="neutralCharge" value="0"/> and <property name="mapName" value="big_world" editable="false"/> both ommits the type, but one is most likely an integer, but how would the code know? and it was editable which editor would you show it in....?

Discussion

  • Chris Duncan

    Chris Duncan - 2011-12-09

    if we do this, it will break all known maps.
    someone will have to go and fix, about >200 map xmls. so, that is not going to happen for sure!
    can you make exceptions somehow that correct typical options to be the type they are supposed to be?

     
  • Klaus Grønbæk

    Klaus Grønbæk - 2011-12-09

    Included in the patch was an update to the GameParser so it will assume that non-typed properties are Integers if the value can be parsed as an integer, and otherwise strings. I did a search through the maps that are included in the SVN checkout, and that logic seamed to work.
    Also it appears like all editable integer properties have a proper type declaration.
    In addition the games.strategy.triplea.Properties class only have methods that return int or boolean, so all string properties are accessed directly through the GameProperties class, and would be the responsibility of the mapwriter..

    I would not be hard to update the game.xml, you can easily write a replacement pattern (regex) and just have your editor do the modification (if you have all 200 maps), like this
    find: (<property [^>]*value="(\d+)"[^>]*)\/>
    replace with: $1 >\t\t\t\n<number max="$2" min="$2"/>\t\t\n</property>

     
  • Chris Duncan

    Chris Duncan - 2011-12-09

    So, are you saying that we can validate that all editable properties have the correct Type set, and then continue to allow non-editable properties to be non-type set?
    That is probably a good move. We could also make all properties require a type, and then include special cases for the values that are not generally typed (mapname, etc), in addition to requiring editable properties to be typed.
    What do you think of this?

    As a basic rule, we can not break compatibility with map xmls. Current map makers already have a tough enough time writing maps that work without errors, so I prefer not to throw new errors at them.

    Complications:
    1. I only have maybe 80-90% of the maps out there. There are maps that I don't have, and some that I don't know how to get, or are not released yet to the public.
    2. The maps are all in zips.
    3. Even if we updated all the maps, we can not force everyone to download the new maps. Therefore, everyone will get error messages, and probably uninstall triplea.
    4. We don't want to force people to redownload maps, and we definitely don't want to rewrite files on their computer.

     
  • Chris Duncan

    Chris Duncan - 2011-12-12
    • status: open --> pending-accepted
     
  • Chris Duncan

    Chris Duncan - 2012-03-12
    • status: pending-accepted --> closed-accepted
     

Log in to post a comment.