Messages

@MrGreen , if you like, here's a temporary AGS 4 build with few fixes to autocomplete:
https://cirrus-ci.com/task/6692180024098816

I found there were several mistakes in it, even prior to addition of array.Length property. For example, if you had array "Struct myarray[10];" and typed "myarray.", the autocomplete would show Struct's members, although you cannot access it without providing element index first.
I tried to fix mistakes with array autocomplete which I found, to make it work depending on whether you have a [n] index or not, whether it's a indexed property which is not a real array, and make sure that it works in chained access expressions too (like "myarray[1].member.memberarray[5].").

King's Quest II+, Quest for Glory II VGA and Heroine's Quest are examples of Sierra-style AGS games with arcade sequences.

I was wondering if I should mention these, since the OP asked about "top down" arcade style. But indeed, if we speak of arcade scenes in a broad sense, there are multiple games that feature combat sequences. Besides the aforementioned games that feature QFG-like combat, there are also games like "Gemini Rue" which has a side-view shooting combat sequence with "shoot or cover" mechanic.

2. Rail shooter sequences where the player moves a targeting reticle with the mouse and shoots at enemies that jump out from behind cover, a'la Lethal Enforcers. (This would actually be an important and recurring element of my idea)

I suddenly remembered that I had a "rail shooter" demo game many years ago:
https://www.mediafire.com/file/jamm30qmmxm/ShootingGallery_Demo2.zip/file
https://www.mediafire.com/file/exxi3y0ddy1/ShootingGallery_Demo3.zip/file
Controls: mouse to aim and shoot, Left/Right arrow keys to move sideways.

I cannot recall if I still have a project source anywhere, but i may try looking around in a spare time.

There's a sticky list of the open-sourced AGS games in Advanced Tech Forums:
https://www.adventuregamestudio.co.uk/forums/advanced-technical-forum/a-sticky-list-with-open-source-ags-games/
Few of those are arcades.

These are not all arcades done with AGS. One way to find these is to go to the AGS game database, and search for "non-adventure games".
Games that were part adventure part arcade are more uncommon and may be difficult to find, because there's no tag to mark ones as such (afaik).

In general case you can set their position with offset in script. For characters there's LockViewAligned and LockViewOffset functions. I don't remember what LockViewAligned is suitable for, but LockViewOffset probably is suitable for the described situation.

The offset is calculated by taking current frame/graphic size and multiplying by scale, for example:

Code: ags

int offset_x_align_left = (pic_width / 2) * mycharacter.Scaling / 100
int offset_x_align_right = -(pic_width / 2) * mycharacter.Scaling / 100

Getting current graphic size may be done by combining Game.GetViewFrame and Game.SpriteWidth/Height:

Code: ags

ViewFrame* vf = Game,GetViewFrame(mycharacter.View, mycharacter.Loop, mycharacter.Frame);
int frame_width = Game.SpriteWidth[vf.Graphic];
int frame_height = Game.SpriteHeight[vf.Graphic];

EDIT: I just remembered that since AGS 3.6.1 LockViewOffset is scaled automatically if you have a "Scale Character sprite offsets" option enabled in General Settings. So in that case you don't have to multiply by scale, and provide offset in unscaled units.

Hi!
Videos cannot be played with any other extension than ogv.
PlayVideo (still possible in 3.6), and the new VideoPlayer also doesn't play with other extensions.
Is this a bug or planned?

OGV is the only format that AGS supports since 3.6.0.

Previously AGS also supported MP3/AVI formats, but these were implemented using DirectShow interface (part of DirectX) and worked only if
- game is run on Windows
- necessary codecs are installed in the system.
that's why it was removed.

In order to support more formats we'd need to include other video decoding libraries into the engine, which is not in the immediate plans.
This may be addressed later though. Another option is implementing a support for plugins to decode videos.

An array of managed structs is in effect an array of pointers. When you create an array, you have a list of pointers, each initialized as "null", but no actual objects yet. So you need to create objects for each element of array separately:

Code: ags

testStruct_Array = new TestStruct[10];
for (int i = 0; i < testStruct_Array.Length; i++)
    testStruct_Array[i] = new TestStruct;

If you had a dynamic array of regular (non-managed) structs, then creating array would be enough.

EDIT:
The fact that Length property is shown in a hint list after "testStruct_Array[0].", instead of struct members - that's a autocomplete bug, and must be fixed in the editor.

I can see mouse.SetPosition calls in the script, maybe that does not work?

Could you at least tell which part does not work properly, what to look for?

I think the clone option was removed in ags4 from the graphic overlay create method.

