using properties for player features

shandlia

05 Oct 2006 23:03

I have been attempting to use properties for the player's features such as race and gender. However when I test it the properties aren't there when I log back in. Is there another command I need to add so that it will save the properties given to the player on creation?

darkgoddessnight

05 Oct 2006 23:51

I am actually having the same problem and would love to know the answer too.

GameBoy

06 Oct 2006 04:22

you should read the documentation on properties, it will give you a basic example on how to script them in ASL, and how to interact with them in-game.

Elexxorine

06 Oct 2006 13:56

The major problem with the built-in system is that all the properties and variables are asigned to the userid which is taken over by some-one else when you log out... now this is what you should do: make a special room, within have objects which are named after the username and set all their properties to those objects so they are stored to their name, not their over-rideable number...

shandlia

06 Oct 2006 16:37

okay, attempting to create an object to give the properties to and using that to be able to save the last location of the player. This script works for the first player in but not for the second player in. Any ideas why?

' "Demo"
' Created with QDK 3.53 - UNREGISTERED VERSION

!include <net.lib>

define game <Demo>
asl-version <350>
gametype multiplayer
start <start>
game info <Created with QDK 3.53 - UNREGISTERED EVALUATION VERSION.>
player startscript for each object in <$name(%userid%)$> move <#quest.thing#;player%userid%>
disconnect {
for each object in <player%userid%> move <#quest.thing#; $name(%userid%)$>
set string <lastroom; #quest.currentroom[userid]#>
}

define options
login on
register on
end define

define synonyms
end define

define room <start>
script if got <self> then goto <#lastroom#> else goto <creation>
end define

define room <2>
north <3>
end define

define room <3>
north <4>
south <2>
end define

define room <4>
south <3>
end define

define room <creation>
command <create self> {
clone <body; self; creation>
property <self; race=race>
conceal <self>
give <self>
goto <2>
}

define object <body>
invisible
end define

end define

define text <intro>

end define

define text <win>

end define

define text <lose>

end define

I'm guessing it has something to do with quest.currentroom[userid] but have no idea what it should be instead. quest.currentroom[player%userid%] maybe?

Elexxorine

06 Oct 2006 20:10

No just userid is correct.... as it's the indox of the built-in string.

Your start script says: for each object in <$name(%userid%)$> move <#quest.thing#;player%userid%>
Firstly: <#name[userid]#> not <$name(%userid%)$>, it's a string not a function and indexs don't need %'s and are done with square brackets, these should be just to the right of the 'p' key...
Secondly: <#quest.thing#;player%userid%> should be <#quest.thing#; #player[userid]#>
Thirdly: the code itself doesn't actually make sesne, tranlated it goes: 'When the player joins, look for each object in the '#name[userid]#' room and move them to the player's inventory. At start up they will have no 'name' string and this code will give an error.... remove it to the log in script....

I think Im Dead

13 Oct 2006 04:08

$name(userid)$ and $name(%userid%)$ should both work fine to return the name the player input upon login, or atleast they have in previous versions.

It's basically reiterating what Elexxorine has said, but try coding what you are going for in these steps, and it should fall together perfectly.

1) player startscript, if exists <$name(%userid%)$> then for each object in <$name(%userid%)$> move to <player%userid%>, else create room <$name(%userid%)$>, then add properties to that room.

(The problem here is quest won't save properties for rooms generated dynamically, so in actuallity it helps to make seperate objects in the room with a similar naming scheme for subsets of character's properties, like $name(%userid%)$-Info, $name(%userid%)$-Stats, or whatever.)

2) disconnect, for each object in <player%userid%> move to <$name(%userid%)$> then disconnect.

And with that you've got a maintainable no frills player recognition and persistent inventory/properties system.

Of course you don't have to bother even having the disconnect or startup if you were to bypass the built in player inventory and log in systems all together but that's a tidbit for another subject.

This topic is now closed. Topics are closed after 60 days of inactivity.

using properties for player features

Connect

Products

Resources

Support