AGSEditor: New features (Source code now available)

[Calin Leafshade]

works fine with ankhsvn in Visual Studio.

[Pumaman]

Thanks for checking, guys.

I'm currently reviewing and merging the latest code into my trunk; there are a couple of things I need to refactor (for example, you can't add new methods to the IEditorComponent interface, because it breaks compatibility with plugins; also, the new GlobalGame class in the AGS.Types assembly isn't really the right thing to do). Anyway, I'll fix these things and put the final code into SVN in a couple of days when I'm done.

Any plans for when the engine release is to be added?

The engine code is much more complicated because it has dependencies on various statically linked libraries, so I need to sit down and spend some time sorting it out so that it can be compiled easily on other machines. That's not my top priority at the moment, I'll take a look at it in a few weeks once we have this editor development process sorted.

[Calin Leafshade]

The new GlobalGame class in the AGS.Types assembly isn't really the right thing to do

I did think this was a rather bad idea and made little sense from an OO perspective.

You can't add new methods to the IEditorComponent interface, because it breaks compatibility with plugins

I think that was tzach for the find/replace.
How would one add things to an interface then? If you need to expand functionality without breaking compatibility with older plugins?

[Knox]

Even though I havent contributed much to the AGS community up to date (mostly asking questions ) I would like to say that this is SO encouraging + exciting that a few good guys are working on the editor + new engine features (in the long run now that the engine might become open source)...anyways, just wanted to say a big thanks to you guys! Really awesome...

[Shane 'ProgZmax' Stevens]

So does this mean we need to get 2008 express if we want to continue contributing edits, CJ?  At this point I'm pretty satisfied with my additions and can't think of anything I'd add except, perhaps, folder support for characters and rooms which I'm sure anyone could do in a pinch, or maybe ellipsis shape support for the room edit drawing tools.  Basically, there just isn't a whole lot I feel needs improvement from my perspective to the editor.

[Pumaman]

Ok, I have merged the code, done some refactoring, and checked the result into SVN.

Can you guys please get the latest version and make sure it still builds for you, and test that the new stuff still works correctly?
Assuming that it does, I'll do a proper build of this code and release it as 3.2.1 Beta 1.

Comments on the code changes

I haven't had as much time to review the changes as I'd have liked, but just a few general comments to bear in mind for future changes:
* Please avoid making changes which are purely personal preference. For example, someone changed some of the fonts and colours in the script editor; please remember that AGS is used by 3000 people who are used to the current editor and change may be confusing. In this example, a proper solution would be to add a GUI to the editor to allow everybody to customize the script editor to their own preferences.
* Please maintain consistency with the existing code. While you personally may prefer "GuiGroup" to "GUIGroup", the existing code has "GUIControl", "GUIButton" etc so let's keep it consistent.
* If you are making a change that is complex and aren't sure of the best way to do something, please just ask on the forum here! Any changes which are 'architectural' in nature can be discussed and we can agree the best way to do something. It'll avoid having to refactor things later on.

Once again, thanks guys for all your hard work in adding these initial changes, and please don't take any of my comments as criticism; we're just starting out with open source AGS so we need to discover the best ways of working together.

How would one add things to an interface then? If you need to expand functionality without breaking compatibility with older plugins?

Interfaces which are only used by plugins can have new methods added to them no problem. It's only interfaces which are implemented by plugins (of which I think IEditorComponent is in fact the only one) that can't be changed, because the plugin class has to match the interface exactly.

In this case an alternative solution was to use an event (which I have done), alternatively you could add a second interface with the new methods on it.

So does this mean we need to get 2008 express if we want to continue contributing edits, CJ?

That would be best, yes. You can still use VC#2010 but would have to be careful when commiting changes, that you didn't check in a VS2010 version of the project file.

[Calin Leafshade]

Exception:

Code: ags

