I use Winamp and Construct 2 for years and never had a problem with them conflicting. Both softwares have crashed in the past, but it happens very rarely, and I've never perceived any sign of incompatibility. I guess it must be something else on your computer.

What if it took a compromise: have the "object" and "condition" panels in the first dialog, and then the parameters and expressions in the second step? In other words, like taking the current three-step approach and merging the first two steps?

I have thought about that. Would already be an improvement. Maybe as a unified dialog could have more advantages, but as a two step process is definitely better than three.

At this point probably the best thing to do would be creating some semi functional mockups and testing with some users to collect their feedback. It's hard to know for sure what would work or not without falling into personal opinion or assumptions. This is the standard practice for interface design.

Animmaniac could you add in the parameters column (before you enter the condition) a place to show the expression so it's right there before you use it?

'm not sure I understand your suggestion. Could you clarify it a bit more?

Animmaniac - ah, that makes a lot more sense now (with the typing in suggestion). I do quite like the idea. Editing parameters in-place could come first, and then typing in a new condition/action is an extension of that.

eah, the presence of editable fields are kind of mandatory for it to work. It makes sense to develop them first.

The three-pane dialog does have some nice features, but I think there's still some issues around how to usefully show expressions without confusing anyone. Also if we had it as a kind of "advanced edit" dialog in addition to the current multi-step system (which would be preserved for beginners), as well as the typing feature, then that's a lot of different ways to add and edit events.

did some more refinements and was able to simplify the three-panel dialog even further. By doing some rearranging most of the visual complexity is gone and should be very easy to grasp:

With the section's titles on top and the buttons on bottom the structure becomes a lot clearer. The default display mode for each panel is a single list (similar to what we use now), so there's only one pick per column. That eliminates any confusion the filter lists may add. Also by displaying the events' description as a tooltip the visual complexity is reduced even further.

For picking expressions I used the same idea of the change of state, but modified it slightly to appear as an overlay window. This makes things even clearer and should help to eliminate any doubts of what's going on. So the expression panel would still pops up every time an editbox is in focus, occupying the space of the two first panels, but as an overlay:

It's not uncommon to hear reports of some users that do not acknowledge the existence of the floating expression panel. This could probably help mitigate that since the expression panel is always at hand when you need it: just click an editbox and it appears over the event dialog, click anywhere else and it disappears. There's no way to hide it behind other windows or out of screen.

Of course the filter lists and the folder structure would still remain as display options for the panels, to fulfill different necessities or user preferences, but the single list could be the default for beginners.

So in my opinion, even more with these refinements, I believe the three-panel dialog could totally replace the step wizard with no major problems and even some improvements. There's no need to keep two different mouse input methods. Mouse and keyboard are complementary, but having a third advanced mouse mode would probably be confusing. Unless we can turn them into some logic variations of the same mouse input method.

