Road to 1.0 - what's to be done

New releases and general discussions.

Post » Thu Sep 16, 2010 2:08 pm

We're nearly at Construct 1.0. In order to reach it, we need to fix the remaining 'showstopper' bugs and final critical issues. An example of that would have been the event sheet editor memory leak that was recently fixed.

Construct is a huge, sprawling and ambitious project, with many plugins and behaviors, and remember us developers are volunteers working in our spare time - bugs are unfortunately going to be a given in any 1.0 release, and it's unlikely they'll ever all be fixed. So with this in mind - what are the important things left to do for a 1.0 release? We know everyone has their pet bug that frustrates them, but we need to target the main issues that affect the most users.

So, with your help, we can make a decent 1.0 release in the coming months...!
Scirra Founder
Posts: 23,854
Reputation: 187,881

Post » Thu Sep 16, 2010 2:37 pm

Families just don't work. I have a hard time pinpointing what it is, but I'm sure Construct starts confusing what variables to reference. Could be because a member of the family has its own variables, or something to do with reading of events, but it renders Families useless to me!

Sorry I can't be more specific. Families work without any issue if I just use them without variables, or perhaps if the members only have the Family variables.
Posts: 234
Reputation: 1,818

Post » Thu Sep 16, 2010 2:47 pm

There is also issue with project corruption. Nigh impossible to pinpoint, too - but the usual culprits are private variables and families.
Posts: 1,910
Reputation: 13,155

Post » Thu Sep 16, 2010 2:55 pm

I would be happy with two bugs getting fixed - the general instability of physics atm and family variables not working correctly (I have variables that are supposedly family variables, but upon checking them, events don't run correctly - seems to happen with multiple families with variables).

I would be really REALLY happy if you guys added individual event sheet caching to speed up previewing as well. :D
Posts: 3,005
Reputation: 27,552

Post » Thu Sep 16, 2010 3:03 pm

The set control action doesn't work, and I think maybe the 360 plug in doesn't work, lfor your own custom named controls, meaning it works for things like "move left", but if you add your own like"axe swing" it doesn't work. Also hinges in physics have stopped working, though I believe davo was already reverting last time I chatted with him

I thought the same thing, and though I haven't tested it, or read up on it yet. I've heard he wiki entry for families says that all members of a family have to have the same set of behaviors and pv's to avoid conflict and the family manager helps with this. Seems like it should be forced with a continue/cancel popup though since not doing it with that way wreaks utter havok on a cap
Spriter Dev
Posts: 3,256
Reputation: 16,813

Post » Thu Sep 16, 2010 4:18 pm

My pc was running horribly slow the other day so I went to my processes list and found 5 Construct.exes. Seems the .exe isn't terminated after closing Construct. Anyone else noticed this?

Also yeah, the xbox controller plugin hasn't worked for a while.
Posts: 1,784
Reputation: 18,274

Post » Thu Sep 16, 2010 4:31 pm

There is an annoying bug that happens sometimes in event sheet editor, and when it happens I need to restart Construct. When I move a group, it leaves all content in its place, moving only the group, and leaving it empty.
Posts: 285
Reputation: 7,344

Post » Thu Sep 16, 2010 4:43 pm

I was about to make this topic! With the same name even...

I haven't had the families bug happen to me actually. Doesn't construct already prompt you to add the variables to the object when adding an object to a family without using the family manager? (It does for me.)

The bug might be caused by 1. adding variables to an object. then, 2. adding the object to a family with variables. I'm guessing this may be the case, as I have never had a problem with family variables, even when adding extra pv's to an object already part of a family with variables. I'll test this when I get home.

I feel that certain things should be labeled as unstable in construct 1.0. Possibly just an added sentence to the plug-in description or tool-tip or whatever. Namely, things that are buggy as hell and nigh unusable. Transitions fall into this category, and possibly the layout object also. Anything that's half complete, or incompatible with other things, or causes crashes that are deemed to difficult to fix, or not worth fixing, should be left labeled with "USE AT YOUR OWN RISK: UNSTABLE." By all means, if the bug is discovered to be easy to fix, then fix it and lose the message.

Getting rid of the plug-in or feature completely is a bad idea, as it would break existing .caps, and more importantly, give construct one less feature, even if it be buggy. Sometimes, even a buggy feature can fill needs of one person. They may use it in just the right way that all's well and fine for them. As such, I feel the unstable label is the best way to go about warning users about the stability of a plug-in or feature.

[size=150:1sh98rv6]Davio's 2 Show-stopping bugs[/size:1sh98rv6]

1. Crashes on layout change.

Bug is (I think) related to keyboard input, or sound. Limiter enabled checkbox in Xaudio2 may be at fault. Sounds across layouts are also suspects. Freeing cache and stopping sounds before layout change seems to have an effect on bug. Crashing also may be due to layout switching in general. Hard to pinpoint exactly, as there are many factors. Investigation needed.

2. Clicking on multi-subevented and/or grouped event structures, or actions within them

This sometimes results in the wrong event being selected. (eg. an action or event within a collapsed group or sub-event becomes selected when clicking on the parent event, or an action in the parent event.).

Sometimes, upon clicking on an action within a complex hierarchy or events, the entire hierarchy of events is selected. This is especially dangerous when one makes heavy use of control+drag to copy actions.(i.e, me.) This can lead to the click and drag facepalm, a situation in which a group of literally hundreds of events is selected and cloned when all one wanted to do is clone a simple set width action with control+drag. I even ran into an instance of this bug where my entire 1500+ event sheet was duplicated.

This bug wouldn't be so bad if it was rare. It happens a lot. Every click I make is carefully placed as to not upset the event sheet gods.
Posts: 1,207
Reputation: 6,865

Post » Thu Sep 16, 2010 8:28 pm

One thing I'd love to see fixed are the issues with full-screen programs, and how the Construct locks up for 30 sec. to 5 min. after viewing something full screen (Doesn't even have to be Temp.exe, exports seem to do this too. Not sure about everything else.) I believe someone said it was a memory issue or something.
Posts: 184
Reputation: 6,825

Post » Thu Sep 16, 2010 8:53 pm

Show stopper ehh?

Try this:
Create a new game, then create a sprite, and copy it.
Click on the sprite in the objects bar, so that both sprites are selected.
Now right click to get a context menu in the animator.
Image ImageImage
Posts: 7,946
Reputation: 91,358


Return to Construct Classic Discussion

Who is online

Users browsing this forum: No registered users and 1 guest