Messages

@Kweepa, do you still have this module lying around? The links are 404.

If updates come out with some reasonable interval (let's say every couple of months), you could also announce them separately as "episode 1/2/3" etc.

how do I remove it from the topic that is in games in production?

You don't. Besides, the thread might be useful to discuss the future in-development process.

- GetTextHeight() no longer reduces "width" parameter by -1. This was an ancient mistake in the engine kept for many years for backwards compatibility.

Do you mean GetTextWidth()?

It also helps with coding, since there's less characters to write. 

That's why God created autocomplete.

I think it absolutely makes sense to remove the limitation (which is clearly a legacy of old-school MS-DOS and its 8-character filenames); meanwhile as a workaround, if it were me I would probably stick a number at the front of the colliding character names, so that cJoseph and cJosephine become c1Joseph and c2Josephine (and corresponding voice files 1jos_.ogg and 2jos_.ogg), for example.

I've updated the module to v0.6. See first post.

The main change in this version is that (as suggested by @eri0o) it now syncs based on the audio clip time stamp, rather than calculating the time based on counting frames. This gives more accurate results, and my subjective impression is that it significantly improves the quality of the lip sync timing.

I've also made sure that it skips syncing when skipping a cut scene (this should improve performance enormously if skipping past many synced lines), and set it to use a packaged data directory ($DATA$/sync) by default on AGS v3.6.0 and later.

There are also a couple of additions/changes to the API and documentation to help with the issues Dave Gilbert and Akril15 faced, and to make it easier to find the sync files on case-sensitive file systems.

EDIT: @Snarky your example is not suitable for AGS 3, because you have a managed struct with dynamic Strings in it. It may be better to have an example of regular structs.

Managed structs are so much more convenient to work with that even if I need them to have Strings (or other managed types), I usually use a property to access ones stored in an array outside of the struct. Though this does require using a factory method to create them, so the example code isn't fully accurate.

That particular way of creating entries doesn't work in AGS, but you can still have arrays.

To set all the values of each entry and add it to the list in one go, make a helper function:

Code: ags

Spell* spell_list[];
int spellCount;

void AddSpell(String name, int val, String description, int otherVal, SpellType type)
{
  if(spellCount == max_spells)
  {
    // Error! Log error and/or quit game 
  }
  spell_list[spellCount] = new Spell;

  // Set the fields
  spell_list[spellCount].Name = name;
  spell_list[spellCount].Value = val;
  spell_list[spellCount].Description = description;
  spell_list[spellCount].OtherValue = otherVal;
  spell_list[spellCount].Type = type;

  spellCount++;
}

Then you can do:

Code: ags

  AddSpell("Acquire Aardvark", 3, "You summon an aardvark.", 20, eDamageNone);
  AddSpell("Superior Acquire Aardvark", 13, "You summon a superior aardvark ", 40, eDamageNone);
  // ...

Which is nearly as easy as the list-declaration style.

Don't play the video in repeatedly_execute(). That's telling AGS to start playing the video again each game cycle.

When it comes to repeatedly_execute() it's not a matter of memory, but of processing (i.e. work the computer has to do). Your computer can do only so much work each game cycle: if you ask it to do too much, the game will start to lag (slow down or stutter).

In this case, the amount of work is trivial, so it doesn't make a significant difference, but in general it's something it's good to be aware of, and to learn how to optimize the code to reduce the amount of work performed (usually by structuring it differently). Khris's version is an optimization because it does less work each game cycle, only checking the list of spells when it's actually necessary to update (once per second).

Another possible optimization for something like this would be to keep a temporary list of the spells that are currently on cooldown, and only update those rather than checking the whole list; but since the list is very short (only 10 entries) and the work of checking the other spells very light, and since adding this "optimization" would require more code (and another array, which takes up memory), it doesn't make sense in this case. But if you had 10,000 different spells, and checking if each was on cooldown took a lot of time/effort, that would be something worth doing. (A middle-ground would be to just keep a counter of how many spells are currently on cooldown; that way you don't have to do anything if the counter is 0.)

But it's good that you're asking. As a general rule of thumb, using repeatedly_execute() is usually the "wrong" solution to most problems when you're starting out. By which I mean that inexperienced AGS coders very often jump to "forcing" things in repeatedly_execute() because they can't think of a better solution. This results in code that is inefficient, inelegant, and sometimes liable to create further problems—when not outright wrong.

