Messages

[METHOD 1]

Create your sprites, labeled something like Xof12.gif, Xof7.gif, Xof5.gif. So you have 27 sprites labeled accordingly. Add them to the puzzle room as objects, all them visible set to except o12of12.gif, o0of7.gif, and o0of5.gif. Also create 24 inventory objects (since you won't need the empty ones, there will be fewer.)

There's no real need to make 27 sprites, and definitely no need to have 24 inventory objects.

First, an object on screen may be combined of just a few sprites in any combination.
Second, inventory items may have their graphic and description changed dynamically, so even if you like to keep all 3 glasses in inventory then you need 3 items at most. The water level in a glass may be set and read using Custom Properties. You add a integer property called "water level" to inventory, and then it's pure arithmetic when you use one item on another.
I did not understand whether the OP wants to have them in inventory at all though, that has to be clarified.

About combining an object from multiple sprites. Try imagining how you break an object into parts. If you are experienced with graphical software then think about graphical layers. If not, think about paper cut outs which you may stick to each other.

A glass with the water is 2 parts: 1) an empty glass shape and 2) a water inside. So you need 2 sprites to represent a glass with any water level. Maybe you don't even need a water sprite since you can use a color to paint water. Of course you may use more sprites for a glass, for example, if you want to cover water with a half-transparent glass side. But that's details. It's up for the game author to define how it should look like. Anything is possible.

How to combine sprites on screen, so that you don't see unnecessary parts of a water sprite, beyond glass's edges?

There are 3 general ways.

