Road to 1.0 - what's to be done

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...!

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.

There is also issue with project corruption. Nigh impossible to pinpoint, too - but the usual culprits are private variables and families.

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.

Ashley

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

konjak

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

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.

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.

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.

Davio's 2 Show-stopping bugs

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.

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.

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.

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

Direct X lost device. It dumps all the textures I believe. I also believe it can't be fixed. It's not a bug in Construct, rather a problem with Direct X.

And Newt, I just tried to recreate your bug. It didn't crash or anything. Worked fine.

> 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

>

Direct X lost device. It dumps all the textures I believe. I also believe it can't be fixed. It's not a bug in Construct, rather a problem with Direct X.

And Newt, I just tried to recreate your bug. It didn't crash or anything. Worked fine.

You were saying earlier that certain things should be labled "USE AT YOUR OWN RISK". Do you think full-screen functionality should be one of them? A message like:

"Due to a current issues with Direct X 9, full screen programs may cause temporary freezing in Construct editor. Using windowed mode for all testing purposes is highly recommended."

I would focus on the editor itself. It is the tool allowing access to Construct's functionality, so it should work hassle-free.

That involves everything, from the picture editor to the project tab (e.g. remove Sounds, Music, Fonts and Menues, they have no functionality and are just irritating first time users; renamed sheets appear with their previous names under layout, etc.), animator tab and especially the wizard with its inconsistencies, wrong labels, wrong descriptions, etc. All of them on the tracker.

And in general, I would rather like to see everything removed, that doesn't work and can't be fixed, than letting it in and confusing users.

Another example is the script editor: why having icons for loading and saving when they have no functionality?

I need to agree with two people here: Aritz and Davioware (on point 2), so basically:

1. Sometimes it only moves groups but leaves the content out of them.

2. Some clicks on the event sheet seem to select things someone would not want to select.

Also (I don't know if this is considered a "Bug"? If not, then sorry) it would be extremely helpful if one could put Layouts from one Cap into a another one. As far as I know this is at the moment only doable with the events.

People working on huge projects would find this really helpfull because there isn't the need to have the .cap of the whole Game open, instead a .cap of one particular section wich could increase the speed of editing. (Opening my 75mb .cap takes a while and previewing a Layout aswell).

Again, if this would actually be a feature and is not a bug at all, sorry.

[quote:3cncnq58]And Newt, I just tried to recreate your bug. It didn't crash or anything. Worked fine.

Perhaps I should have been more specific.

Left click on the the object in the object bar, and right click on Default in the animator.

...Clicking on angle seems to work fine most of the time.

However if you then left click... kabloowie.