[SUGGESTION] Seven fair improvements for AGS 3.2

[subspark]

Here are seven suggestions for AGS 3.2 that I feel would be rather usefull:

• Longer view descriptions. (max length=32)
  
  
  
• Descriptions for Loops.
  
  
  
• Access to the Room Script through the Room Editor toolbar.
  
  
  
• The ability to drag folders into other folders and rearrange them.
  
  
  
• Place and drag hotspot WalkTo coords with mouseclick functionality.
  
  
  
• Implement FaceDirection command for more precision over character views.
  
  
  Example:
  

  Code: ags

  cEgo.FaceDirection(eDownRight);

  
  
  
  
• Freezing views, loops or frames until walk or other mousemode action.
  
  
  Example:
  

  Code: ags

  cEgo.FreezeView(VIEW, LOOP, FRAME);

  
  
  Cheers,
  Sparky.

[Scavenger]

For FaceDirection, I have just what you need.

Code: ags

//Put in Script Header
enum Directions
{
  eUp, 
  eDown, 
  eLeft, 
  eRight
};

//Put in Script
function FaceDirection (this Character*, Directions direction)
{
  if (direction == eUp)
  {
    this.Loop = 3;
  }
  else if (direction == eDown)
  {
    this.Loop = 0;
  }
    else if (direction == eLeft)
  {
    this.Loop = 1;
  }
    else if (direction == eRight)
  {
    this.Loop = 2;
  }
}

If you want them to turn to face that particular direction, there's a slightly different function for that I wrote in my last game, but this version's in my latest build.

[subspark]

Hmm i get an error when I use the function:

Error:

'.FaceDirection' is not a public member of 'Character'. Are you sure you spelt it correctly (remember, capital letters are important)?

Isn't a function supposed to autocomplete? That was the given second half of the request. I put the enum in my global script header and not every room right? - Thanks very much btw Scavenger!

Cheers,
Sparky.

[Akatosh]

Well, that function isn't an extender of Character right now, so you need to call it like this:

Code: ags

FaceDirection(player, eUp);

And not like this:

Code: ags

player.FaceDirection(eUp);

/EDIT: Wait, according to the manual it IS an extender of Character. Strange. Did you remember to do the standard imports/exports?

[Shane 'ProgZmax' Stevens]

FaceLocation with +1/-1 tweaks for the x and y values could easily be added to that script to allow any character to turn gradually to face a direction.  I actually have a function that does this so whenever the player looks at something he turns to face it rather than just standing still or popping to a new loop instantly.  Like:

player.FaceDir(UP)  would have a call to FaceLocation(player.x,player.y-1,eBlock) (or eNoBlock if you don't care if it's interrupted).

You could also combine the functionality of both approaches with an optional variable that by default uses facelocation, and when set to true just sets the player loop:

player.FaceDir(UP,INSTANT) would reference player.loop=3.


Lots of room for custom functions with the scripting system without needing CJ to spend time on hardcoded versions!

[subspark]

I aggree with you here progzmax. Theres great oportunity to extend the functionality of AGS without the need for CJ's magic. Having said that, my other suggestions are unfortunately clearly in CJ's department.

Thanks for all the fresh ideas guys! Youve all been a big help.

Cheers,
Sparky

[Pumaman]

Would anyone else find any of the other ideas useful?

[Matti]

I support these two suggestions:

• The ability to drag folders into other folders and rearrange them.
  
  
• Place and drag hotspot WalkTo coords with mouseclick functionality.

[Stacy Davidson]

* Place and drag hotspot WalkTo coords with mouseclick functionality.
* Implement FaceDirection command for more precision over character views.

These two would definitely save a little legwork while coding.  I'd love to be able to make generic hotspots I can just make on the map screen and name, and use for whatever I want in the game without having to worry about flipping back and forth and remembering X/Y coords.  Nothing earth shattering, but cool nonetheless.

-s

[Scavenger]

I would find all of the above useful, apart from the FaceDirection one, since I already coded that one B3

[NsMn]

I think so too, only "FreezeView" could also be coded easily. Something that locks the player's current frame when he stops walking would be more useful, since it's nearly impossible to code.

[Shane 'ProgZmax' Stevens]

I think more folder optimization would be good (I suggested it ages ago) but the other options, especially the hotspot walkto adjustment, to be more of a patch on a tire than what could be done to really overhaul and improve room edit.  For example:


1.  Why not have characters visible in room edit so you can drag them about and place them where you want?  Their Room, x and y values would adjust to whatever the room edit values are automatically.

