There are also others little oddities in event sheet editor... for example, when you have a condition selected and right-click, there is "delete event" and "toggle event" in the menu, and they do nothing. And I guess you shouldn't be able to select a condition and an event at the same time, this is possible by left-clicking an event and then right-clicking a condition in some other event. When "delete event" in the menu �s selected, it removes the unselected event containing the selected condition.

Also... dragdropping an event to the blank area in the bottomside of the event sheet editor makes the mouse cursor the "not possible" -sign. It would speed things up if dragdropping there just moved the event to bottom of the event list.

There was some bugs with dragdropping groups too, some of them were pretty bad and caused a group to "malform" so that events inside weren't showing, no matter if you clicked the expand/collapse button. I'll try to reproduce this SomeDay.

And. The expand/collapse button could be in different color when collapsed, so that user notices it mode easily if there's some events hidden in subevents. Currently collapsed subevents would be pretty easy to miss, for example when viewing some other's code.

It would also be nice, if a single existing condition could be turned to an event or subevent with only dragdropping. Currently you must first create a new event, then move the condition there and then delete the first condition. Especially with subevents this is a pain since you often want to make a subevent by moving a condition from the main event.

Whew. There is some suggestions. I guess that most of them aren't hard to implement?

I'd like to see some overall improvements in platform behavior... It's still too limiting for anything too serious. Moving platforms, one-sided solids, ladder climbing, edge gripping, walljumps, better-looking suspended jump (the current looks like suspended float, there should be better algorithms to do a suspended jump), event-simulated controls for cutscenes, different solids for different objects (some object could cross a wall that another couldn't), and lots of customability. More trigger conditions (bumps into floor[=lands]/ceiling/left/right) and more actions (simulating controls, halt a jump [simulate ceiling bump ], setting sprite-specific solids, and when advanced features are added clinging to a ladder, etc. )

The behaviors' idea is to bring so good basic functionality that user doesn't necessarily have to create his own, but the functionality should also be very extendable so that user could use behavior as a base and implement some additional features... or that's what I think .

I'm sorry to bump this but... well, maybe I should just post this to bug tracker and stop whining in this thread

I experinced the same problem, but after reboot I was unable to reproduce it. So, it may be a problem with Construct, not just with the mouse.

Maybe you could make a warning message about saving a backup when importing .caps from older versions? Or the message could ask if you want Construct to make a backup copy of the file.

Woah! At last, new build \:D/ And we're getting closer to 1.0. Let's test it right away ->

fileshack.us/get_file.php

That beizer curve thing but now with the mesh over the top!

Yay! Btw, when does the new build come out? It has been already nearly month since last build. Does it also have the Plasma object?

Ashley: Thanks a lot for the lerp() function! My head would have already exploded with that cubic bezier without that linear interpolation function ;). Maybe you could still add qarp() (quadratic interpolation: lerp(lerp(A, B, x), lerp(B, C, x), x), that's useful for smooth curves. People could make smoothly curving paths etc. without math.

Behaviors are only included if all the objects in the family have the behavior.

That's why I they don't work - I had the physics and dragdrop behaviors with every member, and dragdrop doesn't show in event sheet editor's tabs at all and physics tab is empty.

Ah, you shouldn't be able to add different object types to a family. Families all have to be the same type of plugin (ie. all sprites, all text). You shouldn't be allowed to add text and sprite to a family - that's why it messes up and crashes.

I realised one more thing about this. Even if the objects that belong into family are of same type, their behaviours might not be. How families should support this? I noticed that currently using families with behaviours doesn't work.

Made bezier curve with two control points. Apparently, the "System: 3 For each Point 0 " loop was unnecessary, so it removed, spine2.cap runs at 144FPS and this spine3.cap runs at 270FPS.

Arima: Yes, the "spine" is a bezier curve, and bezier curves can have many control points, however, there is seldom more than two besides of the starting and ending point, because that takes a lot of computing power (well, it's not noticeable with just one curve, but if you have a CAD program with thousands of them)... However, you could append many curves to a spline. I'll make a curve with two control points and then check if I can make a spline.

Well. I got carried away and did this meanwhile. Now I made a mesh, whose every corner is movable and every side is modifiable by one control point.

Note the last event! At first it was like this, and FPS was like shit:

System: 3 For each Point 0 
System: 3 For each CurveR 0 
System: 3 For each CurveL 0 
Point: 8 Value 'a' Equal to CurveR 0 .Value('a')
Point: 8 Value 'a' Equal to CurveL0 .Value('a')

System: 3 For each Point 0 
System: 3 For each CurveR 0 
Point: 8 Value 'a' Equal to CurveR 0 .Value('a')
System: 3 For each CurveL 0 
Point: 8 Value 'a' Equal to CurveL 0 .Value('a')

Actually, I have the same problem. I made a character that shoots rotating circle saw-like things. The projectile uses bullet movement, and if I make the sprite to rotate, the rotating angle affects the movement too. They should implement texture angles and actual moving angles separately.