Drasa's Forum Posts

  • Bah, I prefer the runtime motion blur! To me that looks nothing like motion blur, because the main object graphic is still perfectly crisp. It's just a smudgy trail behind it.

    Well, it's a different effect. This is pretty common in some games, and although it has maybe originally intended to simulate something like motion blur, it is nowadays used as a effect of its own. I can think that some want to use an effect just like this.

  • It'd be really nice to be able to set multiple inputs for one action. Sure, you can work around this, but it'd certainly add a lot of code bloat in many situations (such as already ORed events and stuff). Low priority, but I'm guessing not terribly hard to implement possibly. Still something I'd like to see.

    Multiple inputs? Could you explain a little more specifically? There is already OR, if you want one of multiple actions to trigger event.

  • There's one problem anyway with keys. Some keys differ in different keyboard layouts, and for example, my finnish keyboard has keys �, � and �.

    Here is a finnish keyboard layout:

    shift up:

�1234567890+�
qwertyuiop�
asdfghjkl��'
<zxcvbnm,.-

shift down:

�!"#�%&/()=?`
QWERTYUIOP�^
ASDFGHJKL��*
ZXCVBNM;:_
[/code:1ncchlht]

Notice how the position of special characters is completely different from english keyboard? And there is specific layouts for about every language using any kind of special characters, umlauts etc. So, if there was a option of "." for example, it would mean a different button in different layouts... Any solutions?

  • I have also translated it into Finnish, but as Rich said, everything's not translatable yet, so I'm keeping a hiatus now.

  • It works even better if you do it with TimeDelta; it would run with machine-independent speed: set opacity - TimeDelta*100 (This would do the fade-out in one second)

  • I'll try make a working example now that Dave has posted an example how to use the distortions... I had already done it if I wasn't so busy, the university is really stressing me

  • Can we expect vector-based collision masks at some point? Or a polygon object? There would be a ready polygon editor with the physics behavior .

  • I can confirm. It's a bug, it shouldn't behave that way.

  • Things like gripping a ledge or wall-jumping aren't such general features though, and should probably be coded as needed by the user. Just my opinion on the matter.

    Well yeah, I agree. I actually meant that there could be additional conditions to help coding there features, something like that there would be events testing a bump on the wall and then user could code that if jump control is pressed within a certain time, jump would happen. Currently that needs detectors. I thought that if behavior knows internally when it has bumped to a wall, it could as well trigger an event too.

    And I guess I don't see what what you mean about the jump, it looks pretty natural to me. Maybe you could try fiddling around more with gravity and jump strength and such, you can get different looking jumps out of it.

    I mean that when the jump key is pressed, the jumping sprite rises at very steady speed, like it was floating. This stands out especially with long jump sustain times. Seems like the "gravity" starts to effect only after the jump key is released or the maximum sustain time has elapsed. If the sprite's upward motion was decelerating even when the sustain key is pressed, it would look more natural. Of course, when jump key was released, the decelerating/downward acceleration must be greater. Maybe there should be "gravity during sustain" so that user could tweak this setting?

  • Was it a logitech wireless mouse? Just out of curiosity.

    Man, you are like a spirit medium . Yes, it was. So you have one too? Maybe it is after all about the mouse...

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • It should work. What's wrong with it?

    I posted a cap demonstrating the bug into the tracker: http://sourceforge.net/tracker/download.php?group_id=207820&atid=1003219&file_id=292232&aid=2094635

  • That's already implemented! You can also use MouseX("Layer name")...

    Ashley: Btw, is there already implemented a general position "translation" between layers? I'd like to compare position of an object that is on zoomed and rotated layer, with another object's position but the coordinates are not really comparable because of the zoom and view angle... is there any solution?

    Edit: Oh, I noticed just that when layer is rotated, even MouseX("layer") doesn't show the real cordinates. I guess than it's not yet implemented?

  • 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