Show Posts

You can view here all posts made by this member. Note that you can only see posts made in areas to which you currently have access.

Messages - morganw

Pages: [1] 2 3 ... 16
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?
Quote from: instructions
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

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: C#
  1. Assembly CurrentDomain_AssemblyResolve(object sender, ResolveEventArgs args)
  2. {
  3.     AssemblyName assembly = new AssemblyName(args.Name);
  5.     if (assembly.Name == "AGS.Types")
  6.     {
  7.         return typeof(BuildTargetsInfo).Assembly;
  8.     }
  10.     return null;
  11. }
  13. private void LoadEditorPluginIntoMemory(string fileName)
  14. {
  15.     AppDomain.CurrentDomain.AssemblyResolve += new ResolveEventHandler(CurrentDomain_AssemblyResolve);
  17.     try
  18.     {
  19.         EditorPlugin plugin = new EditorPlugin(fileName, _pluginEditorController);
  20.         _editorPlugins.Add(plugin);
  21.     }
  22.     catch (AGSEditorException ex)
  23.     {
  24.         _guiController.ShowMessage("There was an error loading plugin '" + fileName + "'." + Environment.NewLine + Environment.NewLine + ex.Message, MessageBoxIcon.Warning);
  25.     }
  26.     catch (Exception ex)
  27.     {
  28.         _guiController.ShowMessage("There was an error loading plugin '" + fileName + "'." + Environment.NewLine + Environment.NewLine + ex.ToString(), MessageBoxIcon.Warning);
  29.     }
  30. }

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: C#
  1. 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: C#
  1. Assembly CurrentDomain_AssemblyResolve(object sender, ResolveEventArgs args)
  2. {
  3.     AssemblyName assembly = new AssemblyName(args.Name);
  5.     if (assembly.Name == "AGS.Types")
  6.     {
  7.         return typeof(BuildTargetsInfo).Assembly;
  8.     }
  10.     return null;
  11. }

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

Code: C#
  1. 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:

...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:

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

Editor Development / Re: Help file... here we go again.
« on: 30 Aug 2018, 17:07 »
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.

Editor Development / Re: Help file... here we go again.
« on: 29 Aug 2018, 23:30 »
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.

Yes, but I wondered if this could cover both cases, as long as any available script functions to restore the state were still available in a newer engine version. So the data version is just the script version, and you drop support support for loading an old restoration script in the same way that legacy functions are phased out (script version strictness).

Just an idea though (and possibly a bad one).


Escoria has an interesting approach, where the save game file contains the script commands to restore you to your current point in the game. Potentially, could the 'cutscene' functionality be used to jump through a script if there are checkpoints set?

Perhaps this explains what I saw, when the file was still being written whilst the engine was trying to open it. It might be the attempt to create a hardlink is triggering a copy as a fallback, but it isn't a blocking operation.

I think there was a suggestion of rebranding 3.4.2+ as 3.5 anyway, just because of the level of change?
Release version is on .NET 2.0, and 3.4.2 is currently on .NET 4.0, so it has already been upgraded.

The usage numbers for XP were actually much lower than I was expecting, so I'd vote to drop it.

Pages: [1] 2 3 ... 16