Is there something wrong with mousedown?

ID:2041494
 
Feb 21 2016, 4:29 am
(See the best response by Ter13.)
Code:
client
    MouseDown(object, location, control, params)
        var/list/f=params2list(params)
        if(in_suit)
            if(f.Find("left"))
                if(usr:MyArma.l_ammo>0)
                    usr:MyArma.l_ammo=max(0,usr:MyArma.l_ammo-1)
                    usr:MyArma.UpdAmmo(usr)
                    spawn(rand(1,3))
                        ArmaGat(object,mob)
            if(f.Find("right"))
                if(usr:MyArma.r_ammo>0)
                    usr:MyArma.r_ammo=max(0,usr:MyArma.r_ammo-1)
                    usr:MyArma.UpdAmmo(usr)
                    spawn(rand(1,3))
                        //ArmaMissile(object,mob)
                        MortarShot(object,mob)
        else
            if(mob.mortar_mode>0)

                MortarShot(object,mob)


Problem description:
This code relates to a mech that is designed to shoot when the player clicks the left mouse button and to shoot a secondary attack upon clicking of the right mouse button, for some reason the right mouse button doesn't register at all.

Is there something special I need to do to enable right mouse clicks to work in this instance?
Feb 21 2016, 4:50 am
A quick search yielded this post:
Issue

I'm assuming it was fixed in 510- and not 509 which I'm running.

However I'm not running games in web-client mode as this post suggests.
Feb 21 2016, 5:27 am (Edited on Feb 21 2016, 3:43 pm)
Best response
Did you set the map element to sent right-clicks to mouse procs in the interface editor?

Also:

f.Find("left")


You are using O(N) operations again when an O(log N) operation is all that's needed:

if(f["left"])


If the "left" parameter is not present, f["left"] will return null, which will evaluate to false in the context of an if statement.

        else
            if(mob.mortar_mode>0)

                MortarShot(object,mob)


Also, that's a bit of a bad habit. You've got a double scope traversal there.

        else if(mob.mortar_mode>0)
            MortarShot(object,mob)


Single scope traversal. Scope traversal can be quite costly.

Those last suggestions aren't about optimization. They are about bad habits. Bad habits like the O(N) operations instead of O(log N) operations are the kind that do really matter quite a lot, because if you don't understand the difference, you can wind up making really bad assumptions in your design that actually make a total rewrite necessary once you hit the point where you start to understand why they are problems. A little bit of housekeeping early can prevent a lot of work later.
Feb 21 2016, 1:04 pm
In response to Ter13
LOL
if(f.Find(""))

That's not a bad habit...
"it's 3 am in the morning and I was sleepy while I was coding" habit.


Right clicks weren't turned on to send to the map was the issue thanks.
That's super obscure. -_-

But more to the reason I used f.Find() is because my impression was that certain paramaters might not be in the list , when unsure what's in a list you're supposed to actually make sure it's there and not assume.

Pretty sure I learned that somewhere in a coding class or tutorial I happened upon (always validate your info actually exists) so to me, that's a super minute point. The rest is helpful, thanks.
Feb 21 2016, 2:14 pm
Technically an associative list lookup is O(log N).
Feb 21 2016, 3:40 pm
"it's 3 am in the morning and I was sleepy while I was coding" habit.

I'm actually currently rewriting a lot of code that you wrote for one of your paid clients... I can promise you that this bad habit and lack of understanding of collections is rampant in all of the code you write and it's not a one off.

That's not a bad habit...

Sorry, but you are wrong. If the O(log N) operation is valid in every case where you are using the O(N) operation, you are just wrong.
Feb 21 2016, 5:57 pm
I feel like Ter13 gets away with savagery remarks. mistakes happen is all that needed to be said.
Feb 21 2016, 6:02 pm
he wants him to learn
Feb 21 2016, 6:37 pm (Edited on Feb 21 2016, 6:49 pm)
I feel like Ter13 gets away with savagery remarks.

I feel like you only post in Developer Help to stir shit.

he wants him to learn

I'm not firing shots. I'm blunt, but I'm not trying to hurt anyone's feelings. The problem isn't bad habits. The problem is bad habits compounded by overestimation of one's own understanding, which in the end undermines someone's ability to understand logical patterns correctly.

Just because I'm not dripping honey into his ears doesn't mean that I'm being disrespectful.

(This is a sample of some code I was fixing earlier in the week of his.)

