Jibble

Author Topic: MonoAGS components system and FileSystem.  (Read 1048 times)

Monsieur OUXX

  • Mittens Half Initiate
    • I can help with proof reading
    • I can help with translating
    • I can help with voice acting
    • Monsieur OUXX worked on one or more games that won an AGS Award!
    •  
    • Monsieur OUXX worked on one or more games that was nominated for an AGS Award!
MonoAGS components system and FileSystem.
« on: 20 Mar 2019, 12:37 »
I'm fiddling with the ResourceSelector branch and I've noticed how FilesView has a private IFileSystem. It's supposed to be populated by FileView's constructor : FilesView(IFileSystem files, ...).
However I can't seem to understand where and how this constructor gets called. Is it with _filesView = rightPanel.AddComponent<FilesView>();?

The reason why I want to know this is because I want to know how the FileSystem is decided. In the master branch, the Resources system has stuff like this :
game.Factory.Resources.ResourcePacks.Add(new ResourcePack(new FileSystemResourcePack(AGSGame.Device.FileSystem, AGSGame.Device.Assemblies.EntryAssembly), 0));
There, the FileSystem is passed explicitly. It's done twice: One for the mobile file system, and one for the Desktop file system.

But then how does it work with FilesView? Why and how is the FileSystem chosen implicitly there?
 

tzachs

  • Local Moderator
  • Parking Goat- games that goats like!
    • I can help with translating
    • tzachs worked on one or more games that won an AGS Award!
    •  
    • tzachs worked on one or more games that was nominated for an AGS Award!
Re: MonoAGS components system and FileSystem.
« Reply #1 on: 20 Mar 2019, 13:18 »
When you call AddComponent<> the engine uses the Resolver class to resolve all the dependencies that the component has in its constructor.
The resolver itself it is tied to the device's file system by default. You can, however, override it with your own file system implementation if you want. To do that, you'll create your own implementation of the IFileSystem interface and then tell the resolver to use your implementation instead. Here's an example of how you'd do something like that.

If you want, you can also create the component yourself and pass a file system explicitly, and then call AddComponent with your component:
Code: C#
  1. var view = new FilesView(AGSGame.Device.FileSystem, ...);
  2. _filesView = rightPanel.AddComponent(view);

p.s The files view is not a complete implementation (I stopped mid-development as I started questioning some design choices I made- so this goes to the back-burner until I figure out what's the next step for the editor).

It's done twice: One for the mobile file system, and one for the Desktop file system.
Not sure what you mean here. The file system is passed once afaik.

Monsieur OUXX

  • Mittens Half Initiate
    • I can help with proof reading
    • I can help with translating
    • I can help with voice acting
    • Monsieur OUXX worked on one or more games that won an AGS Award!
    •  
    • Monsieur OUXX worked on one or more games that was nominated for an AGS Award!
Re: MonoAGS components system and FileSystem.
« Reply #2 on: 21 Mar 2019, 08:33 »
It's done twice: One for the mobile file system, and one for the Desktop file system.
Not sure what you mean here. The file system is passed once afaik.

game.Factory.Resources.ResourcePacks.Ad d(new ResourcePack(new FileSystemResourcePack(AGSGame.Device.FileSystem, AGSGame.Device.Assemblies.EntryAssembly), 0));
game.Factory.Resources.ResourcePacks.Ad d(new ResourcePack(new EmbeddedResourcesPack(AGSGame.Device.Assemblies.EntryAssembly, CustomAssemblyName), 1));
 

tzachs

  • Local Moderator
  • Parking Goat- games that goats like!
    • I can help with translating
    • tzachs worked on one or more games that won an AGS Award!
    •  
    • tzachs worked on one or more games that was nominated for an AGS Award!
Re: MonoAGS components system and FileSystem.
« Reply #3 on: 21 Mar 2019, 18:34 »
Ah, well, that's not "one for mobile, one for desktop". That's one for loading from the file system and one for loading resources embedded in the project (which is not necessarily for mobile -> most developers would probably prefer to embed their assets on desktop too, so they won't need to distribute all of their assets in separate files).

Re: MonoAGS components system and FileSystem.
« Reply #4 on: 25 Mar 2019, 19:58 »
most developers would probably prefer to embed their assets on desktop too, so they won't need to distribute all of their assets in separate files.

In regards to AGS developers were constantly complaining that they have to distribute it as one big file, because it forces users to redownload gygabytes of data to fix 1 bug.

(On other hand AGS supports reading smaller files from disk, but they ignore this for years, so idk.)

If there were a tool for automated repacking of the embedded main file that could solve the issue partially (not sure if that would work with Steam's auto updates).
« Last Edit: 25 Mar 2019, 20:03 by Crimson Wizard »

Re: MonoAGS components system and FileSystem.
« Reply #5 on: 25 Mar 2019, 21:17 »
Steam supports binary patching, so it usually can make the downloads works with one big file, providing it has some logic - my experience with ags is the diff is rarely big, a new room hits 3 MB and not 900 MB when updating... But for other systems, if something needs to be updated, they DON'T support binary patching, so separate files are preferable.

tzachs

  • Local Moderator
  • Parking Goat- games that goats like!
    • I can help with translating
    • tzachs worked on one or more games that won an AGS Award!
    •  
    • tzachs worked on one or more games that was nominated for an AGS Award!
Re: MonoAGS components system and FileSystem.
« Reply #6 on: 26 Mar 2019, 13:20 »
In regards to AGS developers were constantly complaining that they have to distribute it as one big file, because it forces users to redownload gygabytes of data to fix 1 bug.

Fair, though I was actually talking about the difference between having the assets embedded in something (be it the executable, or "asset pack files") and just distributing all of the assets in their unchanged forms (i.e having your bg.png appear as bg.png in the distributed folder) so that users have the ability to change the background image of your game (for example). I imagine most developers would not want that, though it might be appealing to a few (to allow for very simple "modding").