Triplea: Invasion U.S.A. Scenario Does not Run

Created on 3 Mar 2017  路  17Comments  路  Source: triplea-game/triplea

When trying to run the scenario, it just goes back to menu. The console shows:

Loading map: Invasion_USA, from: C:\Users\Judy\triplea\downloadedMaps\invasion_usa-master.zip
Loading resources from the following paths: [C:\Users\Judy\triplea\downloadedMaps\invasion_usa-master.zip, C:\Program Files\TripleA_1.9.0.0.3266\assets]
Could not find: Invasion_USA/ doc/images/invasionusa.png
Loading map: Invasion_USA, from: C:\Users\Judy\triplea\downloadedMaps\invasion_usa-master.zip
Loading resources from the following paths: [C:\Users\Judy\triplea\downloadedMaps\invasion_usa-master.zip, C:\Program Files\TripleA_1.9.0.0.3266\assets]
Could not find: Invasion_USA/ doc/images/invasionusa.png
Loading map: Invasion_USA, from: C:\Users\Judy\triplea\downloadedMaps\invasion_usa-master.zip
Loading resources from the following paths: [C:\Users\Judy\triplea\downloadedMaps\invasion_usa-master.zip, C:\Program Files\TripleA_1.9.0.0.3266\assets]
Loading map: Invasion_USA, from: C:\Users\Judy\triplea\downloadedMaps\invasion_usa-master.zip
Loading resources from the following paths: [C:\Users\Judy\triplea\downloadedMaps\invasion_usa-master.zip, C:\Program Files\TripleA_1.9.0.0.3266\assets]
java.lang.reflect.InvocationTargetException
at java.awt.EventQueue.invokeAndWait(Unknown Source)
at java.awt.EventQueue.invokeAndWait(Unknown Source)
at javax.swing.SwingUtilities.invokeAndWait(Unknown Source)
at games.strategy.triplea.TripleA.startGame(TripleA.java:122)
at games.strategy.engine.framework.startup.launcher.LocalLauncher.launchInNewThread(LocalLauncher.java:49)
at games.strategy.engine.framework.startup.launcher.AbstractLauncher.lambda$launch$116(AbstractLauncher.java:43)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.IllegalStateException: Error in resource loading. Unable to load expected resource: polygons.txt, the error is that either we did not find the correct path to load. Check the resource loader to make sure the map zip or dir was added. Failing that, the path in this error message should be available relative to the map folder, or relative to the root of the map zip
at games.strategy.triplea.ui.mapdata.MapData.(MapData.java:155)
at games.strategy.triplea.ui.UIContext.internalSetMapDir(UIContext.java:77)
at games.strategy.triplea.ui.AbstractUIContext.setDefaultMapDir(AbstractUIContext.java:118)
at games.strategy.triplea.ui.TripleAFrame.(TripleAFrame.java:227)
at games.strategy.triplea.TripleA.lambda$startGame$335(TripleA.java:124)
at java.awt.event.InvocationEvent.dispatch(Unknown Source)
at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
at java.awt.EventQueue.access$500(Unknown Source)
at java.awt.EventQueue$3.run(Unknown Source)
at java.awt.EventQueue$3.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at games.strategy.engine.framework.GameRunner$1.dispatchEvent(GameRunner.java:360)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)
Loading map: , from: C:\Users\Judy\triplea\downloadedMaps\
Loading resources from the following paths: [C:\Users\Judy\triplea\downloadedMaps\, C:\Program Files\TripleA_1.9.0.0.3266\assets]

I think the problem is the space in "Invasion_USA/ doc/images/invasionusa.png" but I don't where the bad code is.

All 17 comments

Just wanted to note that the space in the path is probably a red herring. It's actually hard-coded in the log message itself (from games.strategy.util.LocalizeHTML):

System.out.println("Could not find: " + mapNameDir + "/ " + ASSET_IMAGE_FOLDER + imageFileName);

The root cause of the problem appears to be an incorrect value for the mapName property:

<property name="mapName" value="Invasion_USA" editable="false"/>

