Push_Wave
icon='icons/explosion2.dmi'
density=0
layer=MOB_LAYER+1
var
exempt
list/owned=new
pow=0
moves=0
exploid
New(loc,mob/e,xdir,dam,dist,xoff,yoff,dontknock,passedexploid)
..()
exploid=passedexploid
spawn(40)
if(src)
src.loc = null
if(!dontknock)
push=1
if(src)src.pow=dam
if(xoff)src.pixel_x=xoff
if(yoff)src.pixel_y=yoff
if(e)src.owner=e
src.dir=xdir
if(dist>=3)src.icon_state="1"
else if(dist>=2)src.icon_state="2"
else src.icon_state="3"
src.moves=dist
spawn()
var/turf/T = get_step(src, dir)
while(loc && T && moves)
Move(T)
sleep(2)
T = get_step(src, dir)
loc = null
Move(new_loc, dir=0)
if(src.push)
for(var/mob/human/eX in hearers(1,src))
var/mob/human/X = eX.Replacement_Start(owner)
if(eX&&eX != X) eX.curexplosions.Add(exploid) //make them immune if they kawa'd from it
spawn()
if(eX!=src.exempt)
if(X && !X.IsProtected() && !(exploid in X.curexplosions))
owned+=X
if(X)X.curexplosions.Add(exploid)
if(X&&!X.ko) X.icon_state="hurt"
if(X&&src&&!X.Juubi_Power)X.Dec_Stam(src.pow, 0, src.owner)//, "Explosion", "Normal")
if(X&&src)X.Hostile(src.owner)
spawn(5) if(X) X.Replacement_End(owner)
if(X && !X.ko && !X.IsProtected())X.animate_movement=2
spawn(5)
if(X && !X.ko && !X.IsProtected() && X.animate_movement==2)
X.animate_movement=1
if(X && !X.ko && !X.IsProtected())
var/turf/T = get_step(X,src.dir)
if(!T)
loc = null
else
X.Move(T)
if(!loc) return
if(src.moves>=3)src.icon_state="1"
else if(src.moves>=2)src.icon_state="2"
else src.icon_state="3"
src.moves--
if(src.moves<=0)
loc = null
return
. = ..()
if(!(. && new_loc)) // Movement failed or hit edge of map
loc = null
walk(src, 0)
Del()
src.loc=null
src.owned = null
..()
This effect creates an explosion that pushes waves out in all directions. Out of nowhere it will start eating up cpu at deletion, but there isn't much going on during deletion. I watched the self cpu of del() jump from 35 to 135 in like one minute!
| |
Apr 1 2016, 7:11 pm
|
|
Popisfizzy
 |
