Code:
var/obj/Bullet/B = new/obj/Bullet Problem description: Now normally it places the bullet infront of the player, as it should as i recall? but then after a while or after walking around alittle, it starts placing it infront but 1 tile to the left or right of the player. or at least to some degree to the left. I can't seem to figure out why? | |
Red Hall Dev wrote:
Haven't compiled this, but get_step() returns a turf. So I believe what was happening is that you were trying to set B.loc to a turf and not a location. > var/obj/Bullet/B = new/obj/Bullet Turfs are locations. They're the ideal location, as a matter of fact. You certainly don't wanna be in an /area. | |
If you're using tile-based movement (the default map format), movement between locations is instantaneous. This means that when the player presses an arrow key to move, their location is changed first, and then their icon glides to that new location. If you use get_step() just after the player starts moving, it'll be based on the new location, despite the fact that the glide may have only moved them a few pixels towards it. This makes it feel as if it's off by a tile.
How to fix it depends on the game and how important fixing this visual discrepancy is to you. You could place the bullet directly at the usr's location, you could synchronize your movement and firing loops (if you have them) so bullets are fired before the step is taken, you could switch to pixel movement, you could estimate how far the player is in to their glide and set the bullet's pixel_x/y to match, ect. If you're using pixel movement, then you should be using step_x/y to properly offset the bullet from the player, instead of working in tiles. | |
I see... thanks for the input all of you.
I believe DarkCampainger is spot-on with his deduction of my problem! so thank you for your insight. I am currently using the default map format yes, and haven't really gotten that into the whole movement aspects of the game yet, as i am only just starting out, and do most of the stuff -as i progress-. I do not recall this being a problem in the past though, but things change i guess, I will look in to the different suggestions :) | |
the problem comes down to step_size, the stepsize is set to 8 (standard in any new project u create), while i guess get_step() only deals with tile by tile, so while i have moved 1 or 2 steps left 8-16pixels im still within the first 32x tile, and as such B.loc = get_step(usr,usr.loc) is placing it 1 tile infront of me, as it should but within the center of the 32x square thus making it off.
| |
Not a whole lot more we can give you to work off of that DarkCampainger hasn't already, outside of giving you the code.
Also, don't listen to Red Hall Dev. | |
I believe the crux of the problem is that you're not setting the step_x and step_y values of the bullet to the same step_x and step_y values of the player. If I've read the help file correctly... That should align your bullet to the same place within it's tile as the player.
Hope that helps. | |
Ah, I forgot the default new project is now set up for pixel movement.
Anyways, you just have to calculate the step_x/y to offset the bullet then. A simple approach would be something like this: var/radius = 8 It uses bitflags to test for cardinal direction components, so you don't need separate cases for the diagonals (for example, both NORTHEAST&NORTH and NORTHEAST&EAST are true statements). If you do this kind of thing often, it might make sense to write a procedure to do it. | |
DarkCampainger i like you! :) haha..
I've been reading up on pixel Movement in the DMguide and i did come up with something similar, only i just checked the users direction and tryed to align it based on what i thought was the distance from center. it was halfway sucessfull though. but this worked perfectly, so thank you for your help :) Best regards, Jarquille | |
Also, make sure you're only using usr if it's a verb.