I got a fix for it too. I moved the code to limit your speed from move to action. It's still not ideal. If you override action you lose this, but that might not be a big deal.

If you'd like to post your fix on my forum, I can take a look and see what works best.
Do you have a setting in the camera controls to keep the camera from showing unnecessary black areas? So, if you are moved to 1,1,1, it wouldn't show all of the black area that isn't part of the map? If you do not have this setting, is there a fairly easy way to implement it?
I think Albro1 means something akin to the Edge_Perspective. I tried using it before and it's horribly glitchy and the camera freaks out.
Oh, and there are some density control issues that are bugging me. I have a tree icon. The area I want to make dense is 66 pixels wide and 30 pixels high. I set the pwidth and pheight accordingly, but the width doesn't seem to want to register correctly. I set it to 66 and walk to the tree, and every side other than the right collides just fine. But when I walk into the right side, I can go partway into the tree, then it spits me back out. It is strange.
If you're using a world_icon_size of 32 then the largest objects you can have are 64x64. the code only checks the surrounding turfs, since the tree is 66 wide that means it's at least 2 turfs away from that side. Since the check isn't made until you get within 64 px of the object you walk in a bit and then it resets your position.

Cut the trees width down a bit and try it again. Just to be safe, make the maximum bounding boxes as 48x48 that should work better. If you want to keep the tree the same, then split it into two entities. tree_left and tree_right, each with 33x30 bounds.
Thanks. Another small question. What do you have to do to update pwidth and pheight at runtime? Is it something with the flags?
you should be able to change pwidth and pheight as you'd like. I don't think there's any special requirements other than making sure you're caning the right atom.
Hmm. I just did a quick test by using spawn().

actor{
parent_type=/mob;
icon='icons.dmi';
icon_state="mob";
pwidth=27;
pheight=26;

player{
Login(){
if(..());
loc=locate(2,2,1);
camera.mode=camera.SLIDE;
camera.lag=48;
spawn(30);
pwidth=48;
pheight=48;
}
}
}


Aaand it didn't work.
That's odd. It works fine for me o__o

try doing ..() after login instead of if(..())
Albro1 wrote:
Do you have a setting in the camera controls to keep the camera from showing unnecessary black areas? So, if you are moved to 1,1,1, it wouldn't show all of the black area that isn't part of the map? If you do not have this setting, is there a fairly easy way to implement it?

you can set bounds for the camera (camera.minx, camera.miny, etc.). There are too many issues that complicate this so there's no generic way for the library to handle it.

The library doesn't support large values of pwidth and pheight. There's nothing special you need to do if you set them at runtime, but large values will never work properly. It depends on how things are positioned, but you're probably safe up to 1.5*world.icon._size, anything larger can cause problems.

What you can do is have the single large object (the tree) be non-dense but have its New() proc spawn multiple dense objects that cover the desired area.
Thanks. I just separated the tree into the 2 dense pieces(Left and right halves of the tree), and then the top. I adjusted the pixel_x's on the top correctly, and modified the bottom left's New() proc so that I can just place the bottom left wherever I want the tree. The bottom left spawns the other pieces in it's New() proc.
I thought of a feature that might be a bit fun to toy around with. A sort of "labyrinth" movement. Like the old wooden-board-with-metal-ball game. So when you use the directional keys, it increases the mobs gravitational pull towards that direction. So, if you hold the left arrow for a few seconds, the player will start to move and accelerate that direction, and you can stop it by holding the other direction. I hope you see where I am going with this.
You should be able to do that by modif6ying what's currently in p_m. I think you need to make the slow_down() proc work differently, as well as adjusting how action() works.

I made an asteroids style game a while ago but never took it anywhere, does that sound similar to what you're referring to?
Probably not. The system would emulate tilting the map and everything rolling with it, if you understand that a bit better. Holding the right arrow would make it seem like you are tilting the map right, making everything start to roll right.
Sounds like you could do this by overriding slow_down() to make it do nothing or make mobs slow down much more gradually. The only difference is that you'd want the player's movements to affect all mobs (though, in labyrinth, there would be just one mob).
Actually, I've got the perfect way to do it.

Change the controls so that they modify the gravity() proc. The gravity() proc will change to pull based on the direction you entered. Then, just add some deflection to bump().

You can adjust gravity() and slowdown() further to customize the feel.
Release Tiny Hero allready D: I am bored.
I got a question on Pixel Movement lib. Mind if I use the turfs for the Isometric demo in my project? Will credit you for it.
Avainer1 wrote:
I got a question on Pixel Movement lib. Mind if I use the turfs for the Isometric demo in my project? Will credit you for it.

I don't mind at all!
Hi Forum account. Enjoying your pixel movement library.

I'm attempting to create a topdown space ship that rotates,speeds up, thrusts forwards backwards left and right(fastest forwards, slowest backwards. and drifts in accordance to the way/ways you thrusted and depending on your speed.

Oh the amazing space games that could be made with this!



Page: 1 2 3 ... 5 6 7 8 9 ... 19 20 21