Messages

[Vinkei]

Actually, the game by itself is being redone in AGS by Vinkei.

Also fixed inventory items with alpha channel not being drawn properly.

Hourra!

I don't know for the digital display. 
But for a analogical clock, there is this french module.

Hihi! I had not realized that OP example code was not working. Sorry about giving bad advices.
I just learn very late about the character & object arrays, and now I want to use them everywhere. 

Not very elegant, but you can also iterate to all characters:

Code: AGS

int i = 0;
while (i < Game.CharacterCount) {
    if (character[i].FollowCharacter(cJack) == true) {
      player.ChangeRoom(1, 200, 2000);
      i++;
    }
}

Not sure if it is Engine related or Editor related, it is probably both.
Is there any good reason not to be able to change a custom property value within AGS script? Why is there no SetProperties functions?
Can it be possible to implement one?
That will make Custom Properties much more useful.
Not a big problem anyway, because workaround solutions are not so hard to setup.

Does AGS see the character's y-coordinate as the lowest non-transparent part of the sprite? Should all sprites in a walk cycle be cropped to have the feet touch the base ?

Short answers: No, Yes.
But you can also play with character Z coordinates, by giving them negative values on game start.

2013/03/20: new version (1.1).
Opening post was updated.
The module now works even if player is moving (it pauses the game while space bar is pressed).
Also I RTFM and change all the System.ScreenWidth() by System.ViewportWidth(). It's cleaner, and more efficient for hotspot detection.

2013/07/04: new minor version (v1.2).
Opening post was updated.
Non clickable objects won't be display anymore by the module.

is the /* */ comment style not useful enough?

Hey, I did not known that! Thanks for this magical tip, Mr Crimson Wizard!
Now I feel stupid to ask for something already implemented (the ability to quick comment large number of lines)... 
Sorry about that.

I will add it to my list of things to add.

That will be nice. But when you now the /* */, a button / keyboard shortcut is less necessary.

Is this /* */ notation mention somewhere in the manual? I can't find it in scripting tutorial.