METHOD 1. Use either a 3rd sprite with cut from a background image, surrounding the glass, or a walk-behind. Then arrange them in layers, ordered from bottom to top (or from distant to close, for the player's perspective).

- The water is the lowest layer. Place it with some offset relative to the glass's position, depending on the wanted water level.
- The surrounding background is the middle layer. It will cover the excess of a water sprite.
- The empty glass shape is the top layer.

METHOD 2. Have several sprites per a water "step". This way you don't have to bother with cutting excess water.
Glass is one sprite, and water is constructed from N steps. These steps may be each separate sprites, or just using a single "step" sprite, depending on the shape of the glass. But you have to use several objects: 12 objects for a glass with 12 levels, 7 objects for a glass with 7 levels, and so on.

This method requires much more objects than method 1, but may be easier to setup a scene in some circumstances.
Also, if you are okay to do bit more scripting, then you may use "room overlays" instead of objects, as overlays are created and deleted dynamically, and there's no limit of them.

METHOD 3. Dynamic sprites. That may sound scary at first, because it requires more scripting, but with dynamic sprites you may create a mix of virtually any number of sprites on a single sprite, and then assign the resulting sprite to the single object.

I think for the glass with the water the order of operations should be following:

- create an empty fully transparent dynamic sprite.
- either paint a water sprite with some offset (depends on water level), or fill part of the sprite with the water color.
- have a sprite with a fully opaque glass shape, and use function CopyTransparencyMask to copy surrounding transparency to the final sprite. That will cut out any excess of painted water.
- finally paint a glass's shape which lets see water inside.


While METHOD 1 and 2 can be used for room objects, they cannot be used for inventory items (at least not with default AGS inventory). So METHOD 3 suits inventory items more.


On another hand, there are ways to simplify things. For example, you may use, say, only 3 variants of sprites for inventory item: empty glass, half-filled glass, and fully filled glass. That will let you use METHOD 1/2 for glasses in the room, and a simple solution for the glasses in inventory.

There is an extra tile offscreen horizontally and vertically, the thing I am trying to do is create an offset so that the offscreen tiles will be displayed, but doesn't seem to work with overlays. Is there a way to do what I want without manually changing the coords of every overlay?

Please elaborate, maybe with screenshots, because I could not understand this part.

Overlays are no different from other objects in regards to how they are displayed in room or inside a camera. In the end engine gathers everything as a single group of sprites (room objects, characters, room overlays, walk-behinds), and camera displays them all as same.

EDIT:
One thing that I might mention is this: in AGS you cannot move camera outside of room bounds.
If you want to have a larger scrolling area inside a small room, then you cannot use camera, but have to move the room contents in opposite direction instead.
If you have a really big map, then don't create overlays for the whole map, but create only a portion, slightly bigger than the observeable area, move these around, changing their graphics dynamically. As overlay leaves an area, "teleport" it to the opposite side.
Well, there is more here, but I'd like to know more details about the system you are trying to create first.

Why did you disable these lines?

Code: ags

x = mouse.x + 10;
y = mouse.y + 10;

They are the ones that make the gui follow the mouse.

I've only posted the lines that needed to be changed last time...

Here's the full code that has to be present:

Code: ags

  int x = mouse.x + 10;
  int y = mouse.y + 10;

  if (x < 0)
    x = 0;
  if (x + gGui9.Width > System.ViewportWidth)
    x = System.ViewportWidth - gGui9.Width;
  if (y < 0)
    y = 0;
  if (y + gGui9.Height > System.ViewportHeight)
    y = System.ViewportHeight - gGui9.Height;

  gGui9.SetPosition(x, y);

I do have that option enabled.  Now it looks like it is going to middle of the screen.

I had to recreate this situation in a test game, 640x400 resolution, "Use low-res coordinates" On.
Either of the above code variants is working for me (the one with "/2", and the one with the System.ViewportWidth).

EDIT: I had a typo in the second variant, it should be just System.ViewportWidth, without "/2".

Which variant did you use in the end? Please post the code that you have.

Could it be the "old" game coming into play?  The resolution or bitrate?  It's bit me before.

So, I've got an idea.

Earlier you mentioned that your game is 640x480.
If you go to General Settings -> Backwards Compatibility, do you have "Use low resolution co-ordinates in script" enabled?

If so, try using Screen.Width / 2 and Height / 2 instead:

Code: ags

<...>
if (x + gGui9.Width > Screen.Width / 2)
    x = Screen.Width / 2 - gGui9.Width;
<...>
if (y + gGui9.Height > Screen.Height / 2)
    y = Screen.Height / 2 - gGui9.Height;

Alternatively you may try using a old-style System.ViewportWidth and System.ViewportHeight without division by 2, because iirc they should account for the old games coordinates division:

Code: ags

<...>
if (x + gGui9.Width > System.ViewportWidth)
    x = System.ViewportWidth - gGui9.Width;
<...>
if (y + gGui9.Height > System.ViewportHeight)
    y = System.ViewportHeight - gGui9.Height;

How weird you can't see my screenshots. I can create a little YouTube if you need to see it.

You could perhaps use some image hosting, like imgur (maybe there are others)?

EDIT: Hmm, actually, it finally loaded for me. Maybe that was a temporary problem.


I'm using exact same code in a dummy game, and it prevents the gui from going off screen.

Could you double check that gGui9 is not changed anywhere below? And that it actually is a gui with overhotspot text?

I changed Mouse X & Y to 10 instead of 20 and that helped. But none of this fixed the cutoff on the right-hand side of the screen.  It still looks the same as the first picture I posted.

Please post the code you are currently using? (not the full code, but the part related to the positioning of this gui)

I cannot see the screenshots, most of them do not load up for me for some reason.

This one with the new code looks better but seems a little too low and too right.  Potentially could disappear from the screen if mouse is moved lower.

I used these lines from your code:

Code: ags

int x = mouse.x + 20;
int y = mouse.y + 20;

You may adjust these to change the relation between the mouse position and the gui.

The gui should not disappear from the screen, that's what the clamping code is preventing. It's possible to test what happens if you put some hotspot at the very screen's edge.

Another thing, since I see the code now, there are lots of lines like:

Code: ags

if (player.ActiveInventory == icigarbox) mouse.ChangeModeGraphic (eModeUseinv,  46); 

I suppose this is for setting cursor to the chosen inventory item.
Normally you should not be doing that, but assign inventory item's "CursorImage" property in the editor, then the cursor will switch to it automatically.

The code snippet that I posted earlier was only for clamping the x coordinate to the screen, nothing else. It has to be combined with the previously existed code to achieve result.

But now I see that you practically had the same code already, except you used hardcoded sizes, but idea was the same. The *only* mistake was that instead of using results of x and y variables when setting gui position, you used mouse.x, mouse.y again, thus all the calculations were lost.

The correct code might look something like:

Code: ags

int x = mouse.x + 20;
int y = mouse.y + 20;

if (x < 0)
    x = 0;
if (x + gGui9.Width > Screen.Width)
    x = Screen.Width - gGui9.Width;
if (y < 0)
    y = 0;
if (y + gGui9.Height > Screen.Height)
    y = Screen.Height - gGui9.Height;

gGui9.SetPosition(x, y); // <---- notice how SetPosition is using previously calculated x and y

When I use that code, it puts the text on the other side of the room.  See image. The cursor is on the doorknob on the bottom to leave the room but the text is on the far right at top.

It should not be happening. Please post the code that you have now.

EDIT: also, I noticed that the code that you posted earlier is strange. You are assigning x & y variables, but gGui9 is still set as "gGui9.SetPosition(mouse.x, mouse.y);". What were you using x and y for then?

How to prevent GUI from going offscreen:

Code: ags

   if (x < 0)
      x = 0;
   if (x + gGui9.Width > Screen.Width)
      x = Screen.Width - gGui9.Width;

Other recommendations: don't use literal numbers for things like screen size, use available script properties (Screen.Width, Screen.Height, Room.Width, Room.Height etc). You may be reusing same code elsewhere, and if you use properties, then it will keep working without modifications. Also less chance to make a typo.

Name your guis according to their purpose. For example, instead of gGui9 you could name it gOverhotspot. Then you will never wonder what is "gui9" if you ever return back to your game after a while.

It generates an unknown character error, as it can't find a char named after the pointer I used in the functions. That said, it doesn't seem to matter, since even if I delete the functions entirely, I get no error messages but get an empty file.

This may or not be a mistake in the Editor program, I'd like to double check, that's why I was asking for a real example that causes this.

Please post the function's declaration or an example of how such function is called.
When you say "gags", what exactly happens? do you mean error, or that it skips one? If it's error, please post error message.

Frankly, I am not sure if "Create voice actor script" handles custom functions, I will have to double check that.

But AFAIK the best solution for anything related to voice scripts is SpeechCenter plugin:
https://www.adventuregamestudio.co.uk/forums/modules-plugins-tools/editor-plugin-speech-center-version-2-2-0/

Yes, the old compiler cannot handle this case for some reason, which I forgot.
I think I tried to investigate once, but it's code is confusing me, so I failed at the time.

You have to call a real function instead:

Code: ags

parent.Children[0]

---->

Code: ags

parent.geti_Children(0)

You can still use the proper syntax when using structs and attributes declared in other script headers.

Once AGS 4 is officially released we can hopefully put an end to this issue once and for all (as it produces warnings for unlinked event handlers).

Yes, this is already in 3.6.2, and I've been already getting questions about older templates/projects posting new warnings.
Of course there's a chance that something is not working right in that regard, especially since rooms are compiled separately from the game scripts.

@updoggg which version of AGS are you using?

No, there should not be any difference in which room you start, the dialogs are unrelated.

Unless your script changes this dialog somehow, and changing to a room skips that.

1. Dialog options do not appear because by default they are not shown if there's only single enabled one, and the game selects the only one available automatically. If you want to override that, set "game.show_single_dialog_option = 1" in game_start.

2. It loops endlessly, because you have "return" instead of "stop". "Return" without a return value returns back to dialog option selection, "stop" ends the dialog. (but @eri0o already mentioned that)

I don't know how your speech is done (and I cannot see your screenshot, it does not load for me for some reason).
But if yours is a normal blocking speech, then I believe that the common approach is to set hotspot label as not visible when the blocking action is performed.

In a most primitive way this may be done like:

Code: ags

function repeatedly_execute_always()
{
    gHotspotDescription.Visible = IsInterfaceEnabled();
}

EDIT: There's a global settings that hides GUI when the interface is disabled, but unfortunately there is no per-GUI setting like that, so it has to be done in script...

If you say that this shouldn't happen, I'll just go ahead and strikethrough that text.

Well, "should not" as in "not supposed to". But whether it does or not I cannot tell, because I've never had seen the report myself and don't know what to test exactly.

I know that Editor had this issue when it failed to close the splash screen in case some library did not load. I have finally fixed this only recently.
But I do not recall same happening in case of loading a unsupported project, or creating a new project from template.