I'm sure you figured this out on your own by now, but just in case. In the panel to the right there is "Project" tab (If it's not there, Open the "home" ribbon and click Project to add it.) there you can right click and add layout. The wiki should probably tell you this.

I haven't gotten around do doing animations and I'm more of a newbie than you, but here's a uglyfix for the movingattack freeze until someone that works with animations can help you. What it does make it do the "moving" animation when no other animations are playing.

http://w17.easy-share.com/1700930026.html

Altlink:

http://depositfiles.com/files/6616641

BTW, your cap run at 15 FPS on my computer. I don't know if that's what you are going for. And when I watched the Guy animations in debug, for some reason it just doesn't seem like "movingattack" resets or ever finishes, so the on "movingattack" finishes event never triggers.

The jittering, I believe is a new bug for this current build.

I work in 800x res and my layouts are big. Sure, when you click the object in the layers menu you can see their X/Y, but it'd be nice to double click and snap to that object or allow zooming out of the layout to view the whole layout. Like I said, very small, so I don't think it's a priority at all.

You could do:

-Always
      -Always
            -Condition 1
            -Condition 2[/code:2ysxil0x]

Same thing that wont do anything different.

That's obvious, because it's not feeding from the first level of the sheet anymore. The first level is an always event just like I thought it was. Why would someone make two levels of blank conditions anyway? I barely even see two levels of always events used. It is worth mentioning though.

This is a very good idea. This way we could properly heavily comment our caps, but at the same time the reader can hide all the comments to keep it clean and readable. We wouldn't have to make the choice between the two and could add little reminders to ourself all over the place without worrying about how it looks.

Should of been this way from the start. Would save yourself a lot of grief. This is the internet, better to be cautious. But I guess I'm preaching to the choir.

Well, i can't really say ther's something this movement has that the built in one doesn't have.

I disagree. It has proper controllability. When you want to do anything besides a simple platformer there is a high probability that you will start to need to hardcode events into the movement or change the way the movement works per character (like a robot vs a human), when you come across problems, you can fix them much easier, and it's easier to work with families ATM. The behavior is best for prototyping and speed (since it's hardcoded), that about it. I would prefer the behavior though, if I'm not going to do anything "special". But that said, this is obvious, because it's impossible for it to do everything for everybody.

Thanks for sharing.

Since the person that PM'd me has unfortunately disallowed PMing, I will go ahead and post my response here so he/she can see it. It's a tiny bit cryptic, but probably to no avail to other viewers reading it.

