Messages

I'm currently dabbling in this area, so I'll have a look at this.
Based on a quick look at the logs provided though, it looks more like the itch.io client has an issue with spaces in the path.

[2018-09-05 @ 23:11:34.768] [launch/native] err: /home/fabrizio/Games/Itch/Tales From The Outer Zone Cyborg Seppuku/CYBORG SEPPUKU v0.6/Linux/CyborgSeppuku: line 12: /home/fabrizio/Games/Itch/Tales
[2018-09-05 @ 23:11:34.768] [launch/native] err: /home/fabrizio/Games/Itch/Tales From The Outer Zone Cyborg Seppuku/CYBORG SEPPUKU v0.6/Linux/From
[2018-09-05 @ 23:11:34.769] [launch/native] err: /home/fabrizio/Games/Itch/Tales From The Outer Zone Cyborg Seppuku/CYBORG SEPPUKU v0.6/Linux/The
[2018-09-05 @ 23:11:34.769] [launch/native] err: /home/fabrizio/Games/Itch/Tales From The Outer Zone Cyborg Seppuku/CYBORG SEPPUKU v0.6/Linux/Outer
[2018-09-05 @ 23:11:34.769] [launch/native] err: /home/fabrizio/Games/Itch/Tales From The Outer Zone Cyborg Seppuku/CYBORG SEPPUKU v0.6/Linux/Zone
[2018-09-05 @ 23:11:34.769] [launch/native] err: /home/fabrizio/Games/Itch/Tales From The Outer Zone Cyborg Seppuku/CYBORG SEPPUKU v0.6/Linux/Cyborg
[2018-09-05 @ 23:11:34.769] [launch/native] err: /home/fabrizio/Games/Itch/Tales From The Outer Zone Cyborg Seppuku/CYBORG SEPPUKU v0.6/Linux/data/ags64: No such file or directory

I upload my browser history and computer usage directly to 4chan.
This enables me to use any web browser, with the choice based solely on the merits of each.

[Game]

I'm currently trying to make something to use in-place of winsetup (specifically for Linux or Mac releases which get uploaded to places such as itch.io), so I'm interested to have a look at how their launcher works. I'm not really following your table though.

Game	Dev	OS	spawn icacls Error code
CYBORG SEPPUKU	The Outer Zone	Linux	?

Are you saying that CYBORG SEPPUKU doesn't work? You won't have icacls on anything that isn't Windows, so have they got something named icacls return errors on all platforms, or does it just fail with no clues as to what happened?

Thanks for testing!

I think this can probably be raised as a bug (unintended behaviour), if clicking on an inventory item does nothing and clicking on buttons does something.

Did you install the additions pack and do this?

For the basic Direct3D acceleration to work in a Windows guest, you have to install the WDDM video driver available for Windows Vista or higher

https://www.virtualbox.org/manual/ch04.html#additions-windows

I can give it a try over the next day or two...

Am I correct guessing that this will substitute the unsigned AGS.Types demanded by plugin with signed one?

Yes, to test this I made the relevant section of PluginsComponents.cs look like this:

Code: csharp

Assembly CurrentDomain_AssemblyResolve(object sender, ResolveEventArgs args)
{
    AssemblyName assembly = new AssemblyName(args.Name);

    if (assembly.Name == "AGS.Types")
    {
        return typeof(BuildTargetsInfo).Assembly;
    }

    return null;
}
    
private void LoadEditorPluginIntoMemory(string fileName)
{
    AppDomain.CurrentDomain.AssemblyResolve += new ResolveEventHandler(CurrentDomain_AssemblyResolve);

    try
    {
        EditorPlugin plugin = new EditorPlugin(fileName, _pluginEditorController);
        _editorPlugins.Add(plugin);
    }
    catch (AGSEditorException ex)
    {
        _guiController.ShowMessage("There was an error loading plugin '" + fileName + "'." + Environment.NewLine + Environment.NewLine + ex.Message, MessageBoxIcon.Warning);
    }
    catch (Exception ex)
    {
        _guiController.ShowMessage("There was an error loading plugin '" + fileName + "'." + Environment.NewLine + Environment.NewLine + ex.ToString(), MessageBoxIcon.Warning);
    }
}

So rather than be an exception you get the chance to load something else, and in this example the only check performed is the name of the requested assembly. What is returned is the Assembly reference for the actual AGS.Types that was built (in this case, the one that is strongnamed).

There is probably a better way to reference the assembly directly, but this:

Code: csharp

return typeof(BuildTargetsInfo).Assembly

just returns the Assembly instance of AGS.Types (the strongnamed one), because that is the assembly where BuildTargetsInfo is located.

Could you also elaborate a little on this, what changes to plugin system will be determined by this (or how)? Just want to be sure that I understand the situation well.

The main restriction is that a strongnamed assembly cannot reference (i.e. build against) an assembly that isn't strongnamed (this is requested as a 'full' bind), but using Assembly.LoadFile is treated differently (this is requested as a 'partial' bind). The loading assembly is permitted to modify the loading behaviour since the code for this is in the signed part (so the handling is in the Editor, not in the plug-in).

I guess the main thing is, at the moment there isn't really any separation of plug-in and Editor, since there is no piece in-between to broker what is available in the Editor and what is requested in the plug-in. I don't know if anyone had plans to change it, but if it would stop using Assembly.LoadFile then however the separation is implemented would also have to be happy with plug-ins requesting signed and unsigned assemblies. I would imagine such a system would probably be more likely to declare and require interfaces rather than assemblies though.

