hp
healthone
icon = 'health one.dmi'
icon_state = "17"
screen_loc = ("3,2")
rangemax = 17
rangemin = 1
width = 17
healthtwo
screen_loc = ("2,2")
icon = 'health two.dmi'
icon_state = "17"
rangemax = 17
rangemin = 1
width = 17
healththree
screen_loc = ("1,2")
icon = 'health three.dmi'
icon_state = "17"
rangemax = 17
rangemin = 1
width = 17
mp
manaone
icon = 'mana one.dmi'
icon_state = "48"
screen_loc = ("3,2")
manatwo
screen_loc = ("2,2")
icon = 'mana two.dmi'
icon_state = "48"
manathree
screen_loc = ("1,2")
icon = 'mana three.dmi'
icon_state = "48"
obj/var
num = 0
rangemax = 0
rangemin = 0
width = 0
mob/proc/Update()
for(var/obj/screen/hp/healthone/O in src.client.screen)
O.num = round((src.health/src.max_health)*O.width)
if(O.num >= O.rangemax)
O.icon_state = "17"
if(O.num <= O.rangemin)
O.icon_state = "1"
if(O.num < O.rangemax && O.num > O.rangemin)
var/newnum = O.num - O.rangemin
O.icon_state = "[newnum]"
for(var/obj/screen/hp/healthtwo/Z in src.client.screen)
Z.num = round(((src.health/src.max_health)*Z.width)+17)
if(Z.num >= Z.rangemax)
Z.icon_state = "17"
if(Z.num <= Z.rangemin)
Z.icon_state = "1"
if(Z.num < Z.rangemax && Z.num > Z.rangemin)
var/newnum = Z.num - Z.rangemin
Z.icon_state = "[newnum]"
for(var/obj/screen/hp/healththree/Z in src.client.screen)
Z.num = round(((src.health/src.max_health)*Z.width)+34)
if(Z.num >= Z.rangemax)
Z.icon_state = "17"
if(Z.num <= Z.rangemin)
Z.icon_state = "1"
if(Z.num < Z.rangemax && Z.num > Z.rangemin)
var/newnum = Z.num - Z.rangemin
Z.icon_state = "[newnum]"
ID:168220
 Nov 24 2005, 4:57 pm
|
|
Due to help from others i've gotten my code to this point
| |
|
Nov 24 2005, 5:06 pm
|
|
Sniper Joe
 |
|
Sure.
obj/screen{var{num;rangemax;rangemin;width};hp{icon_state="17";rangemin=1;rangemax=17;width=17;healthone{icon='health one.dmi';screen_loc=("3,2")};healthtwo{screen_loc=("2,2");icon='health two.dmi'};healththree{screen_loc=("1,2");icon='health three.dmi'}};mp{icon_state="48";manaone{icon='mana one.dmi';screen_loc=("3,2")};manatwo{screen_loc=("2,2");icon='mana two.dmi'};manathree{screen_loc=("1,2");icon='mana three.dmi'}}} | |
Artemio wrote:
Sure. Heh, there's a fine line between making "less bulky" and an "unreadable one-lined mess". I personally don't think that compressing your programming into less lines would be better while programming, but just telling the compiler to do more stuff in less functions. Although I could be misinterpretating what he means, and he actually means "make it look shorter so it looks more efficient". :P ~~> Unknown Person | |
Not to be butting in on this other guys conversation, but are you the same Sniper Joe that makes sprite sheets?
| |
I can give you a great way, but I have to know first about this.
When the num is between the values it minuses the min range. Why is that? This will return the max is number is greater than max, min is number less the min, or number if between them. But no where about minusing min if between. min(rangemax,max(rangemin,num)) | |
Darkdemonrad wrote:
Due to help from others i've gotten my code to this point I can see you have some repetitive programming in there. It's more important to make your programming flexible and robust, so a hud system that shouldn't have to do the generic copy/paste/edit system that most newbies do to develop something similar to what they did before. A good first step to try and optimize an engine is to look at it and try and see what you are repeating. This is what I have found: - You end up looping through three data types and the only difference would be to add their 'num' by 17 if the data type is of "healthtwo", and 34 if it is of "healththree". You can easily just do one loop through all of the data type of /obj/screen/hp and see what data type they are, then do the operations inside of that loop instead at least. - I also see that your Update() proc doesn't mention anything about the mp hud objects, so I assume that you do that somewhere else, which means you do two updates for the HP bars and MP bars. You don't even define those conventional variables you used in the hp stat bar. You might as well define the stat bars in the same subclass so they can share variables they have in common. - Your statistical hud objects has many repeated preset variables. You can set their variables in the /obj/screen/hp class. Some other things which can be improved on is when you do the equation to find what icon state the new hud object has to change to. The whole block of checks of O.num, and the useless comparisons can be done using min() and max(). Another potential problem that might happen is that you might have more stat meters on your hud. Your update() proc might become very long. The current style of how you update() your stat objects is to check every single data type that might be in the client's screen, then doing the equations there. If it ends up being too long, a more simple and organized way is to define an update proc inside the screen object, and let mob/Update() tell all of the screen objects in the client's screen to update(). Some variables which are not needed to be defined in the class is num, since its only use pretty much is temporary storage to get the final icon_state of the object. We can define this localy when we need to. All of that summed up could be similar to this: obj/screen The amount of flexibility your engine needs depends on what you will use it for. It seems logical, but some people just pass by this good rule of thumb. If your hud engine only has one type of unique factor, then don't develop functions made more flexible in that factor, since you are only going to use it once. On the other hand, if you have many types of statbar-like hud objects, it would be a good idea to make it more flexible and robust. Prevent yourself from repeating programming when you can just do specific checks if there are any specific child classes which need an exception. If you don't understand a concept of what I just explained, ask. ~~> Unknown Person | |
Sorry guys that code was horribly horribly bugged. it worked but not in the right way. I have it working now with a third of the code thanks all :D
| |
Heh, there's a fine line between making "less bulky" and an "unreadable one-lined mess". I personally don't think that compressing your programming into less lines would be better while programming, but just telling the compiler to do more stuff in less functions. I agree, but; Although I could be misinterpretating what he means, and he actually means "make it look shorter-- I agree with this as well, which is why I compressed it into 2 lines. | |