ID:146934
 
this is the code i am trying to use..it is my weapon equip and un equip..

        verb/get()//global verb for all object under the /obj/weapons
set src in oview(1)
set category = null
src.Move(usr)//You picked it up
verb/equip()
set src in usr
set category = null
if(!usr.equiped)
usr.Attack+=src.attackadd//The power of the the weapon is now with you
src.verbs+=/obj/weapons/proc/unequip//Now you can unequip the weapon
src.verbs-=/obj/weapons/verb/equip//No longer have the equip verb
src.suffix+="Equiped"//Shows it as equiped
usr.equiped = 1
else
usr << "You already have something equiped!"
proc/unequip()
set src in usr
if(!usr.equiped)//Extra precautions
usr << "You don't have anything equiped!"
else
usr.Attack-=src.attackadd//You can no longer use the power of the weapon
src.verbs-=/obj/weapons/proc/unequip
src.verbs+=/obj/weapons/verb/equip
src.suffix = ""//No longer shows it as equiped
usr.equiped = 0



whan a person saves the game and logs out and logs back in, the weapon they have equiped shows as equiped, but it won't let you un-equip it.

is it in my equip/unequip? or could it be my save?
mob
usr
icon = 'character.dmi'

mob
Login()

alert("the game is still being made. do not ask for gm, or how to play.. clicking OK means Psychotic OwNs you.!")
world << "<b>[src]</b> has logged in."
src.loc = locate(3,3,1)
icon_state = gender
..()
switch(input("What do you want to do?")in list("Make new character", "Continue with old character", "Quit"))
if("Quit")
del(usr)
if("Make new character")
switch(input("Are you sure? If you have an old character, it will be erased.")in list("Yes", "No"))
if("No")
return ..()
if("Yes")
var/savefile/F = new(key)
Write(F)
if("Continue with old character")
switch(input("If you haven't already played on this server you will need to go back and create a new character. ?")in list("Yes", "No"))
if("Yes")
var/savefile/F = new(ckey)
Read(F)
if("No")
return ..()
There are three main problems here, with a few minor ones riding their coattails.

The first, and most severe, is design. An equipment system should never ever give the items a var that's just 1 for equipped, 0 for unequipped. The reason that's wrong is that it's infinitely more useful to know which item if any is equipped than to know if a particular one is supposed to be. Make a var like mob/var/obj/weapons/weapon, and that will be null by default (no weapon) or set to the weapon itself.

The second problem is that your code isn't correct for the design. You have a var called usr.equiped, for which its spelling is the least of its problems. If this was supposed to be just a yes/no var like it's being used as, then the var should belong to the item, not the mob. (However, I strenuously repeat that you should not make this change. Make the change from the previous paragraph. Here I'm only explaining a reason why the current method is failing; you're implementing the incorrect design with incorrect code. Fix the design and this problem is moot.)

The third problem is that verbs added to mob.verbs don't save. You need to re-add the verbs when the character is finished loading. (The simplest approach is to create an obj proc called AddVerbs() that will add verbs as needed when the character loads, depending on the status of the item. So you could call this for each item in inventory, and it might for example add an unequip verb if the item is in use.)

Additionally, there are a couple of bogus bits to fix:
mob
usr

usr is a var. You really really don't want a type path called /mob/usr. Really. Get rid of that usr line.

return ..()

The only problem with that line (which appears twice) in Login() is that ..() was already called. You should under no circumstances call ..() twice in Login(), and almost never in any other proc either. ..() is really only meant to be called once, since it basically says "Do what this proc does by default." Unless you want the regular Login() called twice, this is bad.

Lummox JR
In response to Lummox JR
you prolly already know it, but yea im a newbie. but thats not to say i dont understand what you are saying. my problem is i don't understand how to fix the problems you pointed out to me.

im thinking i am using a completely wrong weapon system than what i need.

what i am wanting is, when a player logs in, their character has no weapons(of course). when they equip a weapon, an icon overlay would appear over the character for a sword(but not THE sword icon they have.). when they equip a sheild, same thing. i have sword/sheild icons that will show when the sword/sheild is laying on the ground and in a persons item list. and a different icon that a person will see on the character when it is equiped on the character. get what i mean?

the weapon system i am using is Nadrew's weapon system.

