Messages

Always happy to see Dillahunt pop up, he has a fun energy. In fact, let's stick with him, in a show that also has another connection to the previous:

[Seven Days]

Well, that's Garret Dillahunt. From his credits, I learn that he was in several shows from that era that sound like they could fit the bill, like Leap Years and Millennium (as well as X-Files itself), but based off the last shot I will guess Seven Days, episode "The Gettysburg Virus."

Compare this thread: https://www.adventuregamestudio.co.uk/forums/index.php?topic=59181.0

A third option is to use the Tween module and then Tween the character scaling at the same time.

And in practice, this will almost certainly be the easiest and best solution.

Something that drives me up the wall is when people don't properly pluralize family names that end with -S, like Jennings or Jones.

I remember reading reviews of The Americans that kept talking about the Jennings family with "the Jennings do this, the Jennings do that." It's "the Jenningses"! You pluralize it just like (almost) any other noun ending in -S: kisses, gases, addresses...

What makes it so exasperating is that the correct pattern is demonstrated in the familiar expression "keeping up with the Joneses" (which also gave name to the Sierra game Jones in the Fast Lane).

I'm curious why you decided to make the acceleration multiplicative, @Crimson Wizard? It's not physically accurate, as now the actual acceleration is dependent on the speed (contrary to Newton's second law).

[cannot]

See thread here.

The documentation for this method states:

Code: ags

Character.ChangeRoomAutoPosition(int room_number, optional int newPosition)

Changes the room that the character is in, and positions him along one of the room edges.

This command simulates the behavior of the old "Go to room" interaction command from AGS 2.72 and previous versions. If newPosition is not specified or is 0, the character will be placed on the opposite side of the new room, if he is within 10 pixels of a room edge in the current room.

Alternatively, you can specify the position where he will get placed in the new room. newPosition can be 1000 for the left edge, 2000 for the right edge, 3000 for the bottom edge and 4000 for the top edge. Then, add on the offset within that edge where you want to place the character, in normal room co-ordinates.

(1) It should be clear from this description that the function cannot work correctly in any game with a room width or height greater than 1000 (because the edge encoding will overflow).

(2) The documentation also leaves undefined how the character will be positioned if it is not within 10 pixels from a room edge.

(3) Khris reports that the current behavior of the function is buggy/not according to spec:

ChangeRoomAutoPosition is buggy apparently, the Tumbleweed template's 2nd room is twice as wide and Roger ended up halfway between the room's center and edge, suggesting that AGS uses the distance from the center to calculate the new position, not the distance from the edge.

(In other words, it fails to position the character along the edge in the new room.)

If this is a regression and hasn't always behaved this way, it should be fixed for backwards compatibility. I cannot test that right now, but I'll try when I can. (And as a minor point, the documentation should be edited to be gender-neutral. I think "it" should be the preferred pronoun for characters.)

Going forward, I propose that the whole function be deprecated, since its API is fundamentally incompatible with an engine supporting larger resolutions/room sizes. If the functionality is desired in the engine, a new function with an API like the version I wrote in AGS Script could be provided:

Code: ags

Character.ChangeRoomEdge(int room_number, optional RoomEdge edge, optional int edgePosition)

(As in my implementation, I also propose removing the 10 pixel condition, and pick the room edge the character is closest to/furthest outside as the exit edge, no matter the distance.)

With the replacement SDL2.dll it fails to crash.
Thanks @Crimson Wizard! Though I don't suppose that is very helpful to isolate the problem.

So, I guess we need to
1) find out what's the difference between SDL2.dll that I built and SDL2.dll that is supplied with the AGS.
2) report to SDL2 team, as this is a SDL2 error, not AGS error.

I built from a release-2.24.1 tag from their repository, and built using provided SDL.sln with MSVS 2015.

Sounds like a plan! Where does the standard SDL2.dll that comes with AGS come from? How about just using the one you built for this test?

I'm so strongly disagreeing with this paragraph, that apparently we have a difference in views on programming at the fundamental level.

My view is that if you have a need, it's better to have some tool to solve it than no tool at all, even if the tool is not perfect. No, variadic function calls, including calls to AGS functions like Display, Character.Say and String.Format, are not "safe" (but then again, no programming language can prevent users from writing code that breaks) because they cannot be fully checked at compile time, but if it was the only way to write functions that could accept different argument types, that would still be very useful.

I have no idea how difficult the different options are to implement. For variadic functions, I imagined that the API might look something like this in use:

Code: ags

function VarFunc(int foo, String bar, ... args)
{
  if(args.Count > 0)
  switch(args.Type[0])
  {
    case eTypeInt:
      int a = args.ValueAsInt[0];
      // Do something with the argument
      break;
  }
}