if(!isnull(list["herp"]))
    return list["herp"]
else
    return null


What I'm pointing out is a persistent lack of understanding of logic patterns, but being waved away because "a class told him to do this" is... Well, how do you respond to that?

When you thoroughly explain that returning null if list["herp"] is null, and otherwise returning the value of list["herp"] is the same thing as just returning list["herp"] without an if-statement, scope traversal, else-jumpcode, or double O(log N) access, "I took a class" is... Well, it's just nonsense.

Ultimately, the problem alone isn't the lack of understanding, but it is being hardened to logical, well-reasoned advice because that person can't see past their own incorrect self-assessments.

I'll happily admit that Avid works faster and pumps out a viable product far more often and more reliably than me. However, just because someone trumps your ability at one aspect of the job doesn't mean that that person is incapable of learning something from someone else.

What else can really be said when someone is wrong, than they are wrong? What's disrespectful about trying to explain why they are wrong and having the respect for that person to not treat them like a hypersensitive child?
Feb 21 2016, 10:14 pm
Tbh i never pay attention to what board im under. im also a blunt person. were still savages. this is a pc world.
Feb 21 2016, 10:37 pm (Edited on Feb 21 2016, 10:48 pm)
In response to Ter13
Um..
Not to be rude but I really don't need (or care) to be lectured, that's why I didn't respond . I've stated that on several occasions, and I can only assume people continue to do it to try to illicit some kind of response so they can point fingers and go "see look how childish he is".
*blank stare* k. got work to do. Is "usually" my response.

Also this doesn't need to devolve into any type of argument.

Despite what ter13 says, I actually know for a fact that in most programming languages you MUST, without a doubt, make sure that values exist otherwise your entire program crashes, not limited to but including "run time errors", DM is a bit more forgiving.

I think it's lunacy to say that you should assume a variable has a certain value, or that it even exists as that's where run-time errors often occur.


But more to the point, in terms of anything that was said to be honest I overlooked it because-- I just don't care that much. Unless it's a game shattering programming habit, I'll consider it keys to refinement and continue doing what I do.

In general, I'm not really that guy who feels the need to act out of character to fit in. I don't do things to gain acceptance, nor do I care to. That being said-

I don't care,need or want to explain myself, why I do the things I do, or why I don't, what I think. Because..why does anyone care? Don't they have better things to do? If not...they probably should.

Nothing will hurt my feelings because it will either be acknowledged as an area of improvement or dismissed as nitpicking.

In this instance it's a little of both.

Taking one snap shot from God knows where in what space in time and pointing to it as evidence of a bad habit is, at most a but dubious and flimsy.

Looking at that code right now, I can easily see it should just be
return list["herp"]

But here's the thing- what if herp doesn't even exist in the list? Then the return code itself throws an error.

But you're saying that it's pointless to check if the value exists in the list al together? That makes 0 sense.

Either way there's quite a few other reasons , which, btw no one's approval is needed for me to have or voice.

Off the top of my head:

  • a) tired and not thinking clearly when I coded it, which happens alot
  • b) just in a rush and on auto-pilot
  • c) copied from an older sub set of code
  • d) making EXTRA sure to fix a null error which I was having trouble finding.


I have a pretty large code base built up of various things at this point. Iso Engines, Side Scrolling Engine, action adventure, etc. And all of it is under constant refinement.

Thus if you were to look at any of my code in any of the games I work on, it's never entirely the same, as I constantly try new approaches, to see what works and what doesn't.

In general, if I have a specific question I'll ask it, but I feel like the minor things you're pointing out are just an issue that you personally have a problem with, which rates very low on my chart of "to do" lists.

Why? The entire point of my post-because it's my chart, and it's not high priority. That should suffice, I don't need to offer any other explanation other than-"Oh, ok thanks for pointing that out."

Often times I notice in this community that people like to do what I call the "li' bro" syndrome. Everyone wants to be the senpai who taught X so they can brag about it. The issue is that when you tell people "hey, I got it. I don't really want or need the help you're offering." They get uber offended, take it personally and scream "Hey you're a douche, I was just trying to help you man, if you weren't like this you would have FRIENDS"

Correct me if I'm wrong but, I'd also have friends if said person weren't trying to force their ideas on me despite me voicing opposition. Highly rude, shows that my opinion isn't respected on any level, and will flatly be dismissed at all times regardless of my current mood.