in your opinion, what would be a better system for doing so?

for me to have used..
mob
usr

..it is because it is what i've seen people use in their demo's, and like most newblets...it is what i copied from the demo's.

my save should only have 1
return..()

then? wouldnt that affect the other popup questions that appear befor making a character?

and do i just delete the ..()? or delete the whole return..()?
In response to Psychotic
Psychotic wrote:
for me to have used..
> mob
> usr
>

..it is because it is what i've seen people use in their demo's, and like most newblets...it is what i copied from the demo's.

If that's in a demo, we need to hunt down the author and smack them. That snippet isn't the least bit viable, and anyone who'd write it has no business writing demos. (Of course, you may have noticed a lot of the demos fall into that category.)

my save should only have 1
return..()
then? wouldnt that affect the other popup questions that appear befor making a character?

No, because ..() itself was called the first time; each place it appears in "return ..()" it's wrong.

and do i just delete the ..()? or delete the whole return..()?

Just remove the ..() part from "return ..()". Returning from the proc is the intended behavior (apparently), but it shouldn't be calling ..() all over again because that was already called.

Lummox JR
In response to Lummox JR
ok. so my save problems that i didnt see that you have pointed out were fixed.

how about this one?

The first, and most severe, is design. An equipment system should never ever give the items a var that's just 1 for equipped, 0 for unequipped. The reason that's wrong is that it's infinitely more useful to know which item if any is equipped than to know if a particular one is supposed to be. Make a var like mob/var/obj/weapons/weapon, and that will be null by default (no weapon) or set to the weapon itself.

Lummox JR<

how and where do i modify that into the code?

In response to Psychotic
Psychotic wrote:
Make a var like mob/var/obj/weapons/weapon, and that will be null by default (no weapon) or set to the weapon itself.

how and where do i modify that into the code?

Exactly as you were instructed.

Lummox JR
In response to Lummox JR
ok, i got that in..not exactly sure if i put it in right though. o_o; i just slaped it into the dm file as wrote. i don't really see change in how its playing. but im guessing i wouldnt at this point anyways.

let me put that onto the back burner for a moment to give a brief catchup on my saving/loading thing.

as it was, the origional save/load had a few problems i didnt notice till a while ago. so i went looking around and found this one..

mob
Login()
usr.loc = locate(8,7,2) // change to your title screen
..()

mob
proc
//----------------------------------//
CreateChar(mob/M) // The char creation function -- Change with whatever you want for
// creating a character.
//----------------------------------//

usr.icon = 'character.dmi' // define the characters icon
icon_state = gender

//----------------------//
usr << "Char gen done!" // this is just a debug message to show that this proc
// is being called.
//----------------------//

usr.loc = locate(3,3,1) // spawn the character to 1,1 on map #1
usr.sight = 0 // make it so the character can see
usr.SaveChar() // Auto-Save the new char for just in case game crashes.
..()

SaveChar() // The proc that saves your character.
var/savefile/F = new("players/[src.ckey].sav") // define the save file and create it
F["name"] << name // Outputs the characters name into the savefile list
F["X"] << src.x // Outputs the char's X coordinate into the list
F["Y"] << src.y // Outputs the char's Y coordinate into the list
F["Z"] << src.z // Outputs the char's Z coordinate into the list
F["Mob"] << usr.client.mob // Outputs ALL of the character (var's, etc) into the list

verb
Save()
usr.SaveChar() // Make a call to the character's saving proc
usr << "Your character has been saved." // Inform the player that he's been saved.

turf/CharHand
icon = 'A Heros Tale.bmp'
density = 1

turf/nomove
density = 1

turf/NewChar
icon = 'new.bmp' // change this to the bmp of your "New Character" button
Click()
usr.sight = 1 // Blackscreen them so they can't choose another choice
if (fexists("players/[usr.ckey].sav")) // Check if they have a save file
switch(alert("If you continue with a new character, your previous character will be erased. Do you wish to continue?","[world.name]","Yes","No"))
if ("Yes")
usr << "... Ok... Beginning character process now."
usr.CreateChar()
return ..()
if ("No")
usr << "Ok, Please reconnect for you are being disconnected now and then choose \"LOAD GAME\""
del(usr)
return ..()
else
usr.CreateChar() // No savefile found, create a new character
return ..()
..()

