mob/var/weapon = 0
obj
var
equiped = 0
weapons
var //Set defaults...
MinDamage = 1
MaxDamage = 1
TheDelay = 0 //Setting this to 0 will let the usr's delay be 4. If this var was 1, it would add 1 to the usr's attack delay and make him/her slower.
verb
pick_up()
set src in oview(1)
Move(usr)
usr << "You pick up the [src]."
destroy()
set src in usr
switch(alert("Do you really want to destroy this?","Destroy [src]:","Yes","No"))
if("Yes")
if(src.equiped == 1)
unequip()
sleep(2)
usr << "You discarded the [src]."
del(src)
equip()
set src in usr
if(usr.weapon == 0)
usr << "You equip the [src]."
usr.Min_Damage += MinDamage
usr.Max_Damage += MaxDamage
usr.Attack_Delay += TheDelay //If this is a positive number, it will make the mob slower... If it is 0, it will do nothing to the mob's attack delay... But if it is negative, it will make the mob attack faster. This is because (for those of you not very good at math) a positive + a negative is the same as a positive - a positive. Example: 4 + (-5) = -1; 8 - (-7) = 15.
suffix = "(Wielded)"
usr.weapon = 1
src.equiped = 1
else
usr << "You may only have one weapon equiped!"
unequip()
set src in usr
if(src.equiped == 1)
usr << "You unequip the [src]."
usr.Min_Damage -= MinDamage
usr.Max_Damage -= MaxDamage
usr.Attack_Delay -= TheDelay
suffix = null
usr.weapon = 0
src.equiped = 0
else
usr << "That's not equiped yet!"
drop()
if(src.equiped == 1)
unequip()
sleep(2)
src.loc = usr.loc
usr << "You drop the [src]."
Giant_Sword //The first weapon... Since we defined the verbs above, we will not need to define anything more.
icon = 'Weapons.dmi'
icon_state = "Giant Sword"
MinDamage = 5
MaxDamage = 12
TheDelay = -2 //Setting this to -1 makes it so it will subtract making the player's attack delay less, which makes him/her faster.
Dagger
icon = 'Weapons.dmi'
icon_state = "Dagger"
MinDamage = 3
MaxDamage = 6
TheDelay = -1
mob/var/armor = 0
obj
armor
var //Set defaults...
Defense = 1
verb
pick_up()
set src in oview(1)
Move(usr)
usr << "You pick up the [src]."
destroy()
set src in usr
switch(alert("Do you really want to destroy this?","Destroy [src]:","Yes","No"))
if("Yes")
if(src.equiped == 1)
unequip()
sleep(2)
usr << "You discarded the [src]."
del(src)
equip()
set src in usr
if(usr.armor == 0)
usr << "You equip the [src]."
usr.Defense += Defense
suffix = "(Wielded)"
usr.armor = 1
src.equiped = 1
else
usr << "You may only have one armor equiped!"
unequip()
set src in usr
if(src.equiped == 1)
usr << "You unequip the [src]."
usr.Defense -= Defense
suffix = null
usr.armor = 0
src.equiped = 0
else
usr << "That's not equiped yet!"
drop()
if(src.equiped == 1)
unequip()
sleep(2)
src.loc = usr.loc
usr << "You drop the [src]."
Tunic icon = 'armor.dmi'
icon_state = "Tunic"
Defense = 2
ID:148171
 Jun 10 2003, 4:36 pm
