My Code isnt working, Someone help find the Problem ?

Oct 6 2016, 6:31 pm In response to Genesismagician
ISSACK	It says Bad Proc what with that ?

Oct 6 2016, 6:32 pm
Genesismagician	turf/EnteredZone Entered(mob/M) if(M.key == "ISSACK") usr.loc=locate(71,34,2) else return ..() Sorry... Use it like that...

Oct 6 2016, 6:56 pm
Nadrew	That's just terrible. 1) There's no guarantee M is a mob or a client. 2) You're using usr. 3) Checking key instead of ckey is never a good idea. 4) No need for else. turf/EnteredZone Entered(mob/M) if(ismob(M) && M.client && M.ckey == "issack") M.loc = locate(71,34,2) return ..()

Oct 6 2016, 6:58 pm
Genesismagician	He doesn't seem like he has any idea what he's doing so I was trying not to over complicate it for him...

Oct 6 2016, 7:00 pm
Nadrew	Teaching people bad practices is counter-intuitive. If he doesn't know what he's doing, teaching him how to do it wrong is a step backwards.

Oct 6 2016, 7:02 pm
Genesismagician	The code works. If it works, it works. From what you just said "Do it my way or you're wrong". Typical response from you.

Oct 6 2016, 7:05 pm
Nadrew	Typical response from someone who knows nothing about programming. Please stop trying to teach people if you don't know what you're talking about.

Oct 6 2016, 7:08 pm
ISSACK	. . . . .

Oct 6 2016, 7:09 pm

Genesismagician

My code works. We can sit here and argue about it until you get pissed off and start deleting my posts like you usually do. Did I argue that my code is not "100% perfect", no. Did I argue that your code is more efficient? No. Why? because your method is more effective. My method is simple and it does work. Will it fuck up eventually? Probably. Over complicating things for noobs only discourages them... In case you haven't noticed.

Oct 6 2016, 7:28 pm

Nadrew

Your method would lead to a runtime error any time anything that wasn't a player moved onto that turf, the argument for Entered() doesn't guarantee the type will match what you cast it to, hence the ismob() and client checks.

Knowing that about Enter()/Entered() and the various procs of that nature is one of the first things a lot of people learn here, you didn't learn it, because you actually used 'usr' in Entered() which is 100% wrong, I don't care what you say.

It's not over-complicating anything, it's teaching them one of the most basic concepts of the language.

It's not a matter of efficiency, or effectiveness, it's a matter of the fact that your code is broken and will cause more errors that the "noob" you're talking about would have no idea about.

Oct 6 2016, 7:48 pm (Edited on Oct 6 2016, 8:00 pm)

Best response

Ter13

Genesismagician wrote:

I see the problem... Not sure how the hell I missed it...

> turf/EnteredZone
>     Entered(mob/M)
>         if(M.key == "ISSACK")
>             return ..()
>

My code works.

No it doesn't.

Genesismagician wrote:

> turf/EnteredZone
>     Entered(mob/M)
>         if(M.key == "ISSACK")
>             usr.loc(71,34,2)
>         else
>             return ..()
>

My code works.

No it doesn't.

Genesismagician wrote:

> turf/EnteredZone
>     Entered(mob/M)
>         if(M.key == "ISSACK")
>             usr.loc = locate(71,34,2)
>         else
>             return ..()
>

No it doesn't.

The reason that gif #1 doesn't work and is wrong is because Entered() is called for any object that moves on top of any turf. Not just mobs. You can't assume that the object will have a key. You have to make sure that the object you are assuming is a mob is actually a mob.

The reason that gif #2 doesn't compile is obvious. loc isn't a proc.

The reason that gif #2 doesn't work and is wrong is because, as I prove in the gif, usr is not always equal to M. You are assuming that usr is the object that entered the zone, but it's not. There are cases where usr will be equal to zero instead of a mob. You aren't accounting for whether usr is valid or not. That's another problem. Instead of validating whether usr would be valid, we simply avoid it by advising people not use usr in places where it even COULD be invalid. That's why we harp on people for using usr incorrectly, because it can fail in spectacular and unpredictable ways and it's a habit that eventually becomes pervasive and causes worse problems.

Even if your code DID work, Genesis, which BTW, none of it does, Nadrew is still only coming at you as harshly as he is because it's hard for new programmers to sort out those that know what they are talking about and those that don't.

You still have a LOT to learn before you should be trying to offer programming help as though you were some kind of expert. That's nothing to be ashamed of. The biggest thing though, is that you need to be able to appraise yourself and be able to self-examine rather than just turning being called out for handing out non-functional code into a pissing contest.

You are provably, irrevocably wrong. Sorry, that's not a personal attack, that's just how it is. Programming is a practical art. Working is only one of the metrics for whether code is good or bad.

Sometimes you may think something works, but it doesn't because there are other problems that the approach causes that you may not necessarily care about. Just because YOU don't care about those problems doesn't mean that the person you are helping doesn't, and you should be aware and up-front about those problems with your approach.

#define isplayer(ref) (ismob(ref)&&ref:client)

turf/teleport
    Entered(atom/movable/o)
        if(isplayer(o))
            var/mob/m = o
            if(m.ckey=="issack")
                m.loc = locate(71,34,2)
        ..() //return is not necessary in Entered() by default.

Make sure to put that #define line in a top-level file like the DME outside of an autoformatted block. Otherwise you might have trouble using it in other parts of the code based on compile order.

Anyway, the above is another approach for how this ought to be done. It works. It doesn't cause runtime errors in any case, and it doesn't have potential failure points.

Entered() accepts any type of movable atom as the first argument. As such, we have to verify that the object is actually a mob before trying to treat it as a mob.

