oosyrag's Forum Posts

  • Never mind, looks like adjacent doesn't count as overlapping after all. Pretty much ignore everything I said in the last post. Experimented a bit and this seems to work: https://www.dropbox.com/s/xgmojljasm5e6 ... .capx?dl=0

  • That idea sounds about right. You'll want them as close to the edge as possible though, so they'll be able to help you "clear" the corner. If they are 4 pixels away, then you might get stuck on the 1-2 pixels where the helper sprite isn't colliding so you don't get nudged, but your main sprite is still colliding with the solid object.

    So the helper sprites should be just 1 pixel away from the sides as to prevent the "nudge event" collision conditions triggering from objects to the side, and the amount nudged should be at least 2 pixels to allow you to clear the corner of the object and continue moving forward. You might want 3, one dead center. If the center one is overlapping, then no nudge.

    Assuming you're using something similar to solids and 8-direction behavior.

  • myvariable is the base speed of the water. As you hold down fire, the base speed at which it is created increases. The expression min() returns the smallest of the two values, in this case either myvariable+50, or 2000. This constrains the maximum of myvariable to 2000. If myvariable is already 2000, myvariable+50=2050. So min(2050,2000) will give you the smaller number, or 2000.

    As a result, as long as the mouse is held down, myvariable will increase 50 every tick until 2000.

  • I understand now, so the events were to set an offset for the sword.

    To do so simply, you can just make a portion of your sword sprite transparent and set the origin a little farther away. Here it is in my example (still just a line though). https://www.dropbox.com/s/m1ogx3npzi13q ... .capx?dl=0

    If you look at the sprite in the image editor, notice that the origin point is in the transparent area and the the collision box is bound to the red "sword".

    But again, the key to making a fantastic animation is to actually animate it (either the player and weapon together, or weapon alone, it is up to you). Having the player and weapon sprites separate has its advantages, such as when you have a lot of weapons and don't want to draw the player for each weapon combination. The weapon itself can be animated on its own too though.

    If you're interested in art and animation, this is one of my favorite videos regarding animation techniques.

    Subscribe to Construct videos now

    And here is a reference for Zelda. https://s-media-cache-ak0.pinimg.com/or ... 1d7372.png

    While the Zelda style is still relatively simple, you can see that the sword swing isn't just a stick, they add swing lines to represent motion. Also, the animation of Link himself adds weight and substance to the sword swing as well. In Zelda, they use a single animation for both the character and weapon, as Link swings that single weapon as his attack 90% of the time.

  • https://www.dropbox.com/s/auxan5t7q3qvg ... .capx?dl=0

    It is more of an intermediate technique. Let me know if you have any specific questions about how it works.

  • You forgot to add on start of layout on you non-disabled grid generation event. Your grid is being created every tick, which immediately covers up your single "dirt" tile you place.

  • Try the stickied FAQ thread.

    The key words for you would be procedural and terrain generation.

    If you tried a google search for "Terraria terrain generation algorithm" you would find enough more than enough information to recreate an identical system.

    It it is a relatively advanced topic though.

  • They work on almost any device made in the last two years.

    Its just a matter of smart design. How to smartly use the least amount of resources for maximum effect, versus what the capabilities of your target device is. Some tablets or phones can be 10 times as capable than others.

  • You probably have gravity enabled, which applies a downward acceleration. You should instead use a set bullet speed at a 90 degree angle with 0 gravity.

    You should also post a capx when asking for help, otherwise people can only guess at what is wrong.

  • Yes, it is possible to do this.

    You will need to build an input queue. I recommend using an array. Every input will be pushed (back) and stored in this array. Then when you hit go, each action will be executed based on the sequence present in the input queue array.

  • As I mentioned in my first post, to sync you must have the host move the object. The peer sends his inputs to the host, and the host will move the object for both the host and peers.

    Before attempting multiplayer, I always recommend going through and actually doing all four official multiplayer tutorials and truly understanding them - trying to figure it out on your own is mostly impossible.

    That said, I would not recommend trying to include multiplayer for a project that is to be turned in on Monday

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Before testing it over a live connection, you should test locally on a single pc by opening multiple tabs/windows. Then you can confirm that it is not a latency issue.

    If it is still bouncing, like I said in my previous post, it is because you are trying moving the object on the peer side only and not the host.

    As for abandoning your project... I would guess that most people who try to use the multiplayer plugin are not properly prepared to do so. On the other hand, it is only by trying and sticking with it you can really understand how to use it, so it is up to you whether or not you are willing to spend the time and effort to learn.

  • On Up Pressed - Set GearVar to min(5,GearVar+1)

    On Down Pressed - Set GearVar to max(0,GearVar-1)

  • Syncing only happens one way - from the host to the peer. Peers do not send synced object positions to the host. That means when you move an object on the peer side only, it will get corrected based on the host's object state. A peer should send their input to the host, and the host should move the proper object based on the peer's input. This will in turn get synced back to the peer if your object is synced.

    If you do any moving on the peer side, this is called local input prediction. This is to show responsive input for the sake of the peer visually, while the peer client is waiting for confirmation from the host during the latency period. As long as they are close, you will not notice any bouncing around of position. The host remains authoritative regarding position and synced variables.