Editor feature requests

[monkey0506]

I may have been a bit confused by your wording, but if the board should be drawn in front of the boxes then just swap the box and board baselines.

[Eric]

Yeah, sorry. That was not the best way to describe the scenario. But as you said, it works much better than I would have imagined. I guess I hereby withdraw my support for a z-order function.

[Snarky]

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?

I'm not sure I follow exactly what it is you're imagining here, but if you're talking about something like a cabinet with objects sitting on a shelf, the issue is that the cabinet is sitting on the floor while the objects are sitting on the shelf off the floor. So it's not an example of the common case I was talking about, since they're not on the same plane. To make it work correctly, you should set the baselines of the objects to be lower down (higher y-value) than the baseline of the cabinet.

So yes, there are definitely cases where the simplest "just set the baseline to the y-coordinate of the lowest pixel" method doesn't give the right results, but it's still pretty easy to make it work correctly. For objects of varying depth it can be a bit tricky, and you might have to write special code or break up the object into separate pieces; this is a fundamental problem of trying to do distance sort with only one distance value for each object.

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!

Actually, z-order is the standard term for sorting objects by "distance," and is commonly used in graphical user interfaces to describe how windows are stacked on top of each other.

If anything should change, I think it ought to be the character property, which might be renamed Y_prime or something like that.

[subspark]

If I were a programmer, I'd be upgrading the image-based pathfinder for a polygonal one instead. While the image-based approach is novel in terms of an easy setup,
it very quickly becomes clumsy and brittle in comparison to its polygonal sibbling.

There's a range of benefits inherent with a polygonal pathfinder that would be impractical or impossible with the existing tools. Complexity, accuracy and speed are its three signature strengths.
To name a few things that a polygonal system will bring to AGS:

• Arbitrary direction-independent navigation interactions Eg. Scaling - walking downwards into the distance
  
• Spiraling multi-tier structures that can overlap.
  
• Solves navigation through complex maze structures accurately and on the fly.
  
• Accurate character maneuverability Eg. Diagonal Loops - character's sense of direction now feels accurate and less clumsy when maneuvered.
  
  If anyone is interested or has already considered upgrading the AGS pathfinder, I believe these links would be very useful.
  http://www.david-gouveia.com/pathfinding-on-a-2d-polygonal-map/
  http://blog.sokay.net/2008/07/23/northstar-intro-to-pathfinding-around-irregular-polygons/

[Shane 'ProgZmax' Stevens]

Yes, though modifications to the pathfinder logic would be an engine-editor issue, as you can 'define' walkable areas and whatever in the editor, but it's actually the engine that makes sense out of it.  Certain elements in the editor would have to be modified, mainly how walkable areas are constructed (the user would instead place points to define a polygon or choose from a selection of preset shapes that can be resized) and saved.  From there the engine would have to interpret the new data, so there's a bit more work involved than just drawing some shapes in the editor.

While I have not tried using polygons in such a way I did use them for a tile-based engine I made once (defining tile and sprite shapes for collisions) and yes, there are considerable speed benefits to referencing a series of points rather than calling up a bitmap and looking for non-transparent or specific color pixels (which is how I believe ags currently handles walkable areas).

[subspark]

modifications to the pathfinder logic would be an engine-editor issue, as you can 'define' walkable areas and whatever in the editor, but it's actually the engine that makes sense out of it

Yes, correct. But I wasn't going to double post between two threads so I picked the editor one I was on at the time.

I did use them for a tile-based engine I made once (defining tile and sprite shapes for collisions

Fascinating, Progz! I'm intrigued.
Do you think it would be possible over time to extend the functionality of your tile-engine to meet the functionality of a full-blown polygonal pathfinding solution?

[SpeechCenter]

Is there any place where we can see all the features requests and their status?
I'm very interested to know this, and may implement some. This question also applies to the engine, I'm actually a C++ programmer, .net is just extra

[steptoe]

This may sound a bit off key here but I'd like to see the main menu icons in AGS further apart. I have bad arthritis and it's difficult to always be precise. A couple more mm apart would be perfect for people like me.

[Alan v.Drake]

A few things I could sure make use of would be:
* Importing animations straight from .ASE format (aseprite) or even .MNG
* A way to overwrite more sprites at once, perhaps with a checkbox saying "Overwrite existing sprites" * done

I will look into those, because I need them since I foresee many tweaks as my game strides forward. If someone wants to help I'll be glad, but that's probably not gonna happen, is it ?

- Alan

[monkey0506]

If someone wants to help I'll be glad, but that's probably not gonna happen, is it ?

Not with that attitude.

What exactly do you want/need help with? I know nothing about ASE. I know MNG is one of the animated PNG formats (personally I think that APNG would be better simply because it, unlike MNG, is backwards compatible, meaning it will still display the first frame in any PNG-compatible software).

[Crimson Wizard]

The now official tracker for Editor bugs and requests:
http://www.adventuregamestudio.co.uk/yabb/index.php?project=5

(I hope that works, and you won't need admin rights to use that )

[Alan v.Drake]

If someone wants to help I'll be glad, but that's probably not gonna happen, is it ?

Not with that attitude.

What exactly do you want/need help with? I know nothing about ASE. I know MNG is one of the animated PNG formats (personally I think that APNG would be better simply because it, unlike MNG, is backwards compatible, meaning it will still display the first frame in any PNG-compatible software).

Don't worry, that's a low priority. With the change I made one can already import over a range of selected sprite via the "tiled import" option.
It would be certainly of use to have the possibility of importing directly animations with alpha channels (apng, mng, ase) if we can find libraries to handle them and it doesn't take too much work.

Also, multiple selected sprites could be merged into one of those formats (gif if withouth alpha) and opened in the associated editor. But maybe i'm going too far.

- Alan

[Crimson Wizard]

Examining the Grim's Cat Lady production screenshots suddenly brought me few ideas:

http://i.imgur.com/2NOz9.jpg

As you see, his project tree is quite a big one. Now, imagine you have opened lots of folders there and now want to close them, or maybe open different type of items. You will need to scroll up until you find the root.

My suggestions:
1. Make "Collapse current tree"/"Collapse all" options in context menu for the project tree.
2. Make "Go to:"->Item category option in context menu.
3. Actually also: "Find item" option which will open a "search for project item" dialog.
4. Add combo-box and filter-box at the top for Project Explorer. Combo-box allows to choose item category which to display, or "All project items". Filter box allows to type a string with wild-card characters and thus filter the displayed contents.

EDIT: A much better alternate for item-type combobox are bitmap buttons that may be toggle on/off, with two extra "check all" and "uncheck all".
EDIT2: Also struck out 2 and 3 since their functionality is covered by suggestion No 4.