For the C# experts. I need help with some items in the Editor

[Joseph DiPerla]

Ok, so I am looking to include a way to compile the AGS game into an Android Package. The basic files to do this on the Java side are already set. I just need to include it in the editor really. Understand, I am still learning C# and the AGS Editor is just so beyond me at the moment. I know how to do what I need to do, but there are still some unanswered items for me. So my questions are these:

1) How and where would I add a menu item to compile the game into an APK? I know there is an AddMenu Function. But thats about all I know.
2) In the editor, once I set up how do I call the function I want to perform when the user clicks on the menu item?
3) How do I get the directory where the game is compiled? By calling AGSEditor.OUTPUT_DIRECTORY?

From everything else, I think I can manage Thanks.

[Crimson Wizard]

1) How and where would I add a menu item to compile the game into an APK? I know there is an AddMenu Function. But thats about all I know.

No, not like that. Better: Build for platform option with selection for Linux, etc. And also an option to Build stand-alone game data only (without EXE)!

[Crimson Wizard]

I just realized this is in wrong subforum . It should be moved it Editor development.
Then, may someone help Joseph please? Tzachs? Alan? Anyone else?
I could check editor code too, but that may take some time, 'cause I almost haven't investigated it yet.

[Calin Leafshade]

The engine is separated into 'Components'. Really the best way forward would maybe be to create a whole new Deployment Component where one could tweak the settings for the compiling and deployment of their game. At the moment the compiling is a very ad hoc affair with just a CompilePlox() kind of function. That would need to be refactored out into something more flexible given the advent of all these newfangled ports.

So really you need to create a new subclass of BaseComponent and add that to the AppController on launch. This component would compile the game data to a cross-platform .ags file but not combine it with any binaries. *Then* the component should initiate some kind of process that combines the data file with whatever binaries/packages the user has requested. You should also keep the "quick compile" mode that ags has that only compiles the scripts and sources data from the filesystem.

The AGS Editor is very nicely made and very modular so doing this would be relatively easy but given the questions you were asking I would say that you are probably not ready to make changes to the editor in a clean and well-structured manner. However feel free to give it a go!

[Crimson Wizard]

The engine is separated into 'Components'. Really the best way forward would maybe be to create a whole new Deployment Component where one could tweak the settings for the compiling and deployment of their game. At the moment the compiling is a very ad hoc affair with just a CompilePlox() kind of function. That would need to be refactored out into something more flexible given the advent of all these newfangled ports.

I just wanted to note, that the game data compilation (compiling scripts, packing) should not really depend on target platform. Only difference is in what add with the data file. The Windows executable should not be attached to it, on first place.
I don't remember how well these operations are divided, by probability is high that these are two different functions. Otherwise, they should be split into two separate tasks 1) making game data file (same for all platforms) 2) adding platform-specific files (executable and whatnot) and packaging into APK or whatever.


EDIT: Hmm, it appears I wrote almost same thing as Calin did. Probably was dreaming on something .

[Crimson Wizard]

I sort of see the way to do this in a "hacky" way, which should not take much time, if time is what your priority is.
Although I totally agree with Calin on writing things in a structured manner.

1. BuildCommandsComponent is an entry point for accepting user selection. It is simple to add new menu item there. Then add event handling to CommandClick() method.
2. I started my experiment with adding a new boolean parameter to CompileGame() method, namely "attachEXE". It is passed further into AGSEditor::CompileGame() and CreateCompiledFiles().
3. There I just skip everything exe-related if the "attachEXE" is not set, first priority is to disable this line:

Code: C#

File.Copy(sourceEXE, newExeName, true);

This will prevent copying acwin.exe to the compilation folder before the compilation (if it is copied, then all game data will get appended to it).
This line starts compilation process:

Code: C#

BusyDialog.Show("Please wait while your game is created...", new BusyDialog.ProcessingHandler(CreateCompiledFiles), forceRebuild);

CreateCompiledFiles() is a function that will be called from "process" window (it is another CreateCompiledFiles). It first calls NativeProxy.CompileGameToDTAFile(), which makes backbone game file, then NativeProxy.CreateGameEXE, which gathers all the files into a package.
4. The actual compilation takes place in AGS.Native library, namely make_data_file() (in agsnative.cpp). Your first intention could be to disable makeFileNameAssumptionsForEXE boolean argument, but it does not seem to do actual exe attachment (this is done prior to this function). Instead, it defines the overall compilation logic, so it is probably better to have it TRUE.
I think if you pass "attachEXE" parameter here, you may choose proper file extension depending on its value (like "ags, instead of "exe").
5. After the process returns to CreateCompiledFiles(), it makes Windows setup program, which you may want to skip too (depending on "attachEXE" flag):

Code: C#

CreateCompiledSetupProgram();

This should result in having a game *.ags created in Compiled folder, with Windows binary not included.

It is also interesting to notice ExtraCompilationStep and ExtraOutputCreationStep delegates, which are called after standard compilation and after all standard files are built, respectively. I think it is pretty valid to add your own packaging & deployment handlers to these.