Messages

I feel it's better to focus on extending plugin interface for now.

Compiling from lua (or other language) to AGS IL is a totally separate task, and will take more time to discuss and implement. Besides, as Calin mentioned, it will add restraints to external language's features and efficiency. It is also a separate way of making scripts. In fact those two ways may co-exist.

The thing I would change are the icons themselves and make the image be a bit more modern and eye-catching so as to make the engine look less like an 90's software tool and more like a.. now.. tool.

Heh, that's a mockup. I just ripped those from current AGS editor, some from Paint.NET and others are quick-drawn by hand

I am of the opinion that expanding the plugin interface is the way to go here, specifically giving plugins access to hook onto game scripting events.

Do you mean registering callback that is called along/instead of default event handlers?
JJS mentioned he is to integrate this plugin in his portable engine. He may update plugin interface perhaps. I will check too if I get time.

EDIT:
There's RequestEventHook function in plugin API. But it allows hooking to very limited number of events, mostly room events (enter/leave) drawing and loading events.
Also, plugin callbacks are run explicitly in the engine code. Adding more hooks this way will require adding calls throughout the engine. That should not be difficult, but I don't like it this way. Perhaps there should be an extendable implemenation. Uh, but that's rather for Engine development board.

Following is my idea on how the Editor interface could be improved accompanied by few mockup screenshots.
I don't like writing long explanations, let's just say those suggestions are based on my own experience working with AGS Editor and also looking and reading on how others work with it (something I mentioned here for instance: http://www.adventuregamestudio.co.uk/yabb/index.php?topic=45623.msg624000#msg624000).

Oh, and important note. That is not in my plans to work on this right away. To be honest I'd wish someone else did this . I do not have much free time, I am not as proficient in C# as in C++, and there are people who know Editor source quite well already. That is - if they like the concept of course.


Let's look on new Project Explorer first:


It consists of three panels:
1. Project item type selection. Those are moved out from the project tree where were represented by root nodes, and now are represented by bitmap buttons.
The upper part has buttons that open new editor panes in the main workspace: General Settings, Colors, Sprites, Text Parser, Lip Sync, Global Variables.
The lower part has buttons that will change the project tree contents: GUI, Inventory items, Dialogs, Views, Characters, Mouse Cursors, Fonts, Audio, Scripts, Plugins, Rooms, Translations.
2. The Search/Filter. Input box is for entering a search line. Buttons have following meanings:
- clear input box;
- filter out on/off (when enabled the tree will hide all the non-matching elements);
- case (in)sensitivty on/off;
- match full name on/off;
- colour picker to mark out matching items.
3. The well known project tree. Now it shows only items of the type which is selected on head panel.


Let's move to the Room editor pane:

As you may notice I've changed the look of background-related buttons, they are:
- Change selected background;
- Import new background; there should not be such item in the combo-box now;
- Delete background;
- Export background.
The "Show this room's" combo-box is replaced with a set of bitmap buttons:
- Nothing (pure background);
- Edges;
- Characters;
- Objects;
- Hotspots;
- Walkable areas;
- Walk-behinds;
- Regions;


Finally a totally new Room Explorer pane. Since of 3.2.2 we have docking panels it will be easy to put it in the position you find appropriate.


As you should notice it's the same gui class as Project Explorer. The upper panel lets you select a content type. The buttons are the same as on Room editor pane with an exception for Edges (since they are not room elements on their own).
By selecting items in the tree you will open corresponding properties. There may be an option to either switch Room view to the element type when one is selected or not.


What do you think of this?

I am actually wondering if there's a way to fully substitute AGSScript with Lua.
To make myself clear - I am not thinking Lua is the best choice (never used it actually) nor that AGSScript should be thrashed right away.
My thought is that since there's an alternate scripting language why not make it fully integrated without AGSScript as an intermediate.
There was a discussion about this earlier (http://www.adventuregamestudio.co.uk/yabb/index.php?topic=46157.msg622114#msg622114).
Not sure if that's easy task though. Just something to keep in mind.

But we would still have to have event callbacks in the AGSScript, like game_start, repeatedly_execute, object interactions?

Do I understand correct that the plugin basically adds a lua-scripts interpreter to the engine?
Sorry, that's probably obvious, just wanted to make it fully clear for myself.

I was a bit nostalgic and reviewed some of the ancient threads I participated in, and I found this:
http://www.adventuregamestudio.co.uk/yabb/index.php?topic=37559.msg494100#msg494100

I remember there was some TCP/IP plugin? Would it be possible to make anything like that?

Now, if we remove the multiplayer aspect and decide to stick to ole good single-player, here's another way to implement that idea.
First the criminal plays the game and commits the crime, then a data file is saved and passed to another player who starts the game as detective, loads that data file and will have to find clues left by criminal player.

Sorry, I didn't understand why you were opposed to the hard-coded interactions. But again, I think the next best thing if we do not have the ability to add interactions to the editor is to hard code it. I think adding mouse cursor modes is heading in the right direction, but not streamlined enough.

Well, you see, problem with AGS, as being mentioned by Chris Jones himself, is that it was written in not a very best way. Ah, well, why to be so tender... it is coded just terribly .
In fact I am pretty much amazed by stoicism CJ had to have to maintain this program for nearly 13 or 14 years.

So, what I meant to say is that many things there were coded the way they are because that did have sense back then, 10 years ago, when everyone wanted to make games with Sierra-like interface. As more time passed more customizable features were added. But it would require lots of rewriting to change it all.

So now when we have this opportunity (at least in theory) I feel a bit strange when I see someone attempts to extend the thing that should not be extended but rather replaced.

Why do you say that? I always liked the idea that there were hard-coded interactions in AGS as it made programming for people like me easier to do.

I'll try to elaborate.
The question here is not how those interactions look in the editor and script. The question is how they look in the engine.
Better idea would be to allow creating interaction types right in the editor, similar to how you create custom properties. That would allow ultimate flexibility.
Newbies could use templates that define some simple default interaction schemas, while hardcore game devs could create their own schemas with custom itneraction types.
Now what you do is making a bunch of interactions that will be in game regardless if game dev wants them to be there or not. And if the engine development will follow this logic, we would have to add more and more hard-coded interactions for every interaction type users would like to have (I dunno, Shoot, Eat, Drink, Dance...).

So, to be frank, I do not see any benefit from this, unless you are doing this for learning purposes only.

On your code.
Why are you using constant values (11,12,13 etc) when you just declared macros for those types? That makes no sense.
More than that, you do realize that you set a "passon" variable to the same value as the mood? Why writing all those "else if" lines when you could just write

Code: cpp

passon = mood;

only once.
Same for inventory:

Code: cpp

run_event_block_inv(iit, mode);

I hadn't paid much attention to how that works, so I'll have too look more to give any further opinion.

I am sorry to say this, but I believe hard-coding interaction modes in the engine is one of the worst ideas I've heard.
Even the fact that few are hard-coded in the current AGS is bad enough already.

[Override built-in inventory window click handling]

I probably know. Strange how I could forget about this one.

This is an excerpt from the manual about game's General Settings:

Override built-in inventory window click handling
Override built-in inventory window click handling - AGS has some built-in processing of Inventory Window GUI controls, whereby a right-click will Look at the item, and a left click will select it if the cursor mode is Interact...

Try to toggle that option to True (General Settings -> Inventory -> Override built-in inventory window click handling).

On other hand you will have to write additional code for selecting items by left click.
Test for eMouseLeftInv mouse "button" (not just eMouseLeft) to know when left click is made over inventory item.

Just a note: no one can tell when the refactored version of code will be put into use. It would probably be better to do this in dev.3.2.2 or JJS's "main" if you expect early update.

Since CHM is made of html pages, wouldn't that be possible to update both online and offline version simultaneously by maintaining a shared bunch of pages that would be copied both to site and repository? Unless there will be any problems with relative links or something.

[use indentation]

That's usually monkey's or Khris's right to say this , but...
for the love of God, please, please! use indentation! It is really hard to understand the code without one. And probably will help you too.
Here's the example of what I am talking about, your code with fixed indentation:

Code: AGS

function on_event (EventType event, int data)
{
  if (event == eEventLoseInventory) 
  {
     mouse.Mode = eModeInteract;
  } 
  if (event == eEventGUIMouseDown && mouse.IsButtonDown(eMouseRight) && player.ActiveInventory != null && data == gInventory.ID) 
  {
     GUIControl *theControl = GUIControl.GetAtScreenXY(mouse.x, mouse.y);
     if (theControl==invCustomInv) //the InvWindow
     {
        InventoryItem *i = InventoryItem.GetAtScreenXY(mouse.x, mouse.y);
        if (i == null)
        { 
           player.ActiveInventory = null;  
           mouse.Mode=eModeInteract;
        }
     }
   }
}

See? now it is much easier to understand what's what, you can distinct different conditional braches at a single glance.

Okay, now, about your problem.
Do I understand correct that you want mouse cursor should change to Interact mode every time after you used the inventory? Then, I believe, your code does not do what it has to.
Let's take the first piece of your code:

Code: ags

if (event == eEventLoseInventory) 
{
   mouse.Mode = eModeInteract;
} 

This code means that every time character looses inventory item (an item is removed from inventory) the mouse cursor mode will be changed to Interact regardless of what it was. That is - if it was Look cursor, or Talk cursor - or any other cursor - it will still change to Interact. Is it really what you want?

The second part of code is executed when you press mouse over Inventory Window. It changes mouse cursor to Interact and removes active inventory item if there's no other item under the cursor.

In other words, there's nothing in this code related to inventory item being used at all.

There are few ways to do what you want, depending on how you handle interactions in general.
For example, you have this in on_mouse_click function (I copied your code from the other recent thread where you posted it):

Code: ags

function on_mouse_click()
{
   if (IsGamePaused() == 1)
   {
     // Game is paused, so do nothing (ie. don't allow mouse click)
   }
   else if (button == eMouseLeft) 
   {
      ProcessClick( mouse.x, mouse.y, mouse.Mode );
   }
   ..... your other code ......
}

Change the code this way:

Code: ags

   ...
   else if (button == eMouseLeft) 
   {
      int mode_was = mouse.Mode; // remember the mouse mode before interaction
      int has_interaction = IsInteractionAvailable (mouse.x, mouse.y, mouse.Mode); // will we have any interaction here?
      ProcessClick( mouse.x, mouse.y, mouse.Mode ); // do actual interaction

      // if we had some interaction and mode was 'use inventory item', then...
      if (mode_was == eModeUseinv && has_interaction != 0)
      {
         // change mode to Interact
         mouse.Mode = eModeInteract;
      }
   }
   ...

I should underline that the code above is an example of how it could be done. I can't guarantee it is the most optimal way to do this in general or for your case.

Are there any plans to improve the manual?

Personally I think it lacks distinct topics on using certain parts of editor. For example, there's no "Room Editor" or "Properties Pane" topics, these are described only in tutorials, which is not really good in my opinion. I remember that caused great confusion for me when I just started to use AGS (I couldn't figure out where to look for information).

Also, I noticed that beginners keep asking same questions about most basic behavior over time. It means that either some information is missing or explained not well enough.
What about searching through Technical board and gather FAQ? It may later be used to improve existing topics, remake FAQ section, or, perhaps, add new HOWTO section in the manual that would cover tips on implementing most desired non-basic game features.


BTW, online manual still describes AGS 2.72 in Tutorial section.

EDIT: maybe I should have posted this in Adventure Related talk board to bring more attention?

It's actually not mentioned in the tutorial, and I remember someone else having the same problem.

Oh dear... I could swear I've seen it, but now I rechecked and it's not there. Sorry.
There's a screenshot of room editor with walkable area list box marked by red oval. But no explanation.

You can animate the background (importing different backgrounds for the same room) and set up the hotspot as usually

That depends... if he needs several hotspots to animate independently and even more change animations over time or at certain events, then it is be better to use objects.
Also keep in mind that there could be only 5 frames in background animation.

I am unable to draw walkable areas on my background.  No matter which button I use -- left or right -- I get the error message that I am currently using the eraser and I should select a different property from the menu.  Honestly, this has me dumbfounded.

I must agree that this is one the things in AGS Editor that may confuse new users.
But the message does not say "select a different property", it actually say "change selection in the list above Property pane". That's what Feijotikus is pointing to.

Oh, and I really hate to say this ('cause this usually sounds like RTFM), but it is all explained in the game manual. Look for Tutorial -> Starting off -> Tutorial part 2 (creating your first room).

I am not Monkey

Thinking of it, perhaps I started from wrong direction.
The action should not happen at first place if there's nothing coded. That means if that action takes place, it was coded. Now all you need is to find the code and remove it.

What's in yours on_mouse_click function?
Do you maybe have some "Look at inventory" event handlers for your inventory items?
Also: is your game based on any game template?