In other words, the variadic arguments would be exposed to the function as a (managed?) struct with array attributes for the type info (as an enum) and to provide access to each argument by its appropriate type (really just a getter).

This would allow you to do a lot of things that can be done by function overloading or generic functions (though not different return types in one function, and probably not support for custom types as arguments), at some slight inconvenience. Of course, you couldn't guarantee at compile time that each function call has the right number and types of arguments, but that's not necessarily a huge problem. After all, String.Format() cannot confirm at compile time whether the variadic arguments match the %tags in the string either.

On the other hand, if it turns out to be easier to implement the other options, they would, together, also cover most of the interesting use cases. And with the ability to pass them on to the native variadic functions added to that, I can't really think of any realistic use case where I'd miss the remaining variadic functionality.

They all enable you to create functions that can take different argument types, though.

See thread.

AGS Script allows you to call functions like String.Format(), Character.Say() and Display() with a variable list of arguments of "arbitrary" types. However, it is not possible to create custom variadic functions in AGS Script (or, at least, there is no way to actually read the argument values). Some way to support this would make the scripting language a lot more powerful and convenient: for example, you could write mathematical functions that could take either ints or floats as arguments (function overloading), create generic functions that could, for example, manipulate arrays of arbitrary types, etc.

Of course, it may be that there are better approaches to achieve those goals, but I thought since it already exists in the engine somehow, this might be relatively easy to implement.

[AGS Editor v3.6.0.38]

The "Resolution" property for sprites used to allow you to scale up "low-resolution" sprites in "high-resolution" (above 320x240) games to 2x size. This capability is now disabled by default. However, I think there are two problems with the way it currently works.

-First, even when "Allow relative asset resolutions" is disabled, the property is available in the sprite editor and can be modified. This is confusing because changing the value has no actual effect in-game. I think the property should be hidden or made non-editable when the game-wide setting is disabled.
-Second, it used to be possible to bulk-edit this setting by selecting multiple sprites and adjusting the property. Now, the changed value is not applied to all the selected sprites, but only to the first one. I would consider this a regression.

Separately from this, I think it would be nice if the ability to pre-scale sprites was reintroduced in a more straightforward way, e.g. a sprite scaling setting that could be set to 1x, 2x, 3x, 4x.

It occurs to me that it would be possible to extend the functionality to support having other characters change rooms in this way as well. However, unless there is actual demand for this feature, I don't think it's worth the effort to implement.

"But in outline..."

1. If you can assume that the room size and room edges of the target room match that of the current room (all relevant rooms follow the same overall layout), you can calculate the target coordinates in this room and send the character to them when calling ChangeRoom(). Done.

2. If you cannot make that assumption, you can do either (a) something like what Nahuel suggests, and store the necessary information in some global array, and again calculate the target coordinates when calling ChangeRoom(); or (b) When sending other characters to a different room using the edge method, add them to a stack along with exit edge/position info; when changing rooms, check the stack to see if there are any characters in the room that need to be positioned.

[close]

Thanks. It's great to have a MacOS build of the engine, but there are a lot of situations where I prefer Wine, for various reasons:

1. I often need to use Windows-only plugins.
2. I sometimes specifically want to run/test the Windows version.
3. When developing and testing, with frequent recompiles, I find it more straightforward and convenient to launch a ready-made EXE.
4. When a game crashes on MacOS, it doesn't always provide the same reporting that the Windows build does.
5. Some Mac versions of games don't run correctly, in my experience.

Yes.

But I can't do any blocking animation here because i want the spider to keep moving a little bit while the deeath music plays.

You can have a non-blocking and a blocking animation running simultaneously, so if you make the spider animation non-blocking that shouldn't be an obstacle.

With the replacement SDL2.dll it fails to crash.
Thanks @Crimson Wizard! Though I don't suppose that is very helpful to isolate the problem.

Also, if you're playing a blocking animation, the game will block so that players can't (normally) do anything. Depending on what you want to happen after the player dies, that may be sufficient. (For example play a blocking animation for ten seconds, then jump back to the main menu or show a Restart/Reload/Quit dialog.)

I'm running Windows 10 in VirtualBox to build the project, and running the EXE in Wine, both on MacOS 10.13.6. (AGS games don't run for me in VirtualBox.) I know it's an unusual setup, but I don't have access to a native Windows box, and it works fine when built with 3.5.0.

The VM/Wine environments probably use different remappings of the AGS project folder, which may be why it doesn't match. The path in the exe_Zone.Identifier_$DATA file seems to refer to the download location of the AGS 3.5.0 editor before unzipping and installing. (I have installed it, and honestly don't know how it could even know the directory where the zip file was saved.) The $DATA file comes from building in 3.5.0; in the 3.6.0 project it's just a remnant of building the game before the update.

I'll try with the other SDL2 file. Where do I need to drop it, and do I need to recompile?