Is there a way to shorten this?

ID:152389
 
Dec 24 2006, 10:56 am
 
    options/Menu
        name="Menu"
        icon='hud.dmi'
        Hud1
            icon_state="0,0"
            screen_loc="8,12"
        Hud2
            icon_state="1,0"
            screen_loc="9,12"
        Hud3
            icon_state="2,0"
            screen_loc="10,12"
        Hud4
            icon_state="3,0"
            screen_loc="11,12"
        Hud5
            icon_state="4,0"
            screen_loc="12,12"
        Hud6
            icon_state="5,0"
            screen_loc="13,12"
        Hud7
            icon_state="6,0"
            screen_loc="14,12"
        Hud8
            icon_state="7,0"
            screen_loc="15,12"
        Hud9
            icon_state="0,1"
            screen_loc="8,13"
        Hud10
            icon_state="1,1"
            screen_loc="9,13"
        Hud11
            icon_state="2,1"
            screen_loc="10,13"
        Hud12
            icon_state="3,1"
            screen_loc="11,13"
        Hud13
            icon_state="4,1"
            screen_loc="12,13"
        Hud14
            icon_state="5,1"
            screen_loc="13,13"
        Hud15
            icon_state="6,1"
            screen_loc="14,13"
        Hud16
            icon_state="7,1"
            screen_loc="15,13"
client/proc/Menu()
    new /obj/hud/options/Menu/Hud1(src)
    new /obj/hud/options/Menu/Hud2(src)
    new /obj/hud/options/Menu/Hud3(src)
    new /obj/hud/options/Menu/Hud4(src)
    new /obj/hud/options/Menu/Hud5(src)
    new /obj/hud/options/Menu/Hud6(src)
    new /obj/hud/options/Menu/Hud7(src)
    new /obj/hud/options/Menu/Hud8(src)
    new /obj/hud/options/Menu/Hud9(src)
    new /obj/hud/options/Menu/Hud10(src)
    new /obj/hud/options/Menu/Hud11(src)
    new /obj/hud/options/Menu/Hud12(src)
    new /obj/hud/options/Menu/Hud13(src)
    new /obj/hud/options/Menu/Hud14(src)
    new /obj/hud/options/Menu/Hud15(src)
    new /obj/hud/options/Menu/Hud16(src)
    ..()


Basically I was trying to get a rectangle on the screen saying Menu... and giving clickable menus below that...
Dec 24 2006, 10:58 am
 
for(var/H in typesof(/obj/HUD))
    src.client.screen+= new H

Dec 24 2006, 1:22 pm
In response to Brendan S
Thanks a bunch... but no way to shorten the defining of what HUD1-16 are?
Dec 24 2006, 6:08 pm
I'd make the icon_states of the icon coordinates. I'd make a for loop to go through every state and add the hub object to the screen. Very simple, actually.
Dec 24 2006, 6:11 pm
In response to Spiderdude
Spiderdude wrote:
Thanks a bunch... but no way to shorten the defining of what HUD1-16 are?

Yes, there is. Defining that many unique type paths is not the way to go. Instead, set up a custom New() proc:

obj/HUD(client/C, X, Y)
  screen_loc = "[X],[Y]"
  C.screen += src


That's just a simple example; I like to set up linked lists to handle my HUD items.

Lummox JR
Dec 31 2006, 8:25 pm
In response to Lummox JR
Lummox JR wrote:
obj/HUD(client/C, X, Y)
>   screen_loc = "[X],[Y]"
>   C.screen += src

That's just a simple example; I like to set up linked lists to handle my HUD items.

Whoa, that's weird... since when has DM supported constructor-like syntax?
Dec 31 2006, 8:30 pm
In response to Jtgibson
 
obj/HUD
  New(client/C, X, Y)
  if(!C || !X || !Y)del src
  screen_loc = "[X],[Y]"
  C.screen += src

wouldn't it be that ?
Dec 31 2006, 9:18 pm
In response to Xx Dark Wizard xX
Xx Dark Wizard xX wrote:
> obj/HUD
>   New(client/C, X, Y)
>   if(!C || !X || !Y)del src
>   screen_loc = "[X],[Y]"
>   C.screen += src
>

wouldn't it be that ?

No, since none of that is indented properly. Also, it's perfectly valid for X and/or Y to be 0 here.

Lummox JR
Dec 31 2006, 11:34 pm
In response to Jtgibson
For a while now, even though I still do things the ol' fashioned way =\
Jan 1 2007, 12:34 am
In response to Lummox JR
Lummox JR wrote:
No, since none of that is indented properly.