i open capx file but they show warning please install (black to alpha yann gragino) but i already install this effect but . not working. and i download and i download alpha threshold form this link . but effect not working still show warning you need (black to alpha yann gragino. please inbox me the solution

Are you sure you are opening the demo capx provided on this topic?

From what you describe it seems you are trying to open another capx, probably from someone's else tutorial or something. My demo doesn't use any "black to alpha" effect.

Thanks for the effect — I was wondering would it be possible to set the opacity for the water?

Not yet, I need to modify the shader to include this feature.

I could nit pick about scalability for large projects and lacking search boxes, but I think the main problem is information overload.

I think that with the filter list it's probably more scalable than the current solution, since they can quickly narrow down the number of items to a subset pertaining to a single category, so it could still be manageable even with a very large number of objects/items. The folder structure also better match the filter list on the side than in the current implementation where folders mix with objects.

For search the idea is to be able to type and jump directly to the match like you do in some file explorers. The mouse cursor determines which list you are searching by hovering. Alternatively you could also navigate and type using the keyboard like you can now. The fuzzy match algorithm would help in this as well.

Regarding the information overload I don't agree that it's too much to be a problem, and it's also neatly organized. But either way if new users find it complicated it can still be simplified by displaying the descriptions only on hover or removing the lateral filter lists (could be an option).

Also IMO the biggest flaw is how it swaps the conditions list for expressions - the dialog is already so packed that there is no more room, so it recycles the middle pane for the fourth expressions panel.

The idea is to recycle both the left and the middle panel for picking expressions only while an editbox is in focus. The reason it changes state is not because there is no more room, it's just a possible solution to not use another window. I agree that the change of state is not the best of things, this is definitely a hard problem to solve. The floating panel is a possible alternative but it also has it's compromises. This is something that needs some testing to see if it's possible to make the change of state clear enough to not confuse users, otherwise it's always possible to launch a new floating panel.

The thing is that putting the steps side by side, besides helping streamline the process of picking events also results in some nice features. If you are editing a condition and suddenly needs to change the object, in the current system you need to back step 2 times, change the object, than step forward 2 times again. With the proposed system with a single click you can change instantly the object, keeping all the filled forms intact. If the object type is different and there's no perfect condition match, the fuzzy match algorithm could kick in and try to predict the best possible match ("set X" => "set position X"). In general this layout makes it less painful to edit events.

*ignore that all icons are default

Another idea is that the list should always be pre-filled with the previous event you were editing. There's a high chance the new event would be related to the previous one, so it's quicker to change just a few parameters than pick all again. For instance, most events created in a row will probably be related to the same object, so you don't need to waste time picking it again. You just edit the differing parameters like conditions or fields. Or if you are setting a bunch of variables, or setting position and scale, or dealing with animations, all conditions will be close to each other so they are a single click away. If they happen to be totally unrelated then you just have to pick all fields normally.

In my view the problem with the current wizard UI is that it demands too much time and clicks just to navigate the windows, especially for users who don't use the keyboard. If you consider the frequency that these actions are repeated during a project there's a lot of wasted work that could be optimized. Every step is modal, so you always waste some time adjusting to the new context and get some cognitive load creating mind maps of where you are. What I tried to do with my proposal is to make it the less modal as possible. The steps are disposed side by side so you get an overview of the process and minimize both the clicks and the switching of states.

I guess my proposal didn't get clear enough. There's no need to parse anything apart from what is already parsed (like expressions).

The idea doesn't revolve around typing complete phrases (or code) and parsing them into events, that would be extremely hard. Instead you type into predefined form fields and use the fuzzy match to auto-complete. In a traditional programming language you would type a delimiter like "." to separate blocks of information for the parser. Likewise in my proposal you press ENTER or use the arrow keys to navigate to the next field, so the information is pre-parsed during filling.

Here's a step by step of how it should work:

Typed Events Mockup

*the image steps don't coincide with the steps below

1 - first initiate the typed method by pressing a shorcut like CTRL+E

2 - then type the object name and press ENTER or RIGHT ARROW to confirm and move to the next field.

It can be very fuzzy like "sp3" so you can economize a lot of key strokes and type faster. The fuzzy match algorithm does a lot of the job for you.

3 - type the condition field and confirm to start iterating It's parameter fields

4 - fuzzy type an object name, confirm

5 - type an expression to the X field, confirm

6 - type another expression to the Y field, confirm. When done you can then navigate to actions or add another event by pressing CTRL+E again.

So basically you just navigate these fields and type in them using the fuzzy match:

Object >> Condition >> Parameter 1 >> Parameter 2 >> Parameter 3 ...

Once you placed an event you could do a single click in a field to fuzzy type it again, or do a double click to edit using the mouse. Like opening an object dialog when an object field is double clicked...

...or click+drag a number to quickly edit it like in the editbox demo I posted earlier...

... or even edit expressions, conditions and actions in place.

This could unleash the power of edit in place (like in a traditional code editor) and probably speed things A LOT. I believe it may even surpass traditional approaches in terms of speed and efficiency, specially if you consider that it's virtually impossible to get code with syntax errors.

So my proposal is nothing different from the events system we already use and doesn't need another specialized parser. It's just a different approach to picking events in place without opening any dialog, so it can be faster.

Animmaniac Yes! That is exactly all I was looking for! Fuzzy matching is brilliant and I love your proof of concept. It gives the versatility and even if that flying list was like code-hint on any other text editor, it's a game changer for a "no programming required" engine.

Thanks. Yeah, the idea for the flying list is basically like code-hint, but adapted to a system where the auto-complete is always on so it doesn't get in the way (only when the user wants to).

Let me know how If I can help with this in anyway!

I have some other good ideas to improve the evensheet with better structuring, an improved color coding, and some power edit-in-place features that could probably speed things up a lot. However these are just some mockups and ideas for a proposal. I have no power nor the knowledge to implement this in Construct, it's up to Ashley and Tom. I definitely would love to redesign the eventsheet and the overall C3 interface, but it's not on my hands.

Also I would not expect any changes like these for C2, if it happens it will probably be for C3.