Animmaniac's Forum Posts

  • You do not have permission to view this post

  • There's an efficient and easy to implement fuzzy match algorithm that I used in my proposal for typing events that could probably fit your needs (there's a working example in the previous link). Here's a website that describes the algorithm in detail: http://www.catalysoft.com/articles/StrikeAMatch.html

    Basically you pre-process the strings you would like to compare by splitting it's letter pairs ("TEXT" => "TE,EX,XT"). You can store each pair as an entry in a 1D array or use a comma separated string. Then you iterate through each pair of the first string and find if there's a match in the second one (you can use the Find expression). If there's a match you increment a variable Intersection an remove the pair from the second list. After processing every pair you calculate the similarity of the two strings by dividing the number of matching pairs by the total number of pairs (sum from the two strings):

    Similarity = 2 * Intersection / TotalNumberOfPairs

    Having the similarity, you just need to set a threshold of how much the strings need to match an use a compare:

    Similarity > 0.9 => do stuff

  • You do not have permission to view this post

  • You do not have permission to view this post

  • In that function "a" is replaced with whatever object type you call the function with. So if you called it like this:

    Call indist (sprite, 100,100,50)

    "a" would be Sprite. It's basically another way to make things more generic.

    Yeah, that part I get it and would be very useful. My main doubt is how to make this viable.

    From my perspective, in order to make it work the "a" would need to be a sol variable previously defined and limited to only one object type, in this case "Sprite".

    Otherwise you could call "indist(sprite, 100,100,50)" or "indist(tiledBG, 100,100,50)", two different object types with different specific conditions. So when placing the condition you would need to select the condition inside a list of an object "a", of the type "sprite", that would temporarily appear into the object list (like local variables do). If not, how would you deal with different object types that have specific conditions not present in other object types? Like you could call both a sprite or a tiledBG, but they don't have the exact same condition set (like "animation is playing" for instance).

    Unless all the object types have a common subset of conditions (like position, size, opacity...) and you can only use these when picking an object through a variable (like "a"), and select them through the system object.

    *Actually I have some ideas for families with multiple object types that probably could help with this. When I get more time I'll post them.

    How about inline vectors?

    OK yeah, I know...

    Well remembered. It's something that would be great if could be incorporated.

  • Very interesting topic.

    There's some ideas that could (and in my opinion should) already be applied to the current event system. Like the possibility to define variables inside event blocks or actions, reference instances by the order of picking, and be able to name function's parameters. I already felt the need for these before and totally endorse them.

    I also really like the idea of creating temporary families inside the code. This could be extremely useful to use with functions and make more modular events.

    Also the possibility to save the SOL to variables is one of my dreams. Being able to pre-process a SOL, store it, and later load it again could help save some serious processing when dealing with a lot of instances and expensive filters. There's some cases where you need to repeat the exact same complex picking at a later time, plus some different conditions, that could be seriously optimized with this. Instead of checking collision, plus position, plus variables, plus n other things... for thousands of instances repeated times, you just compute it once and store it, then load it when needed. Most certainly just manipulating a list should be a lot faster than to compute everything again.

    One thing that I noticed is that your proposal works easily with typed code, but do you have thought in how it would work with the event wizard?

    For instance, since the actions don't seem to show an explicit object type like conditions do ("sprite: ..." or "system: ..." ), I imagine they would be a generic editbox where you type actions as expressions, am I right? That works well for setting variables, but how about other actions that depends on dropdowns with options and the like? Or things that are very specific to an object type?

    Also here the "a" is only referenced inside the function but appear as an object type in the condition below. To place the second condition, would it show on the objects list like local variables do, or the idea is to have a generic editbox for the object type as well?

    +-------------------------------------+
| on function "indist" (a, x,y,dist)  | returnSol a
| a: filter distance(a.x,a.y,x,y)<dist|
+-------------------------------------+[/code:2711oo0f]

  • You do not have permission to view this post

  • You do not have permission to view this post

  • You do not have permission to view this post

  • You do not have permission to view this post

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

  • You do not have permission to view this post

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

  • You do not have permission to view this post

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