Editor Wishlist/Coordination

[ddq]

+1 for copying GUI controls. It'd be a big time saver when trying to make a GUI with many identically sized elements.

All these other suggestions sound great too, though the main thing I'd like to see would be a better zoom and pan for the room editor like ProgZ said, as long as it wouldn't require a huge overhaul and buttloads of work.

Can't wait to see what the future holds!

[Calin Leafshade]

For GUIs:
-Moving Gui elements with the keyboard when selected - done!
-Selecting multiple Gui elements at once - nearly done!
-Gui alignment tools like in VS could be useful too - done!

Maybe we should build some kind of taskgroups where people focus on one part of the IDE like Gui-Designer, Roomeditor, Dialogeditor. Maybe even with separate sourcecontrol for each group?

Actually most of the things like the room editor and gui editor don't need a massive amount of work so a full task force might be overkill.
I've already implemented most of the things requested for guis in about 2 hours of coding time (without the rigorous testing required obviously).

Most of the things people want done to the editor are the fixing of annoyances like being able to flip a group of view frames and things like that.
We can't make many huge changes to the way AGS works because the engine still needs to understand all the conventions so these changes are more about making the editing experience even less painless than it already is.

[Ryan Timothy B]

I'm not sure if this can be done with the *editor* side of things, but I suggested on this thread that whenever you add/edit/delete a global variable every room should be changed to an updated status so that they are forced to recompile on next build. It prevents issues if you create or change a variable to the same name as a room variable that's already existing, which causes unexpected errors. Or if a room is using a global variable and you delete it, it will crash the game when you go to run it.



Also a trivial one I suggested a while ago was having the X and Y input boxes and such for the positions for Objects, GUI controls, characters to support simple math. Such as: 150-10. Unless obviously it proves to be harder than it should be to do this. It was just something I figured the editor should support anyway, whether it recalculates it once you input it, or just keeps it stored as 150-10 would do.

The only reason I wanted it to support simple math is if I went to move every GUI element over 10 pixels or whatever, I can just subtract it without doing math. But if Calin is going to support selecting of multiple elements, this may not be needed anymore.

[tzachs]

