Active Player Pool System

[Bue]

I'm experimenting with some ideas to improve the social aspect of a private server.

Particularly with small servers and centralized population versus large servers and sparse population; for example, on small servers, active players tend to pool around the main city, while on large servers, AFK, autotrade, and autobot makes active players less distinguishable, also players tend to 'get away from the crowd.'

The idea is very simple; allow players to provide some 'presence' as well as providing information about other's 'presence.' Furthermore, players can decide how much 'presence' they want to show; for example, if you want to party up for a dungeon, then let other active players know that.

So the resulting idea is the 'active player pool system.' Since players on private servers often refresh and respawn at some location frequently, players can also opt-in the APP system for free supplies, such as scrolls, potions, and other power-ups.

Upon opt-in, the NPC will display information about other active players (either in chat window or NPC dialog) ordered relative to the player's level (or by pvp rating, hueheu). The player may also opt-in for other things like searching for party or guild, which will add them to a separate pool.

Moreover, the system allows GMs to gauge the active server population and analyse the information to see what kind of events to throw, hell, you can even throw in the support system in it as well.

Finally, the APP system is self-maintained, the system logs in the time the player previously opt-in and deleted APP entries every X minutes / hours, depending on how reliable you want the system to be. In addition, the system removes entries when players log out.

Other 'presence' solutions 1) announcement, 2) @main chat, and 3) drama are somewhat lacking.

So gentleman, and ladies, what do you think? (Particularly that british fellow.)

TL;DR: Players can frequently opt-in the active player pool system for free supplies (limited only to the player), as well as maintaining presence and staying inform of other players (relative to the player's statistics) and activities. APP system will reset the active status of the player depending on some time period.

[Axiom]

Sounds like too much trouble for a simple fix. Shouting out over at @main or a simple /b ought to catch the attention of anyone active. At least, as far as running activities is concerned. Now, for studying how many people are active in contrast to AFKs, vends, etc, it may be useful. Personally, I can get accurate enough estimates over @who3 and @users though but that's just me.

[Bue]

It is more complicated than a simple @main.

It is the accessibility of information at the right time at the right place; safe location, resupplied, and ready to go.

Pretty much like how google tailors your search results and ads based on your search history, except in this case, the information is optional and mutually beneficial.

The basic implementation is very simple since it is information based, but you can add in complicated features that can expand on the idea of moving information between players and other social features.

[Axiom]

Giving players the option of opting in or not would yield inaccurate data, wouldn't it?

[Bue]

You need to opt-in for the supplies, otherwise the system is broken. lol

It is very discrete; player opt-in for supplies, system handles players additional information (almost like advertising), and players can also choose to use the system.

Information can range from trading to recruitment to anything.

For example, on my server, when you opt-in: you'll get scrolls, potions, and field items that increase your survivability; since I practically made the entire server a living death trap except certain areas, strict economy, and sparse resources. Other players within the area will be displayed and ordered by level and pvp rating.

[Axiom]

Sorry if I was vague, but my concern with using such a system to monitor activity is not every active account may choose to opt-in. There can be many causes for that, ranging from new players not aware of the system or old ones who simply no longer fiind any benefit to it. Given these factors, the system is prone to yielding an active count smaller than it may actually be. As far as this being a tool for collecting server data, there are simpler ways to get more reliable data. 

Now as far as creating a pool or queue for players joining parties and active events go, I'd say this is a great idea.

[Bue]

In this case, you've a very limited imagination.

New players won't be aware of a system that hands out information and supplies, and may possibly be placed right next to the healer and warper? Or the supplies and information cannot change to match the statistics of the current player?

This system is always beneficial and provides plenty of opportunities given the information that can be harness. Even if the system doesn't hand out free supplies, the idea is that you can still use it to advertise your guild, find a party, or trade something.

For example, if you're guild-less, then you may go into the APP and opt for the guild recruitment pool. A guild leader looking to recruit can access the APP and contact you while you're active, furthermore, why not throw in a function that allows the guild recruit to warp to the location of the guild leader?

Also, this is very important to note, while in-game the active player pool system is not name the active player pool system. You can mask it under the label Kafra Corp. It's all about imagination.

[Axiom]

Lack of imagination indeed. I apologize, but let's act grown-up here and skip the pot shots.

If the APP were positioned as a multifunctional hub NPC of sorts, then it may just work. Kafra may be risky as bots are bound to access it as well.

[Bue]

Given the capability of the item database files, which allows storage, trade, and sell restriction along with stack limit and among other scripting possibilities; bots cannot benefit anymore from the supplies than players can with both supplies and information.

Bots can participate in the active player pool all they want; makes my job much easier if you know what I mean.

At this point, It'll be more interesting if you can come up with a better solution...

Afterall, you must be doing something with Chu! And you need to forgive me, if I sound rude, been coming up with plenty of ideas recently.

[Axiom]

Oh no, my concern regarding the bots isn't so much about them getting the free items. There are easy workarounds to that. It's more along the lines of making sure whether or not the APP can tell between human or bot, at least for the APP NPCs bots are likely to use (warper, stirage and healer types?). Mistaking bots for humans can throw off statistics unless we can differentiate.

As far as stat tracking goes, I think adding a log on the warper (if there is one available) is the best place for it. People use it a lot, and the number of unique uses it gets hourly should show you how much traffic you get in your server throughout the day and when it's busiest. Adding a sort of captcha system in (I've seen some servers with the system before) to prevent bot use can also take bots out of the computation of statistics (and prevent them from using the NPC, natch).