> I knew sooner or later you would get pissed, but I was hoping you wouldn't. You help out a lot and I hope you don't decide to leave. Honestly, you made some of the best suggestions (coming from me is a lot. I DON'T KISS ASS.) for this thing and it could be made into something great with more honest criticism. I wouldn't be able to make much without your ---------. But that said, if you do decide to leave, best of luck.

>

> BTW, I think if you wait a little until the community grows a bit (I actually could advertise Construct around and make it gain a few thousands user, but I'm not because it's not ready for making anything REAL yet, IMO. Also, the communities I would show it to are very good, some with good programmers, but they are also harsh, and they will call it crap in its current state.). I think you would get much more appreciation for your --------- and good input, and more people helping out also... Sucks if you leave tho.

>

> Although I'm too impatient at the moment with Construct and also too stupid, I can't say I completely understand your explanation, but I will look it over a few times later and see if I can.

>

> As for Instances vs Objects, I will have to disagree. Maybe if you are making an Asteroids clone or another Mario clone then you will be using more instances. Those games deal with the same rocks or enemies that repeat across the game stage. However, if you are going to make a REAL (or "professional quality", I should say) game that's a team game or multi character game with different unique characters on the screen at the same time; all with their own unique abilities, look, and animations, you will need a lot of objects. Unless you can tell me each instances can completely change its SHAPE, SIZE, SPRITE/IMAGE/LOOK, PHYSICS, BEHAVIOR, all can be created and destroyed separately whenever at runtime, and all have their own private variables that react differently to the game world when you want them to (that's a lot of variables for one object. This is why I think families are so important. Even for some simple expressions using BOXES I have to sometimes make a new object and events until families work correctly, or I learn how to use them correctly, if I'm the problem. I can give caps to show what I mean.).

>

> Think about this: In Street Fighter, Ryu, Guile, and Chun-li are not the same Object, but they should be in the same player/character Family. Unless you can show me otherwise. I think you are forgetting all instances USE THE SAME SPRITE, so they LOOK THE SAME. (Note: Street Figher probably isn't the PERFECT example, because you can get away with doing most of it with using hitboxes and switching animations. But what happens when each character aren't the same shape/size and they have totally different hitboxes, physics/behaviors, and the background isn't just there for show, but instead, it's a mix of objects that alter the game. I can't see a solution besides a new object.)

>

> Don't get my wrong though, I'd be happy if you could show me an easier way.

>

You can use a "for each loop" based on a family. I do not believe there will be a need for 1000 different objects. Normally, you would only need 10-15 with 1000 instances of them.

As for the actions you call the unique objects, you can assign a private variable to the UNIMPLEMENTED expression that you need. Since the "for each" picks all in the group one by one -- even by family -- the actions can be:

ball set 'variable" to ball.vectorY

object set 'variable" to object.vectorY

bimbo set 'variable" to bimbo.vectorY

If the objects "ball", "object", and "bimbo" are in the same family. All those 'variable' actions will work (of course, only after using "for each".)

To avoid having to do this too much, you can put that in a functioncall, but since the screen updates every tick, you will only need it once.

They will for sure once and for all clean all bugs in the animations. And they will also for sure implement expressions in families.

But I am done with them. I worked my ass off to take it somewhere. I am not gonna type in there any more. I am done with trying to communicate with people that can not read caps, and caps are all I can communicate with since my ----- sucks ass.

You can call me rude, but at least I was honest.

Good luck with all your products, and ty for arguments that we had. I learned from them. Arguments? Discussions? Not sure about --- ----- ----.

ty for speedy reply

This thread confuses me. So I'll have to ask a few questions.

I haven't got around to animations quite yet, but I looked at TheInstances' cap and it looked like it has "trigger once" in the events, yet you guys are saying it doesn't? You guys are talking about "always" events, but I don't quite understand the problem here. Unless you mean starting an event with always is so bad it negates the trigger once, but that doesn't make any sense and that's different than what I was lead to believe from the start of looking at this forum and using Construct. I thought the always event didn't really mean much and was just what the program does by default every tick, because when I delete the "always" condition and leave the field blank, it doesn't do anything to the event, and when I run it, it works exactly the same either way. Strange.

<img src="http://img377.imageshack.us/img377/5241/triggersj0.png">

<img src="http://img241.imageshack.us/img241/3999/triggerblankij8.png">

It would be nice if we had this option.

<img src="http://img165.imageshack.us/img165/5040/pointwpointfe2.png">

But besides that, what I'm trying to accomplish might be simple, so I'll ask -- How would I set up my events to make it so my detector can do this:

edit- new pic

<img src="http://img374.imageshack.us/img374/1626/overlapspointzo0.png">

...With every box family I add no matter the size at runtime.

Keep in mind this view isn't top down or platform, its in between the two and it's faking Z depth. And all my boxes will have a totally different sprite/look.

Since there is no "point overlaps point", I don't quite see how I could do this without having to add thousands of width and height sprites to overlap (although, I might be missing something). I want to use the right green box sprite to stop the character from going left into the box, and bottom darkred sprite for going up inside and vice versa for top and left. And no, solids don't work for this, I'll just have to add a cap for you, because you probably won't get why otherwise. If you download the cap go under the sky sprite and hit the shift key. This you cannot do with "solid" and these boxes aren't might to be solid anyway, I want some other objects to do some separate things with solids.

(Which leads me to another question, can I use solid in events? if not please add the options. So I can do -- IF "object" COMES IN CONTACT WITH "solid" - DO STUFF.)

[solved]new features like overlaps at offset and collision masks make this not so much a problem

thx