Very cool!

Thanks for writing out the logic of how you would achieve that elsewhere. My brain is a bit foggy today and I'm not in a good spot to write out all of the logic, but let me tell you how I would get started.

This is a non-scripting approach, as I agree, the scripting side of Construct removes a lot of the advantages of Construct.

Create a Family. I'll call it inventoryFamily for now.

Think of the Family as the equivalent of a class. Of course a lot of differences though. Adding sprites to this family will add all the behaviors, effects, and instance variables to the sprite.

To start, will add a string instance variable to the inventoryFamily. I'd just call it inventory.

Create a function for addToInventory. One param will be uid, which first condition will be to select inventoryFamily by UID.

Now you are sure you have the instance you want. Another param can be the inventory item to add, whether it is a word or a reference number. Adding would set inventory = inventory & "," & param (if inventory has value). You can also use scripting in an event, if you want to make use of like .split(',') .push and .join(',').

If another action needs to be taken I'd make another function for that. Sometimes I'll make a function for each different action and other times I'll make one function and pass a param for the different actions. Of course the latter turns into a long event of elses, but if it is only a few actions for each sometimes I'd prefer that to keep them organized and not pollute the function namespace.

This also isn't my favorite, but I'd probably do call function by name. That way, the name of the follow-up action (removeMoney, modifyHealth) could be stored wherever you need it (with the item type; if action from the carrier, would create an instanceVariable on the inventoryFamily of pickupItemAction; or pass the param into the function).

It would be great to be able to attach a function to an object such as a method, but the functions that first grab the instance by UID achieve the same thing.

custom actions canʻt return a value

Does creating a function with a return value not take care of this?

As for some of the other limitations you mentioned - let me remind you my brain is foggy and also mention you prob know more than I do, so this isn't disputing what you say - but I'm not sure about some of the direct downsides or limitations. For example, in general you don't want to pollute the global space, but what advantage is it if all Construct objects were NOT in the global space?

I kind of suggested using scripting because it sounded like you wanted to adhere to common programming practices. I almost always use events, unless I want to hit an API or its code I want to use elsewhere.

I think the thing I like the most about using Construct (non-scripting) is the syntax check. It will prevent you on the spot from using a variable that isn't declared or missing a comma or period somewhere. It's not really even a pain point in my normal dev/day job, but its just nice that when you build your project to preview your game, you don't have everything breaking because of a typo.

I know that didn't address everything, but maybe it's all I got, ha!

Cool idea. I like it.

With the examples in the original post, I think it would make more sense to provide your solution in other engines/languages and the problem you forsee implementing in Construct since your claim is that Construct causes difficulties.

I do agree that sometimes I find myself wishing I could quickly use a .map() to achieve something - and yes, you can use JavaScript in Construct. As others have said, it is preference.

But with events, I don't see why you couldn't achieve either of those with mostly instance variables and functions.

Picking in events is essentially filtering, which can be done on instance variables. Functions can have return values - if you want to break out complex logic into re-usable bits. tokenAt and tokenCount can be used if you want an instance variable as an array. If you need an array of objects, you can use tokenAt and uids. If you want an array of custom objects, as opposed to instances, I prob would recommend JavaScript.

My point is that these are the same tools you would use to achieve your functionality in any programming language. It does seem a bit awkward at times, but that is because Construct was originally built as a no-code engine. So there are some trade-offs there - think target audience. However, I'm a programmer and still enjoy using Construct. I'm not actually sure why, but I do!

but with constructs current limitations . . . to avoid c3 limitations in functions and custom actions.

What are the limitations? Can you elaborate?

Also, I'm not sure who said it, but I don't think it is fair to say a lot of loops or for eachs would kill performance. Of course a certain amount of loops will kill performance - anywhere, any engine, platform - but I've seen people act like adding a couple of "for loops" into their project is the end of the world. I'm just saying, test it to see if it actually does, especially if you are making a video comparing engines, ha.

All I am asking for is a scripting interface to query the collision cells, it could be something like:

runtime.collisionCells.getInstancesInRect(x1,y1,x2,y2)

You don't think that would loop over every instance under the hood? I'm not sure how that would be more performant.

I wasn't arguing anything. I was trying to be helpful in first defining the problem you want solved. But clearly you have issues with that, or with me, or something, so I won't waste either of our time with further comments.

You have the scale rate at 1?

What do you have Fullscreen Mode set to?

How did they get there in the first place?

That would be where I would start.

You can also have an event to check if they overlap a solid and move them, but I wouldn't go to that solution first, as you might run into it later at undesired times.

I believe it is because you have the scale rate at 0

One idea is to define my own borders within a layout at max size but that method would be very complicated and tedious to implement...

I'm not sure why that would be very complicated and tedious. Can you explain the issues you have with that method?

I think that is your easiest route. Make the layout very large. What is the downside of having large parts of the layout unused?

You could cover the unused area with a tiled background, block it off with solid objects, or whatever else you need to do, depending on your game mechanics.

If you are thinking of issues more so with the level editor part, you could set the area of the tilemap, which would stop them from trying to edit the tiles outside the level. If not using a tilemap and something like drag and drop, you could just have an event to check on drop if the dropped position is greater than the level width/height.

Maybe there is a way to change the layout size now, but I know in the past it was not possible. Even if it is, I'm still not sure how it would make anything that much easier for you here.