System.Collections.Generic.KeyNotFoundException was unhandled by user code
  Message=The given key was not present in the dictionary.
  Source=mscorlib
  StackTrace:
       at System.ThrowHelper.ThrowKeyNotFoundException()
       at System.Collections.Generic.Dictionary`2.get_Item(TKey key)
       at AGS.Types.BaseListSelectTypeConverter`1.ConvertTo(ITypeDescriptorContext context, CultureInfo culture, Object value, Type destinationType) in C:\Users\Steve\Documents\ags\trunk\Editor\AGS.Types\PropertyGridExtras\BaseListSelectTypeConverter.cs:line 73
       at System.ComponentModel.TypeConverter.ConvertToString(ITypeDescriptorContext context, Object value)
       at System.Windows.Forms.PropertyGridInternal.GridEntry.GetPropertyTextValue(Object value)
  InnerException: 

As far as I can tell it happens when the property grid tries to get a string value for room 0 for a character (should return none).
I'm not sure if this is specific to my game files and somehow a character got its room set to 0 somehow.

I fixed it by editing my games XML file but it might be an editor issue.

[tzachs]

It seems that the Replace/Replace All functionality is broken in this version (it works in my original version).
Replace in document now replaces the first line of the file always.
Replace all in document now freezes the application (and from a quick debugging session, it seems to replace the same line all over again endlessly).

The rest of the features I put in seem to be working fine.

* If you are making a change that is complex and aren't sure of the best way to do something, please just ask on the forum here! Any changes which are 'architectural' in nature can be discussed and we can agree the best way to do something. It'll avoid having to refactor things later on.

That's good to know, the reason that I didn't ask is because I remember you saying that the code is provided as is without any support, so I didn't want to bother you (and nobody else has enough knowledge of the code as of now, I'm sure this will improve in the future).

[Pumaman]

System.Collections.Generic.KeyNotFoundException was unhandled by user code
  Message=The given key was not present in the dictionary.

As far as I can tell it happens when the property grid tries to get a string value for room 0 for a character (should return none).
I'm not sure if this is specific to my game files and somehow a character got its room set to 0 somehow.

Actually this seems to be a pre-existing AGS 3.2 bug where it crashes if you delete/exclude a room that a character is set to start in. I've checked a fix in to SVN.

It seems that the Replace/Replace All functionality is broken in this version (it works in my original version).
Replace in document now replaces the first line of the file always.
Replace all in document now freezes the application (and from a quick debugging session, it seems to replace the same line all over again endlessly).

Thanks for testing, I've now checked in a fix for this.
Can you please get the latest and make sure it's now working ok; also I slightly changed the way the standard Replace works to be more consistent with how VS does it.

That's good to know, the reason that I didn't ask is because I remember you saying that the code is provided as is without any support, so I didn't want to bother you (and nobody else has enough knowledge of the code as of now, I'm sure this will improve in the future).

Well, it's not only me that can give feedback. Lately I've been quite bad at keeping up my appearances on this forum, but I'm confident that if I'm not around you guys can agree on the way to do things. In particular more experienced C# developers like yourself can provide guidance to less experienced C# devs which would be very useful.

Generally my opinion is that the most important thing is to keep consistency with the existing code. The editor architecture is not perfect by any means, but rather than everyone going off in different directions and adding bits in different ways, if we just keep within the patterns used in the existing code it'll be easier for everyone to follow.

Those of you that have contributed so far (is that just tzachs, Calin, progz?) can you please:
1. let me know under what name you'd like to be credited
2. post a quick list of your changes here so that I can assembly an accurate changelog

[Sslaxx]

Any plans for when the engine release is to be added?

The engine code is much more complicated because it has dependencies on various statically linked libraries, so I need to sit down and spend some time sorting it out so that it can be compiled easily on other machines. That's not my top priority at the moment, I'll take a look at it in a few weeks once we have this editor development process sorted.

Consider that id Software released the source code for the original Doom in an initially non-compilable state due to its use of proprietary libraries. It certainly did not stop people from getting it working, and there are people here who I am sure could get the code for the AGS runtime to work in a similar fashion (eventually, at least - I'd not doubt in the slightest it'd be hard going).