We do something called "casting". Casting is treating one data type as another. In this case, we're casting upward, making the data type's container more specific. This allows us to treat the movable atom as a /mob, which we have already verified that it is. This gives us certain compile-time assurance that o will have a ckey variable.

This is not overcomplicated. It is the optimally correct way to do this.

Oct 6 2016, 8:03 pm In response to Ter13
ISSACK	If I wanted to add another person to that List I would Just do this right?: turf/EnteredZone Entered(mob/M) if(ismob(M) && M.client && M.ckey == "ISSACK,White Zetsu210") M.loc = locate(71,34,2) return ..()

Oct 6 2016, 8:49 pm (Edited on Oct 6 2016, 10:09 pm)

Ter13

ISSACK, that's close, but not exactly right.

What we're looking for is a logical or operator.

A logical or operator runs from left to right and will allow you to check if one of a series of operations is true.

if(ismob(M) && M.client && M.ckey == "issack" || M.ckey == "whitezetsu210")

Now you might start to notice that once you start adding admins, you'll start having to change stuff all over your code. That's a problem. A real big problem. And god forbid you have a typo.

Well, we can make this a lot easier:

if(isadmin(M))

But how do we define a proc for isadmin?

var
    list/admins = list("issack"=1,"whitezetsu210"=1)
proc
    isadmin(ref)
        var/ckey
        if(ismob(ref))
            ckey = ref:ckey
        else if(istype(ref,/client))
            ckey = ref:ckey
        else if(istext(ref))
            ckey = ckey(ref)
        else
            return 0
        return admins[ckey]||0

What we just did is create a global procedure for checking whether someone is an admin. We can check if a mob, a client, or a text string matches one of the keys stored in the global admin list.

Why would we do it this way?

Well, the reason we would do it this way is that it makes it much easier to add another admin to the game.

We can even add new admins to the game dynamically while it is running, and we can put a file on the host's hard drive and load that when the game starts to store any added admins!

proc
    //get a valid ckey from a mob, client, or text string
    get_ckey(ref)
        //READABLE METHOD:
        //This method uses if-else statements to get the ckey based on the three accepted types of values
        if(ismob(ref)||istype(ref,/client))
            return ref:ckey
        else if(istext(ref))
            return ckey(ref)
        else
            return null
        //OPTIMIZED METHOD:
        //This method does the same thing, but without if statements
        //return ((ismob(ref)||istype(ref,/client))&&ref:ckey)||(istext(ref)&&ckey(ref))||0

    //check if a mob, client, or text string is an admin
    isadmin(ref)
        var/ckey = get_ckey(ref)
        if(!ckey) return 0
        return admins[ckey]||0

admin_manager
    proc
        //adds an admin to the global admins list by mob, client, or text string
        add_admin(ref)
            var/ckey = get_ckey(ref) //get the ckey of the reference
            if(ckey&&!admins[ckey]) //if the key is valid, add to the admins list
                admins[ckey] = 1
                save() //save the change
                return 1
            return 0

        //removes an admin from the global admins list by mob, client, or text string
        remove_admin(ref)
            var/ckey = get_ckey(ref) //get the ckey of the reference
            if(ckey&&admins[ckey]) //if the key is valid, remove from the admins list
                admins[ckey] = null
                save() //save the change
                return 1
            return 0

        //save the global admins list to JSON
        save()
            if(fexists("admins.json")) //check if the file already exists
                if(!fdel("admins.json")) //delete the old file.
                    world.log << "unable to clear old admins file!"
                    return 0
            text2file(json_encode(admins),"admins.json") //export the admins list decoded to JSON format as raw text file.
            return 1

        //load the global admins list from JSON
        load()
            if(!fexists("admins.json")) //if the file doesn't exist, don't do anything
                return 0
            var/list/loading = json_decode(file2text("admins.json")) //load the file into raw text and then decode it into a list.
            admins |= loading //add to the global admins list without overwriting your hard-coded admins.
            return 1

    New()
        load() //load the admins list from the hard drive when the admin_manager is created.

var
    admin_manager/admin_manager = new() //create a single instance of the admin_manager datum before the world loads fully.
    list/admins = list("issack"=1,"whitezetsu210"=1) //these hardcoded admins won't be removed when loading the admin configuration file.

Isn't it awesome that you can write code that you never have to touch again? Code that can reach into deeper parts of your project and make your life much easier?

Now we don't have to worry about adding new admins to the game. We just add and remove them and never have to change our code again! We can even distribute our game's runnable files and let hosts determine who their own admins are by either editing that admins.json file and adding their own values! No need to hardcode people or give people the source code just to add admins!

Hey! You! If you skimmed this, at least read this bit! Just having this code is nothing. You can do this too, and easily if you spend some time trying to learn the syntax of DM and investigating how the engine works. I didn't copy this code from anywhere. I just wrote it tonight specifically for this question. You can do this too. Don't give up. Stick with it, and read. Read lots. You'll get there faster the more you force yourself to understand. Just having the code is nothing. The will to understand the code is everything.

Good luck!

Oct 23 2016, 1:10 pm
ISSACK	Sigh Question when u told me the Code it worked perfectly but Now try testing it doesnt work. any answer's on why ? Anyone ?

Oct 23 2016, 1:23 pm
Ter13	When you say it doesn't work... How does it not work?

Oct 23 2016, 1:25 pm In response to Ter13
ISSACK	Well when I compile it says no Error's When I run it to test it it does not take me to the Cords I need to.

Oct 23 2016, 2:24 pm In response to ISSACK
Ter13	ISSACK wrote: Well when I compile it says no Error's When I run it to test it it does not take me to the Cords I need to I can't help you without information on what you used, and how you used it.