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).

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).

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();

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.

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.

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.

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.

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

Edit:
Yes, here it is. Guild Ranks

Ah, I stand corrected.

Yea, if only I had an auto-subscription to stefan's post so I'd know when he added something that I requested. However, I still believe that a guild object would be useful, and I also believe that knowing rank names would be useful (as they can usually better reflect what the rank's function is). On the other hand, with this news, I can start constructing my own guild database to reflect what information can already be received.

The problem with having an object is that it is tying something that is outside of the server into the server. That means that every use of the guild object would require a request outside of the gserver to the guild database, unless it is cached and then possible problems might arise with keeping things in sync.

Perhaps a requesttext/sendtext method might be better, like Warcaptain said. Then it is possible to control when requests are being thrown about, and it would be many times easier to implement.

Yes, I am not sure if requesting text can return an object, but if you are THAT depserate to have an object maybe he can do it so it returns one and then you can make some sort of serverr. object.. that is again if serverr. variables can be objects lol

No, I'd use a DB NPC to store guild info. It's not storing the information for the guild that's impossible, it's not having access to most of the guild DB info so that you can integrate it into the system. Also, for efficiency's sake, not being able to tell if a guild exists or not.

However, I bet most scripters would be uncertain as to how they would go about storing that info. A guild object would be beneficial to the scripting language. Access to guild DB info would be beneficial simply to integrating a scripted system to handle information. The benefits of the former would obviously include those of the latter.