mob
proc
LoadCharacter() // The load character proc
var/savefile/F = new("players/[src.ckey].sav") // define the location of the save file
var/X // Defines a temporary X variable
var/Y // Defines a temporary Y variable
var/Z // Defines a temporary Z variable
var/mob/newmob = new() // Initialize a new mob
F["name"] >> name // Load the name from the list into the character's name
F["X"] >> X // Load the X variable from the savefile to the temporary X variable
F["Y"] >> Y // Load the Y variable from the savefile to the temporary Y variable
F["Z"] >> Z // Load the Z variable from the savefile to the temporary Z variable
F["Mob"] >> newmob // Load all the mob data into the initialized mob
newmob.loc = locate(X,Y,Z) // Move the initialized mob to the last saved location
newmob.client = src.client // Set the mob's client to players client

turf/LoadChar
icon = 'load.bmp' // change the bmp to the bmp to your "Load Character" image
Click()
if(fexists("players/[usr.ckey].sav")) // check to see if the character has a savefile
usr.LoadCharacter() // Make a call to load the character

//----------------------------------//
world << "\[[world.name]]--> [usr.name] has logged in!" // Announce to the world
// that the user logged in
//----------------------------------//

usr << "Welcome back to the game!" // Welcome the player
return ..()
else
alert("You don't HAVE an old character here, or it isn't found in our databases!")
// Uh oh! No player file found when they clicked Load!
return ..()
..()


i see this as more usefull because it just gives new and load.

it works almost perfectly, but it is giving a runtime error.

runtime error: Cannot read null.name
proc name: Click (/turf/LoadChar/Click)
usr: null
src: LoadChar (7,10,2) (/turf/LoadChar)
call stack:
LoadChar (7,10,2) (/turf/LoadChar): Click(LoadChar (7,10,2) (/turf/LoadChar))

the save/load code somes from Griswald's character handling demo. i've edited things where i needed to, but changed nothing more. only things i had to edit were the locations and dmi file names. only other thing i added was the icon_state = gender

when the person clicks load, it loads the character, but doesnt put them at the place where either they last saved or at the default starting location for a character(3,3,1)
In response to Psychotic
Don't use usr in procs.
In response to N1ghtW1ng
N1ghtW1ng wrote:
Don't use usr in procs.

And why not:
Click me!
In response to N1ghtW1ng
N1ghtW1ng wrote:
Don't use usr in procs.

bbbllllaaaahhhh :P

its out of therrrre..

but its not fixed. im still having the problem of it moving my character from the start new character/load old character screen.
In response to Lenox
usr is usually wrong in:
Most procs


Thinking verbs?
In response to Hell Ramen
befor,. the codes wern't letting the load/start screen show. i went into my admin dm file and deleted a line. the line i deleted i don't remember, but it let my login screen show up.

it's only problem is that after the player selects "load" it gives the error message, creates a player icon, but doesnt transport the player's character to the starting location of the world map, location 3,3,1.

In response to Psychotic
Psychotic wrote:
befor,. the codes wern't letting the load/start screen show. i went into my admin dm file and deleted a line. the line i deleted i don't remember, but it let my login screen show up.

it's only problem is that after the player selects "load" it gives the error message, creates a player icon, but doesnt transport the player's character to the starting location of the world map, location 3,3,1.

You need to post the changes you made to this segment of code if you want further help with it.

Lummox JR
In response to Hell Ramen
Usr is fine in verbs. It's just that if it's in a proc, then you don't know who it is, because you don't know who or what is ultimately calling the proc. Verbs have to be called by a character (although you can use them as procs), so as long as you don't call them like a proc, usr is fine in them.

...

That was confused.
In response to Lummox JR
mob
Login()
usr.loc = locate(8,7,2) // change to your title screen
..()

mob
proc
//----------------------------------//
CreateChar(mob/M) // The char creation function -- Change with whatever you want for
// creating a character.
//----------------------------------//

usr.icon = 'character.dmi' // define the characters icon
icon_state = gender

//----------------------//
usr << "Char gen done!" // this is just a debug message to show that this proc
// is being called.
//----------------------//

usr.loc = locate(3,3,1) // spawn the character to 1,1 on map #1
usr.sight = 0 // make it so the character can see
usr.SaveChar() // Auto-Save the new char for just in case game crashes.
..()