[tzachs]

Thanks for testing, I've now checked in a fix for this.
Can you please get the latest and make sure it's now working ok; also I slightly changed the way the standard Replace works to be more consistent with how VS does it.

Tested and the fix works.

Well, it's not only me that can give feedback. Lately I've been quite bad at keeping up my appearances on this forum, but I'm confident that if I'm not around you guys can agree on the way to do things. In particular more experienced C# developers like yourself can provide guidance to less experienced C# devs which would be very useful.

Generally my opinion is that the most important thing is to keep consistency with the existing code. The editor architecture is not perfect by any means, but rather than everyone going off in different directions and adding bits in different ways, if we just keep within the patterns used in the existing code it'll be easier for everyone to follow.

I totally agree.
My only gripe here, is that experience in c# is not enough. Every code base tells its own story and requires understanding of its inner structure & patterns, a thing which only you fully understands at this point of time.
The rest of us will get there too eventually, but for now I don't feel we're really equipped to give advice on how things are suppose to work and how classes are supposed to interact with each other, we can only give advice on the technical side.
It doesn't mean we won't try though, but you can count on us making a lot more mistakes in the near future that stem from not fully understanding the design.
Not much to do about it, then let time run its course (and maybe also what I mentioned earlier, of doing a study of the code and writing some help documents with class diagrams etc).

