Code:
Problem description:
I'm not sure if this is a bug or what but if you shoot the beam, and then walk back and forth, sometimes damage doesn't apply its like its skipping and going through. This can be done at a lower FPS if needed. Also if you host with 2 people, and 1 person shoots it towards you and another does the back and forth same thing will happend.
How to replicate the issue:
Shoot Beam > walk left past it > Walk Right past it. Sometimes damage doesn't apply
Shoot Beam > Walk left past it > stop and not move > damage apply.
2015-07/Zasif-0001/projectile.rar
It's not really the code I use, but it does have same effect, was wondering about another thing, diagonal tails how would that work with tiled movement, stacking another layer of tails on top of the current tail using pixel_x/y?
| |
The trick is to actually stretch each tile slightly to account for the length of the hypotenuse.
Basically, we can calculate the length of the diagonal beam: TILE_DIAG = sqrt(TILE_WIDTH**2 + TILE_HEIGHT**2) Assuming you use a 32x32 tile size, we're looking at: TILE_DIAG = sqrt(1024 + 1024) TILE_DIAG = sqrt(2048) TILE_DIAG = 45.255 (approx, rounded up) Next, we need to stretch the beam given the ratio of its length by the target length. The scaling factor should be: 45.255 / 32 Or approximately 1.4142 In order to apply a diagonal direction to a beam, we'd want to use transform. var/matrix/m = matrix() Now, we can actually speed this up a LOT if we precalculate our matrices and jam them into a global list: var Now we just update our tail and beam objects... obj Now, here's the added benefit of this. You can remove the directions from the beam.dmi file. You only need a single direction, the east-facing one for each icon_state. Transform gives you the other 7 directions for free. | |
god this is so sexy
| |
Ter, You should make a lib or a snippet sunday about tiled/pixel projectiles. :X I actually have a library for pixel movement projectiles. It costs $150 a non-exclusive, non-transferable license. I could be convinced to convert it to tiled projectiles that can move in full 360 degree angles, but I'd have to charge the original license fee plus another $50 for the additional work. (again, non-exclusive, non-transferable) Projectiles are sort of my bread and butter. It's what I've done the most work with in the last year. | |
I'm pretty sure there are a few already from when pixel movement wasn't built-in. However, the solution of "stretching the beam to connect diagonally" has nothing to do with pixel projectiles.
| |
Not really what I was suggesting, was more about a demo 1 - tiled movement demo 2 - pixel movemnt. :P
| |
However, the solution of "stretching the beam to connect diagonally" has nothing to do with pixel projectiles. Yep, it's pretty much unnecessary in a pixel beam system. It's actually easier if you are in pixel mode already anyway just to calculate the sin/cos values for the direction of the beam's travel and plop down objects without bothing to scale them. Stretching is pretty much irrelevant at a pixel level. It's useful for the tiled approach, but not so much the pixel approach. | |
Anyway, cheers, happy to be of service.
| |
If the tail doesn't show up, could there be an issue with something else in the project that makes the tail not show up?
| |
^Move isn't called when you manually locate stuff.
Damage is only triggered when the beam moves on top of the mob.
You also want to trigger damage on Crossed().
Basically, what's going on in your bug, is that you are calling the damage routine right before the head of the projectile leaves the tile. Since the projectile moves only once every 8 frames, there is a chance the player is going to move out of the way before Move() is called on that square, allowing them to zip right on through a projectile.
In order to fix this, you need to stop depending on searching behavior in Move(), and take advantage of work the built-in engine does for you. Basically, what I'm going to do to your snippet, is I'm going to define a few new procs that will allow you to detect all kinds of information regarding movements that you otherwise would not be able to access.
These functions are:
onEnter(): called on a movable when it tries to enter an atom. Return 1 to allow, 0 to disallow
onExit(): called on a movable when it tries to exit an atom. Return 1 to allow, 0 to disallow
onEntered(): called after a movable has succeeded in entering an atom. Does nothing by default.
onExited(): called after a movable has succeeded in exiting an atom. Does nothing by default.
onCross(): called when this movable tries to overlap another. 1 to allow 0 to disallow
onUncross(): called when this movable tries to stop overlapping another. 1 to allow 0 to disallow
onCrossed(): called when this movable starts overlapping another. Does nothing by default
onUncrossed(): called when this movable stops overlapping another. Does nothing by default
Bumped(): Called when a movable bumps into this atom.
I'm changing a lot of built-in behavior of the collision system, so pay attention to the consequences and adapt your code accordingly. They should be obvious.
Sure, you can fix it without these overrides, but your method requires a polling loop every time the projectile moves. Mine doesn't. No loops, perfect reliability, no skipping, no mistakes.
I took the liberty of pointing out a few things you are doing that show some misunderstandings in how you write code. But it can all be streamlined quite a bit and your issue will be fixed easily by doing a few things with collision analogues.
Now that we've done all that, we can actually just make projectiles!