SaveChar() // The proc that saves your character.
var/savefile/F = new("players/[src.ckey].sav") // define the save file and create it
F["name"] << name // Outputs the characters name into the savefile list
F["X"] << src.x // Outputs the char's X coordinate into the list
F["Y"] << src.y // Outputs the char's Y coordinate into the list
F["Z"] << src.z // Outputs the char's Z coordinate into the list
F["Mob"] << usr.client.mob // Outputs ALL of the character (var's, etc) into the list

verb
Save()
usr.SaveChar() // Make a call to the character's saving proc
usr << "Your character has been saved." // Inform the player that he's been saved.

turf/CharHand
icon = 'A Heros Tale.bmp'
density = 1

turf/nomove
density = 1

turf/NewChar
icon = 'new.bmp' // change this to the bmp of your "New Character" button
Click()
usr.sight = 1 // Blackscreen them so they can't choose another choice
if (fexists("players/[usr.ckey].sav")) // Check if they have a save file
switch(alert("If you continue with a new character, your previous character will be erased. Do you wish to continue?","[world.name]","Yes","No"))
if ("Yes")
usr << "... Ok... Beginning character process now."
usr.CreateChar()
return ..()
if ("No")
usr << "Ok, Please reconnect for you are being disconnected now and then choose \"LOAD GAME\""
del(usr)
return ..()
else
usr.CreateChar() // No savefile found, create a new character
return ..()
..()

mob
proc
LoadCharacter() // The load character proc
var/savefile/F = new("players/[src.ckey].sav") // define the location of the save file
var/X // Defines a temporary X variable
var/Y // Defines a temporary Y variable
var/Z // Defines a temporary Z variable
var/mob/newmob = new() // Initialize a new mob
F["name"] >> name // Load the name from the list into the character's name
F["X"] >> X // Load the X variable from the savefile to the temporary X variable
F["Y"] >> Y // Load the Y variable from the savefile to the temporary Y variable
F["Z"] >> Z // Load the Z variable from the savefile to the temporary Z variable
F["Mob"] >> newmob // Load all the mob data into the initialized mob
newmob.loc = locate(X,Y,Z) // Move the initialized mob to the last saved location
newmob.client = src.client // Set the mob's client to players client

turf/LoadChar
icon = 'load.bmp' // change the bmp to the bmp to your "Load Character" image
Click()
if(fexists("players/[usr.ckey].sav")) // check to see if the character has a savefile
usr.LoadCharacter() // Make a call to load the character

//----------------------------------//
world << "\[[world.name]]--> [usr.name] has logged in!" // Announce to the world
// that the user logged in
//----------------------------------//

usr << "Welcome back to the game!" // Welcome the player
return ..()
else
alert("You don't HAVE an old character here, or it isn't found in our databases!")
// Uh oh! No player file found when they clicked Load!
return ..()
..()


that is the entire login code for both new character and load character.

the problem is loading a character, as stated befor.

In response to Psychotic
You've got usr abuse running amuck in your procs. Why that's still the case, since N1ghtW1ng already advised you to fix it, remains a mystery. Take usr completely out of CreateChar() and SaveChar() where it doesn't belong, and replace it with src which is correct for those procs. Do the same in Login(), where usr is only semi-reliable but src is always consistent.

In loading, there are a few steps you can eliminate. Loading the name is useless; that's loaded with the mob, and loading src.name won't help you since src.name isn't used from that point on. Initializing newmob is also useless; it will be created from the file. You should also take out the newmob.client=src.client line; that change happens the instant the new mob is loaded because of the key var. And that automatic mob switch is what's indirectly causing some of your troubles, as I'll explain below.

In turf/LoadChar/Click(), you've got a more subtle form of usr abuse. Normally usr is just dandy in Click(), since it can be treated more or less as a verb. However, once you load a new character, assumptions about usr go out the window. After LoadCharacter() has been called, a new mob is now in control. If mob/Logout() is deleting the old mob, as I suspect has happened here, that explains not only your runtime error, but also the failure to transport the character to the correct coordinates. Since usr is still the old mob, if mob/Logout() deleted it, usr is now null. Back in that Click() proc, you need to know the new mob--or at least the who the client was prior to LoadCharacter() being called--and use that new mob instead of usr after the character loads.