Do I just have to give up on him having naturalistic pathing and add a simple frame counter to do the room swaps, only worrying about his position if the player enters a room he's in or vice versa?

Quick answer: yes. Only the room the player is currently in is loaded, so the engine doesn't have access to walkable area masks etc. for other rooms, and cannot do pathfinding there.

It would probably be possible to do some quick math when the player enters the room the roaming character is currently in to determine where they should be based on the timing, to achieve the same effect from the player's POV.

Also is there a way to adjust the volume of sound effects without having to tie it to a char or channel or object?

Sure. If you group all sound effects under a particular AudioType, you can adjust the default volume for that AudioType (Game.SetAudioTypeVolume); or you can adjust it individually as you play the sound:

Code: ags

  AudioChannel* ac = myClip.Play();
  ac.Volume = 80;

This code is technically unsafe because AudioClip.Play() will return null if the clip fails to play for some reason—for example that you've exceeded the number of available AudioChannels and the currently playing audio is all higher-priority than the clip you're trying to play. So to be on the safe side you should do a null-check, but this is pretty tedious to do every time, and I think most game makers tend to cross their fingers and hope to get away with it.

Or you could write a helper function:

Code: ags

Channel* PlayVolume(this AudioClip*, int vol)
{
  AudioChannel* ac = myClip.Play();
  if(ac != null)
    ac.Volume = vol;
}

And then you can just call:

Code: ags

  myClip.PlayVolume(80);

Yeah, what CW said. That's not an issue of scaling the mouse cursor graphic, but "scaling" the mouse coordinates. I think I mentioned to you on Discord that to avoid this, you'll have to snap the mouse coordinates to the closest multiple of the scaling factor.

Just wanted to say that I think it's great that you're opening all these "tickets," even if it turns out that some of them are not priorities to implement. Once you've used the engine for a while, you get used to its quirks, and it can make you blind to things that should be fixed.

With TextBox this is handled in a dumb way, the first enabled TextBox found receives input.

Are you sure about that? The way I remember it, every TextBox currently visible receives the input.

What "items" are you referring to here? In AGS 4.0 a lot more project assets are stored as files in folders, so there is less need to export things.

So the only thing I can think of at this time is to having an object for presenting the mouse sprite in any of the rooms (since we can't have global objects)

I still think the easiest way is the no-code solution of simply importing a sprite that has been scaled up for the cursor graphic. In most games the number of cursor sprites is very limited, so this is quick to do and won't make any appreciable difference to game size.

I question whether there is any actual need for engine support here.

Scaling cursor graphic is as trivial as creating a resized dynamic sprite and setting to cursor.

There are a few wrinkles with this, if you want a "general" solution that "just works":

-There's no way to know the cursor's hotspot coordinates (the cursor pixel that acts as the "point" of interaction; e.g. in the LucasArts crosshair it's the center of the sprite), so when scaling up the cursor you have to just know what it should be and manually set it
-You can have animated cursors, and in that case you need to replace the sprites in the view. (Possible to do, but adds complication; also, if for some reason you reuse the view for something else, e.g. an in-game manual, that will also be affected.)
-If you're using a module that changes the mouse graphics, it won't respect the rescaling

Labels are not conceived as an interactable element, so the concept of "highlight" doesn't really apply to them. It is possible to implement it in script if required.

But I agree that all controls should offer other text alignment options, at least right-alignment.

* The entire Parser could actually be replaced with an external text file for adding/editing words and types, instead of needing to edit everyting direclty in the editor.

It wouldn't be too difficult to write a parser module that could do this. (Personally I'm not convinced that a parser belongs in the core AGS engine/editor.)

That's my thinking as well, but on Discord @Crimson Wizard had a different take, essentially arguing (if I have it right) that even though inventory[0] is not a valid inventory item, Game.InventoryItemCount should be equal to the size of the inventory[] array (i.e. the highest valid index + 1).

I think the problem here is that the design choice to use 1-based inventory ID numbers but access them through an array (with 0-based indexing) is inherently inconsistent, so there is no truly "correct" way to do it. The proper fix would be to start the IDs from zero.

search for sprite sheets of games that you like and draw over them and change it a little bit to your taste

I'll point out that the AGS Awards client includes an avatar gallery that auto-plays forward walk animations for a whole bunch of characters, and many of those assets have been theoretically open-sourced under a Creative Commons license. (Maybe all of them at this point? I seem to recall a discussion about removing any that weren't.) It's just that nobody has done the work of actually uploading them anywhere, but I have most of them on my computer/dropbox.