Topic: Editor feature requests

[SpeechCenter]

Following my experience developing an editor plugin, I would like to ask the following features:
* If a game uses a component (plugin) that is not currently installed, keep the previous component xml as-is when saving the .agf file. Currently it deletes this xml node completely
* Interface to get the current game player id (IGame doesn't provide this information)
* It's only possible to load one room at a time and it affects the GUI if there is an existing room edit in progress. There should be a way to load a room in-memory without affecting the GUI
* If a script or room was changed, but not saved, there should be a way to detect that there are pending changes.
* When a plugin component FromXml method is called, the CurrentGame DirectoryPath is null, it should have the right value when this method is called.
* Ability to register plugin's own unhandled exception handler, maybe by giving an option to load a plugin to its own AppDomain or an internal mechanism
* Provide plugin access to the properties window
* Provide plugin access to the error pane
* Allow a plugin to add an additional window in the right pane (next to the tree and properties window)

Additionally, I believe the following editor feature should be useful to the user:
Add back and forwards buttons to go through the different open documents. An enhancement could be to give a component an ability to add its internal locations to these events, but it's a nice-to-have addition.

[SpeechCenter]

Quick question, now that the forum has been upgraded, should this (and similar requests) go to the Editor Development subforum in order to be considered or is this the right place?

[Snarky]

They should probably go to Editor Development, but that's not a condition for (or guarantee of) being considered.

[dbuske]

It would help to be able to test a room without having
to go through every room to test room 40 and beyond.

[monkey_05_06]

dbuske, you can. Just set the room the player starts in.

[Ryan Timothy]

Or with debug mode on Press Ctrl+X to change rooms. Unless you've removed the on key press call, which is basically this:

Code: Adventure Game Studio

1. if (keycode == eKeyCtrlX) Debug(3,0); // Ctrl-X, teleport to room

[dbuske]

Thank you Guys.  This will help me test the games faster.

[General_Knox]

Not sure if this has been asked before or even possible:

1) The ability to lock an object in the room editor
2) The ability to change an object's Z depth (like buttons).
3) "Zoom To" object/character if the room is really large and you dont want to scroll around manually triyng to find it
4) Have the option to specify in "Preferences" the maximum number of objects per room (so people can plug in their own values)

[Ryan Timothy]

"The ability to change an object's Z depth (like buttons)."
Are you speaking of the baseline? It's already possible in the room editor. Just change BaselineOverridden to true and set the baseline yourself.

[Eric]

Z-depth is background to foreground, the implied third dimension.

[Ryan Timothy]

Which is exactly what the baseline controls.

[Eric]

...Well, now that you mention it, so it is. But it's established on the vertical dimension, which makes it non-intuitive for sleepyheads like me. 

[monkey_05_06]

With the background itself being 2-dimensional, how else should the z-order/baseline be represented? Although it would be fair to note that characters have both a baseline which controls what is drawn in front of what, and a z-order, which basically just offset's the y position the character is drawn at while still triggering events as if the y is unchanged.

[Eric]

Z-index in CSS, for instance, simply uses a stacking order number. I'm guessing it probably works much like I anticipate BaselineOverridden would. An object with a z-index of 1 is behind one with a z-order of 2, etc. An object with a z-index of 10000 is on top of everything.

[General_Knox]

Actually having z-order for objects instead of baselines could be cool...or atleast offered along with baselines.

[Snarky]

The problem with a fixed z-order is that the case where it is tied to the on-screen position (i.e. something that is lower on screen is closer) is so common that it ought to be really easy to enable. Basically any time you have characters, objects and walkbehinds arranged on a plane seen from above (which is most of the time), this is the case you want. Using the baselines (i.e. bottom pixel y-coordinate) for z-order is a very straightforward and pretty intuitive way to make it work.

You don't want to have to manually shuffle the z-order every time a character walks in front of or behind a tree, for example. It's much easier if the tree's z-order is set to its baseline and the character's z-order is set to its baseline and it just works.

What is a bit confusing is the Character.z is not the z-order, but a way to adjust the y-position without affecting the z-order. (Intuitively, it lifts the character up off the ground.)

[Kweepa]

The problem is that AGS has two meanings for Z.
One is the GUI sort order, which shouldn't be called Z-order at all. The end-user may not know about projection matrices, and the Z here is pretty arbitrary.
The second is the third spatial coordinate, up/down relative to the ground. This makes a little more sense except that x and y don't exactly define a ground plane in a lot of cases.

This could all be cleared up by renaming the GUI variable.

[EDIT] Cool! I got a little light bulb icon!

[Eric]

Basically any time you have characters, objects and walkbehinds arranged on a plane seen from above (which is most of the time), this is the case you want.

I admit up front that I might be talking out of my ass here, but I can see some instances where that might not be the case. Say you have a shelf that a character can tip over, and things that are on the shelf. The things on the shelf would need to have a lower baseline than the shelf, though that's not physically the case. Right?

Now say you have a two-by-four that overhangs a stack of boxes on which it sits on top. Would it be tricky to set the baseline so that the board appeared on top of the boxes, and yet the character would walk behind it in the proper manner at the places where it overhangs? Like I said, I'm perfectly willing to accept "You are talking out of your ass" as a response. I haven't gotten far enough into game making myself to have encountered a situation like this.

[monkey_05_06]

Regarding the 2x4 overhanging the boxes scenario, it wouldn't actually be that difficult, assuming that if the character is behind the board then they're also behind the boxes as well.

As long as the box baseline is greater than the board baseline, you can let the player's baseline be determined automatically based on their y. So say the box baseline is at 200, the board baseline can be at 199. If the player's y is 200+ they'll be drawn in front of both, 198- they'll be drawn behind both.

[Eric]

I'm going to go upstairs and mess around with AGS a bit to see if this is the case, but for other beginners who might be wondering: would that not draw the board behind the boxes?