Atlas strangeness when editing rms while opened

[FeXoR]

Random maps are loaded from different paths in Atlas and the game itself.

- The sub path '\binaries\data\mods\public\maps\random' in the svn directory

- The custom content path '%localappdata%/0ad\cache\mods\public\maps\random' (for windows I'm working on)

If I have atlas opened and edit a file in the custom map folder and then generate the map (again) the changes are applied.

If I do the same in the svn path the changes are NOT applied. In some cases it raises an javascript error stating a syntax error in the last line of the file (no matter if something near the last line was modified). Atlas needs to be reloaded to see the changes.That should be the same for the game itself I think.

I don't know if this is a known issue or how it works with Alpha 9.

I'm using Vista (longhorn, home premium), tortoiseSVN and the current SVN version. 

Edited April 14, 2012 by FeXoR

[historic_bruno]

- The custom content path '%localappdata%/0ad\cache\mods\public\maps\random' (for windows I'm working on)

That's not really a custom content path, it's the cache path. I suspect when you modify those files you're working around a bug in the hotloading system (I don't know which bug or why what you're doing is working).

[FeXoR]

That's not really a custom content path, it's the cache path. I suspect when you modify those files you're working around a bug in the hotloading system (I don't know which bug or why what you're doing is working).

What you are saying is similar to what Philip said in Ticket #631 and your previous answer agreeing with Ykkrosh in this post.

Atlas Tricks (Page seams a little hidden for me) says %appdata%\0ad\cache\mods\public\maps\scenarios would be the default directory for saving maps in Atlas but it changed to %localappdata% as I stated in this post. The above is true for Alpha 9 (not sure about %localappdata% or %appdata%) but for the SVN version the default save path is \binaries\data\mods\public\map\scenarios in the SVN directory. Atlas and the game itself search for files in %localappdata% as well though (SVN version).

Ticket #1145 sais it would be fixed but I cannot find out where in My Documents the files have to be placed (and so doubt that it works at all). It provides a link to this list and some other useful related stuff.

Now I'm quite confused and don't understand:

- Why you say %appdata%/0ad\cache\mods\public\maps is not the custom map folder though it behaves exactly like I would think a custom map folder would?

- Why was it changed from %localappdata% to %appdata% (indicating it can be changed) but not to My Documents/0ad/maps as suggest in this list?

- In witch way the virtual file system is broken and how you 'lost control' of the paths like said in this post?

- Why is Ticket #1145 set to fixed though it doesn't appear to be fixed?

BTW: It works for AI as well: %appdata%\0ad\cache\mods\public\simulation\ai

Edited April 15, 2012 by FeXoR

[historic_bruno]

Atlas Tricks (Page seams a little hidden for me) says %appdata%\0ad\cache\mods\public\maps\scenarios would be the default directory for saving maps in Atlas

- Why you say %appdata%/0ad\cache\mods\public\maps is not the custom map folder though it behaves exactly like I would think a custom map folder would?

That page basically says Atlas doesn't have proper mod support yet (which is true), what it doesn't say is that releases often store data in an unwritable location (like a .zip archive or outside the user's home directory). There are technical reasons why it fails and why the files end up in cache instead, it has to do with the inner workings of the VFS. The cache is actually intended for files that are loaded from other sources (like textures from PNGs), they get converted and stored in cache to reduce load time on the next use. The cache will never ever be officially intended for doing what you're doing, it's a temporary hack because of some missing VFS functionality and mod support

but it changed to %localappdata% as I stated in this post. The above is true for Alpha 9 (not sure about %localappdata% or %appdata%) but for the SVN version the default save path is \binaries\data\mods\public\map\scenarios in the SVN directory. Atlas and the game itself search for files in %localappdata% as well though (SVN version).

This changed according to the discussion we had here. Cache should go in local app data instead of roaming, which is a useful distinction for users on domains. It's pretty standard behavior for modern Windows apps. See the link for details.

Ticket #1145 sais it would be fixed but I cannot find out where in My Documents the files have to be placed (and so doubt that it works at all). It provides a link to this list and some other useful related stuff.

- Why was it changed from %localappdata% to %appdata% (indicating it can be changed) but not to My Documents/0ad/maps as suggest in this list?

- Why is Ticket #1145 set to fixed though it doesn't appear to be fixed?

#1145 was only intended to shuffle existing data paths, not fix the broken VFS However the description in the ticket is slightly outdated, as the comments explain, the original planned locations were changed due to feedback from others. I just forgot to update the description for Windows.

Fixing mod support in Atlas and generally is a problem for another ticket (#889 is somewhat of a placeholder for that).

- In witch way the virtual file system is broken?

Understand the VFS as a means to translate a game path like maps/scenarios to a real system path on your computer. Actually there can be multiple real paths per a single VFS path, such as if you have multiple mods installed. Now for reading files that is OK, you can have different priorities and pick the file from the mod with highest priority. But for writing files, as Atlas does, there should only be a single real path which is known to be writable. The VFS lacks that currently, but in the future we will have a single "user mod" directory in a standard location, and Atlas will always save maps there.

I'm not sure why hotloading of random maps is broken for SVN versions, I think it's a separate issue from the above.

[FeXoR]

That page basically says Atlas doesn't have proper mod support yet (which is true), what it doesn't say is that releases often store data in an unwritable location (like a .zip archive or outside the user's home directory). There are technical reasons why it fails and why the files end up in cache instead, it has to do with the inner workings of the VFS. The cache is actually intended for files that are loaded from other sources (like textures from PNGs), they get converted and stored in cache to reduce load time on the next use. The cache will never ever be officially intended for doing what you're doing, it's a temporary hack because of some missing VFS functionality and mod support

This changed according to the discussion we had here. Cache should go in local app data instead of roaming, which is a useful distinction for users on domains. It's pretty standard behavior for modern Windows apps. See the link for details.

#1145 was only intended to shuffle existing data paths, not fix the broken VFS However the description in the ticket is slightly outdated, as the comments explain, the original planned locations were changed due to feedback from others. I just forgot to update the description for Windows.

Fixing mod support in Atlas and generally is a problem for another ticket (#889 is somewhat of a placeholder for that).

Understand the VFS as a means to translate a game path like maps/scenarios to a real system path on your computer. Actually there can be multiple real paths per a single VFS path, such as if you have multiple mods installed. Now for reading files that is OK, you can have different priorities and pick the file from the mod with highest priority. But for writing files, as Atlas does, there should only be a single real path which is known to be writable. The VFS lacks that currently, but in the future we will have a single "user mod" directory in a standard location, and Atlas will always save maps there.

I'm not sure why hotloading of random maps is broken for SVN versions, I think it's a separate issue from the above.

Thx much for explaining

I think those issues should be fixed soon. I already send a false patch to be reviewed because I couldn't see the false behavior in Atlas. I will try to remember to restart Atlas ofc. but it's not my work practice to close and reopen programs over and over again. At least it's an annoyance. Since i had problems with broken patches too I think I will work as follows:

- Modify files in cache (if possible for all my desired changes) to be able to see the results in Atlas without reopening it until I'm done.

- SVN update

- Copy modified files to the SVN tree

- Rename cache folder

- Test

- Generate patch

- Revert SVN and delete all added files

- Apply patch to see if everything works fine

- Test

- Send patch to be reviewed

Will that likely lead to problems or will it work fine (until the real custom content folders are implemented ofc.)?

Edited April 16, 2012 by FeXoR