This just started acting up tonight. I cloned a layout, and immediately afterward, I noticed that Construct will not accept "global" as an object of any sort. Hard to say if it's to do with the cloning, but it seems pretty well universal to Construct, as ALL .cap files I try to open are now affected by this.

<img src="http://i26.tinypic.com/23i89s9.jpg">

Sexy, eh?

I figure it's probably a matter of clearing a registry entry somewhere, or something like that. Hopefully it's not a matter of 0.99.91 itself being bugged, with it being the latest "stable" release and all.

Anyway, any thoughts on this?

On left clicked is a trigger, so you don't really want to have both in there. You're only going to have success with one trigger of the exact same type in a given frame. Just make the secondary conditions into sub-events (looks like you can get away with the second one being an "else" here, too).

That's true too, SpriteFont is basically made of awesome. Except when you try to update the text every frame of course, because there's no quicker way to kill your framerate.

Set up custom pathfinding for the truck objects, and give them both the Add Pathfinding Obstacle Truck and the Avoid Moving Over Truck. Then regenerate each one's obstacle map periodically, since they're moving objects. I think that should solve a majority of your issue.

Alternately, have an invisible Sprite (use bounding box collision) with a larger radius than each truck follow them around (and probably match their angle), and use that for their pathfinding instead of the trucks themselves. It would give you a little less of that "trucks crashing into each other" effect. This gets trickier, though, since you'll need to account for each truck's own invisible sprite so that it will actually move at all.

Beyond that, there's something to be said for checking if the trucks are within a certain radius of each other, then if so, using the LinearAim System expression to find out where they're headed and then veering away from that point. It's going to take a little more number-crunching and finessing for you to do to get it the way you like it, but it might be the most satisfactory option when you're done.

If anyone complains about the weapons themselves being unrealistic, they're overthinking it. Besides, it really comes down to who's holding the thing, after all.

I mean, let's take the broadsword/claymore example: both of similar lengths and weights. But if my grandmother has a broadsword, and King Arthur has a claymore, I'm pretty sure about the odds on who's going to slay the dragon with it and rescue the fair maiden, all other things being equal.

What I'm really saying here is, don't let it bother you, just make sure they're all balanced the way you'd like, and attribute any strangeness to the Squishies themselves.