at least there's a New() proc that the code is trying to be in =)

Xx Dark Wizard xX wrote:
> obj/HUD
>   New(client/C, X, Y)
>   if(!C || !X || !Y)del src
>   screen_loc = "[X],[Y]"
>   C.screen += src
>

wouldn't it be that ?

the constructor isn't the best place to check if the client is null since you'd be checking that for every /obj/HUD that's created. you may be creating two /obj/HUD objects from the same parent proc, so its simpler to check if the client is null in the parent proc than it is to check that in both of the constructors for the objects you're creating.

for example:
mob
  proc
    init_HUD_1()
      new /obj/HUD/menu1(src.client,1,1)
      new /obj/HUD/menu2(src.client,15,1)

or

    init_HUD_2()
      if(src.client)
        new /obj/HUD/menu1(src.client,1,1)
        new /obj/HUD/menu2(src.client,15,1)


if you check for the client being null in the constructor of the HUD object, init_HUD_1 is checking the same thing twice. if you didn't check in the constructor and relied on the parent procedure checking, then init_HUD_2 only checks for the client being null once. you could create the HUD objects from inside a proc belonging to the client, in which case you'd know for sure that the client exists and even checking once would be unnecessary.

its a small difference, but these things can add up. it won't always be checking for a client being null, which is probably a very quick check. some times you may be checking whether two objects are in view of each other, or whether a particular object is in a list. while a lot of these checks are easy for you to type, they may be a lot harder for BYOND to execute and the difference between doing them 5 times and doing them once could easily add up. its not likely to make a difference in this case, but its something that you should be aware of.
Jan 1 2007, 6:09 am
In response to Lummox JR
Lummox JR wrote:
No, since none of that is indented properly. Also, it's perfectly valid for X and/or Y to be 0 here.

Lummox JR

I shouldn't be coding so late, oops.
Jan 1 2007, 10:19 am
In response to OneFishDown
OneFishDown wrote:
if you check for the client being null in the constructor of the HUD object, init_HUD_1 is checking the same thing twice. if you didn't check in the constructor and relied on the parent procedure checking, then init_HUD_2 only checks for the client being null once. you could create the HUD objects from inside a proc belonging to the client, in which case you'd know for sure that the client exists and even checking once would be unnecessary.

its a small difference, but these things can add up. it won't always be checking for a client being null, which is probably a very quick check. some times you may be checking whether two objects are in view of each other, or whether a particular object is in a list. while a lot of these checks are easy for you to type, they may be a lot harder for BYOND to execute and the difference between doing them 5 times and doing them once could easily add up. its not likely to make a difference in this case, but its something that you should be aware of.

True, but I would actually say it would be more important to encapsulate the if(src.client) check within the HUD object than it would be to use it externally. If you forget to call it externally, it's possible your code would fail with a stream of errors if you accidentally were to try to make a HUD on an NPC and forgot to check if it actually had a client. In this case, the errors would be readily fixable, but in some cases it can be harder to track down, especially if you have a deep call stack before the client variable is actually used.

I'm always of the opinion that getting your code working is more important than making sure it runs at optimum speed. A car that runs like a Viper but has no wheels isn't much of a car. =)
Jan 1 2007, 11:32 am
In response to Jtgibson
Jtgibson wrote:
True, but I would actually say it would be more important to encapsulate the if(src.client) check within the HUD object than it would be to use it externally. If you forget to call it externally, it's possible your code would fail with a stream of errors if you accidentally were to try to make a HUD on an NPC and forgot to check if it actually had a client. In this case, the errors would be readily fixable, but in some cases it can be harder to track down, especially if you have a deep call stack before the client variable is actually used.

I'm always of the opinion that getting your code working is more important than making sure it runs at optimum speed. A car that runs like a Viper but has no wheels isn't much of a car. =)

in this case the difference in performance is minor, but most people wouldn't even think of that difference. if people don't realize the difference now, its not likely that they'd realize the difference when its more significant. its not important that you do make your program as fast as possible, but its important that you know what is slowing it down and how you could make it faster.
Jan 2 2007, 10:12 am
In response to OneFishDown
I tend to be of two minds on the issue of doing a client check in a HUD object. At creation time, you're almost certainly dealing with a valid client, so it often makes sense not to check; it is not, however, bulletproof. I tend to put in the check, just to be safe, but in any code requiring a tight optimized loop it'd be worth ditching like you said.

Lummox JR