Messages

I tried your game, and this crash is caused by the line

Code: ags

import bool GUIControl* getAgentMarker(this Character*);

This line has a syntax mistake (bool followed by GUIControl*), but Editor crashes when trying to report the error.
This crash seem to be fixed in an updated 3.5.1 (see latest patch here: https://www.adventuregamestudio.co.uk/forums/index.php?topic=60441.0).

Anyways, the correct line should probably be

Code: ags

import GUIControl* getAgentMarker(this Character*);

As far as I know, TweenFadeOut calls Visible = false secretly when transparency reaches 100, so that's same case in practice.

So, you are making whole GUI invisible, not just the button?

Well, I just created a new view (585) with exactly the same sprites and now it is working. I don't know why it was not working with the 583. As a test I have deleted the 583 and created back again and it doesn't work again. It seems that this view number is not working, at least in my project.

Is there anything in scripts triggering on view 583? Like some code in repeatedly_execute_* functions, which tests if player's view is 583 and changes it? Perhaps do "Find in project" for "583".

I seem to have fixed this, the temp build download will appear here, in about 1 hour:
https://cirrus-ci.com/task/6686114136719360

EDIT: should be available now.

Looks like I managed to reproduce it in a new test game. I made a button with all the different graphics, then when I click it, it does this:

Code: ags

function btn1_OnClick(GUIControl *control, MouseButton button)
{
  btn1.Visible = false;
  Wait(40);
  btn1.Visible = true;
}

Yes I see now; looks like I fixed one thing but broke another... This happens in both 3.5.1 and 3.6.0.

[3.6.0.37]

So earlier I used the version 3.6.0.37 and everything worked well. I have a GUI button that has a normal image, pushed image and a mouse over image. After I click the button, I make it invisible. Then, if I make it visible again, it will show the normal image (it's reseted to the default look). So all is well.

After updating to 3.6.0.40, the button behaviour changed. When I make the button visible again after clicking it and hiding it, it still displays the mouse over image (the button is highlighted). This happens even if the mouse isn't over the button. The only way to "reset" the button to the normal image, is to hover the mouse over it again, and then move the mouse away from it. This behaviour might have started already in the previous RC 4 version.

I cannot reproduce this, in a test game I made button acts properly when becoming visible again. I tried both making button invisible and whole gui invisible (and visible again).

I may mention that between 0.37 and 0.40 I did one fix related to button update after interface gets disabled and enabled (on game pause/unpause). Maybe this is connected somehow, but so far I cannot tell what went wrong.

Can I see your game somehow, is it available for download?

I am wondering if the engine gives some troubles when having more than x views in the game.

Does it work with any random view, like view 1, 2 etc?
Is it absolutely certain that view 583 does exist?
Sorry for stupid questions, I had to be sure.

BTW, I just wanted to mention, that you don't have to use raw numbers. For each View AGS generates a constant, which name corresponds to view's name in capital letters. For example, if your view is called PlayerView, then it will be PLAYERVIEW, and you can do:

Code: ags

Isaac.ChangeView(PLAYERVIEW);

Please tell, in which situation do you call this? What function; and are there any other view-related commands around these lines?

What happens if you use same command elsewhere, for instance, in game_start, or when starting some room which is easy to test, in "before fade-in" event?

Please tell, what is the version of AGS exactly you are using? This may be found in Help -> About menu.

Do I understand correctly, that there's no error message whatsoever, and the program just terminates?

Is it acceptable for you to upload your game project somewhere for AGS developers to test it? This may be done through PM on this forums, for example, and we promise that we won't distribute your game sources.

If not, we will need to think how to diagnose this problem...

Do you use any source control utility with your project (SVN, Git, and so forth)?  If yes, then you could go back in history and find a change which started causing this problem.

Alternatively, one solution (which may be quite slow) is:
1) make a full project backup
2) start removing rooms and scripts, until you reach a state at which it no longer crashes.
This will narrow the problem down a bit.

You can either use F1 and search in the Editor manual

It does not search for the parts of function names in the offline manual either, for some reason.

This looks like some possible issue with the search in both cases, because there are several "CreateFrom***" functions belonging to DynamicSprite.
Maybe it cannot reliably search for parts of function names.

Both answers are: "no", but there may be workarounds (of varied levels of ugliness).

For the first case, the existing workaround is known as "object pool", when you create alot of hidden objects in the editor, and then reuse them at runtime, remembering which ones are "in use" and which are "free". Same works for characters, and anything else. That is how arcade games were created in AGS in the past.

For the second case, depending on which particular functions do you want to use, you may sometimes utilize a hidden "reference object".
For one example, if you make a hidden object, you could animate it and make Overlay follow that animation, by setting current object's frames in late_repeatedly_execute_always.
For pathfinding, you may order a transparent object to move around, and sync Overlay's position with it.

Alternatively, you would have to reimplement these functions in script.

Is there a "GetNumberOfWalkBehindsInTheRoom()" method?

Not really, when in the editor users are presented with max areas always, regardless if they use them all or not.
The supported number of areas is hardcoded and may depend on the engine version (may be found in the manual hmm, manual is missing these), but absolute maximum is always 256, because that's a 8-bit mask.