There's probably something to be said for making sure certain classes of weapons have certain things in common, even if damage isn't one of those things. Range is a really good example, and it doesn't seem like there's a real bonus to making a rapier shorter than any other sword; it might as well be a big dagger or something, at that point, which is likely to read better intuitively (meaning there'll be no surprise for the player when it also attacks more rapidly).

Props to you for asking for advice here Few people seem to do it, and I suspect it's largely a matter of ego. Everyone wants their game to fit their own personal vision, after all, and soliciting advice somehow "dilutes" that vision for them. But that's a bit silly, as you well know; the best games aren't conceived in a vacuum, but with a lot of serious collaborative effort.

If it helps at all, I answered a similar question recently over in Help/Tech Support.

Maybe that will be of some use here.

Sounds good by me. If nothing else, it's more stable by virtue of the fix to "else".

If the RTS behavior could limit itself to certain kinds of objects or families for its travel, rather than just avoid them, I would probably use this exact approach myself. It's incredibly handy and consise, the way you've done it!

As it stands, I'm trying to solve basically the opposite problem, which turns out to be a bit more work. This is a nice bit of inspiration, though (yours too, toralord).

Oh, just one little suggestion: Movement's a bit smoother if you change out the "Every 500 milliseconds" condition for "If != Hunter 2 is moving". Assuming you don't want the pauses, anyway.

As an alternative to set layer angle(that doesn't work) we have a nice camera plugin

Although you will have to create a custom movement for it to work,but this method you don't need large rotating sprites and can create your levels normally

Yeah, this right here is probably the best (or at least easiest) solution. Rotate the whole world with Advanced Camera, rotate the player by an opposite amount, and switch to Custom Movement. I can't think of any reason why it shouldn't work.

I think you're on a newer version of Construct than I am, so your .cap won't load for me, but have you checked to make sure your layer isn't set for Linear Sampling? Even if the application is set to Point Sampling, try setting that one layer to Point as well, just to make sure.

Also, I've occasionally noticed some blurriness when using transitions, so see if turning off any transitions between the previous layout and that one makes a difference of any kind.

See, my game is a 2D platformer, and since I'm relatively new at Construct, I don't have any idea how to make cutscenes. If there's an "easy" way, I'd like to know it first before getting into the tough intricate stuff. I have the unstable version (0.99.91) if that matters. All I'm really looking for at this point is "This character talks, then this character talks, then this character moves, repeat it a little, then it's over". I wish I knew how to do it myself but I don't really have any idea.

I just tackled something similar in nature myself, about a week ago. I ended up doing everything via an array, so that I could save and load files between it and an external editor.

Forgive the really rough pseudocode, but basically the logic is something like this:

* At the start of the layout:

• Load Array from the file
• Set the variable 'Step' to 0
• Call the "NextStep" function

* On timer "StepTimer"

• Call the "NextStep" function

* On function "NextStep"

• Add 1 to 'Step'

** If Array(Level#, 'Step', TimerSlot#) > 0

-- Start "StepTimer" with the value in Array(Level#, 'Step', TimerSlot#)

* Always:

• Write the text at Array(Level#, 'Step', TextSlot#) at speed Array(Level#, 'Step', TextSpeedSlot#)
• Display the appropriately numbered sprite found at Array(Level#, 'Step', BackgroundSlot#) and move it to the background area, and make all other sprites from the background category invisible
• Display the appropriately numbered sprite found at Array(Level#, 'Step', LeftPortraitSlot#) on the left side, and the same on the right but with RightPortraitSlot#, and make all other sprites from the portrait category invisible
• Play the sound effect, if any, defined at Array(Level#, 'Step', SoundSlot#)

* If Array(Level#, 'Step', TimerSlot#) = 0

• Prompt the player to push a button to continue

** On the push of that button, call the "NextStep" function

* If Array(Level#, 'Step', TimerSlot#) < 0

• Proceed to the next level

Anyway, I'm sure you could adapt this to your purposes. Just add more Z slots to your Array to do more things, and of course more X and more Y slots for levels and maximum steps per cutscene, respectively. Mine's presently at about 10X, 40Y, 8Z; it's much easier to handle with an external editor (or a dedicated layout), as you can probably imagine. I guess if you're strongly inclined, though, you could just set a whole mess of values by hand in an include sheet.

What I think is actually going on is that time delta continues while things are loading (i.e, the time delta for the first frame of a layout includes the time it takes to load the layout as well as the time it takes to execute the events and draw the screen) but the event sheet isn't running extra times. That's what happens with my game. How I solved that was in the application properties/runtime properties/advanced, set the minimum frames per second there to something like 30. That way the time delta won't keep racking up while it's loading.

Instead of using a countdown timer based on time delta, what you should use (again, what I'm using) is a tick timer. Basically, if value is greater than zero, subtract one from that value. Every time the event sheet runs, you'll know it by watching that value.

As for a loading screen, you can do that too. Before going to the layout that takes a long time to load, put a black sprite or box across the whole screen and your loading image somewhere as well in the previous layout. There is a trick, however; you have to display that one frame before going to the other layout (let the layout finish running its events), or it won't draw the loading graphics before going to the other layout.

I tested the idea of it being based on TimeDelta, and no luck. I've already got minimum FPS, etc, set up. When I ran a simple once-per-loop increment counter, it seems that there are multiple ticks (between about 165 and 750, depending on the machine I've tested it on) of actual game logic going before the layout is visible.

As for implementing a loading screen, I should have specified that it's not an issue of getting something like that working, but rather of overcoming this particular hurdle in order to make it work. I've got a nearly feature-complete game here, and this is one of the biggest obstacles it's still facing. The suggestion is appreciated, though, as a month or so ago when I first picked up Construct I was trying to do everything like I would do it the hard way in C++ (old habits are hard to break!)

Any other thoughts on this one?