Equally, this probably needs testing with the most complex plug-ins people can find. At the moment I've only started up these two plug-ins for testing, but I've not built anything for Android or actually edited a font.

It looks fairly easy to just redirect a failed load attempt of an assembly which had a null key, to the version which has a key. I defined this event handler:

Code: csharp

Assembly CurrentDomain_AssemblyResolve(object sender, ResolveEventArgs args)
{
    AssemblyName assembly = new AssemblyName(args.Name);

    if (assembly.Name == "AGS.Types")
    {
        return typeof(BuildTargetsInfo).Assembly;
    }

    return null;
}

Then registered it just before the plug-in is loaded:

Code: csharp

AppDomain.CurrentDomain.AssemblyResolve += new ResolveEventHandler(CurrentDomain_AssemblyResolve);

...and monkey's Android builder and Rulaman's font editor seemed to work fine. You can use stricter checks, like checking requested versions and keys, but there seems to be no requirement for the plug-in itself to be signed. Maybe it is best to open an issue on GitHub, since future changes to the plug-in system are probably determined by the choice made here. The restrictions seem to only impact the assemblies directly referenced to build the Editor, rather than ones that it loads dynamically.

I think as long as there is no forked version, or alternate builds (like Alan's) which could then isolate itself with another set of keys, they isn't much additional benefit other than the settings paths managing themselves. '.NET 4.5' was either for the signed irrKlang or the NuGet package that is basically a simplified LocalFileSettingsProvider, so easiest solution is to remove the signing and add the NuGet package. Maybe it is preferable to use the built in serializer instead though?

Signing the plugin will not solve the issue. The problem is that the plugin was compiled with a reference to an AGS.Types assembly that didn't have a strong name. With AGS.Types now having a strong name it is not backwards compatible with previous versions. When AGS tries to load the plugin, it can't since the plugin is missing one of the references.
So indeed the consequence is that all plugins will need to be recompiled with the new library reference.

Do you also see an issue referencing a specific version of irrKlang? It looks like there are some options to redirect reference loading, but with (what I think is) the newest version of the SpeechCenter plugin the first error I get is trying to load irrKlang rather than AGS.Types.

Just to confirm, is this the latest version?

Found one here:
http://www.adventuregamestudio.co.uk/AGS.Plugin.Sample.zip

...although I haven't tried it yet.

Alright, this looks like another consequence that was not thought of beforehand. There is a number of editor plugins, Speech Center is one of the most popular ones, and there is at least one other I know - Rulaman's Font Editor. Does this means we need plugin author to come by and recompile the plugin? (idk what are other editor plugins in use)
From now on writing editor plugin was relatively simple, now if someone does that will have to know to do this signing too. And also, does not this mean that there should be two version of each plugin from now on - for old Editor and for the new one?

I think the main restriction is that a signed assembly cannot load an unsigned one, although to permit access to internals for the unit tests I had permit access via the public key. For an external interface though, I would need to test it. Is there a plugin stub somewhere that I can test with? We could look at using something else though, the main benefit of this was that it was built-in, so for a Mono build it was likely to be well tested.

May there be an alternate solution to signing, like using some third-party settings library instead of Microsoft's one?
I remember you've mentioned this library, will it work without strongname? The strongname issue is mentioned in its readme, but it's not stated explicitly.

I think the problems are generally in terms of deployment, where the program is delivered using ClickOnce and installed per user. In that case you do end up with multiple installations, so using a strongname would override where the settings are loaded from. So the main purpose of the library is to just override the settings path (manually), so that you can store settings where you like.

It was to get a namespace for the settings class, to differentiate between builds which are (effectively) portable and the actually releases where settings need to persist between versions. As long as the plug-in isn't mixed assembly, you can retrospectively sign it by decompiling and recompiling with a generated key.

Ah right, it probably does end up being dependent on the template, and possible whether your buttons are square, as to which setting would be best. I guess this setting would make a lot more sense being per GUI or per GUIControl, rather than setting it globally. You could also argue the opposite, that it if defaulted to not greying out the controls, beginners wouldn't know there was an option to grey out the controls.

A possibly related issue, I imagine the original design of the settings panel was meant to be highlighting the choice in a bold font where the chosen value was not the default, and use a regular font when the chosen setting was the default. At the moment I think what have become the defaults are sometime highlighted in bold, so it does look a little strange (like settings have already been modified).

The problem is, a lot of the previous scripts were relying on the blocking behaviour of the GUI to operate.

Newer templates are here:
https://github.com/adventuregamestudio/ags-template-source

I think it is addressed in, at least some of them.

When I checked recently, I think there was an extra file present which looked like it had some extra index data in it. It does work at the moment when the script keyword matches an index name, so any issues could be just the lack of indexing, or the missing of the extra file.

I think eri0o has already set it up so that built html and chm file have a release tag, and I think the wiki repository can also have a tag.

The names are what came out of the conversion (probably where the original content didn't have something considered to be a title). Some of them are wrong, but links including those names were used everywhere. It is cleaned up a lot now, so renaming is possible but I think you then lose the edit history.

This one?
https://www.youtube.com/watch?v=5crT0mNIrEw