The code should be fine. "/Catalog" is the top most "<Catalog>" node. If you mean because it uses a forward slash, that's from XPATH - it needs the "/" symbol for the first node.

Link to .capx file (required!):

Sample Capx

Steps to reproduce:

1. Run the sample Capx. An index error in system.js is returned.

2. Disable the sprite foreach loop, no errors are returned.

3. Or invert the disabled actions in condition two (so the text is not using loopindex). This also allows the code to run.

Observed result:

Using loopindex in XML and then again somewhere else on Construct in the same tick causes an index error in system.js.

Expected result:

The loopindex from the XML should not be interfering with the loopindex in the sprite foreach.

Browsers affected:

Chrome: yes

Firefox: yes

Operating system & service pack:

Windows 7.

Construct 2 version:

R116.

Link to .capx file:

Sample Capx

Steps to reproduce:

1. Delete Sprite1.

2. Try and add ContainerText as a container object to Sprite2.

Observed result:

Construct no longer has access to ContainerText.

Expected result:

When deleting Sprite1 it should release ContainerText back from the Sprite1 so that other objects can add it.

Construct 2 version:

R116

Very cool, thanks mate!

Edit - Never mind, I think I was just misunderstanding what max_distance was in pushOutSolidNearest.

If you set the physics gravity to 30 then change the global variable ay to 50*30 or 1500.

Oh, 50! That fixes it. I figured out at one point that I probably should be multiplying ay, but I was doing 500 * gravity, not 50. That makes sense though - 500 I'm guessing is based on 50 * gravity(10), so setting it back to 50 and then multiplying it works. At the risk of badgering you too much, where does the number 50 come from? Why is that the base value?

Thanks mate! You're like a mysterious super-hero of games coding.

Sorry to double post, but I had a question for R0J0hound :

I was wondering if there was a way to speed up the object that travels along the path?

I'm only just getting used to physics so I may be way off here. I'm trying to set my object to have gravity 30 so that it travels up and down quite fast. The algorithm in your capx seems to take the mass of the object into account, but will always give it enough vx and vy to get to it's destination, therefore putting it at a constant speed regardless of the mass.

For now I was able to just cobble together a solution where I multiply the vx and vy by 1.75 for gravity 30, which works out fine (the bullet travels much faster and follows the line nicely), but surely there is a better way of doing it? <img src="smileys/smiley1.gif" border="0" align="middle" />

Is there another or better way to speed up the object as it travels along the path, be it by increasing the gravity or otherwise?

If you are just showing different states of the same object, your best bet would be to do what zendorf suggested in the linked thread, where you set each blood type to be an animation frame and then just choose one at random.

R0J0hound: That's...holy heck. I think I just spent the last month fiddling with a system that I can just replace with this. I'm both amazed and kicking myself at the same time. I don't know what to feel!

Hi,

Currently, when I change layout, the global variables will reset

Unless you are triggering the "Reset global variables" action, they shouldn't be. That's the whole purpose of global variables.

Global Variable Demo Capx

R115: Press space bar to progress to the next level. Notice how the score does not reset.

Be sure you don't have any "On start of layout" events where you are setting the score back to 0 - this will fire every time you change to a new layout, not just the first time you start your game.

Yeah, super good news, it's only an issue with chrome.

Testing the capx in Firefox, there are a few variations but not as marked as in Chrome.

Easy solution, stop using Chrome, yeah ! ^^

I can get it to happen in FireFox too, but it seems Firefox takes more load to get the FPS down. Here's my firefox test with more sprites:

<img src="https://dl.dropbox.com/u/20830426/firefoxTest.png" border="0" />

Also, I'm not sure this test is valid anyway, as you're unlikely to have such a logic in a "true" game. I'm not understanding how spawning 10k sprite is a good way to "lock" the FPS, as the loop only happens when the character is out of the screen, and the layout is supposedly restarted at this moment anyway.

Perhaps I didn't describe the original post properly. The problem isn't so much that if you just happen to have 300000 sprites on screen C2 starts to go wonky, it's that lower frame rates seem to have an affect on the jump arc of the platform behaviour. The purpose of spawning all the sprites and keeping them on screen was simply a way bog the browser down to lower frame rates. I wanted to see how performing the exact same action at different frame rates changed the jump path the player took.

The locking the frame rate post was separate from spawning all these sprites - That second post was what happens to the jump path when the frame rate is locked at 60. At that point, the gravity or whatever seems to be causing the variation, works out fine. It's when fps fluctuations occur that the course of the player changes. The second post was more of a real world example, the first post is what seems to be the same problem taken much more extreme (ie. forcing the game to run at around 30fps instead of 58fps).

I'm no expert at this though <img src="smileys/smiley1.gif" border="0" align="middle" />

So here's a funny thing, I added the following condition in:

<img src="https://dl.dropbox.com/u/20830426/c2FrameLock.png" border="0" />

This is in a version where I'm not spawning 10000 objects each test, but is more of a general test of jump accuracy.

With the frame rate locked at 60fps all three runs overlap perfectly:

<img src="https://dl.dropbox.com/u/20830426/frameLocked.png" border="0" />

Without locking at a framerate of 60, the following variations in jump height appear (remembering this is just letting chrome hover around 58-60fps without artificially hampering the fps):

<img src="https://dl.dropbox.com/u/20830426/notFrameLocked.png" border="0" />

The difference isn't much but it is highlighting the same problem - that the frame-rate jitter is causing different jump heights.

Ashley: Not being that familiar with this territory myself, is this a solvable problem? Being HTML5 is there anything that can be done code wise to correct this?