Graal Forums

Graal Forums (https://forums.graalonline.com/forums/index.php)
-   Future Improvements (https://forums.graalonline.com/forums/forumdisplay.php?f=10)
-   -   Guild Object for Scripting (https://forums.graalonline.com/forums/showthread.php?t=66341)

jake13jake 05-31-2006 02:26 AM

Guild Object for Scripting
 
Let's face it, there is almost no point to being in a guild anymore. However, there does exist a database for guilds, so there can be many upsides for scripters being able to access that guild database.

I think what would be the best way to make guilds gain a meaning, would be to create a guild object for scripting. Such an object would be most useful if similar to the player object, and also, if the guild was removed, all of it's stats could be wiped as well without the server having to make their own cleaning routine.

An example for such usage:

player.guild.clientr.bank_funds=money
player.guild.client.uniform=body,colors,hat

Also, it could have pre-existing vars
player.guild.ranks[0] could list the leader of the guild
player.guild.ranks[1] could list everyone in the level below the guild
player.guild.ranks[0].name could return the name of the leader's rank.
And also other information given in the DB
player.guild.status
player.guild.members (list of all members of guild)
player.guild.members.size() (for number of members)
player.guild.est
player.guild.fullname
player.guild.email
player.guild.allies
player.guild.enemies
player.guild.charter
player.guild.website
player.guild.worlds
player.guild.activity
player.guild.rating

More questionably:
player.guild.timejoined (of a specific player)
player.guild.lastontag (of a specific player)

guilds array could list the active guilds in the level
allguilds array could list the active guilds on the server
player.guilds array could contain a list of guilds the player is in (and also give access to their flags).

ApothiX 05-31-2006 03:33 AM

As much as I hate your useless bloatty addition requests, this one isn't that bad. However I would have to ask for a few things differently.

player.guilds[] shouldn't exist, it would definitely bloat the hell out of the player object.

Perhaps a player.getActiveGuilds() function that returns an array of integers (IDs) of which the player is in, and can be accessed by using guilds[ID]

Also, of course, all of these variables would have to be read-only. Nothing should be modified in the guild database unless it is someone with the correct credentials to do so. I would feel a little uneasy if I logged on a server and some script was modifying my global guild.

One more thing: Guilds should not have clientside 'client.' variables. All variables added via script should be completely serverside. That would be a hell of a lot of information the server would have to send (and update) if all the guilds had clientside variables associated with them.

jake13jake 05-31-2006 03:56 AM

Quote:

Originally Posted by ApothiX
As much as I hate your useless bloatty addition requests, this one isn't that bad. However I would have to ask for a few things differently.

player.guilds[] shouldn't exist, it would definitely bloat the hell out of the player object.

Perhaps a player.getActiveGuilds() function that returns an array of integers (IDs) of which the player is in, and can be accessed by using guilds[ID]

Also, of course, all of these variables would have to be read-only. Nothing should be modified in the guild database unless it is someone with the correct credentials to do so. I would feel a little uneasy if I logged on a server and some script was modifying my global guild.

One more thing: Guilds should not have clientside 'client.' variables. All variables added via script should be completely serverside. That would be a hell of a lot of information the server would have to send (and update) if all the guilds had clientside variables associated with them.

Well, the player.guilds list idea is more so I could script deterrents to multi-guilding that don't restrict the player, but instead the guild. If guilds had advantages that could be inflicted by having multi-guilders, they'd probably discourage it more.

I guess it would make sense not to have client.vars, but clientr.vars would be important as well as regular flag vars, and of course all of the other vars you would want to be read-only (and readable both clientside/serverside).

ApothiX 05-31-2006 04:00 AM

Quote:

Originally Posted by jake13jake
Well, the player.guilds list idea is more so I could script deterrents to multi-guilding that don't restrict the player, but instead the guild. If guilds had advantages that could be inflicted by having multi-guilders, they'd probably discourage it more.

Could just as well be accomplished via: if(player.getActiveGuilds().size() > 1)

Quote:

Originally Posted by jake13jake
I guess it would make sense not to have client.vars, but clientr.vars would be important as well as regular flag vars, and of course all of the other vars you would want to be read-only (and readable both clientside/serverside).

clientr. variables wouldn't be so bad, because I think the server only sends them when you request them. But client. variables are kept in client memory at all times (I believe)

jake13jake 05-31-2006 04:12 AM

Quote:

Originally Posted by ApothiX
Could just as well be accomplished via: if(player.getActiveGuilds().size() > 1)


clientr. variables wouldn't be so bad, because I think the server only sends them when you request them. But client. variables are kept in client memory at all times (I believe)

other ideas pertaining to multi-guilding:
player.isInEnemyGuild(ofthisguild)
player.isInAlliedGuild(ofthisguild)

I'd rather do something like guild.clientr.bank_funds += num/player.getActiveGuilds().size();

Rick 05-31-2006 05:08 AM

Quote:

Originally Posted by ApothiX
clientr. variables wouldn't be so bad, because I think the server only sends them when you request them. But client. variables are kept in client memory at all times (I believe)

Wrong. clientr variables are sent to the client just like client variables. The difference is that the client cannot update the values of clientr variables.

jake13jake 05-31-2006 05:12 AM

Quote:

Originally Posted by Rick
Wrong. clientr variables are sent to the client just like client variables. The difference is that the client cannot update the values of clientr variables.

I believe you misinterpreted OkieSmokie.

client.variables are stored in the client's memory (RAM). Otherwise you'd experience lag when setting a client.variable clientside. You might have thought he meant storing it in the hard drive though.

Rick 05-31-2006 05:25 AM

Quote:

Originally Posted by jake13jake
I believe you misinterpreted OkieSmokie.

client.variables are stored in the client's memory (RAM). Otherwise you'd experience lag when setting a client.variable clientside. You might have thought he meant storing it in the hard drive though.

My point was that clientr variables are not requested: they are sent on connect and value updates.

jake13jake 05-31-2006 05:47 AM

Quote:

Originally Posted by Rick
My point was that clientr variables are not requested: they are sent on connect and value updates.

Yea, both are stored in memory. I was thinking you were disagreeing with something else (didn't read it correctly). The difference is just that a client.var change can be sent to the server.

Warcaptain 05-31-2006 07:11 AM

I think this would make a better addition to the requesttext function

the ability to request SOME of the guild info is already there, ie: rank, and i think members too.

I am not sure, I would suggest using the search function (on the forums)

jake13jake 05-31-2006 06:04 PM

Quote:

Originally Posted by Warcaptain
I think this would make a better addition to the requesttext function

the ability to request SOME of the guild info is already there, ie: rank, and i think members too.

I am not sure, I would suggest using the search function (on the forums)

You don't get the entire point. It would save servers from having to create their own guild databases to store serverside flags for all guilds, and thus it would take less time to be able to implement a huge improvement in the quality of guilds for gameplay.

Warcaptain 05-31-2006 08:55 PM

You would not have to store it all on the server.

All a world would have to do is have a requesttext function setup to retrieve and read data.

The only thing I could think of they would have to make is like, guild funds.. and there is no reason to have 'global' funds for a guild.. as some people MIGHT not like people making lots of money easily on classic (as bush items are allowed) and going on Graal2001 and getting hundreds of gralats.

jake13jake 05-31-2006 10:51 PM

Quote:

Originally Posted by Warcaptain
You would not have to store it all on the server.

All a world would have to do is have a requesttext function setup to retrieve and read data.

The only thing I could think of they would have to make is like, guild funds.. and there is no reason to have 'global' funds for a guild.. as some people MIGHT not like people making lots of money easily on classic (as bush items are allowed) and going on Graal2001 and getting hundreds of gralats.

Well, I was thinking more like having guild ratings and when a guild would have a certain rating, all of their members that are in that guild (and only that guild) could have special weapons (The idea being to recycle the Nation NPCWs that never got used, as I've already rescripted a few). However, since a guild's rating could fall, they could lose these if they didn't perform well enough. Money was just the broadest idea I could think of. The general idea would be to more easily treat guilds as a group of players rather than just being HD-immune to each other, etc.

Warcaptain 06-01-2006 02:36 AM

As I said, you can already access guild rankings via requesttext I believe.

Edit:
Yes, here it is. Guild Ranks

ApothiX 06-01-2006 04:41 AM

Quote:

Originally Posted by Rick
Wrong. clientr variables are sent to the client just like client variables. The difference is that the client cannot update the values of clientr variables.

Ah, I stand corrected.


All times are GMT +2. The time now is 02:15 AM.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.
Copyright (C) 1998-2019 Toonslab All Rights Reserved.