Thanks Rex and Ashley for the info

I looked through the example code you posted, Rex,

and in the context of some of the things you said, Ashley,

I think I kind of see what's going on.

Is there a place in any of the runtime files I could look to see the implementation of the SOL system?

In particular I'd be interested to see a list of the available methods and fields you can use to interact with the SOL.

Kind of the SOL "interface".

Is a SOL attached to each C2 object type, and implemented as a SOL JavaScript object, assigned to a JavaScript field of the c2 object type?

Or is it something global to the entire runtime?

I might be misremembering, but it seems like I've been seeing things that looked to me like they could indicate that it's handled on a per C2 object type basis.

I haven't yet been able to track the references to the SOL far enough back upstream to see where they are originating from.

I also gather that there is a SOL stack that is used to store (for later restoration) SOL state as you recurs into deeper levels of events. Though again, I'm having trouble finding the actual code that would make it clear if that stack is a field of a C2 object type. I suspect that it might be in the commonace.js file, but I haven't been able to spend much time poking around in it yet.

Sorry for the noobly questions.

Is there a good place or plugin to look at to learn how to implement object picking?

I've been looking around a bit, and it's hard to tell what is and is not special-case picking code.

(Kind of the same way the function object has the "fast trigger" system that's not intended for general SDK use.)

Does anyone know of an SDK picking tutorial, or a plugin that has generally applicable picking code?

Part of the reason I'm interested is that I'm building a document full of template code snippets for various common ACE related tasks, such as looping, executing triggered conditions, and now picking and SOL manipulation, if I can figure it out.

Any thoughts or advice much appreciated, thanks.

Hey Thndr, <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile">

You might be able to solve this by using "Families" to escape the reciprocal picking that happens with containers.

Manual > Families: https://www.scirra.com/manual/142/families

Setup:

Place the person into a family named "Damageable".

Event:

Hitbox is attacking. // Selects all attacking Hitbox objects.

For each hitbox.

Event:

Hitbox is overlapping Damageable family

Pseron.UID does NOT equal Damageable.UID // Prevents the Hitbox from attacking the Person who owns it.

Actions:

Damage Damageable. // Deals damage to all Persons overlapping the Hitbox who are not the Hitbox owner.

Note the sub event condition that includes Person.UID.

Here we are assuming that the Hitbox's Person is selected because they are both in the same container, and we're also hoping that won't influence the selected objects in the Damageable family, and it shouldn't, BUT...

If you want to be absolutely sure that the containers aren't involved, and thus can't get up to any of their containerly shenanigans, then instead of getting Person.UID from the Person implicitly selected along with the Hitbox, you can store the Person UID directly in the corresponding Hitbox when the Hitbox is created.

Event:

Hitbox, On created:

Actions:

Set Hitbox private variable "parentPersonUID" to Person.UID.

Hey unska, <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile">

Construct 2 has a feature called "Families" which might help out in this case.

Manual > Families: https://www.scirra.com/manual/142/families

You can put several objects in a family, then write events that apply to the family , and those events will affect all the family member objects.

You can also add private variables to a family, and all family member objects will get their own local copies of those variables. This could be handy for the properties common to all monsters, speed, bullets, health, sprite, name, loot drop, and such.

As for collisions and graphics, for a single character I usually create two separate dedicated objects. One for collisions, physics, and motion, and one for the graphical representation of the object in the game. The physics object will be invisible. The graphics object will be pinned to the physics object. This way my collision geometry can be very simple and predictable, and my graphics can be modified without affecting the collision properties of the character.

Hey farflamex,

I'm not sure if this is what you're looking for, but the Browser object has expressions for screen width and height, as well as a "Request fullscreen" action.

You could try using the "overlapping at offset" condition of the Sprite object to test to see if it *will* be overlapping a wall if it makes a given move. You can use that information to cancel the move if it would result in overlapping a wall.

The "overlapping at offset" condition basically ghost moves your object temporarily to a nearby offset, where it checks for an overlap, and afterwards returns the object to it's real location.

Awesome, glad it helped out.

Oh, I fixed the images. My "Img" tags were around the web address, not the file address. Derp. :)

(edit: just realize that "ran" variable was declared just above the if statement, and added it in.)

I just found a block of code in the Function object's runtime that seems to log info to the browser's(?) console when the game is in preview mode.

// Note: executing fast trigger path based on fs.name
var ran = this.runtime.trigger(cr.plugins_.Function.prototype.cnds.OnFunction, this, fs.name);

// In preview mode, log to the console if nothing was triggered
if (isInPreview && !ran)
{
	log("[Construct 2] Function object: called function '" + name_ + "', but no event was triggered. Is the function call spelt incorrectly or no longer used?", "warn");
}[/code:3owxtq4i]

