So i know how to change icon_state using a verb that references. However, i'm not sure how to make the icon_state change by only referencing the variable.
is there a way to do that?
what i am trying to do is get a wood box to display three differant icon_states, the first when it's variable is greater than five, the second when it's greater than or equal to 1, and the third when it's variable is equal to 0.
ID:165448
Dec 22 2006, 10:02 pm
|
|
I'm fairly certain this would be simple... something like a verb such as PutIn()... a var such as quantity for the dresser.. everytime you add something to the dresser O.quantity++
if(O.quantity=1) O.icon_state== "One" if(O.qunatity=10) O.icon_State=="Stuffed" something like that... I haven't programmed in a year.... will come back when I have a better answer |
In response to Spiderdude
|
|
if(O.quantity==1) |
In response to Rky_nick
|
|
Rky_nick wrote:
How exactly does the varible lower or increase? you could add a if(varible > 5) or if(varible >= 1 && < 5) dont want any mix ups and then if(varible == 0)__________________________ The variable would rise when wood was put into the box, and would lower when wood is taken out. I appriciate the code snippets, but when i put them into it, i get a bunch of errors (and i did change the words to corispond with the variable.) I guess my question is: Do I have to have a verb to make it work? if so, i suppose i will have to make a child of the get verb... If i do that, how would i make it check the woodbox varible before it allows the verb? And if i do make a parent Get verb, is there a way to keep usrs from "Get"-ting obj's i don't want them to get? (i.e. i don't want them to be able to pick up the woodbox itself, just the wood inside) I know i'm just starting to learn, but i'm trying to keep things as clean as possible so that when i do run into problem (like this) it would be easy for someone more skilled than i to help me find my errors |
In response to Cuddlebear
|
|
There shouldn't be errors... and no you need it in the verb that's there... when you do take them out.... make it check using an if() and then if(it equals a certain amount left in the bin)
icon_state="changethistothestate" |
In response to Cuddlebear
|
|
Cuddlebear wrote:
The variable would rise when wood was put into the box, and would lower when wood is taken out. Put simply, don't copy and paste code from the forums. Posted code is for reference only. Learn from it, then code your own. I guess my question is: Do I have to have a verb to make it work? ...of course not. But you probably want a verb, dont you. if so, i suppose i will have to make a child of the get verb... That would be pretty wise, yes. If i do that, how would i make it check the woodbox varible before it allows the verb? Seriously, if you don't know how to do that, go read the DM Guide... you can't use a simple 'if()' check to check a var? ...If you do, then you should probably benefit more from switch() in this case. :P And if i do make a parent Get verb, is there a way to keep usrs from "Get"-ting obj's i don't want them to get? (i.e. i don't want them to be able to pick up the woodbox itself, just the wood inside) Since you're overriding the parent Get verb with a child for the woodbox, as long as you don't call '..()' there, the parent verb won't execute. I know i'm just starting to learn, Yes. If you can't simply check a variable, go read guides and tutorials and begin from scratch. Or can you? but i'm trying to keep things as clean as possible so that when i do run into problem (like this) it would be easy for someone more skilled than i to help me find my errors You know, it's a TINY bit easier to find your errors if you post your code. Just a thought. It also doesn't make you look like a Help Vampire which only wants code he can copy and paste. |
In response to Kaioken
|
|
=/ i'm not looking for code, i'm looking for explainations, and if someone can, a point in the right direction.
i was offered a snippet, i took it to learn from it. I'm not some uber fanboi out to impress people with my non-existant mad skillz by taking someone else's work, changing the icons, and then passing it off as my own. as far as the GM guide goes, it's great referance if you are familar w/ coding already. however, it's crappy for laymen use. There isn't much why to it. The tutorials are better, especially Z's, but they don't expand much on anything and only give a few examples. I'm trying hard to learn, but i don't have the benifit of an in-house expert to lean over my shoulder and tell me that I forgot to specify a obj path properly or that i'm using my if statement wrong. I know there ar code-vampires out there, and you've probably dealt with many before, but rest assured that i am not one, so the sarcasm is unnecessary. |
In response to Cuddlebear
|
|
I know you aren't, we already know each other. :P
Was just saying that you look like one, posting with no code and all. Didn't my previous post offer enough info, or do you have another question? Why don'tcha have a go at it and post what you came up with? |
In response to Kaioken
|
|
i came up with this:
obj/hearth_stuff/woodbox Is there any way to make this cleaner or less bulky? |
In response to Cuddlebear
|
|
Just going to point out one or two things
< else if(wood_supply <= 0) icon_state = "woodbox_empty" You should have it ==0 since the box can't hold less than 0... illogical not that it makes much difference... < take_log() set src in view(1) wood_supply -- I see a bug here... -- without even checking if there's enough to take out? If you take out 1... and there's 0 left before... you end up with -1... fix it Hopefully in obj/hearth_stuff/woodbox icon_state = "woodbox_full" You defined an icon file in obj or hearth_stuff from which the icon_states all came from... Is this box going to hold infinite wood? In games lke Black and White they had it... but a lot of games want a limit... if you want to impliment one... you should do it on the add_log proc |
In response to Spiderdude
|
|
mob/icon='blah.dmi' That's what I used... the icon state changed the way it was supposed to... remember to use my words from above... I didn't edit your coding much at all |
In response to Cuddlebear
|
|
I thought that was slightly harsh, Kaioken. (Plus, Cuddlebear is female, so use of the masculine pronoun is possibly not nice)
Anyway, Cuddlebear, the general way you'd set this up depends on how you've got your get verb set up. Essentially, something like this: obj Hope that helps. |
In response to Jp
|
|
so then a put verb to add wood the the pile would look like this??
verb/put i'm gonna go try it out now. I appriciate the guidance. The proc did what i wanted to happen, but couldn't figure out how; it condensed the code down to less lines! |
In response to Jp
|
|
I'm running into runtime trouble for my get verb now that i've made a parent verb for all objects. now usrs can pick up all the objects, including the fireplace, the chimney, and the windows O.o. outside of going into each object anf making it its own version of the verb (what i wanted to avoid) what else would fix this?
Would having a variable that decided if something could be picked up or not fix this, or just make it as messy as before? |
In response to Cuddlebear
|
|
What are the runtime errors? I might have made a stupid mistake myself - and of course, I don't know exactly what you're doing.
There are a few ways you could go about making un-pick-uppable items: 1 - Inherit all pick-uppable items from a '/obj/gettable' type, and define get() for /obj/gettable. This is probably the best solution. You could then define a seperate get() verb for the woodpile, because you override it completely anyway. 2 - Inherit all un-pick-uppable items from a '/obj/stationary' type, and redefine /obj/stationary.get() so that it doesn't work. Probably nonoptimal, because all non-gettable items will then have a useless get() verb. Plus, it's not good design. You should try to define objects around having things, not making having x the default and redefining types that don't need it to not having x, if you understand me there. 3 - Define a 'gettable' variable under /obj, and check it in the default get() proc. It's fairly elegant, but it still runs into the problems of 2. As for your put() verb: verb/put That's not quite right. I'll run through why: verb/put() //You forgot the brackets, but that's a minor syntax error that you probably could have caught on your own So, looking though it, it looks like you need some way of getting an object of a particular type out of a mob's inventory (In this case, it'll be usr, because it's a verb, but usr is inappropriate in most procs, so be careful with it). Looking through the reference, the locate() procedure seems to be able to do that. The syntax is this: locate(typepath) in something And it returns an object of type 'typepath' within 'something'. If there is no such object, it returns null. So, the revised verb looks like this: verb/put() Tada! Simple. I'm not sure if you know this already, but hitting 'F1' in DreamMaker brings up a lovely little reference where you can check the syntax of various inbuilt procedures (like locate()) and what they do. As for not understanding the code I suggested, it's a matter of reading it through - it's like learning any language, except DM (And most programming languages) have the fortunate benefit that they follow a strict grammar and don't have idioms. Basically, it just takes time. Read through it a few times. Look at what each line is doing, try to come up with why it's doing it. A lot of it involves shorthand, too - there are a few statements, like variable++ or if(variable) that are simple shortcuts to expressing long complicated things. Understanding those can be difficult. Probably the only reason it's shorter is that I didn't have the messages in there. Beyond that, there's really not much difference (Although yours had an interesting bug where you could drive quantity down to negative-as-low-as-you-wanted-to-go, because you subtracted before you checked whether it was legal). Really, just keep at it. It only takes time, and you've got an extremely good attitude - you're the kind I think of as a 'good newbie' - you're at least fairly intelligent, you can think for yourself, you try code before asking us a question, you don't expect to get an immediate answer that solves your every problem, and you don't copy code. I think you'll do fine. |
In response to Jp
|
|
Jp wrote:
I thought that was slightly harsh, Kaioken. Well, meh, I guess. Was probably on a bad mood (...worse than usual, anyway). (Plus, Cuddlebear is female, so use of the masculine pronoun is possibly not nice) _> I guess it may seem obvious, but you can never know for sure (unless you check up the (true) gender registered with the key) by just glancing at the keyname. > proc/get_icon_state() //Defines a get_icon_state() proc for all /obj/woodpiles IMO, naming it 'set_icon_state' is more appropriate, since it does set it, and 'get' implies it will only return the correct icon_state instead. Also, in get()'s, I'd use Move() rather than forcing the 'loc' var. Just better practice, even if it may not be useful for her now. There ARE movement system procs for all atoms, not only turfs, y'know. |
and then you would change the icon state accordingly.
if you did this after it increases or decreases you could do this without making a unneccesary loop proccess. I try to avoid loops as much as possible because my whacked out common sense tells me they generate lag.