As to the character not moving to the correct coordinates, here's the deal: mob/Logout() is apparently deleting the old mob. That's not a bad thing, but it has one side effect: It kills all that mob's active procs, including LoadCharacter(). As soon as you load the new mob, since the player's key saved along with it, the client is automatically connected to that mob. In the process of this automatic switch, mob/Logout() is called for the old mob--and hence that mob is deleted in this case--and mob/Login() for the new one. Once the old mob is deleted, LoadCharacter() ends abruptly and does not run the newmob.loc=locate(X,Y,Z) line. The way to fix this is to make LoadCharacter() a client proc, not a mob proc, and to make the appropriate adjustments.

There's a lot to go over here, but first and foremost you should fix the usr abuse. The other problems that led to this error are nothing compared to that, since these you could at least spot. Abusing usr leads to lots of errors that you can't spot, so fix it while you can. Then change LoadCharacter() to a client proc, and make the necessary changes to it and other procs.

Lummox JR
In response to Lummox JR
Lummox JR wrote:
You've got usr abuse running amuck in your procs. Why that's still the case, since N1ghtW1ng already advised you to fix it, remains a mystery. Take usr completely out of CreateChar() and SaveChar() where it doesn't belong, and replace it with src which is correct for those procs. Do the same in Login(), where usr is only semi-reliable but src is always consistent.

There's a lot to go over here, but first and foremost you should fix the usr abuse. The other problems that led to this error are nothing compared to that, since these you could at least spot. Abusing usr leads to lots of errors that you can't spot, so fix it while you can. Then change LoadCharacter() to a client proc, and make the necessary changes to it and other procs.

Lummox JR

once again...>WHERE< do i edit usr into src? do i change all usr to src? a certain few?
once again...while i understand how a code works, and what certain parts to edit to to change its affects, i dont know how to change all of the code. i understand what you say about usr and src, but i have yet to have been given an example as to how they work differently...its like...while i don't know much about HTML's, i can edit the small parts that change the things you see, not what you don't. for instance, an IFrame.. i know how to change its hight, width, the page viewed through it...but that is all. nothing else...i hope you understand what im trying to say.
In response to Psychotic
Psychotic wrote:
Lummox JR wrote:
You've got usr abuse running amuck in your procs. Why that's still the case, since N1ghtW1ng already advised you to fix it, remains a mystery. Take usr completely out of CreateChar() and SaveChar() where it doesn't belong, and replace it with src which is correct for those procs. Do the same in Login(), where usr is only semi-reliable but src is always consistent.

once again...>WHERE< do i edit usr into src? do i change all usr to src? a certain few?

Take usr completely out of CreateChar() and SaveChar() where it doesn't belong, and replace it with src which is correct for those procs.
That couldn't possibly be any clearer. It did not say to change just one instance of usr in those procs, nor did it even hint at such a thing. It said to change all of those instances, in those procs, to src.

once again...while i understand how a code works, and what certain parts to edit to to change its affects, i dont know how to change all of the code. i understand what you say about usr and src, but i have yet to have been given an example as to how they work differently...its like...while i don't know much about HTML's, i can edit the small parts that change the things you see, not what you don't. for instance, an IFrame.. i know how to change its hight, width, the page viewed through it...but that is all. nothing else...i hope you understand what im trying to say.

Then the first thing you need to do, before you make the changes in your code, is to read about the differences between src and usr. Those are explained in a handy article on BYONDscape: Dream Tutor: usr Unfriendly

Lummox JR
In response to Lummox JR
ok! there! >_< its out.

but im still having loading problems.

im getting the runtime error still.

runtime error: Cannot read null.name
proc name: Click (/turf/LoadChar/Click)
usr: null
src: LoadChar (6,7,2) (/turf/LoadChar)
call stack:
LoadChar (6,7,2) (/turf/LoadChar): Click(LoadChar (6,7,2) (/turf/LoadChar))
In response to Psychotic
Psychotic wrote:
ok! there! >_< its out.

but im still having loading problems.

im getting the runtime error still.

Well of course you are. After fixing the usr abuse issue, you had to go fix the other problems I pointed out in that other post. The next steps are already spelled out for you.

Lummox JR
Page: 1 2