As a novice programmer, I have taken the habit to test alternative methods of code by commenting / uncommenting portion of my scripts code.
I have not found such options in AGS editor 3.2.1 (but I may have not search at the right place...)
Would it be possible to add a button in the right click menu that will comment selected lines of code (i.e. adding a // at the beginning of each line)? and of course the reverse option will be useful too!
Am I the only one that will use this option?
Thanks.

@Billbis: Unfortunatley I was just looking that up, apparently it ignores all interfaces, which includes the buttons on them.

Oups, now I feel stupid. 
I should RTFM before giving bad advises.

Did you try ProcessClick (int x, int y, CursorMode) ?

You can store mouse.x and mouse.y when player clic. When view changes, you process another clic on the stored coordinates.

I am a bit confuse by the different SaveGameSlots that exist, and how they are explain in AGS manual:

The SaveGameDialog function uses slots numbered from 1 to 20, so if you don't want to interfere with the player's saves, I would recommend saving to slot numbers of 100 and above.

NOTE: if you specify one of the standard slots (1-50), then AGS will rearrange the other save games to make sure there is a sequence of slots from 1 upwards. Therefore, you will need to refresh any save game lists you have after calling this function.

How many SaveGameSlot categories there is ? 1 - 20, 21 - 50, 51 - 100 and 101 - infinite? What are there respective properties? Seems very unclear to me.

[compile-time scripts]

One idea that I had early on but never quite got around to sorting out is compile-time scripts.

I totally support this. It would be very useful for game optimization and intensive calculation processes. I can use this for determination of Hotspots coordinates.
(Even if I do not know how to code a "for each room in project" instructions.)
Also, it will be even better, if possible, that this possibility works with AGS script, and not just Lua code. Maybe by doing a independent - but compatible with Lua - plugin ?

Well, I am note a coder. Plugins and C++ are far to much complicated for my current skills.  But thank you for the advice.
I do not want to appear closed to optimisations, but still: do you encouter a problem with this module? Does it miss hotspots? It perfectly works with my projects (but I need more testers). We had a proverb in french: "Le mieux est l'ennemi du bien." (Better is the enemy of good.)

[here (<6 ko)]

If one thinks he is a hard worker person, he can use the beta 0.1 version of this module, which do exactly that: require two hotspot custom properties wich contain there approximate middle point corrdinates. You can found it here (<6 ko). 
However, let me insist again on the fact that last version of this module will not miss reasonnably big hotspots (i.e. >= 1/1000 of screen surface).
EDIT: The irony is that on the french forum, when I first presented this module, they asked for an automatic detection of hotspot coordinates. 

EDIT 2013/07/05: I now recommend alternative edition v1.3 of the module, and no more beta 0.1, see first post.

The way I deal with that is to create a InvItem custom property named DefaultSentence, which I fill with a funny sentence ("I won't paint this in red !" for a red paint pot).
Then I have this function:

Code: AGS

function DefaultInvInteraction(InventoryItem* item)
{
  player.Say(item.GetTextProperty("DefaultSentence"));
}

Which I use like this:

Code: AGS

function hGreyBin_UseInv()
{
  DefaultInvInteraction(player.ActiveInventory);
}

Hope that helps...

Ok, that's a fair enough question.
To clarify things, I just want to say that current version of this module (v1.0):
-does not care about GUI. Players never know if a tree is interactive in point & click, but let's admit he/she is smart enough to know that GUI buttons are clickable.
-perfectly detects object and characters, no matter how small they are. Simply by using object.X() and character.x().
-does perform a stochastic determination of hotspot coordinates, which is efficient (we will discuss about that).

Hotspot detection raises quite a long discussion on the French AGS forum.
It appears that to our knowledge, there is no hotspot.x() function or equivalent. This is quite understandable due to the very nature of hotspot, which is drawn by game maker and never move.
In such a situation, we explored three different approaches:
1- Create a hotspot.x() function, or an equivalent. But such a function needs to be feed with coordinates. So it was just two hotspot custom properties siaHotspotX and siaHotspotY. Game devellopers have to fill this custom properties for each hotspot in there game. The first version (dropbox link, <6ko) of the module was based on this. This a (very) laborious solution, but it is perfectly accurate and efficient. But come on, we can do better. 
2- Screen screen () for hotspots, pixel by pixel. Note that for 1024 x 768 games, that will require an noloopcheck. You immediatly feel that this is not a sustainable solution: it takes to long to be performed each time player press the key. You may want to do it on eEventEnterRoomBeforeFadein, so only once per room. But then you will have to do it not for each pixel at screen, but for each pixel present on the room ! Room size can be very different, so computation time will depend on room size. Even if you can admit that wider rooms need longer loading time, you do not expect any loading time in an adventure game. Furthermore, the future is made of HD, 4K and other retina display. So that clearly not a sustainable solution.
You might think that instead of screening each pixel individually, you can screen only 1 over 2 pixel. That is still a lot. So lets say one pixel over 16. That seems reasonable -but wait we will miss small and misplace hotspots!
3- That why I came to stochastic determination of hotspot coordinates. Which is reasonably fast and reasonably accurate. Perfect mix between the two first solution.
I admit it is disturbing to know that your algorithm is not perfect and might do mistakes, but lets consider the advantages:
It is independent of game resolution, but only dependent of the relative size of your hotspot and your screen area, so quite adapted for a module.
It is accurate. Yes, it is. Let assume that your hotspot area is 1/1000 of your screen area. Which is ridiculously small for a hostpot.
The gray area is 1/1000 of the surface:

Then, on first space bar pressed, it will be missed only (999/1000)^10000 = 0.005 % percent of the time. And if it is not found on fist pressure, there is more than 99,9 % chance that it will be detect on second pressure. Module remembers previously found hotspots and will not forget them until player leaves the room.
So, basically, even if it is possible, hotspot will not be missed. Try it, you will see. 
Let finished by saying that:
-Game will not crash if the module do not detect a hotspot. And player can still click on that hotspot or press space bar again. It is not a big deal.
-If you have very small hotspots and want to use my module:  make bigger hotspot, or draw an object on it, or use custom properties to enter hotspots coordinates.
-If there is an efficient and accurate way to detect hotspot, please tell me. 
-You can modify and redistribute this module freely. 
And not showing small hotspots to player is a good feature to do easter eggs!

I think GetRoomProperty might do it: AGS online manual
But maybe no.