Some great great stuff there (and Calin, you're a machine!)

I haven't looked at the source code yet, so I don't know what's doable, but here are the things I intend to tackle (some are easier than others):

* Context menu for the loops in the view editor, with: copy, cut, paste, flip all, create from folder.
* Docking abilities to the forms (visual studio style) and being able to have more than one form open at a time.
* Enhancing the text editor with: Find all references, find/replace all in all projects/open documents.
* Having writable custom properties (not too optimistic about that one, though)
* Be able to name (x,y) locations in the room editor and use them in-game.

[Wonkyth]

Some good suggestions coming in!
One thing though, if this is a wishlist, could it be possible to have a complete list of approved changes/additions in the first post, Calin?
It would make it easier when the time comes to assign jobs.

EDIT: I wouldn't mind sprucing up the IntelliSense stuff a little, as it seems a little glitchy atm...

[monkey0506]

However GUIControl is an abstract class so I guess I'd have to implement the ICloneable interface for each inherited class separately.. which sounds boring ^_^

I'll look into it.

As I've noted my knowledge of C# is limited, but from what I've read, and from looking at the implementation of the GUIControl class itself, I don't see why this would be necessary. Abstract classes can have non-abstract methods defined (the GUIControl class is already doing this). So then wouldn't it simply be sufficient to do:

Code: ags

namespace AGS.Types
{
    public abstract class GUIControl : ICloneable
    {
        public object Clone()
        {
            // NOTE: the GUIControl class has no non-value members, so a shallow copy is fine
            return this.MemberwiseClone();
        }
        
        // ...the rest of the GUIControl class...
    }
}

..or am I overlooking something?

[Calin Leafshade]

thats true actually. A memberwiseclone of the object would be fine.

and then if necessary the object could be cast to any of the derivatives of the GUIControl class.

I think your C# is likely much better than mine :p

[tzachs]

We had a similar problem at work.
A memberwise clone would work in most cases, but if one of GUIControl's children has non-value members, then they will not be cloned.

I would write:

Code: ags

public object Clone()
{
    Object clone = this.MemberwiseClone();
    NonValueClone(clone);
    return clone;
}

//Override this method to add specific non value members to the clone
protected virtual void NonValueClone(Object clone)
{}

And then go over all of the children, and if one of them has a non value member, override the method:

Code: ags

class MyGui : GuiControl
{
   private MySpecialData _mySpecialData;

   override void NonValueClone(object clone)
   {
        //Calling base, since maybe in the future GuiControl will have non value members of 
        //its own
        base.NonValueClone(clone);

        //Unfortunately, I didn't see a way to avoid casting here
        MyGui myClone = clone as MyGui;

        if (myClone != null)
        {
            myClone._mySpecialData = _mySpecialData.Clone();
        }
   }
}

Maybe even NonValueClone should be made abstract, so that every new control that's added will force the developer to think about the non value clone, and possibly avoid future bugs...

[monkey0506]

Based on what is currently defined as far as GUIControl and its derived types, a MemberwiseClone should be fine since each of them use only value types (bool, int, string, and enums). Seeing as we can't implement any new GUIControl types for run-time as yet there'd be no real point in implementing new types right now that would fail to conform to this.

You make a valid point about non-value types, but for now it's not really a concern.

[Knox]

Copying the gui's + controls is an excellent idea! I would suggest perhaps giving more control on the folders, like being able to drag folders over each other to change their order, or class them alphabetically, etc...more like in windows.

Here are some more suggestions if you think some of them are good ideas:

-Being able to create or class dialogs + inventory items + gui's + characters into folders

-Having a prompt pop-up when deleting a loop inside a view to ask the user if they are sure they want to delete the last loop...right now if you click on the button by accident, you`re screwed...!

-Adding "undo" to certain actions like deleting controls, gui's, etc...I think Undo is missing in AGS, if Im not mistaken (?)

-Adding bookmarks to sprite folders (with keyboard shortcuts for quick access), and  bookmarks to the script editor (like in UltraEdit).

-Keyboard shortcuts feature (that can be modified by the user)

Ill think of more when Im actually working in AGS and post here frequently if you dont mind...

[Calin Leafshade]

copy/paste with a memberwise clone works fine.

I'll implement using the windows clipboard tomorrow instead of a buffer var so that copy/paste can be across editor instances. Done!

Undo is something I've wanted to add for a while but the implementation of that should really be editor wide so it needs a little more planning I think.

EDIT: I really think a new subforum for this might be a good idea. Otherwise these conversations are going to get ridiculous.

[subspark]

Yeah we need a subsection for 3rd party editor development. I suggest a generic title that can eventually be applied also to a forum for engine development also.

[Calin Leafshade]

Would anyone like to test my editor 'adjustments' thus far?

not ready for public consumption but i'd like some feedback on the changes ive made

[Sslaxx]

Would anyone like to test my editor 'adjustments' thus far?

not ready for public consumption but i'd like some feedback on the changes ive made

I'd be interested in taking a look. Linux (Mono), Win2K and WinXP (.NET) here to try it on. Also got Mono via WINE too.

[Dave Gilbert]

One thing my wife reeeallly wanted when working on Puzzle Bots was the ability to get the value of variables when the game pauses at break points.

[Calin Leafshade]

I'm fairly sure that would require engine adjustment and would be non-trivial to implement.. although it would be *awesome* if that could happen.

[Wyz]

you could do that with just the editor, then you need to include a API call (and hide this in the editor view) that transfers the new value and variable name to a dataset every time a variable is changed, and somehow make this data set visible to the user. Ok, that is a lot of work

[Calin Leafshade]

Sounds like you have it well under control.. I'll leave you to do that 

[tzachs]

I'm not sure I got you there, Wyz. How will you make the engine send a message each time a variable is changed if you don't have the code for the engine?
Can you do that with the API? How?

[Wyz]

Well it's a bit of trickery but it boils done to this:

Say you have this code:

Code: ags

some_var = SomeFunction(some_parameter);
SomeRoutine();
some_var++;

Then you would make the editor change it to this:

Code: ags

some_var = SomeFunction(some_parameter);
DebugScope("some_var", some_var);
SomeRoutine();
some_var++;
DebugScope("some_var", some_var);

DebugScope would be implemented with the plugin API to do something useful with the values. Now the trickery: you need to hide the newly added lines to the user. Also, it must only be generated when the user uses the scope.