ID:1106331
 

Alright so I was attempting to do 2 things, and upon my attempt, I somehow managed to corrupt my project so that whenever I opened it, it would lock up (and no I did not have the game file running)

Yesterday, I had a conversation with a friend about attempting to do two very reasonable things. What I did to cause my crash, I have no idea.

Here's what I was trying to do:

1. Create away for a movable object (ie: like a ranged attack of some sort, lets just say an arrow for the sake of convenience) to pass through predefined "dense" objects. Sounds simply enough - I speculated to a friend that this would presumably involve a bump check in someway, which he confirmed and stated that he generally makes a var like "cancross" and what not, and that i'd merely need to check upon firing said ranged object when it "bumps" into something. In theory it sounded easy, in practice...well I failed horribly. (cannot even access my resource file now...with some type of weird error)- So i'm starting over.

2. Second part I never even attempted because I was so focused on part 1. But I might as well throw this in here - I have 32x32 mobs, and I made the weapons correctly scaled to their bodies as if it were the real world. (using a real-life sword to my own body as a reference) Only problem with this is, say the player strikes another, it is not really appearing to strike them - they are only appearing to strike the edge of their "box" that they player stands in. I want to have the ladder half of the weapon (when extended outwards) reach into nearby squares depending on where the player is intending to strike. Now I know this would possibly be an overlay - but i haven't the slightest idea how to offset an overlay.....if that makes any sense?

Anyway, I would like to begin an open discussion & debate of how to particularly going about the most efficient way of solving these issues.
One time it happened to me something similar to your #1 thing. I was trying to make a dagger that could through dense turfs but then no mob could enter a turf and they never leave "null" loc. But I still could access the game.

...Now that I'm reading what I writed I realize that is not usefull for you. Sorry...
1. Depends whether you're using pixel movement or not.

Cross is what you're looking for.

Bump occurs after you already attempted to move but failed, you bumped a dense object.

Cross occurs when another object attempts to overlap this one.

If it's pixel movement, look into Cross(), you can override it to allow crossing.

I'm not sure whether Cross would work if you're only using tile based movement, for that case, you can use bump (or Bumped, I think Bumped would be better).

With Cross you can just override it and allow crossing.
Bump/Bumped - Simply edit location to the bumped object's location, depending on how the projectile was moved you might need to re-start it.


2. You can have 32x32 icon and have offsets (pixel_x/pixel_y) by editing an object beforehand then adding that object to overlays.

However, if I understood you correctly then it would simply be easier to have an overlay icon bigger than 32x32, just because the mob is a certain size it doesn't mean you can't have a different sized overlay.

Even if the sword itself is tiny, you can use the space of the bigger icon as offsets to position things how you would like.

*I'd happily provide a code snippet with comments if it's not enough, from what I understood you get the idea of what you want to do but you just don't know how, code snippets can help you, normally people supply them and explain what they're doing.
Don't try to re-invent the wheel doing it all by yourself, someone already solved those issues, learn from them.
In response to Rotem12
Wouldn't Enter() be better for what is being asked for #1 on tile-based? Not sure how Enter() works exactly in pixel movement.

For two, you forget to mention the bounding boxes for pixel movement, which would allow the OP to get the two mobs closer together before attacking, which would reduce the need for offsets, though the offsets would still have a use.
@Rotem12:
Cross is what you're looking for.

Cross() ? Hmm, you know i've actually never heard of that..strange, I'll have to F1 it, thanks!

@NNAAAAHH
Wouldn't Enter() be better for what is being asked for #1 on tile-based? Not sure how Enter() works exactly in pixel movement.

I dont understand how Enter() would work there... explain?

@Rotem12
just because the mob is a certain size it doesn't mean you can't have a different sized overlay.

You know I honestly DID NOT EVEN THINK about that.....
But I suppose that'll take quite a few times of trial and error to make it match up perfectly.....


*I'd happily provide a code snippet with comments if it's not enough, from what I understood you get the idea of what you want to do but you just don't know how, code snippets can help you, normally people supply them and explain what they're doing.Don't try to re-invent the wheel doing it all by yourself, someone already solved those issues, learn from them.


Go right ahead, if you wish, but regardless it wont be a snippet, since i'll have to probably rework it ;)
In response to Komuroto
In tile-based movement, Enter() tells everything else if the atom can enter the other atom. You can check the type of the obj/mob inside of Enter and return TRUE to permit the object to enter, it wouldn't matter if the object and turf were dense.
But that seems like a bunch of unnecessary coding doesn't it?