The more social implications of it (queueing, recruitment, etc) is conceptually sound. It's just a matter of integrating it properly in-game.

[Bue]

Oh no, my concern regarding the bots isn't so much about them getting the free items. There are easy workarounds to that. It's more along the lines of making sure whether or not the APP can tell between human or bot, at least for the APP NPCs bots are likely to use (warper, stirage and healer types?). Mistaking bots for humans can throw off statistics unless we can differentiate.

As far as stat tracking goes, I think adding a log on the warper (if there is one available) is the best place for it. People use it a lot, and the number of unique uses it gets hourly should show you how much traffic you get in your server throughout the day and when it's busiest. Adding a sort of captcha system in (I've seen some servers with the system before) to prevent bot use can also take bots out of the computation of statistics (and prevent them from using the NPC, natch).

The more social implications of it (queueing, recruitment, etc) is conceptually sound. It's just a matter of integrating it properly in-game.

The only statistic that the APP system track is the # of active players.

For example, the APP system pushes an active player onto the SQL table 'active_player' or some data structure like an array, which stores only it's character / account ID. From this, you can obtain information across other SQL tables or from the scripting engine; you can even attach the player onto scripts without the player even clicking on a NPC.

For example, say you've an array of account IDs, then you can use attachrid <account ID> and run a script with that player attached; this allows GMs to either warp all active players to a particular location or send out messages only to the players in the APP system; in fact you can built some exclusive messaging systems this way, but would probably be very inefficient.

Spoiler

*attachrid(<account ID>)
*detachrid;

These commands allow the manipulation of the script's currently attached player.
While attachrid allows attaching of a different player by using it's account id
for the parameter rid, detachrid makes the following commands run, as if the
script was never invoked by a player.

In case, that the player cannot be attached, such as, when the player went
offline in the mean time, attachrid returns 0, otherwise 1.

[close]

Spoiler

*dispbottom "<message>";

This command will send the given message into the invoking character's chat
window.

[close]

Spoiler

OnWhisperGlobal:

[close]

The statistic tracking methods you're describing is quantitative and less discrete, since the number of active players is inferred, which can be inaccurate given the wrong correlation equations. Other quantitative methods like the ones used in old warping scripts uses the idea of displaying the # of players on a specific map as the player invoke the menu, but if you look at the complexity of the system, it is actually very inefficient because every time you call the menu O(M) * Frequency * Players instructions will run; M is number of maps. This idea applies to all quantitative tracking methods.

With the APP system, players opt-in optionally every other time period, this way you've O(1) * CONSTANT * Players; and you know for sure that the player is active; if there is any doubt, you can even run some scripts to double check since you've the account ID.

Furthermore, you never want to impose restrictive systems like captcha if you can avoided it. If you do it to something so trivial, it practically screams "I am very incompetent!" It would be interesting to see what happens if bots opt-in regularly on the APP system, whether the system can be self-policing would be very interesting.

[Bue]

Since I've gotten more ideas out of our discussion than I initially thought off, I don't mind developing a basic version of the APP system for you to test and used on your server.

