• 18
  • 80
  • 6

Recent Posts

  • C

    @rainova said in Issues with "missing unit icon/image (won't be displayed)":

    @frigoref @Cernel "missing unit icon/image (won't be displayed)" errors also occur with up to date TripleA versions, e.g. in BC270 wars, when barbarians conquer walls.

    I started a "270BC Wars" game and, during the first turn of Carthage, edited 99 swordman units in Roma. On the barbarians turn between the turns of Carthage and Rome, Roma was conquered by the barbarians, destroying the metropolis unit and all wall_fallen units they conquered.

    Game history:
    Battle in Roma
    barbarians attack with 99 swordmen
    Rome defend with 1 ballista, 1 horseman, 1 legionary, 1 metropolis, 1 skirmisher, 1 territory and 4 walls
    Rome roll Artillery dice in Roma : 4
    1 swordman owned by the barbarians lost in Roma
    barbarians roll dice for 98 swordmen in Roma, round 2 : 3,1,5,5,2,6,1,4,3,3,6,5,1,6,5,6,2,6,6,4,5,5,5,5,2,6,5,5,3,6,1,6,6,1,3,6,4,5,2,2,5,6,6,3,6,6,4,2,1,2,6,3,3,4,6,5,3,2,1,5,4,6,2,1,5,1,6,2,6,2,4,2,3,6,4,6,3,6,5,5,2,2,6,1,4,1,2,3,2,2,4,6,6,5,5,4,6,2
    Rome roll dice for 1 horseman, 1 legionary, 1 skirmisher and 4 walls in Roma, round 2 : 4,3,1
    1 skirmisher owned by the Rome, 1 horseman owned by the Rome, 1 ballista owned by the Rome, 1 legionary owned by the Rome, 1 swordman owned by the barbarians and 4 walls owned by the Rome lost in Roma
    4 wall_fallens owned by the Rome added in Roma
    barbarians takes Roma from Rome
    Some non-combat units are destroyed:
    barbarians win
    Battle casualty summary: Battle score (TUV change) for attacker is 12

    The line "Some non-combat units are destroyed:" is not making sense: why to have a colon followed by nothing? Either something is missing after the colon or the colon should have not been there.

    Beside the apparently pointless colon, I had no issues at all.

    This is all I had in the console so nothing referring to the "270BC Wars" game.

    gen 17, 2022 9:00:33 AM org.triplea.game.client.HeadedGameRunner lambda$initializeClientSettingAndLogging$0
    GRAVE: Illegal character in opaque part at index 2: C:\Users\001\triplea\downloadedMaps\world_war_ii_v4\map\games\WW2v4.xml
    java.lang.IllegalArgumentException: Illegal character in opaque part at index 2: C:\Users\001\triplea\downloadedMaps\world_war_ii_v4\map\games\WW2v4.xml
    at java.base/java.net.URI.create(URI.java:883)
    at games.strategy.engine.framework.startup.ui.panels.main.game.selector.GameSelectorModel.gameUriExistsOnFileSystem(GameSelectorModel.java:216)
    at java.base/java.util.Optional.filter(Optional.java:223)
    at games.strategy.engine.framework.startup.ui.panels.main.game.selector.GameSelectorModel.loadDefaultGameSameThread(GameSelectorModel.java:209)
    at games.strategy.engine.framework.GameRunner.showMainFrame(GameRunner.java:80)
    at java.base/java.lang.Thread.run(Thread.java:834)
    Caused by: java.net.URISyntaxException: Illegal character in opaque part at index 2: C:\Users\001\triplea\downloadedMaps\world_war_ii_v4\map\games\WW2v4.xml
    at java.base/java.net.URI$Parser.fail(URI.java:2913)
    at java.base/java.net.URI$Parser.checkChars(URI.java:3084)
    at java.base/java.net.URI$Parser.parse(URI.java:3120)
    at java.base/java.net.URI.<init>(URI.java:600)
    at java.base/java.net.URI.create(URI.java:881)
    ... 5 more

    As far as the rules go, walls can never be non-owned, because, if non-owned units conquer any territory, all walls in it are immediately removed from the game.

    As far as the intended behaviour of the game goes, the "barbarians" player (which exists for owning everything which the rules describe as being owned by nothing) can never own wall units because it has no way to have them in its inventory and the wall units themselves can never be captured, whereas every wall_fallen unit it may capture is removed from play as per what defined in the game file.
    https://raw.githubusercontent.com/triplea-maps/270bc_wars/master/map/games/270BC_Wars.xml

    <attachment name="unitAttachment" attachTo="wall_fallen" javaClass="games.strategy.triplea.attachments.UnitAttachment" type="unitType"> <option name="movement" value="0"/> <option name="canNotMoveDuringCombatMove" value="true"/> <option name="attack" value="0"/> <option name="defense" value="0"/> <option name="isInfrastructure" value="true"/> <option name="destroyedWhenCapturedBy" value="barbarians"/> <option name="hitPoints" value="2"/> <option name="whenHitPointsRepairedChangesInto" value="0:true:wall"/> <option name="requiresUnits" value="metropolis"/> </attachment>

    Specifically the line <option name="destroyedWhenCapturedBy" value="barbarians"/>, which is validated by the always-true property Units Can Be Destroyed Instead Of Captured.

    <property name="Units Can Be Destroyed Instead Of Captured" value="true" editable="false"> <boolean/> </property>

    So, for a user, there is no proper way (I'm aware of) ever to ending up having to see any barbarians-owned wall or wall_fallen units.

    If such an error has been reported, please give a link to it, or else report the error if you will have it. After I'm aware of a report featuring this problem, I may give suggestions on how to fix it.

    Given that we are not really overstaffed on the developer side, we should be very restrictive, i.e. only support the latest offcial version (2.5.x) and the latest development version (2.6.x). Only these versions should be considered up to date.

    I suggest accepting all versions from the latest release onwards (without ignoring all versions between the latest release and the latest pre-release): whereas there is an abundance of error reports in general, I'm not under the impression that pre-releases are being tested that much.

    Another question is what to do about all already opened reports: I suppose it would be too much work closing them individually (by checking whether or not each of them refers to an acceptable version).

    How about in case of an error, we only show the Report to TripleA button, if the version is up to date and otherwise comment that the version is not and suggest to update?

    Yes, but please be sure to word it in a way which will not appear telling the user that updating is going to fix the problem, just that it may. Also a suggestion to try replicating the problem again with the up-to-date version (in order to report it) may be good.

    If you consider this reasonable and start a feature request, I'll look into it further.

    I'm not a developer, but it seems that the project may benefit from cutting down the number of currently open issues. On the other hand, I'm not seeing a scarcity of error reports.

    Regarding the part of the "root cause" that the map developer forgot a - probably relatively unimportant - image (which might be the case in the BC270 wars example above, although there may be another reason): As far as I looked into the automatic Error Reports, this frequently happens with infrastructure that can be generic among players. How about we put such images into a new generic subfolder of the units folder (next to Americans, British, Carthage, ...) and implement that the image load looks into that folder if it can't find an image in the player's subfolder? If interesed: Please feature request 😉

    I'm not aware I've forgotten any units. Regarding walls, I have deliberately not added them to the "barbarians" sub-folder of the "units" folder, assuming they were not needed by the game.

    As for what you are suggesting, there is no need to have such a feature request. It looks like you are not aware that having images directly inside the "units" folder allows them to be called for any player not having the same-named images within its "units" sub-folder. The only difference with your proposal is that your proposal would make virtually impossible to name any player as "generic" or cause confusion if a map-maker does so.

    @Cernel btw Could you do without the player logos on your walls images? That would reduce the number of images and therefore simplify maintenance.

    Thanks for the suggestion, but I think this is remaining the way it is (as it is my deliberate decision as the map-maker needlessly to have "wall" and "wall"-related units images per every player but "barbarians"). I agree such a choice is needlessly slightly increasing weight and maintenance, but I'm not seeing this as prohibitive. By the way, you could say the same for the "metropolis" and "fort" units too.

    read more
  • R

    @frigoref @Cernel "missing unit icon/image (won't be displayed)" errors also occur with up to date TripleA versions, e.g. in BC270 wars, when barbarians conquer walls.

    Regarding the part of the "root cause" @Cernel pointed out, i.e. old TripleA version:

    there is still an alignment needed on which TripleA versions we consider (very) old

    Given that we are not really overstaffed on the developer side, we should be very restrictive, i.e. only support the latest offcial version (2.5.x) and the latest development version (2.6.x). Only these versions should be considered up to date.

    How about in case of an error, we only show the Report to TripleA button, if the version is up to date and otherwise comment that the version is not and suggest to update?

    If you consider this reasonable and start a feature request, I'll look into it further.

    Regarding the part of the "root cause" that the map developer forgot a - probably relatively unimportant - image (which might be the case in the BC270 wars example above, although there may be another reason): As far as I looked into the automatic Error Reports, this frequently happens with infrastructure that can be generic among players. How about we put such images into a new generic subfolder of the units folder (next to Americans, British, Carthage, ...) and implement that the image load looks into that folder if it can't find an image in the player's subfolder? If interesed: Please feature request 😉

    @Cernel btw Could you do without the player logos on your walls images? That would reduce the number of images and therefore simplify maintenance.

    read more
  • R

    @thedog Just to maximise information about the game: The battle calculator does take into account the Air/Land/Sea Battle Rounds settings.

    read more
  • @cernel, thanks for your feedback!
    If I summarize your post, you are answering question 5. (Does anyone has an idea what the root cause could be and how to solve it?) and questioning whether we should attend to those issues due to the old TripleA version they are coming from.

    I agree with both of your points, i.e., the root cause analysis including how to address it and the suggestion to ignore issues raised for (very) old TripleA version.

    However, there is still an alignment needed on which TripleA versions we consider (very) old and also my other questions stay 1.-4. are unanswered.
    You partially answered 2. (How can the problem be reproduced?) by suggesting to start the map, but shouldn't we make it mandatory or at least available to have some reproducible step-by-step guide to make our part easier? This way we could focus on actually solving the issues instead of trying to find ways to reproduce them.

    read more