At least on *NIX, it's apparently case sensitive. Changing it to "invasion_usa" allowed me to start the game (and fixed the missing _doc/images/invasionusa.png_ image error on the game notes page):

diff --git a/map/games/Invasion_USA_1.5.0.xml b/map/games/Invasion_USA_1.5.0.xml
index 4cbcb34..de8563b 100644
--- a/map/games/Invasion_USA_1.5.0.xml
+++ b/map/games/Invasion_USA_1.5.0.xml
@@ -1699,7 +1699,7 @@
         </property>

                 <!-- Map Name: also used for map utils when asked -->
-                <property name="mapName" value="Invasion_USA" editable="false"/>
+                <property name="mapName" value="invasion_usa" editable="false"/>

                <property name="notes"> 
                <value>

It looks like the other game XML files for this map have the same issue. Any PR should probably hit all three.

EDIT: The OP is on Windows but is loading the map from a zip archive. URLClassLoader appears to be case sensitive, at least for the jar/zip scheme. I suspect that if one were to clone from Git or explode the zip archive, and load the map from there, the problem would not occur on Windows due to its case-insensitive file system.

EDIT: The OP is on Windows but is loading the map from a zip archive. URLClassLoader appears to be case sensitive, at least for the jar/zip scheme. I suspect that if one were to clone from Git or explode the zip archive, and load the map from there, the problem would not occur on Windows due to its case-insensitive file system.

Being on Windows, too. I have experienced that
<property name="mapName" value="any_map" editable="false"/>
is case sensitive in either scenario: zipped, unzipped, cloned...

This issue has been addressed sometimes in the triplea-maps section or in the forums. So as capitals are avoided in the zip and directoy name, they must be avoided in the corresponding mapName, too.

Thanks for the background information, @panther2. With regards to the case sensitivity of mapName, I should have been clearer that I was talking about only those places where it is used in a file path, where it might work on Windows if it had the wrong case. However, mapName appears to be used for all sorts of things within a game, so I agree with your observation that, in general, it is treated in a case-sensitive manner regardless of platform.

Just out of curiosity, I wanted to test the theory about this map working on Windows when loaded from a folder instead of a zip. When I say "working," I only mean that I can start the game--I have no idea if I could actually play it to completion with the mapName as is.

I installed TripleA 1.9.0.0.3832 on a Windows box and cloned triplea-maps/invasion_usa into %USERPROFILE%\triplea\downloadedMaps. (I had to edit each game XML file to remove the DTD due to the bug you previously reported, but I didn't touch the mapName property, which I verified was Invasion_USA.) After starting TripleA, I was able to select the Invasion USA map and start a local game without error.

I verified that when loading a map from a cloned repo, the URLClassLoader is using the file scheme. My guess is that, for such a scheme, the URI path is passed directly to the native file system for processing, which would explain why the path is treated in a case-insensitive manner on Windows, as observed above.

Very interesting, thanks so much for sharing your observations, @ssoloff .

I am glad you pointed out the removal of the DTD from the XML - that is exactly the workaround that I was asking for in #1547 - for any reason that did not come to my mind. That finally enables me to download and test the latest version(s).

I have already had the experience of games working in the folders, but not when they are zipped. I always test my games both ways. This scenario was in the repository, has it been fixed or should I post a fix myself.

@RogerCooper, I have a fix prepared. I will try to submit a PR in the next few hours. See triplea-maps/invasion_usa PR #14.

@ssoloff

I am still a bit confused: I have again downloaded the (so far unchanged) zip file from the repo, so this is the one containing the mapName with capitals. I am on Windows 7 (64bit).
When starting TripleA selecting the map-zip, this is what happens:

1

When replacing the zip-file with the unpacked folder-structure, this is what happens:

2

I can only run the game without issue when changing mapName to lower cases (either within the zip or unzipped), as you did in your above mentioned pull request https://github.com/triplea-maps/invasion_usa/pull/14 .

So it appears, that here Windows is case sensitive in these both cases.

On the other hand you experienced a case-insensivity when cloning directly.
So is this caused by a difference between cloning the files on the one hand and downloading the zip (running as well the zip as from the (unpacked) folder on the other hand) - both directly from the repo?

When cloning directly - do you have folder name and mapName identical in that case? If not what is the difference? I mean when starting TripleA in either scenario the map data base on the harddrive should be identical - or what am I missing?

I simply fail to reproduce a scenario in which my Windows reacts case-insensitvely here ...

Rethinking I am also wondering why this issue should be OS-dependent. I mean isn't it Java that searches for a directory name that matches the pattern as defined by the mapName ?

Thank you :-)