|
|
okay i need some help, the problem is that you can equipe as many armors as you want, i want it to only be one, just lke my weapon code.here are the two codes:
| |
i got it from RPG tutorial 2( thats where ive learned alot of my codeing)
http://developer.byond.com/hub/Kunark/RPGTutorial2 | |
You would probably want to include a variable for this that sees if the user is already wearing something. Something like...
mob var wearing = 0 then in the code incorperate the following... if(usr.visi == 0) usr.visi +=1 //blah blah blah, let the user wear the armor, basically continue on with the code. Then... else return // basically, this sees if the user is wearing anything, if he/she/it is, then the user cant wear armor, if not then go about letting him/her/it wear the armor. Sorry if I have been a little brief, and my comments arent that good. I am in a rush so please forgive me if i made a mistake. I must admit I didnt read your entire code, but I hope this is of some help. | |
First, my tutorial works just fine it is the newbies that slaughter it up (except for alot of spelling errors, when you type that much in a day your bound to get alot and not know of them.).
Second, it doesn't need to be perfect. I based my equipping system around using a true/false only system, not a text system, because in alot of RPGs like that is based on, text isn't needed. In other words, it isn't a "flaw", it is just a different way of coding it in an envirement that doesn't need the other way, it is only a few people that need it the other way. Besides, once a newbie is able to fully understand number 2, they should be able to transfer it into a text equipping system if they need to. I will make changes to it to show a weapon "name"/reference system, but I am ashamed that anyone will say they are ashamed of me for having an extremely small flaw in the code when the code that was released is the basic support system of probably most of the newbies, and yet I hardly get credit for it. | |
Kunark wrote:
Second, it doesn't need to be perfect. I based my equipping system around using a true/false only system, not a text system, because in alot of RPGs like that is based on, text isn't needed. In other words, it isn't a "flaw", it is just a different way of coding it in an envirement that doesn't need the other way, it is only a few people that need it the other way. Besides, once a newbie is able to fully understand number 2, they should be able to transfer it into a text equipping system if they need to. Text? Noo-no-no-no-no. The key word here, m'good man, is reference. Is it better to know whether you have a weapon equipped, or which weapon it is? Obviously the latter--especially because it answers the first question as well (null being a "no"). If you only know you have a weapon equipped, but you don't know which one, then you have to loop through every weapon in your inventory to find it. Text has absolutely nothing to do with it. I have no idea where you're coming from there. Unless you mean something like setting a var to "long sword" and then looping through to find something with a matching name, which is even more bogus than what you're doing now. Essentially your system works by basing itself entirely on the one other thing it's useful to know: whether any given weapon is equipped. Yet for obvious reasons this is a lot less useful than the player knowing which weapon (or armor, etc.) they have. It is clearly not merely a few people who would use such functionality; that one piece of information is many times more useful than the weapon knowing directly whether it's equipped. And whether a weapon is equipped can be derived very very easily--and without looping through anything--by checking to see if 1) the weapon's loc is a mob, and 2) if loc:weapon matches src. (Competent code will do type casting of course, to avoid the : usage.) So practically speaking, your boolean yes/no system is written entirely backwards, requiring loops to handle the most common function (finding out which weapon if any is equipped) while using individual object vars to handle a lesser piece of information, and taking up more memory in the process. You've used too many vars to store too little information each, and when more complex information is needed (for a relatively common task at that), you have to go the long way around. This is hardly the kind of simplicity you seem to have sought; if anything you've made a simple problem more complex. Worse however is that this backwards design is not robust, nor especially stable. Quite simple bugs related to saving, loading, spawning new objects, dropping objects, etc. can lead to errors that are difficult to fix. It is not uncommon in games designed around this system to end up with two weapons that are marked as "equipped"--or worse, they're not just marked that way, but both still think they are equipped. It's more common than you'd think, and it doesn't lend itself to self-correction like a more savvy approach; by merely using a single var that will hold a reference to the weapon, you'll find that in erroneous circumstances it will tend to revert to null, or in a worst-case scenario will point to a weapon you don't even have--in which case you can correct for it quite easily. (if(weapon && weapon.loc!=src) weapon=null) When you create a var, it should hold as much information as possible. Never ever use a boolean in one place when a reference in another place would serve you better--a reference provides much more information. Never force the use of a number where text might be required. And so it goes. If your vars are not concise in their purpose, then your program may have to go to ridiculous lengths to connect the dots. The concept of conciseness is key and cannot be overstated. The goal you should be seeking is to include the maximum amount of useful information in the least number of vars spread over the fewest objects. It serves two purposes: First, it makes related information (like if a weapon is in use) easy to look up. Second, it means there are fewer things that can go wrong. The more vars you juggle, the more errors you're likely to have. The less information in each, the more work you have to put into getting any use out of them. Is it more useful to know someone's name and look up their phone number, or their phone number and look up their name? Knowing the name is easier for a lot of reasons: The phone book is keyed that way (a big advantage), you can compensate for misspellings by looking up similar names (while doing that with numbers is nigh impossible), and the name tends to be keyed to a lot of other information that's also handy. This isn't strictly analogous to an equipment demo, but basically you've got a large pool of objects that you've got to check for a yes/no, when really it should be easy to just say "that one" and have done with it. Moreover, you don't end up with a case of two or more objects ambiguously vying to be the one if anything goes wrong. If for no other reason, the tutorial must be changed so that newbies will experience fewer bugs. But as an added plus, doing it the right way would actually teach them something valuable about design and program logic. Doing it the wrong way has taught them how to make buggy code that fails in unpredictable and exotic ways, as many have already demonstrated admirably. Lummox JR | |
I understood about the variables already, I just didn't see many ways it could be all that useful to do that... When you first said that, I first thought about a "text" system which would save the name as the weapon var, and from my experience, is a harder, but more useful system than var, but after a minute I realized a reference system would be the way to go and edited reference into my post. I haven't touched an RPG battle system for a long long long time.
| |
Ok yo getting back to the point this kid needs help. Wither the system sucks or not is not our choice to make we are just here to help with wut he needs. Anyway just make a new variable like weapon and armor and then in your equip proc make src.weapon = 1 also make sure it is in your unequip proc as well because otherwise you will have people equiping it then unequping and it still saying that its on. Also put in if(usr.weapon = 1)
USR THIS IS ALREADY EQUIPED. if try and helpo you a lil more but im at my cousins for them weekend and this is a french keyboard. anwya have a good on Cloud54367 | |
Cloud54367 wrote:
Ok yo getting back to the point this kid needs help. Wither the system sucks or not is not our choice to make we are just here to help with wut he needs. I'm sorry, but I must have missed the orientation lecture that told me this was my job description. When do we get paid, again? Whether a system is sucky or not is extremely relevant to how and how well we can help somebody. Lummox JR | |
Its on thing if you mention that with the souloution but he asks how to make it so he can only have one equiped and you lecture him on how his armor system blows. You should at leats fix the problem as well.
| |
Cloud54367 wrote:
Its on thing if you mention that with the souloution but he asks how to make it so he can only have one equiped and you lecture him on how his armor system blows. You should at leats fix the problem as well. Actually I was lecturing Kunark on how his armor system blew. But quite clearly if you switch to a more correct reference-based implementation, only equipping one piece of armor is not only easy, but easier than modifying the system to handle more. So my discussion contained the solution in itself. Lummox JR | |
The design flaw is this: the usr.weapon var should not just be a yes/no value, nor should there even be a need for a src.equiped var--even if it's spelled correctly. It's more important to know which weapon a mob is wielding than just whether they have one.
Lummox JR