Forum_account's Shoutbox

Page: 1 2 3 4 5 6 7 8 ... 19 20 21
Jul 22 2011, 11:36 pm
You can already move diagonally with this, and it does equalize the speed so that moving diagonally doesn't make you move faster than those who aren't.

Unless you're referring to diagonal movement in a different sense?
Jul 23 2011, 2:57 am
Resonence wrote:
How would I go about easily implementing diagonal pixel movement?

I'm not sure what you mean. If you press up and right, your mob will move diagonally. If you want to make a single key that causes you to move diagonally you'd have to override the action() proc. You can either make it call the move() proc twice (ex: to move northeast call move(NORTH) and move(EAST)), or you can override move() to make it support diagonal directions.
Jul 23 2011, 4:30 am
When I move diagonal by holding both arrow keys, it defaults to either my north or south icon_state. Shouldn't it naturally be defaulting to my east or west icon_state?
Jul 23 2011, 4:40 am
For that I think you'd have to override the set_state proc. You can look at its implementation in mob-movement.dm to get an idea of what to do.
Jul 23 2011, 5:36 am
I am not comprehending what needs to be done. Also, I want to make mobs dense as how they are in tile-based movement. Please help me. Thanks!
Jul 23 2011, 8:30 am
To make mobs dense, override the can_bump() proc:

mob/can_bump(atom/a)
    if(ismob(a)) return 1
    return ..()
Jul 23 2011, 8:49 am
Thanks! I'll try to figure out what needs to be done to change the icon state at a later date.
Jul 23 2011, 9:08 am
You can look through mob-movement.dm to see where the mob's dir is set to help figure out what you'd need to add to make it support diagonals. I dont have an example off the top of my head.
Jul 23 2011, 5:13 pm
move_towards() in pathing seems to do nothing but spit errors out at me.
Jul 25 2011, 5:50 pm
Bravo1 wrote:
move_towards() in pathing seems to do nothing but spit errors out at me.

This'll be fixed in the next update, but if you want to make the change yourself, line 209 in mob-pathing.dm is "else if(destination)", within that else if block all occurrences of "next_step" should be "destination" instead.

Did you ever figure out what was causing high CPU usage with move_to? I've been doing some testing and haven't noticed any problems, though I am just testing with one mob making calls to move_to and you had multiple (but I see < 1% CPU usage).
Jul 25 2011, 6:01 pm
Yes, since move_to plans out a path to the target, the greater the distance the more possible paths occur, leading to more and more iterations to find the shortest and most effective path. with 1-4 mobs it works perfectly fine but with every mob the lag increases. at 11 mobs you can't use move_to for anything more than 6 steps. I didn't want the mobs targeting each other from across the map anyway, so it's not a big issue.
Jul 27 2011, 1:26 pm
Jul 27 2011, 1:37 pm
Bravo1 wrote:
So 1337

lol, I didn't even realize I was close to a milestone!
Jul 27 2011, 5:19 pm
IS your version of the A* 4 directional or does it allow diagonal moves, because if it is then I can see why my mobs are getting stuck on so many corners. I was thinking of modifying it to check only the cardinal directions in certain cases, like move_to(turf/t,diag=1) if diag is zero then it uses the cardinal pathfinding only. How does that sound?
Jul 27 2011, 5:27 pm
The pathfinding part is 4-directional so that it doesn't cut corners but the path following part can cause the mob to move diagonally.

I wouldn't be surprised if it has problems. If you can find a way to reproduce it (give me a mob's starting position, size, destination, and local map layout) I can work on improving the path following.

To get this information, I'd do something like this:

mob
    var
        atom/move_target
        start_px
        start_py
    move_to(atom/a)
        move_target = a
        start_px = px
        start_py = py
        ..()
    Click()
        world << "[move_target.x], [move_target.y]"
        world << "[start_px], [start_py]"


That way you just have to click on a mob that's stuck and it'll tell you what command caused it.
Jul 28 2011, 1:23 pm
So, like rotating a rectangle, can you rotate an object's density to be diagonal?
Jul 28 2011, 1:32 pm
No, the bounding boxes of atoms are always aligned the same way. No matter what, the collision detection is going to be an approximation so if you want to have mobs that rotate, you'll have to find some way to compromise and represent them with rectangles.
Jul 30 2011, 12:25 am
There was some way of doing it with trig and polygons and all that but it's a bit too much trouble for what it's worth. The current bounding boxes work just fine, in my opinion.

Oh, btw, Kaiochao notified me of a glitch/bug in p_m. It seems that the compensation for diagonal movement isn't perfect vel_y always gets modified to a greater factor than vel_x. Negative or positive, x reads as 3.2.. and y reads as 3.7.. with a move_speed of 5. I can't explain it as they're both being worked out in the same exact fashion. Perhaps it's a timing issue?
Jul 30 2011, 3:17 am
Bravo1 wrote:
There was some way of doing it with trig and polygons and all that but it's a bit too much trouble for what it's worth. The current bounding boxes work just fine, in my opinion.

It's possible to implement this, I'm just choosing not to. It's more likely that I'd implement circular bounding volumes, but that's not very likely either.

Oh, btw, Kaiochao notified me of a glitch/bug in p_m. It seems that the compensation for diagonal movement isn't perfect vel_y always gets modified to a greater factor than vel_x.

I've identified the problem, I just need to fix it.
Jul 30 2011, 10:44 am
Well, I have a fix for it that works perfectly. It happens mainly in action() so I've modified it. Works perfectly now. Also, I added extra arguments and cases to move() it works pretty smoothly and allows you to send diagonal directions to move(). If you want the snipped just let me know where to post it =P.
Page: 1 2 3 4 5 6 7 8 ... 19 20 21