@panther2

When replacing the zip-file with the unpacked folder-structure, this is what happens

When you unpack the zip archive, the map will be in a folder named invasion_usa-master. Try renaming it to just invasion_usa. I found I had to do that to get it to work (both on Windows and *NIX). (When cloning, the folder is already named invasion_usa.)

I don't know if this is a true statement (and I don't have my dev environment in front of me at the moment to verify), but I think TripleA only supports <mapName>-master in the path when it is loading the map from a correspondingly-named <mapName>-master.zip file. I remember seeing a class that handles this. (A quick GitHub search turned up ResourceLocationTracker, but I'm not sure if that class tells the whole story.)

If you are saying that you are able to get the map to load from the unpacked invasion_usa-master folder by just changing mapName to invasion_usa in the XML, then I'm afraid I can't explain why that works without further debugging. 鈽癸笍

@panther2

Rethinking I am also wondering why this issue should be OS-dependent. I mean isn't it Java that searches for a directory name that matches the pattern as defined by the mapName ?

That would be true if the Java file system libraries were pure Java, but they ultimately delegate many operations to the native OS (asking if a file named <something> exists in the file system is one of those operations). See this SO question for a classic example of "my code works on Windows but not on Linux" related to the file system. The accepted answer explains it well.

@ssoloff

Thank you for the Java-related link, very helpful!

Furthermore I can confirm you are right on the 'master'-extension.
I have done some more testing and found out that I accidentally thought that loading the map successfully from the unzipped folder structure was due to the correction of the mapName. In fact it was due to the removal of '-master' from the folder name. On my first try (2 days ago) I did that and on my second try (that resulted in the second GIF) I simply forgot that.

So all in all I was now able to reproduce on my Windows that when

  • loading the map from the -master.zip, the mapName inside the game.xml is case sensitive, so the map does not load when mapName contains capitals,
  • loading the map from the unzipped mapName-master folder fails,
  • loading the map from the unzipped mapName folder (removing the -master from the folder name) works regardless of whether the mapName contains capitals or not.

However this issue seems to be important "only" in case of adding new map-repos, as AFAIK all present maps follow the standard of small letters in the mapName according to the map (directory) name.

Again, thanks a lot, and I hope I did not waste too much of your time. :-)

@panther2 No problem at all. This is helping me, as well, learn more about how TripleA works by digging into some of the dark corners. :smile:

How do I upload the fixed file?

@RogerCooper, are you talking about uploading a fixed Invasion_USA_1.5.0.xml file to the triplea-maps/invasion_usa repo? A fix has already been submitted--it is pending review before it can be merged.

Bumping...

@ron-murhammer, I submitted some PRs to fix this issue about a week ago. Those were my first map-specific PRs (triplea-maps/invasion_usa#14, triplea-maps/invasion_usa#15), so I may not have followed SOP. Is there someone I specifically have to tag in a map repo to have them review those PRs?

@ssoloff Merged them both. For maps, its a good idea to ping myself or Dan as we don't check the maps repos for PRs that much.

@ron-murhammer Got it. Thanks!

Was this page helpful?
0 / 5 - 0 ratings

Related issues

drockken picture drockken  路  6Comments

DanVanAtta picture DanVanAtta  路  5Comments

ron-murhammer picture ron-murhammer  路  6Comments

DanVanAtta picture DanVanAtta  路  8Comments

RoiEXLab picture RoiEXLab  路  3Comments