Hello, plugin developers.
AGS 3.0 beta 13 includes the first draft of the .NET Editor Plugin API, so I wanted to talk briefly about how it works.
The first thing to note is that run-time plugins (ie. plugins that need to be distributed with the game) have not changed, and 3.0 still supports them under the same plain DLL API that it always has done.
What is new are editor-only plugins. AGS 2.7 did support these using COM, but it didn't work very well and I don't think any of these plugins were successfully written.
AGS 3.0 removes support for this COM approach, and instead has a .NET-based plugin API for writing editor-only plugins.
What's an editor-only plugin? Well, it's something that enhances the editor functionality (eg. a new dialog editor, automatic script generator, etc) but doesn't change the run-time behaviour of the game and therefore your plugin doesn't need to be distributed with the game (which also means it doesn't make the game Windows-only).
I haven't yet written any documentation for the new API (this will be forthcoming), and currently it is fairly limited. This thread is for your feedback about what you want the API to be able to do, so that I can design it to provide useful features for plugin writers.
Instead of documentation for the time being there is this sample plugin:
http://www.adventuregamestudio.co.uk/AGS.Plugin.Sample.zip
This needs Visual Studio 2005 to compile. If you don't own that, there is the free Visual C# 2005 Express (http://msdn2.microsoft.com/en-us/express/aa700756.aspx) which you can download from Microsoft and should be able to create plugins (can someone let me know if this works).
When you load the sample project, check the Reference to "AGS.Types.dll". If it's broken, remove the reference and add it back, pointing to the AGS.Types.dll file in your AGS 3.0 beta 13 folder.
AGS detects these plugins by looking for files "AGS.Plugin.*.dll" in the editor folder when it starts up. The sample plugin above adds its own project tree entry and main menu item, so that you can get a feel for how the basics work.
At the moment you can't access any of the game data, so part of my question is what you want to be able to access and in what way you might want to change things from a plugin.
Feedback welcome.
Things people might want as plugins:
Sprite Editor: access to sprites
Speech/Music/Media manager (think someone tried this for the old COM plugin API)
Visual Express C# seemed to work for me, but it does keep complaining about not being able to copy dome file to Debug...
I played around with this a bit, and aside from being able to redesign how dialogs work in the editor and SSH's suggestions I can't really think of anything else right now that would be useful to alter/add to the editor. Perhaps the ability to edit the room tools so you can add additional tool types aside from circle and line draw would be nice. Most of my other ideas would require the ability to create engine functions to go with the editor additions (like new gui tools) but this is still a nice idea.
I get the same error, although the DLL still builds fine:
QuoteError 1 The command "copy D:\SupFiles\Visual Studio Projects\AGS.Plugin.Sample\bin\Release\AGS.Plugin.Sample.dll D:\SupFiles\Visual Studio Projects\AGS.Plugin.Sample\netedit\bin\Debug" exited with code 1. AGS.Plugin.Sample
Nice work, always been a fan of C#. :)
Well I'm planning on writing a simpler script editor, so I suppose access to scripts and any game script-o-names (for objects, characters, dialogs, etc.)
Someone might knock up some kind of awesome dialog editor too.
Oh heh sorry, I left a post build event that I'd been using to test it. Just remove the post build event from the project and that should stop the error.
Thanks for your feedback so far, guys.
thinking back, something a lot of people have asked for is the ability to zoom in on a background when placing objects and drawing walkables/behinds/hotspots/regions. I will never have the skill to write a plugin but the people that do, if you're looking for a suggestion from the various masses through time... There's one!
Is there any possibility of being able to write AGS editor plugins in AGS, or is that too wacky?
On a related note, it would be nice if we could see command-line options and manipulate the global copy/paste buffer in AGS, too!
Quote from: Pumaman on Sun 07/10/2007 18:11:17
At the moment you can't access any of the game data, so part of my question is what you want to be able to access and in what way you might want to change things from a plugin.
I'm working on an audio file manager plugin (AGS.Plugin.AudioManager.dll (http://ueberlicht.googlepages.com/AGS.Plugin.AudioManager.dll)), so it would be nice to have access to:
1)
The name of the game folder.
(As a workaround, the plugin reads the registry key "RecentPath0".)
2)
The script name of the characters.
(It gets the names from "Game.agf", which of course isn't updated when the user changes the name/adds a character)
3)
The script files.
(For some kind of "Search usage of file in script" feature.)
QuoteOn a related note, it would be nice if we could see command-line options and manipulate the global copy/paste buffer in AGS, too!
This is more an engine plugin than editor plugin request, but what would you want to put/get from there? Text? Images?
QuoteI'm working on an audio file manager plugin (AGS.Plugin.AudioManager.dll), so it would be nice to have access to:
Looks good, those should be easy enough to implement.
Quote from: Pumaman on Sun 07/10/2007 18:11:17
At the moment you can't access any of the game data, so part of my question is what you want to be able to access and in what way you might want to change things from a plugin.
I would vote for dialog data structures, so an import/export dialog plugin could be developed. As a matter of fact, it wouldn't hurt to have access to these structures at runtime too. ;D
Direct access to the dialogs in game would be interesting, though I'd much rather see a dialog creation overhaul at the moment so you can just write dialogs as you would any other script and make calls to other functions and such without run-script.
This might not be the right place, it's more of an engine plug-in. I'd like to see the AGS engine be able to use internet connectivity. For example, if the player gives the game permission to look through their hotmail contacts list by supplying the necessary email and password info, the game extracts the the contact info and puts in names of the contacts as characters in the game or in dialog responses.
Quote from: Reid on Mon 29/10/2007 00:56:49
I'd like to see the AGS engine be able to use internet connectivity. For example, if the player gives the game permission to look through their hotmail contacts list by supplying the necessary email and password info, the game extracts the the contact info and puts in names of the contacts as characters in the game or in dialog responses.
This is a very specific feature, thus it should not be in the engine, but on a plugin. There are many libraries to do that, you should look up on the internet for them.
[
Update] As a sidenote, you should create a new thread requesting some help with this... maybe someone has already done some research in this area... it is an interesting feature, I would definitely find it very useful.
There was a TCP/IP plugin created but I don't think it was ever properly finished.
It would be perfectly possible to create a plugin with internet connectivity if you had some C++ knowledge and were so inclined.
As CJ said, you can use the
TCP/IP Plugin (http://www.adventuregamestudio.co.uk/yabb/index.php?topic=4343.0), in this case I recommend
this page (http://www.hypothetic.org/docs/msn/index.php). I guess the best approach would be to
write a module (http://www.adventuregamestudio.co.uk/yabb/index.php?topic=26283.0) based on the TCP/IP Plugin.
On a second thought, the engine itself could provide simple TCP/IP commands, like the ones in the TCP/IP plugin, thus paving the way to many modules (hi-score posting/fetching, login, remote savegames, Msn-awareness, etc).
QuoteThere was a TCP/IP plugin created but I don't think it was ever properly finished.
One more reason for the 'engine' approach. The others are: CJ's support and documentation... :) And, of course, last but not least, multiplatform-ness...
TCP/IP support can also lead to very nasty things if not watched carefully though, I think having it as a plugin is better.
I don't think that network connectivity is something that should be considered a "core feature" for the engine to support. Also, there's a lot of things on my to-do list and even if I thought it was a good idea, it's really not going to get a high priority.
Having someone else write and support it as a plugin has a better chance of it coming to fruition.
Quote from: smiley on Mon 22/10/2007 14:29:59
I'm working on an audio file manager plugin (AGS.Plugin.AudioManager.dll (http://ueberlicht.googlepages.com/AGS.Plugin.AudioManager.dll)), so it would be nice to have access to:
Beta 15 exposes a new "CurrentGame" property on the IAGSEditor interface which should give you access to all of this. Please note that you do have write access to all properties, but be careful if you start changing things; I'd recommend using the game data in a read-only fashion.
Thanks a lot! Works fine so far.
Very nice. :) Though I have a question. Is there a way to edit the built-in context menus? Currently my simple script editor uses as OpenDialog for the user to select the script he wants to edit. I was thinking if I could have my plugin add a new option to the right-click menu for scripts to open up the respective script in the Simple Script Editor, it'd be a lot simpler for the user.
Here's a WIP of what I currently have:
(http://i6.photobucket.com/albums/y237/supsuper/AGS/simplescript.jpg)
Looks good! I'll see if I can add some method of intercepting context menu creation.
Could you open up the possibility to extend existing classes (like Sprite, for example) so we could put in additional properties in the editor? I'd like to add a Name property to Sprite that would store (by default) the filename of the sprite loaded (or in the case of already compiled sprite folders it would just rename them something like sprite1, sprite2 incrementally) and display Name instead of the Number property in the manager. Then you could re-organize the sprites by names like bill_walk1, bill_walk2, etc. The ability to edit existing parts of the editor would also be useful, since I could simply edit the sprite manager slightly to add some right-click functionality (rename/sort by). None of this would touch the sprite numbers so it shouldn't break any of the engine code. Otherwise I'd have to reproduce the sprite manager from scratch (which would be redundant). Thanks!
This is fantastic! Bravo!
Paul.
Quote from: ProgZmax on Thu 06/12/2007 23:41:55
Could you open up the possibility to extend existing classes (like Sprite, for example) so we could put in additional properties in the editor?
This is actually quite awkward to implement, but I'll have a think about how it could be done.
Is there any way I can get some kind of AGS script reference (objects/functions/properties/enums/etc.) in some easy-to-process format? (text/xml/etc.)
I was writing my own from scratch for my Simple Script plugin but then noticed AGS.Types seems to have a lot of classes for this kind of stuff so I was wondering if I could avoid all this extra work.
Well, the Script class has an AutoCompleteData property, which stores all the information that autocomplete has cached about the script. I guess it depends whether the information you need is the same as that, or not.
The only other option would be to use the built-in script header file and parse that yourself, but that would probably be duplicating a lot of work.
Quote from: Pumaman on Sat 08/12/2007 21:59:00
Well, the Script class has an AutoCompleteData property, which stores all the information that autocomplete has cached about the script. I guess it depends whether the information you need is the same as that, or not.
Wow, that's very handy, thanks. :)
Is there something similar for AGS' built-in stuff?
There is a Script object representing the built-in stuff, but I don't think it's exposed on the plugin API at the moment. I'll look into it.
I'm working on adding the possibility for the user to refer to the audio files in the script by a name instead of a number. The plugin currently adds a new script whose header contains an enum declaration. But to make the enums effect all the user's scripts this header has to be the topmost.
So it would be nice if there's a way to make it stay at the top when the user adds a new script or changes the order.
Ah yeah, in fact what I'd like to do is something similar to the Native Plugin API whereby the plugin can add extra hidden script headers that the user can't see and that always get compiled before the user scripts.
That sounds cool! Is this coming in the next release?
I would find it very usefull.
Cheers,
Paul.