What do "isInPreview" and "!ran" represent here? I have a guess, but I haven't come across "isInPreview" in the SDK documentation, though I might have just missed them.

Is this method of logging safe to implement as a third-party plugin developer, or is it a special case thing. 
Any weird pitfalls to be aware of? 

Just curious. Thanks.

(Note: File and image attaching are not working for me at the moment, so I'm using external URLs for when everything comes back on line.)

Hey justifun,

Essentially you would be simulating a 3D space.

I'll outline some terms and ideas first, and then explain how you might put them together to get your character jumping up onto crates and walking on them.

Three Axes

Ignoring jumping (Z) to start with, you just have X and Y making up the ground plane.

X allows you to walk West and East, which is represented as left and right movement on the screen.

Y allows you to walk North (away from camera) and South (towards camera), which is represented as up and down movement on the screen.

When you add jumping, you now have a third coordinate to keep track of, Z. We track the character's Z coord with our custom altitude variable.

Z allows you to ascend and descent over the "ground", and is represented as up and down movement on the screen.

Since Y and Z are both represented as up and down movement on the screen, in many games a shadow is placed under the character, so that it's easy to tell the difference between walking North and South, and Jumping up and down. When jumping, the character moves up and down, but the shadow stays on the ground at the footprint coords.

Collision & Z-overlap

(image link) - Here the player is in mid jump, and their shadow is visible on the block just below.

If we want the character to be able to stand on a box, then we need to know when the character's XY footprint is overlapping the box's XY footprint.

We also need to know how "tall" the box is, (its Z-height).

Once we know we're overlapping a box on the altitude (Z) axis, we can grab the Z-height value of the box, and use that as the current ground height. If that height is higher than the player's Z elevation, then the box is an obstacle to the player, but if it's lower than the player's Z elevation, then the player can pass "over" the box, or walk on it.

(image link) - Player sitting on a block, overhanging edge. (Player's footprint in green.)

(image link) - Player falling off the block. Notice that the footprint no longer overlaps the block's footprint.

(image link) - Player sitting on ground beside block.

Z-axis physics

In my first post I explained that you could outsource the jumping mechanics to a platform behavior object. In this new case, where the ground can have more than one height things get trickier. It's still possible to outsource to a platform behavior object, but its tricky enough that it might be better to just build your own simple Z-axis physics.

Demo capx

I built a demo capx that shows how some of this stuff could work in practice, though the code is a little hacky in places.

fi_demo_JumpingInPseudo3D.capx

No worries. Hope it works out.

Is there a good way to make Conditions and Actions that take an arbitrary number of arguments?

I notice that the Function object uses

AddVariadicParams()

to do this, but when I searched the forums, I only found one post on the topic explaining that it sort of a hack, built specifically for the Function object. Granted the post was from a few years ago so I don't know if AddVariadicParams has changed since then.

The best work around I've found other than that is to provide a single do-nothing parameter, from which you can call an expression that has the side effect of passing its variable arguments into an array behind the scenes, which can then be used by the Actions or Condition.

Any thoughts or suggestions welcome.

Hey Taximan,

One possible approach is, instead of having the 8 direction behavior control your character sprite directly, have it control your character's invisible "footprint" (a separate sprite object). Create a new object to act as your character sprite and, every tick, set its coordinates to match the coordinates of your footprint object.

Altitude variable

Now you just need one more value to store the player's current altitude above the ground. Normally your altitude will be 0, because you'll be standing flat on the ground. When you jump, this value will increase up to your maximum jump height and then decrease back to 0.

So far so good, but that altitude number won't move your player by itself.

Actually jumping

Earlier I said we'd set the character's coordinates to match the footprint's coordinates. We now need to make a small change...

We still make the character's X coord match the footprint's X coord, but we set the character's Y coord to equal the footprint's Y coord PLUS the altitude number.

Now when you move the character should follow the footprint, and when you jump, the character should hop up and down "vertically" over the footprint.

As an added bonus, you can attach a little shadow image to the footprint object and it will always be directly "under" your character even when jumping.

Borrowing Jump altitude from the Platform behavior

Now, if you don't want to build custom code to make the altitude variable "jump" when you press jump, you can borrow the jump behavior from the platform object in a roundabout way.

We basically create an invisible platform object that can only jump, put it somewhere out of the way, and we use its Y position as the real character's jump altitude.

Specifically, we create an invisible platform object with it's controls disabled (so the player can't move it), and then we make the game's Jump key trigger the platform object's "Simulate control" action to simulate a Jump, so the player can make it jump, but not move around.

We'll also need to make an invisible solid object for it to stand on, and we'll position them both so that the platform object's Y coord is 0 when it's resting on the solid ground object.

Every tick, the player's altitude variable should be set to the platform object's Y coord.

This method also allows you to optionally use some of the other nice features of the platform object's jump system, like holding jump to go higher.