Is there a reason you keep on deleting this thread and reposting it?
|
Yeah, don't do that. It's super obnoxious.
| |
It's the the third post, just more information. Can someone help me out please? I won't post it again.
| |
projectile This is an example projectile code. It's really simple. All it does is allow you to override the projectile type to create and fire new kinds of projectiles. It's very, very simple and uses BYOND's built-in behavior to do almost all of its work. Let's create a child type of projectile that pushes players when they hit them. projectile Pusher projectiles are fairly complex, but the basic logic is all in place. The reason your projectiles are slow is because your logic is overcomplicated and poorly designed. There's not much to it but to throw it away and try to create something like the above example. I really recommend not using whatever leaked codebase you have your hands on. It's teaching you bad habits and it's going to be impossible for you to fix with your current level of knowledge. BTW, I don't help people after they delete a thread that I've answered, so if you are looking for help in the future, probably best to read this and understand why we frown on deleting answered threads: http://www.byond.com/forum/?post=2015299 | |
Ter13 wrote:
Moved() //called after each successful moveUsing a boolean operations to, essentially, evaluate an arithmetic statement. While syntactically not wrong, I hate it semantically. It just feels like putting ice cream on pizza. | |
syntactically not wrong I literally want to scream whenever I hear programmers talk about pre/post increment/decrement "best practices". Logic is all that matters. If a programmer can't understand the logic pattern, they are a bad programmer. If the compiler can't understand the logic pattern, the programmer is a bad programmer. If the compiler does understand the logic pattern, and the programmer does understand the logic pattern, the programmer is still more than likely a bad programmer because there's a better approach floating out there in the caffeine/junk food aether. | |
It's not really about the decrementation operator and more about the idea that you're switching from an arithmetic "realm" into a boolean "realm". E.g., the following examples would both elicit the same reaction from me.
--distance As opposed to something like, distance-- // or --distance, whatever. The reason behind this is that distance is initially treated as something arithmetic. E.g., something where the difference between distance == 2 and distance == 24914 are meaningful distinctions. Switching suddenly to using a boolean operator, a "realm" where where the distinction between distance == 2 and distance == 24914 doesn't particularly matter, screams "not wrong, but not really right either". Like I said, there is literally nothing syntactically or logically wrong—it will do exactly as you expect. Nevertheless, it just feels gross to me. It's probably just from me looking at things from a math perspective, to be honest. Treating something as one thing, and then moving on and treating it as another conceptually distinct thing—even if they are related—is often a good way to run into trouble, i.e. it is no bueno. Here, that's not really an issue, but that voice in the back of my head still yells. | |
if(!--distance) dec <src,distance> (push) bnot (pop push) cmp (pop) --distance if(!distance) dec <src,distance> (push) pop access <src,distance> (push) bnot (pop) (push) cmp distance-- if(distance == 0) dec <src,distance> (push) pop access <src,distance> (push) push [0] eql (pop pop push) cmp Computers care about binary. That's it. They don't care what the value represents. Divorce yourself from the data model and get down with the electromagnetic spectrum. Information is arbitrary and your revulsion toward operator inclusivity is making you adopt patterns that are objectively inferior for the medium in which you are writing them. It's a trivial concern, granted. It's a stylistic choice, granted. But stylistic choices don't mean equivalent choices. This isn't a case of it works, so it must be right either. This is a case of irrelevant axioms being applied to a problem. <3 | |
Well, I simply wrote it as the above to clarify that the remark was unrelated to the decrementation operator. E.g.,
if(--distance == 0)
would be equally-valid and not "mixing domains" so to speak. Assuming I'm getting this correctly (I've never messed around with assembly or bytecode or what have you), this would be dec <src,distance> (push) push [0] eql (pop pop push) cmp And yes, while it may be objectively inferior if you're game is minimizing the number of instructions per lines of code or something like that, that's not the only game we play as programmers. Sometimes, clarity and consistency of the code we write is also an important measure, and it is entirely justifiable when the losses are also irrelevancies and not bottlenecks. E.g., you can drive dangerously if you're losing blood, but it's harder to justify when the cut was from paper and not from a knife. Now, is using the logical not operator that big a deal re: clarity and consistency as opposed to comparing to zero? Not really. But I don't accept the idea, even implied, that a good programmer is a one who sacrifices gains of being clear for gains of milliseconds. | |
When I'm putting on pants in the morning, I don't pick up my wallet off the dresser, put it in the pocket of my pants, throw the pants on the floor, then pick the pants up again and put them on.
Sometimes, clarity and consistency of the code we write is also an important measure, and it is entirely justifiable when the losses are also irrelevancies and not bottlenecks That'd be a great point if I'd waded into a random thread and told you that you were wrong for using --distance==0. But I think you've maybe forgotten which side of the wall the door is on. | |
Ter13 wrote:
But I think you've maybe forgotten which side of the wall the door is on. Oh, cool, now you're being an asshole because ?????. I have spent the thread doing my best to stress the mutually-respectful tone I had wanted, as I've realized I can come across a hostile and acerbic when that tone was very much not what I've wanted. But I suppose if you've pissed in the mop water I prepared, I can throw the whole thing out into the street. That'd be a great point if I'd waded into a random thread Points one, two, and three proceed as follows. 1. I was already on this thread, even as trivial a remark as it was. It popped up on my pager, so I looked at the thread. 2. A forum thread—on any forum—is not a heart-to-heart between two old chums, it's a circle of people discussing, with an open seat and a sign saying "join in if you'd like!". Not to suggest etymology is an infallible basis for determining meaning, but "forum" is a word that has never denoted privacy. and told you that you were wrong for using --distance==0. 3. I did not once even suggest it's wrong let alone outright say it, and you may go look back through what I wrote if you want to dispute that point. From the get-go, I insisted that—yes—it is a perfectly correct in terms of syntax and logic. What I said is that as far as semantics go, it is perhaps not the best choice. Maybe subtlety is lost on you? When I'm putting on pants in the morning, I don't pick up my wallet off the dresser, put it in the pocket of my pants, throw the pants on the floor, then pick the pants up again and put them on. But I do suspect that when you throw on a pair of pants in the morning, you scissors to the legs because what you really wanted to wear were shorts. | |
I think you've gone and taken offense from a text post in which you are the one that supplies the tone.
No hostility was intended. Just logic. But I don't accept the idea, even implied, that a good programmer is a one who sacrifices gains of being clear for gains of milliseconds. A good programmer is someone who understands the tools at his disposal. The only lack of clarity about the boolean/arithmetic cross-over is in the person reading the code. If that person doesn't understand the tools, it will be unclear. I make a large number of sacrifices of speed in the above post for the sake of ease of polymorphic variation and for the sake of sensible design choices. It's a little suspect to be pretending that I'm talking about micro-optimization, because I'm not. I'm talking about use and understanding of logical patterns and bringing to bear the correct axioms to the discipline. | |
Ter13 wrote:
No hostility was intended. Just logic. These claims are not one of mutual exclusivity. The comment But I think you've maybe forgotten which side of the wall the door is on. is little more than a snide, smug remark, or at the very least I can see no other way of interpreting it. The only lack of clarity about the boolean/arithmetic cross-over is in the person reading the code. This was a general remark, not aimed at the matter at hand specifically. By suggesting that all that matters is that which is "objectively superior" when playing the game of "minimize instructions" is readily extended to "minimize instructions even when there is a loss of clarity". As I have tried to stress—and as I have tried time-and-time again in this thread—this matter in particular (boolean operations on arithmetic data) is not much one of clarity. It's a little suspect to be pretending that I'm talking about micro-optimization There is little conclusion that can be drawn otherwise when you cite assembly instructions to claim that a logically-equivalent method is objectively inferior due to the fact that the "objectively superior" method uses exactly one less instructions. There is no pretending on my half at all, unless you can suggest an alternate reason to bring in assembly and then criticize my method as objectively inferior. Piddling over using one extra constant-time instruction sounds quite a lot like talking about micro-optimization. What happened is I cited something I felt was semantically-iffy and explained why. You countered with assembly instructions demonstrating why my method was inferior under the implicit assumptions that the operation with fewer assembly instructions is the one that is objectively better, and then Information is arbitrary and your revulsion toward operator inclusivity is making you adopt patterns that are objectively inferior for the medium in which you are writing them. you proceeded to suggest that because I did not like this method because of how it treated data as one type and then proceeded to treat it like another, I am somehow an inferior programmer. I honestly don't know your game here or what you're trying to achieve. I made my reasoning behind the statement clear, and defended myself against your specific claims here, and you have proceeded to suggest I may be a poor programmer (unless the suggestions that I am objectively wrong and that I am unable to divorce the abstraction and the implementation are not jabs at my ability as a programmer). My patience has grown quite thin. | |
Please stop. This is not the place for this. I am not attempting to insult you. I'm a very direct person. If I had insulted you, you wouldn't have to explain to me that I did. If you are insulted, I apologize, but I did not insult you. You became insulted.
| |
Damn!
| |
Damn, Daniel.
| |
As a neutral observer, I do think there is something to be said here.
Ter13 said: I think you've gone and taken offense from a text post in which you are the one that supplies the tone. Your posts do hold a condescending undertone. Whether you realize this or not is a different monster. One can be direct and not be offensive in their communication. Simply being mindful of not only the other person, but your choice of words, are steps in achieving this. However, when it is your ego talking, mindfulness is out the window; you are only concerned with what's in front of you, in this case being right or wrong. While you did apologize, you don't seem to have acknowledged the underlying issue that causes these incidents. Instead, the situation was dismissed as existing entirely in Popisfizzy's mind, and that's simply a denial of the reality here. I've already said more than I intended, so I'll stop here. I do encourage you to think about what happened here, using more than your intellect. Or you could blow everything off and continue being misunderstood, that works too. I don't think you (or anyone) deserve the latter though. | |
Also something I wanted to say to the OP: ditch that GOA source. All of the original developers jumped shipped with good reason.
| |
To FEEL insulted is to be invested emotionally, thats your won problem/fault.
being mindful of another persons FEELINGS in a conversation you just don't attach any emotion to beyond the logic, doesn't make sense. You CHOOSE to feel insulted, you LET someone make you angry. there either both wrong or both right so either way its moot. | |