Although, at the current standpoint, everything is still conceptual, whether or not it will actually work requires some testing.

[Axiom]

I'd be happy to test whatever you come up with. Mind, my server only tops at 20-30 on active hours though.

[Bue]

I'd be happy to test whatever you come up with. Mind, my server only tops at 20-30 on active hours though.

Here is what I can conclude from our discussion:
1. Active Player Pool System
- Complementary medium for social interaction; active player, party, and guild pooling.
- Allows Game Masters to easily manage all active players via scripting and communication, specified.

2. Game Relay Chat System
- Third mode of communication through in-game chat window.
- Practical applications include guild-alliance chat and GM support chat, specified.

The difficulty now is making these system as efficient, user-friend, and intuitive as possible. Getting players to initially try out the system requires some incentive though; and whether or not they continue to use the system would determine whether the idea is a bust or not.

I've work and school, so getting these systems scripted and tested might take some time. >.> Doesn't seem like anyone else is interested though. = =

[Triper]

Dunno why, it can be an easy and simple way to check stuff instead of using the usual ways.
I just dunno if it will be enough to be better then the RO map+where players are system. It's a really good system for checks but mixed with this it can even be a better option! It could be like an "upgrade" =P

[Soulman]

Could be somewhat useful to server owners, but I doubt that it's in much demand, and therefore I doubt you will get a lot of support for this project.

[Bue]

I just dunno if it will be enough to be better then the RO map+where players are system.

They're two separate systems; this one mainly keeps track of active account IDs, which I dubbed active player pooling.

Could be somewhat useful to server owners, but I doubt that it's in much demand, and therefore I doubt you will get a lot of support for this project.

I don't expect inexperience server owners to understand the importance of managing active account IDs.

Mathematically, you can think of an account ID as a player and that the active player pool as a set of players.

If you're a computer scientist, you'll know immediately what I am talking about; set theory. Using set theory, you can at least apply some mathematical logic and theory to develop very complex systems and algorithms.

For example, take a look at a guild tournament match, you can picture this as a mutually disjointed set with two (or more) partitions, one for guild X and the other for guild Y, so by definition, any guild member in guild X cannot be in guild Y during the tournament match, but of course, this can never happen since you can only be a guild member of one guild.

Now, say that the tournament allows alliance guild members to participate together since there aren't enough members for each guild individually. In this case, you can picture all the guild members within an alliance as one set, but the problem is that one guild might be ally to both guild X and Y, thus violating the rule that any guild member in guild X cannot be in guild Y during the tournament match (and vice versa) since the alliance guild is union with both guilds.


==========================================

Now if you look at the active player pool system; you can use set theory to define subsets such as event, party, guild, and quest player groups, enforce rules between each subset, and handle only specific subsets of players.

The magic about all of this is that using account IDs, ALL the information you need to know about any player can be taken from the MySQL tables AND you can attach ANY script to ANY player or subset. 

Spoiler

*query_sql("your MySQL query"{, <array variable>{, <array variable>{, ...}}});
*query_logsql("your MySQL query"{, <array variable>{, <array variable>{, ...}}});

Executes an SQL query. A 'select' query can fill array variables with up to 128 rows of values,
and will return the number of rows (i.e. array size).

Note that 'query_sql' runs on the main database while 'query_logsql' runs on the log database.

Example:
set @nb, query_sql("select name,fame from `char` ORDER BY fame DESC LIMIT 5", @name$, @fame);
mes "Hall Of Fame: TOP5";
mes "1."+@name$[0]+"("+@fame[0]+")"; // Will return a person with the biggest fame value.
mes "2."+@name$[1]+"("+@fame[1]+")";
mes "3."+@name$[2]+"("+@fame[2]+")";
mes "4."+@name$[3]+"("+@fame[3]+")";
mes "5."+@name$[4]+"("+@fame[4]+")";

[close]

Spoiler

*attachrid(<account ID>)
*detachrid;

These commands allow the manipulation of the script's currently attached player.
While attachrid allows attaching of a different player by using it's account id
for the parameter rid, detachrid makes the following commands run, as if the
script was never invoked by a player.

In case, that the player cannot be attached, such as, when the player went
offline in the mean time, attachrid returns 0, otherwise 1.

[close]

==========================================