It may be possible to scan the area mask on room load and check which pixel colors are present; afaik AGS does that for walk-behinds when cutting them into separate sprites.

@Crimson Wizard - I am not quite ready to talk about my plugin in detail yet, as would like to use it in a commercial game.

Well, there's no need to go in full detail, but perhaps only mention the general purpose would be possible? If we do not see your code, we cannot "steal" anything anyway.

Of course it's up to you; but as I participate in AGS "tech support" for more than a decade already, I find that quite often people may use overcomplicated methods. So double checking that other methods don't exist may be useful.
For another reason, this helps to learn if AGS itself is missing some features, that could be added in the future for user convenience.

[not overwritten]

The solution to this issue is to either
a) create an array of dynamic sprites so each overlay has its own
b) use the clone option so each overlay has its own

I might add, that you also may assign same dynamic sprite to multiple overlays, so long as you keep that dynamic sprite saved somewhere (in a global variable, or inside a global array) and not overwritten.

Since you are generating maps using same "tiles library", you may also use a slightly different approach.
Make an array of dynamic sprites, containing only necessary variants. You may precreate it once at the game start. Then, when you are creating overlays on a map, simply use dynamic sprites from that array.
Such approach should improve performance too.

I am writing a plugin and as part  of what my plugin needs to do, I basically need to redraw everything on the screen.

Could you please tell, for which purpose do you need to do that? I am asking, because sometimes there may be more convenient ways to achieve what you want. Maybe they already exist, if not, maybe something could be added to the plugin API, or script, to let that happen.
Like eri0o said above, depending on how much "in sync" would you like to keep your drawing, keeping your plugin up-to-date with the engine may become a struggle.

Basically, my Draw() loop is something like:

Code: ags

DrawObjects()
SortCharactersByY()
DrawCharacters()

This is wrong: the objects, and characters, and walk-behinds are all sorted among each other. So you need to gather ALL types of objects together and sort, then draw ALL of them sorted. For example, in AGS this is done by gathering structs of [sprite / order] in one std::vector from all relevant objects, then running std::sort: then you have a list of sprites to draw in a proper order.

What I think the Engine is doing is that it's basically creating the WBs as sprites and then simply sorting the sprites (chars, objects and WBs) in order of Y

It's not always Y.
Characters and Objects use Y by default. But they also have Baseline property: if it's set to 0 (by default), then they use their own Y instead. If Baseline is set to anything besides 0, then they use Baseline explicitly.
Walk-behinds always use Baseline as-is.
GUI and Overlays use ZOrder property for the similar purpose.
Since 3.6.0 Overlays may be drawn "inside" the room if they are created as "room overlays", with a special flag. In which case they use their ZOrder property to sort among characters and objects.

Summed up:
Room Objects: Y; but if Baseline !=0 then use Baseline;
Characters: Y; but if Baseline !=0 then use Baseline;
Walk-behinds: Baseline;
Overlays: ZOrder;
GUI: ZOrder;

BUT there is a mode in there called "DrawOverCharSprite". I think that my plugin could do that, but I am still not 100% how that works?

DrawOverCharSprite mode is a performance optimization done by the Software renderer. Because with the software rendering it may be slow to redraw large images on screen every time, instead every character and room object has an additional intermediate bitmap, consisting of its own sprite, and any parts of walk-behinds it is standing beyond painted over.
In other words: take a separate image size of character's sprite, paint character sprite, then paint over a piece of walk-behind which intersects with it.

Whether that is necessary for your plugin or not, - I cannot tell.

[DELETED] because I should not continue discussing unrelated things here.

It's not an "arbitrary value," it's 0, aka null.

If 0 and null are considered "the same", we have a serious problem here.

Hmm. I have no idea why Snarky even mentioned "null" in this context, as the sprites in Overlays and other game objects are referenced not by a pointer, but by an integer (sprite ID).

No, "null" is not the same as "0" in AGS script; even though it was originally based on C programming language, but it ended up something like a mix of C and C#. "Null" may be only applied to pointers. Other variables cannot be assigned "null", and pointers cannot be assigned "0" and other numbers.

In AGS script non-pointers cannot be nullified (or "undefined"), like in javascript, for example, - they always have a value.

Should AGS throw a warning (or actually, simulationSteps warnings) about that? Seems like it would clutter up the logs.

Yes, that's a valid point. This would require a somewhat different approach then, but I'm not sure which at the moment.

For example, engine could only save the information, but process it only when updating/redrawing the game - for the objects that still don't reference anything,

Anyway, that's completely separate topic, and I would not want to clutter this forum thread. There was already a ticket opened regarding this: https://github.com/adventuregamestudio/ags/issues/1880

Well, display of the placeholder sprite could be confusing, but I explained what it means in my very first reply. Both original and following script versions seem to  contain logical mistakes, where overlays kept using a DynamicSprite(s) which went out of its (their) life scope.

But warnings regarding missing sprites should be added of course, imo that's an oversight that there was none at least printed to warnings log.