Ahoy. You may think that you have a small problem here that can be solved very simply by the experts floating around this forum, but one look at the code you posted reveals a host of problems which need to be addressed before you can get your game working properly.



First, what is going on there? Perhaps this is just a problem with how you cut and pasted the snippet of code you posted here, but anyone with knowledge of DM would know how to indent their code: for example, I'm guessing you want the "del src" line to be spawned after 100 ticks, but that's not what's happening here; you would need to indent the line under spawn, and why is that New() proc definition just floating out in the middle of nowhere? You may not be interested in that section of code at all (you're just here to figure out what's wrong with Bump) but what it tells me is that you don't know how to indent code, and you're just throwing together random stuff in the hopes it'll work.



Let's take a look at what you're doing here. First, you define Bump(), which takes one argument, which you have defined simply as "A". You then tell the game to assume that A is a mob when you assign it to var/mob/M and then later try to access M.SpiritualEnergy. What if this object (I'm guessing it's some sort of 'Beam') had bumped into a dense /obj, /turf, or even a dense /area? You are guaranteed to get runtime errors with this code because of that assumption. So, first and foremost, we need to check if A was not a mob, and return in that case.


Next you're checking if M is equal to usr.SpiritualEnergy and returning if that is true. I'm guessing that what you're trying to do here is make sure that the Beam can't hit the person who "shot"/"cast" it. You also define another /mob variable called O and set it equal to usr.SpiritualEnergy. You then define a variable called "damage" and set it equal to rand(O.SpiritualEnergy - M.SpiritualEnergy). Okay, so think really critically here (you should get used to thinking very critically when programming), what are we telling the computer to do? First we've made sure that M is a mob, and we're assuming that O is a mob. But O is usr.SpiritualEnergy... so is SpiritualEnergy a mob variable? O is a mob, so wouldn't that mean that O.SpiritualEnergy is a mob, too? And wouldn't that mean that M.SpiritualEnergy would be a mob, too? Mob - Mob doesn't make any sense.

And then you have this:


That tells me that you don't know anything about type casting, which is essential to programming in DM. Here's a tip you should remember when programming in DM, and I'm being completely serious: never use the : operator. Ever. If you're using it, then you're doing something wrong that is very easy to fix. What the : operator says is "k has a variable called dir, but you (the compiler) don't know about it, so just assume that it's there and try to compile anyway." Here you should be asking yourself, why doesn't the compiler know about the "dir" variable? Well, it only knows what we tell it, and you've told it nothing about var/k. If we had said var/atom/k, then it would know that we're going to put an /atom into k, so it would know about the dir variable. Here, you know that you're going to be putting an /obj/byakutrail into it, so why not tell the compiler that that's what k is going to be?


What this all adds up to is that you don't have a handle on DM programming yet. That's fine, we all started out knowing nothing and trying to get stuff to work. The only problem is that I can't really tell you how to solve your problem, because the code you've posted makes no sense. You have some learning to do, and I suggest you start here. Also, being very clear on these forums is a big help (explain exactly what you're trying to do, instead of "does nothing"). Here's another tip which will help you for the rest of your programming days: when something doesn't work the way you want it to, let your code tell you what's going on. Consider this example:



Now when you run that program and something Bumps into something else, tell me what's happening in the program if you see this message:
Bump: 1, Starting
Bump: 2, Bob/Bob

Look up at the code. We're never getting to the 3rd message, so it must be stopping right before that, right after we check if M == usr.SpiritualEnergy. In this case, we gave ourselves more information about what's going on, so we can see that both M and usr.SpiritualEnergy were objects named "Bob". So that's why it "does nothing". If we had seen the "Bump: 6, finished, everything's working!" message then we'd know that our problem was somewhere else. If we see the 3rd message, but nothing else, then we know that our problem was between message 3 and 4.

A little self help goes a long way.

So delete it when it hits something.

Do you mean that it goes through the person and out the other side?

Don't think on terms of what the spell is going to do; think in terms of how the code will be interpreted. If you mean that it's a piercing spell because it simply is like an arrow and pierces them, then you would want to delete the obj; it has no point in existing, its job is done once it hits the intended target.

Otherwise, if you mean that the obj is supposed to enter one side of your target and go out the other, then say that. Be specific, not as abstract as "it's a piercing spell." We don't know what's going on in your brain or what you mean unless you explain.

As an acquaintance often says, "Communication is key." I don't mean to be rude in any way, I'm just trying to help you so in the future you ask the correct question so you may get a better answer.

... Depends on the piercing. When I think piercing, I plop it in the category of "Piercing, Slashing, Bludgeoning, or Touch" because I'm a total D&D nerd. Of course, not everyone thinks the way I do; just an example of how people plop terms into different categories. Still, you're welcome... I'm not quite sure how you would do that, though. I would give advice on the code, but I fear it may be wrong and possibly insinuate a bad habit.