This idea is practically a wet dream for any script developer, since it provides a viable way to group players together rather than setting a boolean variable or running the player through a series of if conditions to verify if they are such and such.

Furthermore, you can organize these account IDs using ANY data structure that fits your needs; whether its a queue for a an event or a heap for a tournament tree.

/nerdorgasm

[Axiom]

Could be somewhat useful to server owners, but I doubt that it's in much demand, and therefore I doubt you will get a lot of support for this project.

The way I see things is free new custom scripts are in high demand regardless of what they are. When you think about it (or pay attention to eAthena/rAthena's boards), you'll see there are very rarely any new content. This particular idea opens the way for several other ideas so I'm all for having it.

[Klassione]

The way I see things is free new custom scripts are in high demand regardless of what they are. When you think about it (or pay attention to eAthena/rAthena's boards), you'll see there are very rarely any new content. This particular idea opens the way for several other ideas so I'm all for having it.

Agreed.

[Bue]

A quick demonstration of one key point; attachrid + active player pool.

Obviously, there are a good number of things wrong with the script at the moment. And currently, I'm trying to figured out a good solution on how to display relevant information and a good data structure for fast searching and easy iteration. I'll post more stuff soon to demonstrate other concepts that we've discussed.

Currently, this script inserts players into the pool and allows you to send a message to the guild chat to every player in the pool.

Code Select Expand

// Initialize the active player pool
function script app_initialpool {
set $@app_base$,"$@ACTIVEPOOL";
set $@party_prefix$,"_PARTY";
set $@guild_prefix$,"_GUILD";
set $@event_prefix$,"_EVENT";

set $@appseries,0; // First array series
set $@appcurrent,0; // APP Size
set $@appsize,128; // APP Array Size
for(set .x,0; .x < $@appsize; set .x,.x+1) { // Initialize APP Array with 0s
setd $@app_base$+$@appseries,0;
}
return;
}

// Expand the active player pool
function script app_expandpool {
set $@appseries,$@appseries+1; // Next array series
set $@appcurrent,0; // Reset APP Size
for(set .x,0; .x < $@appsize; set .x,.x+1) { // Initialize APP Array with 0s
setd $@app_base$+$@appseries,0;
}
return;
}

// Display the current active player pool
function script app_displaypool {
for(set .y,0; .y <= $@appseries; set .y,.y+1) {
for(set .x,0; .x < $@appcurrent; set .x,.x+1) {
npctalk "[Series " + .y +" Current " + .x+ "] " + rid2name(getd($@app_base$+.y+"["+.x+"]"));
}
}
return;
}

// Insert active player into the pool
function script app_addplayer {
if($@appcurrent >= $@appsize) {
callfunc "app_expandpool";
callfunc "app_addplayer";
} else {
setd $@app_base$+$@appseries+"["+$@appcurrent+"]", getcharid(3);
announce "Active Player Pool Activated: " + rid2name(getd($@app_base$+$@appseries+"["+$@appcurrent+"]")) + ".",bc_self;
set $@appcurrent, $@appcurrent + 1;
}
return;
}

prontera,156,173,4 script app_main 123,{
switch(select("Enter Active Player Pool","Display Active Player Pool")) {
case 1: callfunc "app_addplayer"; break;
case 2: callfunc "app_displaypool"; break;
default: npctalk "Invalid selection."; break;
}
close;

OnWhisperGlobal:
/* APP Command Block */
// See the explanation on how the whisper system works.
// Commands should be delimited by #, make sure everything is 'checked'



/* APP Chat Block */
set .whisperchat$,@whispervar0$;
set .whispername$,rid2name(getcharid(3));

// Attach everyone in APP to the current script
for(set .y,0; .y <= $@appseries; set .y,.y+1) {
for(set .x,0; .x < $@appcurrent; set .x,.x+1) {
attachrid(getd($@app_base$+.y+"["+.x+"]"));
dispbottom "[Chatroom " + .whispername$ + "]: " + .whisperchat$;
// Don't detachrid unless the next few processes shouldn't be
// run for the player. Let the remaining script handle clean up
}
}
end;

OnInit:
callfunc "app_initialpool";
end;
}

[Cawliflower]

I've already done multiple systems like this in my past servers and on the current. At least the RO community will benefit off of this. This does help server owners gather data and analyze the community. However, most server owners aren't competent anyway.