I actually do have another somewhat related question, what are your feelings about integrating other open source projects (assuming they're stable and known-to-work)?

Those of you that have contributed so far (is that just tzachs, Calin, progz?) can you please:
1. let me know under what name you'd like to be credited
2. post a quick list of your changes here so that I can assembly an accurate changelog

Actually, I believe that helios123 also made a change to the editor.
Anyway, my name for credits sake is Tzach Shabtay, the entire list of my changes is in the first post in this thread, under "Features Added".

[Calin Leafshade]

Ok well, in the spirit of asking for help here is something i consider fairly urgent:

we need to reform the user properties system.

Currently the properties system is very set in stone and not easy to add to. It's just a form with alot of radio buttons essentially.

Really it should be closer to the VS system of a property grid to which editor components can add and get properties on the fly.
(or alternatively a tree + pane system similar to the editor itself)

What would be the best way to tackle this and how should the classes be integrated with the current class structure?

As for credit and stuff:

Steven Poulton
And I did:

GUIEditor -
Control snapping
Control alignment/distribution
Control grouping
Control locking
Anything else related to the gui editor

I added coordinates when dragging characters and objects in the room editor.

I coded the scintilla lexer for the dialog editor.

[Shane 'ProgZmax' Stevens]

I don't care about or need any credit.  My additions were motivated purely by a desire to have these things in the editor; it's as simple as that.

As for specific changes/additions:

1.  Altered the character and gui color properties to display color values as a visible RGB swatch that can be easily customized and set directly without using the color picker in the editor.  This includes support for legacy AGS colors 0-31 (0,0,8*1, 0,0,8*2, 0,0,8*3, etc).

2.  Added support to view characters in room edit and adjust their placement accurately from the bottom-center of the sprite.  This was changed without any prior discussion by Calin to a separate checkbox property, which is fine.  Can also copy their coordinates to the clipboard via a right-click menu like objects.

3.  Cleaned up the arrangement of the Room Edit interface to comfortably fit in the mouse coordinates, the zoom and transparency sliders, with room
for new elements.

4.  Coordinates now display properly based on whether or not hi or low-res coordinates are enabled (and will copy to the clipboard correctly).

5.  Added a quick fix for a bug occurring for some imported games with no background images for guis that would load with -1 (instead of 0=transparent).  This led to a crash when running the game and seems to have been fixed (reported by Le Woltaire).  This should be 100% compatible with your acwin fix as all it does is check the gui background images as they load and change any negative values to zero in the editor.

6.  Disabled warnings when guis are larger than a room's dimensions.  Since room dimensions can vary widely, and because no harm is caused by an oversized gui, this warning seems unnecessary.  This was a fix we both agreed on in the wishlist thread but wasn't a high priority.

7.  New characters and characters without any frames in loop 0 of their normalview could generate a crash.  Now, instead of demanding an image the editor will display SPRITE 0 from the sprite list if loop 0 is empty.  

8.  By request, I made the middle mouse button function as a 'copy coordinates to clipboard' menu for all modes except Edges as it was suggested to me
that copying the coordinates when viewing regions/walkable areas and hotspots is very desirable, and because the right mouse has incompatible functionality in those modes with a menu (erase, hotspot/region/walkable area select).


I think that's about it.

[Calin Leafshade]

2.  Added support to view characters in room edit and adjust their placement accurately from the bottom-center of the sprite.  This was changed without any prior discussion by Calin to a separate checkbox property, which is fine.  Can also copy their coordinates to the clipboard via a right-click menu like objects.

Ideally this needs to be moved to the user properties. A checkbox is a poor solution but dragging from the bottom centre is not standard behaviour.
Gui controls dont drag from their top left, nor do objects so why should characters drag from bottom centre?
The whole point of dragging a character in this manner is to do it by eye. If you wanted to do it with coordinates then you would do so in the property grid.

In any event, I didnt reverse your edit, merely made it non-compulsory.

[Pumaman]

Consider that id Software released the source code for the original Doom in an initially non-compilable state due to its use of proprietary libraries. It certainly did not stop people from getting it working, and there are people here who I am sure could get the code for the AGS runtime to work in a similar fashion (eventually, at least - I'd not doubt in the slightest it'd be hard going).

I could do, but why? What's the great hurry? I'd much rather take some time to sort it out into a proper working state than give people something uncompilable and have them waste time trying to make it work (and possibly generate invalid/crashing builds of the engine as a result).

Tested and the fix works.

Thanks for testing.

My only gripe here, is that experience in c# is not enough. Every code base tells its own story and requires understanding of its inner structure & patterns, a thing which only you fully understands at this point of time.

This is true, yes. I'll do my best to be around to answer any questions about it, but at the same time if I'm not around at the time then I don't want that to halt anything being done.

I actually do have another somewhat related question, what are your feelings about integrating other open source projects (assuming they're stable and known-to-work)?

Depends on various factors, such as the license (eg. I don't want to use any GPL code, but LGPL is ok), the usefulness of the library, etc. Do you have a specific example in mind?

Actually, I believe that helios123 also made a change to the editor.

Ah thanks, I'll take a look at that.

we need to reform the user properties system.

Currently the properties system is very set in stone and not easy to add to. It's just a form with alot of radio buttons essentially.

Really it should be closer to the VS system of a property grid to which editor components can add and get properties on the fly.
(or alternatively a tree + pane system similar to the editor itself)

Are you talking about Custom Properties, or the editor's User Preferences dialog?

1.  Altered the character and gui color properties to display color values as a visible RGB swatch that can be easily customized and set directly without using the color picker in the editor.  This includes support for legacy AGS colors 0-31 (0,0,8*1, 0,0,8*2, 0,0,8*3, etc).

By the way, I had to change this code to work with 8-bit games, since they can't have an AGS Colour Number greater than 255, and the palette needs to be scanned to find the nearest colour to the one chosen.
Something to bear in mind for future editor changes, anything dealing with colours needs to work with all colour depths.

I also made the ColourNumber property visible because with 8-bit games you quite often want to set this manually; and with hi-colour games it's useful to be able to see it.

Ideally this needs to be moved to the user properties. A checkbox is a poor solution but dragging from the bottom centre is not standard behaviour.
Gui controls dont drag from their top left, nor do objects so why should characters drag from bottom centre?

I agree with this, I'm not sure I see the point of having an option to make the bottom-centre jump to the mouse position. In what situations is this useful?


Going forward, we need a process for adding things to the AGS code. Just because somebody has a great idea for the editor, we don't want them just diving in and changing everything, when it might not be a feature that other people would find useful -- and might in fact break other things in the process.

So we need to decide on a way that people can propose a change, we can agree whether or not to approve it (or whether it might be better as a plugin, for example), and then if approved they can go ahead and do it.

[kaputtnik]

So we need to decide on a way that people can propose a change, we can agree whether or not to approve it (or whether it might be better as a plugin, for example), and then if approved they can go ahead and do it.

Since at the moment it seems that AGS development is heading towards a more or less structured model of a group of steady collaborators who have access to the code base, it might be a good idea to set up a bug tracker and a feature/feature request tracker. The active AGS community is quite large, and I guess we could accumulate lots of useful bug reports and maybe gather and choose from a list of features that make sense if people used a tracker, rather than posting on the forums. And the group of developers can split the workload much easier.

[Calin Leafshade]

we need to reform the user properties system.

Currently the properties system is very set in stone and not easy to add to. It's just a form with alot of radio buttons essentially.

Really it should be closer to the VS system of a property grid to which editor components can add and get properties on the fly.
(or alternatively a tree + pane system similar to the editor itself)

Are you talking about Custom Properties, or the editor's User Preferences dialog?

I mean the editor user preferences.

If someone wants to edit or add a feature to the editor then its very likely that there would be some preferences associated with that feature.

As such it should be possible for an editor component to register new user preferences to some kind of dictionary and get those preferences

For instance, with the gui editor:

It is conceivable that a user might not like the control snapping. They find it an annoyance and its not applicable for the way they use the editor.

The gui controller should be able to query all the panes on the start up and register their preferences in the global preferences dialog for users to change.
and then the panes should be able to query the gui controller for those preferences and act accordingly.

[tzachs]

Depends on various factors, such as the license (eg. I don't want to use any GPL code, but LGPL is ok), the usefulness of the library, etc. Do you have a specific example in mind?

Yes!
It's called DockPanel Suite and provides docking abilities to panels a-la visual studio.

I'm not really good with licensing issues, so I'm not sure if it's GPL, LGPL or something else...
Here are the terms and conditions (copied & pasted from the documentation):

DockPanel suite is provided as free software with source code provided. You can freely use it in your applications (commercial or non-commercial). Weifen Luo, The author of the control, owns the copyright of the control, and is NOT responsible for any damage in your application caused by using this control, directly or indirectly.
Weifen Luo will feel honored if his name appears somewhere in your applications using this control (about box, documentation, etc).

[mike_conley]

Hey all - hope it's OK if I jump in here.

Going forward, we need a process for adding things to the AGS code. Just because somebody has a great idea for the editor, we don't want them just diving in and changing everything, when it might not be a feature that other people would find useful -- and might in fact break other things in the process.

You might be interested in a code review tool, like Review Board:

http://www.reviewboard.org/

The idea:  patches for AGS can be submitted for review, and commented on.  People put their eyes all over it, ask questions, etc.  When the review request gets the green light (or the "Ship it"), the review requester (or the project maintainer) can then apply the patch.

Screenshots
A demo instance to play with
List of happy users

Review Board is open-source, free to use, and MIT licensed.

I worked on Review Board for a Google Summer of Code project last Summer.  I still contribute in my spare time.  I'm also a huge fan of adventure games and AGS:  I'm really excited to hear that you're opening up the code!

Anyhow, I just thought I'd suggest RB.  You might find it useful.  No worries if it's not the direction you want to go.  But if you want to set it up, let me know, and I can help out.

All the best,

-Mike

[Gilbert]

Assuming that it does, I'll do a proper build of this code and release it as 3.2.1 Beta 1.

BTW, as V3.2 is not "officially officially" released yet (i.e. not announced on main page and the installer-less version is not available), would you just skip it and make V3.2.1 the "real" official version? Besides the changes in the editor, there're a couple of bug fixes in the engine, so would it be better to have V3.2 released first (with the less buggy engine), or just wait for yet another version?