I can assure you the number of times I actually use this forum in a month is probably the one or two times I post a question when I've worked so much my brain has become fuzzy. And it always devolves into some nonsense like this, random guy A --> hey lemme ignore the question totally and make my reply to be about 70% unrelated topics so that I can showcase how much smarter I believe myself to be.


That being said I tend to take anything that's said to me with a grain of salt. No one is perfect, I've never claimed to be, so I'm not sure why a lot of people in this community like to throw so much shade or pop up like "yo I'mma let you finish in a minute, but this way to do it is the best of all time" But in all honesty I usually just don't care. And none of you should either with the very low production rate of games in this community. it's like people spend all their time trying to one up each other or putting on aires instead of actually being productive.

That's why I didn't go out of my way to explain anything in context to what was said, because time is the most precious commodity you have in life. Every minute or second you waste is one you'll never get back. And I absolutely refuse to continue wasting time having realized this one simple truth.

If it's not advancing me, I let it go. If it's not helping me, I reject it.

I am aware that telling the truth makes you the "bad guy", but truthfully I'm ok with that.
You may now all continue talking about how I have no friends because of how much of a blistering ass I am, simply for saying "No thanks, I'm not interested."

*resuming anti-social mode in 3,2,1*
Feb 21 2016, 11:35 pm
 
var/list/l = list()
if(l["herp"]==null)
    world << "This doesn't cause a runtime. l\[\"herp\"] is null"
l = list("herp"=4)
if(l["herp"])
    world << "This doesn't cause a runtime either. l\[\"herp\"] is [l["herp"]]"
Feb 22 2016, 12:08 am
In response to Avidanimefan
I don't want to dogpile on you here, but I have to point out two things: 1) You're working on an assumption that directly contradicts the DM Reference, which is something you should have known going in, and 2) your attitude towards Ter's attempt to set you straight is proving his point.

Avidanimefan wrote:
Despite what ter13 says, I actually know for a fact that in most programming languages you MUST, without a doubt, make sure that values exist otherwise your entire program crashes, not limited to but including "run time errors", DM is a bit more forgiving.

I think it's lunacy to say that you should assume a variable has a certain value, or that it even exists as that's where run-time errors often occur.

On that point you would be correct, except you're doing sanity checking in entirely the wrong place and in the wrong way. list["herp"] will never crash unless the list itself is null, as explained further below. And this is one of the things Ter was trying to point out.

Meanwhile a sanity check you should be doing, you're not. In the original post, you're not checking to see if usr.MyArma is non-null. Nor are you using type-casting so you can avoid abuse of the : operator--which is something you should strenuously avoid, as it's an easy way to turn things you might catch at compile-time into runtime errors.

Abuse of the : operator is one of the "big three" things I always warn newbies to avoid (the other two being usr abuse and goto abuse). Under the hood : and . behave the same, but you should go out of your way to use . because it shifts more potential for problems onto the compiling stage, where you can catch them early.

I don't care,need or want to explain myself, why I do the things I do, or why I don't, what I think. Because..why does anyone care? Don't they have better things to do? If not...they probably should.

If you're being paid to program, code that is clean, fast, and reliable is kind of a big deal. Ter was only trying to convey something that's pretty important, and defending your way of doing things as just a habit or "it was 3 AM" doesn't really fly.

Looking at that code right now, I can easily see it should just be
return list["herp"]
But here's the thing- what if herp doesn't even exist in the list? Then the return code itself throws an error.

No it does not. If "herp" is not in the list, then list["herp"] is null. The only way for that line to throw an error is if the list itself is null, or if it is not a list. In that case list.Find("herp") is every bit as likely to crash the proc, and only ("herp" in list) is safe.

In list/associations in the BYOND reference:
Associated values default to null if none is assigned. This is also the value returned when the supplied index item does not exist in the list. The list defined above, for example, would return null for params["time"].

So while you're right that you should be looking for nulls and unexpected values in places where they could potentially crop up, you're wrong that list[item] poses a crash risk unless the list itself is null--and in that case, list.Find() is just as bad.

More importantly, the behavior of associative lists is strongly built into DM and it's something you should have a better handle on before offering DM programming services professionally. So when a guy with experience tries to give you some super important pointers and you get defensive and blow him off, you're hurting yourself (and of course, your clients). Ter's not trying to be mean; he wants to help you become a better programmer.