Thank you, but how would I connect those to variables in Construct, such as a private variable, or the return value of an object's property?

This appears to be working. Thank you —

I have a couple more questions.

One, is there a way to scale the video in Movie.cap?

Two, is there a way to dynamically scale the Flash window? For example, if I want the Flash window to scale with the size of the game window.

Bump. Still looking for help on this. Could someone possibly contact R0J0hound (https://www.scirra.com/users/r0j0hound) please? He's the one who created these methods.

I would myself, but this forum system prevents me from doing so.

This is what loops are for.

You'll still need an object to collide with the wall, but you'll simply make it invisible. You'll spawn a bullet object at the end of the gun object, and run a loop that iterates the bullet's position across space until it finds a collision. Loops run within a step instead of once every step, so it will not continue any other code until that loop is done, and the iteration ensures contact, so the bullet movement is instantaneous without concern of it overlapping too far or phasing through other objects.

Basically, you would use a while loop condition. The loop is run while the bullet is not overlapping anything. The actions in the loop should move the bullet forward one or more pixels ahead (the farther this distance, the less iterations the loop will have to run as the bullet will make contact that much faster, so keep that in mind). In an else condition, add a break loop action, destroy the bullet and create the spark effect.

Be mindful of while loops, as they will run forever until a condition is satisfied. Make sure your environment is air tight, or create an escape condition such as breaking the loop or destroying the bullet after it has traveled a certain distance.

But bear in mind behaviors will only give you a limited set of abilities, and unless you're making a very simple game, you're going to need events to some extent to control those behaviors.

I think it goes without saying that the built in avi object is not a viable solution given the intrusive and irremovable user controls embedded in the player.

I need to play videos in my game, and there's no decent way to do that it seems.

I really need a plugin or something for this, but for now I've resorted to using the method given by this thread:

69.24.73.172/scirra/forum/viewtopic.php

All three of these cap files half work and have some critical problem.

"video.cap" doesn't display any video, but plays audio.

"Movie.cap" works fine, but the video is always a fixed size and I don't know how to scale it.

"flash.cap" works (if I embed a video in an swf and play that) and scales with the size of the window which is what I need it to do, but there doesn't seem to be a way to remove the Flash player. Changing layouts doesn't remove it. Using windll.user32.DestroyWindow(hwnd) crashes the program entirely, giving me this error message:

Probably not worth it to mess with video.cap. If there's a way to scale the video in the Movie.cap method or a way to safely remove the Flash player in the flash.cap method, that should solve my problem. Preferably I'd like to use Movie.cap because Flash is less likely to be compatible on other computers.

Help solving this problem would be much appreciated.

> Okay I did that, and it DID fix the per frame issue, so that's out of the way. However, there's still often a one frame jump that occurs when the loop is executed.

>

If you're referring to the shaking, this is because you're pushing out before moving the object and handling it's controls, so it's essentially pushing out of the wall only to move right back in in the same frame. You should push out after movement and controls -- also remember to update your sensor positions before pushing out if you do this.

Moved SF Sensors after SF Movement, and moved SF Step between them. This nearly solved it...

> I'm aware of this. I setup conditions that check which speed is faster as to which loop to execute, but it's very faulty. I toggled those conditions for now but left them in so you can see what I did.

>

This looks about right, although I advise pushing out in the path of least resistance, which I'll explain in a minute.

Try enabling the conditions, then holding shift while running off of a platform onto the ground, you'll see what I mean.

> Try calling the function while forgetting picked objects so they all reposition rather than just the one that was picked by the event from which the function is called.

>

*facepalm* I feel like an idiot for missing this. After doing this along with reordering the code, it was completely solved. Attached cap with updated code demonstrates.

> Well, if the player gets stuck in a wall, I don't know how to find which direction requires the least number of steps before picking which ejection routine to run.

>

This is a matter of trial and error. You need to push out in a direction, counting the amount of steps taken, then reset to the original position and check push out in another direction, repeating the pattern. At the end, pick the direction with the lowest amount of steps necessary and push out in that direction. Since you already know how many steps it takes, you don't need to check overlap anymore.

> I'm not sure I understand this... do you mean a check AHEAD prediction system instead of a check BEHIND ejection system? If so, I'm not sure how to accomplish that in Construct.

>

Yes, the concept boils down to this:

1. Calculate based on velocity how many pixels the object will move that frame(for X and Y separately)

2. Using a loop, move the object in increments of one each loop

3. If the object hits an obstacle, move back one pixel and break from the loop; else, break from the loop when you've moved the amount of pixels calculated in step 1

Sounds tricky but doable. If at some point this becomes necessary, I'll give it a try.

Alright, thank you so much linkman, I'm going to continue with this setup. If anything goes wrong I'll come back to this thread, but for now it's good.

Thank you for your help so far. I've attached a new cap to this post with the current progress.

It looks like While is simply broken in this case, although I doubt that's the answer you wanted to hear. If you place While in an event by itself and then do your collision checking as a sub-event to that -- using, of course, an else statement to break from the current loop so it doesn't loop forever -- then you'll achieve the results you want. Example:

While

--sensor overlaps solid: Do stuff

--else: Break current loop

Okay I did that, and it DID fix the per frame issue, so that's out of the way. However, there's still often a one frame jump that occurs when the loop is executed.

Unfortunately, what you want this to do and what it actually does may differ, because as you have it setup now, if you run horizontally into a wall at high speed and the "down" sensor overlaps the ground, you're automatically pushed up through the obstacle, winding up on top. Horizontal and vertical speeds need to be accounted for when determining in which direction you want to push out.

I'm aware of this. I setup conditions that check which speed is faster as to which loop to execute, but it's very faulty. I toggled those conditions for now but left them in so you can see what I did.

I reordered the loops so that x ejection runs first, and what happens is, every frame that the player is inside the solid, it runs the y ejection loop once, so holding shift while running into a wall causes the player to climb one pixel every other frame. You'll see what I mean. The goal is to remove that one frame skip altogether so this wouldn't happen at all.

As another tip on the matter -- I apologize if this has strayed too far from the original topic -- you generally want to be pushing out in the direction that requires the smallest number of steps, rather than arbitrarily pushing out in each direction systematically. Expanding on the previous point, this is because as you always push out up first, then you will never end up pushing out right or left.

Well, if the player gets stuck in a wall, I don't know how to find which direction requires the least number of steps before picking which ejection routine to run.

One more thing to think about is how fast you want your player to go. At some point, your player may move so fast they might skip through obstacles. In this case, you need to move from a "move then push out" system to a "push to new position" system, whereby you incrementally push your object and check for collisions until you've either hit a non passable wall or have pushed as far as the objects speed allows it to move in one frame.

I'm not sure I understand this... do you mean a check AHEAD prediction system instead of a check BEHIND ejection system? If so, I'm not sure how to accomplish that in Construct.

Oh sorry about that. I thought I removed all the external stuff.

Updated. Also removed some pointless variables.

I've been working on a custom platformer engine with someone, and we cannot get past this one simple problem. Supposedly, loops run within a single step instead of per step. However, the actions I've placed within these loops are running per step.

This problem has been driving me crazy for days. I've tried all kinds of tricks, workarounds, variations, and every type of loop. I've simplified the code as much as possible trying to defeat this.

This should be a basic, straightforward collision system. All it's doing is:

while object overlapping solid

shift the object by one pixel

I've even read elsewhere on the forum that this exact method should work, that the effect should be no overlapping visibly taking place. What's happening though is that, if the object phases into a solid, it's ejected one pixel per step as if there were no loop being used. This results in quick skips or "slides" when the player overlaps a solid.

I've reduced the engine to specifically the graphics and code needed to demonstrate this, so it's easy to examine. Most of it is commented. Basically here's how it works:

The player object is surrounded by three sensors for the sides and bottom. These are used for collision testing, the player object is not. The sensors are positioned to the player in a function. This function is called every step, and also called during the while loop that's supposed to eject the player during a collision.

A separate object holds the player's variables for movement, such as x and y speed. The player's position is updated every step based on these variables.

Input group: Uses variables as proxy for input

Character Setup group: Initializes movement variables and spawns the player.

Sensor group: Holds the while loops that eject the player in the event the sensors collide with solids.

Movement groups: Handles player movement variables such as speed, gravity, assigning rendered positions to the player, and controlling the player's movement through input.

Step group: Positions the sensors to the player via image points.

Temporary Code group: Debug stuff and placeholder code for later. Doesn't do anything significant. Draws X and Y positions on screen.

The cap file is attached to the post.

Arrow keys move, Z key is jump, shift boosts x speed. Holding shift and running into walls really shows the problem here.

I would appreciate it greatly if anyone can help with this. We're rather stuck until we get past this problem.

You don't understand man. An exe is when your program is compiled to machine code. Its practically unreadable by humans, and Construct has no way to (at least not conventionally) mess with a game after its been compiled. C++ does not run in real time, it compiles. I don't know exactly what language Construct uses or how it compiles, but even languages that are interpreted in real time like Python, you don't just mess with the memory after its become a program. Unless you're a genius with binary or hex, you cannot feasibly work with a game after Construct has exported it.

I'll take a look at this, thank you.

Anyway after trying Arima's suggestion (which I should have done in the first place really) I discovered it was strangely all because of the zip file object. I had one in the layout and once I removed it, the error never showed up again, so changing layouts is now not a problem. I hadn't used the zip object yet but I intended to, so I hope I still can. If not I'll just do something different for the assets.

Also, for reference, the exact error message I was getting was this:

img837.imageshack.us/img837/3254/r6025.png