2.  Why not have a 'view all' and 'view x' checkbox next to each of the room edit sections (walkable areas, walk behinds, hotspots, regions, objects, *characters) so you can view these items together.  I know for a fact that the ability to draw a region while walkable areas can actually be seen would be an immense improvement over switching back and forth between the two and guessing.  Also, being able to see how objects/*characters react with walkbehinds through room edit beforehand would make baseline positioning trivial.  The same goes for hotspots and hotspot walk-to placement.

3.  Expand the background frame limit by allowing you to specify a view and loop exactly like an object/character animation with a warning in the manual that large animations could drastically reduce performance on low-end systems.  Finally, controls similar to Animation would be good (eForward, eBackward) and while GetBackground/SetBackgroundFrame work, why not have a standardized .Frame setting like with characters and objects that can be set manually?

4.  Walkable areas that overlap and can be assigned to ANY character.  I think this would be an important and innovative way to make sections that only one character responds to.  With such functionality you could easily have them follow a complex walk path without interfering with the player or without extensive use of repeatedly_execute.

5.  Regions that overlap and can be assigned to ANY character.  This ties directly into #4, but unlike the player there has been absolutely no way to make NPC's react to elements from inside room edit.  By allowing the author to tie a region to a specific character, they could react just like the player would when walking over a region, greatly improving the usability of the editor.  This could be as simple as allowing ALL characters to react to regions and then using an if statement to decide which ones actually do something.  These regions could be quickly used as waypoints or for performing complicated animations that would otherwise take a lot of additional scripting and timing.

6.  Add the ability to export ALL room edit entities (background, objects, *characters, walkable areas, walk behinds, regions) and re-import them.  I would find the ability to export and tweak walkable and walkbehind areas in particular far more useful since I'll often need a bit of precision that I can't get in the editor.



I do realize that at least a few of these would require a fair bit of effort, but with the exception of 4 and 5 they are suggestions I've seen offered time and again (and not just by me) and I think that if we're talking about expanding the powers of room edit we might as well cover the ways it could really be improved from a usability and convenience standpoint.

Again, I understand the complexities but I think if room edit is ever going to improve, these are an excellent start point.  Thanks!


*provided characters were added

[Vince Twelve]

Longer view descriptions and descriptions for loops would be useful.

Pretty much all of Progz' suggestions would help with issues I've bumped up against in the past.

#1 for taking the guesswork out of setting NPC starting positions, or where I'm using a character instead of a room object (which I've done for lots of various reasons.

#2 I often find myself using a hotspot for an object's click interactions instead of the object.  Especially if the object has, for example, a shadow included on it's sprite that I don't want to be clickable, or if it has holes in the middle, like a ladder, that I want to be clickable.  Drawing that hotspot usually involves me turning on objects, putting my fingers on the screen, then switching to hotspots and drawing lines between my fingers.  Being able to see them together would be useful.

#3 I don't usually use background frames for animations, but could see how it would be useful.

#4 In Puzzle bots, there are a bunch of playable characters and one of them was really wide, my choices were to A) Have the thinner bots walk up to the edges of rooms/ledges and have him hang way off the edge, B) Have the thinner bots stay a large distance away from the edges of the rooms and have the wide bot walk up close to them, or C) Draw a walkable area around an inner walkable area and turn it on/off depending on which bot is currently walking.

On a related note, I could still use way more walkable areas.  Nanobots and Puzzlebots need way more walkable areas than I have (making option C above much less usable), but I find ways to work around them, like using solid invisible characters to block off walkable areas.

#5 I don't know that I would have a use for, since at most, I use two or three regions in a room usually.  But it's the same thought process as the walkable areas.

#6 Very useful.

But yeah, a lot of these would require some fundamental changes and are non-trivial obviously.  Good ideas though!

[Matti]

I totally support all of ProgZs suggestions! Didn't dare to suggest them myself (a few of them circled around in my mind since quite some time and some have already been mentioned I think), cause somehow they'd naturally be something everyone would benefit from, so I thought CJ just has a higher priority list or that that these things are too hard to implement..

However, these would be some neat features.

[janker]

I think it would be very useful to add possibility to change idle view frame speed! Or to make left, right, down and up standing animated stance without using idle view. I hope this could be useful to many!

One more stuff! Can you add Save As?   Cause' many times i made something wrong in script editor and when I press F5 to test game it reported an error message and I couldn't fix it and my game was automatically saved! and never again I could play my little game... Just make an option to load before all those script errors. Could be useful specially for beginners!

[subspark]

OH THANKYOU for spilling the beans at last ProgZ. Every suggestion you made has been fighting around in the back of my brain for a long while now.

To expand on your first idea - it would be equally important to be able to view the scale/tint/light of characters by dragging them around the confines of the walkable areas we set. I can't imagine why we'd have to guess this sort of stuff forever.

I imagine CJ is already running for the hills but I have it in me to make one more suggestion:
vSync for DirectX9 mode. I'm getting image tearing all over the place with full screen animations. I certainly agree with ProgZMax's third suggestion although without vertical sync, image tearing would still be a real issue.

Cheers,
Paul.

[Rocco]

i need more walkable areas, so i suggest to increase the limit of walkable areas and maybe regions.