It was not removed. I thought about removing it once, but did not do so.

What I wanted to verify with the last version of AGS is a bug I found in the previous version : it seems overlays have a problem. I use an overlay when I right click on a button to make it "selected", it's a dynamic sprite where I draw colored lines on a transparent background. When I was on AGS 3.6, it worked perfectly, but since I'm in 4.0, it's a weird thing : the Overlay seems to take for its graphic the last sprite that was created by the game.

What does "right click to make it selected" mean in terms of script? how is overlay and dynamic sprite declared, how sprite is assigned to overlay? Please give actual details, or better post a script of what you are doing.

By the way, I don't know why sprite 0 was the last dynamicsprite created in script, because sprite 0 is existing in the sprites saved in editor (it's a blank square for me). Perhaps the problem is that overlay's graphic doesn't properly resets to sprite 0 in engine ?

Since v3.6.2 (and in 4,0) Engine no longer reset any objects to sprite 0 when the dynamic sprite is deleted. This was done on purpose, for several reasons.

Hi @Crimson Wizard , I encounter a crash when launching the new version (not my game, but the editor) of AGS 4.0 (I can't launch it, everytime the same crash), here's what's displayed :

https://drive.google.com/file/d/1iNk0P9ZIMU9-EgFXNHexVFDCIpjn6ZWu/view?usp=sharing

You need to install a newer VC Redistributable. This is the same case as with the latest 3.6.2 version, but I forgot to mention it here.

Either use installer program, which contains VC Redist, or download and install separately using this link:
https://download.visualstudio.microsoft.com/download/pr/5319f718-2a84-4aff-86be-8dbdefd92ca1/DD1A8BE03398367745A87A5E35BEBDAB00FDAD080CF42AF0C3F20802D08C25D4/VC_redist.x86.exe

Entirely out of curiosity, is there a reason for some of the colour features being ordered RGBA, and others in ARGB? And is that purely on the backend, or will we using both formats at different times in the 4.0 editor?

It's ARGB when typed as a number in the script for two reasons:
- because then it matches internal representation in the engine, so less data to convert and less hassle.
- because then it's possible to cast between RGB and ARGB by a simple assignment and adding alpha with bitwise OR, e.g. "int argb = rgb | 0xFF000000". If it were RGBA, then extra conversion would be required in such case.


On another hand, it's made RGBA when you type the color in the properties in the editor, in a string like "128;64;64;255". This is made so to let Alpha be optional, in which case it's reduced to 3 numbers ("128;64;64"). If alpha were first, then it would have to be made obligatory. This is done for user convenience, in assumption that 99% of colors set this way will be opaque with default alpha of 255.
But since this form is used in GUI only, it may be changed too if found inconvenient, without affecting the game data.

Fully resolved in the latest AGS 4 release now.

[IMPORTANT:]

Updated to Alpha 18
(Please use download links in the first post)

IMPORTANT: starting from this version Editor will require a different VC Redistributable to run.
Installer contains the VC Redist, but if you are getting AGS in an archive, and the necessary component does not happen to already be on your system, then here's a download link to Microsoft's site:
https://download.visualstudio.microsoft.com/download/pr/5319f718-2a84-4aff-86be-8dbdefd92ca1/DD1A8BE03398367745A87A5E35BEBDAB00FDAD080CF42AF0C3F20802D08C25D4/VC_redist.x86.exe

Contains all the new features and fixes from 3.6.2 Beta 6 (excepts ones related to backwards compatibility).


Own changes:

Common:
 - Color number properties now correspond to the encoded 32-bit ARGB (A8R8G8B8 format).

Editor:
 - In 32-bit game projects you can assign full RGBA color definition, where alpha is optional, and is assumed 255 if not specified. Color value 0 means "transparent" regardless of game's color depth.
   NOTE: color picker currently does not let define alpha, so only opaque colors may be selected using it; but you may still enter RGBA value into properties by hand as "RR; GG; BB; AA".

Compiler:
 - Fixed unnecessary warnings about function parameters in function declarations "hiding" global functions of same name. Only report such warnings for function bodies.
 - Fixed incorrect "overflow" error reported for a bitwise left shift operation, when shifting a byte value by 24 bits.

Script API:
- All existing Color properties now assume full ARGB values (0xAARRGGBB) in 32-bit games. This means that you *must* specify alpha value when assigning a color number directly, otherwise the game will treat the color as fully transparent.
- Added Game.GetColorFromRGBA() function that creates a color number for red, green, blue and alpha combination.
- Added DrawingSurface.BlendMode property that lets define blend mode for primitive drawing operations (line, rectangle, triangle, etc).
- Added DrawingSurface.SetPixel() function that lets to set a pixel value of specified color, disregarding any surface's drawing settings.

Engine:
 - All color settings in a 32-bit game now respect alpha value, meaning they may be translucent. This refers to almost anything that may have a color: texts, GUI backgrounds, DrawingSurface's DrawingColor, and so forth. The exceptions are things that only make sense with opaque color: Tint settings, and screen Fade effects.
 - Fixed Type.GetByName() functions not working again.
 - Fixed loss of precision in sprite rotation, which could cause rotating sprites by a multiple of 90 degrees to cause unexpected shifts of an image by few pixels (regression in 4.0 Alpha).
 - Fixed 32-bit images loaded with DynamicSprite.CreateFromFile() becoming completely transparent (regression since previous 4.0 Alphas).
 - Fixed GUI not redrawing properly by software renderer.


This update is likely the last change to the color format. I wish it was done altogether from the start, but somehow the changes were split into multiple updates, where one update made it proper 32-bit color but without alpha, and this update finally makes AGS respect alpha component as well.

If you're upgrading an older project, you need to know that:
- Color properties in the editor are supposed to update automatically.
- In script, if you were using Game.GetColorFromRGB when assigning colors, then no changes are necessary.
- But if you were assigning color numbers directly, then you will have to fix them all to the ARGB format: either use Game.GetColorFromRGB, or change to a number that has ARGB encoded. The easiest way to do the latter is to write color in hexadecimal notation (some graphic editors let you display colors like that): that is - 0xAARRGGBB; for example: 0xFF000000 is a opaque black, 0xFFFF0000 is a opaque red, 0x8000FF00 is a half-translucent green, and so forth. Note that if you're writing colors as a raw number, then you must define opacity (alpha) value, there's no way around it, except using Game.GetColorFromRGB that automatically makes opaque color. If you forget alpha, then your color will be treated as transparent.

Handler functions for character or inventory events still need to be inside the global script unfortunately, but IIRC AGS4 will address this.

3.6.2 already lets select the script module for the handlers:
https://www.adventuregamestudio.co.uk/forums/ags-engine-editor-releases/ags-3-6-2-beta-1-a-wip-3-6-update/

Separating the code among multiple modules is a matter of organization and convenience, and AGS is not much different in this regard compared to other programming systems.

I don't think there's any common agreement on "how much" code should be in a single script, it's a subjective view. But I'd say that besides the amount, there's a strong reason to split the code belonging to different features. To give a quick example: math functions, drawing functions, functions for mini-games (not related to regular gameplay), and so on.

Advantages of having code in separate scripts are:
1. Easier to work with the big project.
2. Enforce encapsulation: the idea that a feature hides its internal work from other code, which helps making it consistent and stable.
3. Having a module with certain feature, or thematically related functions, which you may share among multiple projects.

The only disadvantage I may think of is that this may require some extra work organizing things, but it usually pays off by making it easier to work further.

In AGS there's a cap of total script modules that you may have, for technical reasons: it's 128 in the current stable version and 1024 starting with 3.6.2.

Alright, the situation is clear now. Since your game is 16-bit, then you won't be able to have translucent effects (at least not easily).

Speaking of cutting out firefly frames, perhaps your artist can make these cuts for you? .

Speaking of coroutines, by coincidence, I've got a working test with coroutines, for AGS 4 version branch:
https://www.adventuregamestudio.co.uk/forums/editor-development/feature-request-behavior-of-hotspot-that-results-in-a-room-change/msg636668451/#msg636668451

That's only a proof of concept, not a complete feature.

The location for the black sprites shows the EXACT SAME LOCATION as the locations for the project with proper sprites.

As in, there is a cardboard box sprite, and for both projects the sprite location is set to the exact same C drive images location. It's just that for one of them, all of the sprites are black, and in the other, all of the sprites show up.

I tried to reimport from source, and nothing seemed to happen (as described above). So I'm still at a loss for how or why all of the sprites are black, if for both projects, they all point to the same sprites!

This is quite strange, and I do not have a ready explanation.

Would it be acceptable for you to send us those two projects for analysis, along with the original images that it mentions?

@Crimson Wizard , hey, just had an idea here, what if when pasting from the clipboard we added a mark in somewhere in the sprite list and then when restoring it could have a message - or output to the output window or a file - that says "sprites 3,4,5 can't be restored because their sources are from the clipboard", or just something like it?

Sprites from clipboard are identified by not having a SourceFile set. Strictly speaking, it does not matter why it's not set, or where it came from, if there's no file path, then it cannot be restored.