ID:1930673
 
Sooo... *whistles* I've never thought of doing this before. But uuhh... Can anyone give insight on this?

The actual creation process
//Start creating the artificial player by loading their data ~Xirre
var/mob/player/newP = new
src.assessingplayer = newP
fakeMobs += newP
newP.ckey = tmpCkey
if(fexists("saves/player/[newP.ckey].sav"))
var/savefile/S = new("saves/player/[newP.ckey].sav")
if("key" in S)
S["key"] >> newP.key
newP.LoadCharacter(newP.ckey)


The whole bits and pieces that are actually related.
//If it's not a real player then delete it. But, still set their variable to null. ~Xirre
if(src.assessingplayer && ismob(src.assessingplayer))
var/mob/player/p = src.assessingplayer
if(!p.client)
fakeMobs -= p
del(p)
src.assessingplayer = null

var/tmpCkey = copytext(log, 1, length(log) - 5)
var/found = 0
for(var/mob/player/_P in fakeMobs)
if(_P.ckey == tmpCkey)
found = 1
//I didn't want to put goto pick letter here because... well who the hell started using goto anyways?
//I'd prefer not to have any unexpectancies pop up from goto. especially in a for loop. ~Xirre
break

if(found)
goto pickletter

//Start creating the artificial player by loading their data ~Xirre
var/mob/player/newP = new
src.assessingplayer = newP
fakeMobs += newP
newP.ckey = tmpCkey
if(fexists("saves/player/[newP.ckey].sav"))
var/savefile/S = new("saves/player/[newP.ckey].sav")
if("key" in S)
S["key"] >> newP.key
newP.LoadCharacter(newP.ckey)


The goal? To create an offline player so it is able to be interacted with as if it were online. Of course, if they log on during this process, I'll delete the mob and all the relations it has to variables and then I'll let it continue doing whatever it was doing from wherever it left off.
Good way to setup user shops, like in MMORPGs :D

I've got nothing to contribute, however, I like the idea.
The only difference between an offline mob and an online mob is the existence of a client connected to it. You might as well not delete the player on Logout().
In response to Kaiochao
Kaiochao wrote:
The only difference between an offline mob and an online mob is the existence of a client connected to it. You might as well not delete the player on Logout().

The one thing I have to check is if the admin who is running this command (the one who has src.assessedplayer) logs off, it needs to delete the mob immediately. That way you don't have senseless clutter. Additionally, as mentioned before, I need to make sure players who log on switch places with this mob. Not in the sense that they just client.mob = newP, but in the sense that they delete newP and the admin's assessedplayer takes over. My reason for this is because what if some douchebag is punching the mob during the edit? lol.

It's still a work in progress so there's room to simplify things. As much as I would love to rewrite the whole thing, I'm just not so enthusiastic about rewriting such big code. It'd take me a while.

Also, before I wrote any of this I made sure to check that LoadCharacter() and every other procedure did not contain any client.whatever code. Thankfully, it wasn't used anywhere.

So, I assume that there's nothing "bad" about making a fake mob and just treating it as a normal player?
In response to A.T.H.K
A.T.H.K wrote:
Good way to setup user shops, like in MMORPGs :D

Take note of what he just said. Damn good idea.
I just had a talk with someone and apparently having this fake player with an actual player's ckey can pose a problem. Such as if A.T.H.K logged on while his fake player was created it would kick the mob off because of the conflict with authentication. Does anyone else know of this?
It would if the ckey is attached, well .. I would assume it would, it just makes sense.

I wouldn't keep any user specific variables on the mob anyway, you can keep those details in tmp vars if you really need them. Something that at least associates the mob with the user is all you should need.

I'd modify that save var to include the above var for saving.

When the user logs in check for an existing mob and attach them to it, you shouldn't need to reload the save as the mob is holding everything anyway..
In response to A.T.H.K
A.T.H.K wrote:
When the user logs in check for an existing mob and attach them to it, you shouldn't need to reload the save as the mob is holding everything anyway..

That's the thing. What if they are being manipulated by another player? The fake mob that is. And then the real player logs in to it.
Freeze the mob until the other user is complete, or kick the other user out of the interaction.
I'm starting to understand the point of this.

Admin can load an offline Player's mob into the world into a Fake Player.

When Admin logs out, all the Fake Players created by Admin are removed from the world.

When Player logs in, all of Player's Fake Players are removed from the world. (Does Player take over from where the Fake Player ended up?)

If a Fake Player is "being manipulated" by a Real Player, but the Fake Player needs to be removed from the world, what should happen? (You mean, there's a running proc that involves Fake Player?) What happens when a Real Player is removed from the world while being manipulated by another player? That should happen to the Fake Player too, right?
In response to Kaiochao
You understood right.

Kaiochao wrote:
When Player logs in, all of Player's Fake Players are removed from the world. (Does Player take over from where the Fake Player ended up?)

It'd be nice to do this because then that's less work on my part. However, what if someone were to interact with this player? Such as killing them? You'd end up with problems because then the player would like in saying, "What the hell?" They would be confused and probably suspecting being drunk last night roleplaying.

If a Fake Player is "being manipulated" by a Real Player, but the Fake Player needs to be removed from the world, what should happen? (You mean, there's a running proc that involves Fake Player?) What happens when a Real Player is removed from the world while being manipulated by another player? That should happen to the Fake Player too, right?

--Scenario--
1: Player A.T.H.K roleplays for a bit.
2: Player A.T.H.K logs off.
3: Admin Xirre decides to do rewards for A.T.H.K. But, since A.T.H.K is offline, a fake version of A.T.H.K is created.

--Problems & Solutions?--
Problem: Well, the fake version of A.T.H.K can be damaged and moved.

Solution: Save only the variables related to roleplaying and not health/other vars.

Problem with the solution: What if ATHK logs in during this process?

Solution: That's the issue here.

Extra problem (which admins should be smart enough not to do): What if the admin logs out? What are the most important steps to take (such as deleting the mob)?

-----

What's in bold needs to be addressed. It's nothing hard to do either. It's just a big pain in the buttocks to achieve because I'd have to go changing a lot of things. Not to mention the fact that I could possibly make the fake version of A.T.H.K invisible too.

A.T.H.K wrote:
Freeze the mob until the other user is complete, or kick the other user out of the interaction.

Care to explain a bit more?
So the point of this is to manage rewards for an offline player? Does that really require the entire player to be loaded?
In response to Kaiochao
Kaiochao wrote:
So the point of this is to manage rewards for an offline player?

Yes.

Does that really require the entire player to be loaded?

Nope. But considering the amount of things I have to change, it's definitely easier.

Xirre wrote:
I'm just not so enthusiastic about rewriting such big code. It'd take me a while.

I could simplify it by only loading certain variables from the mob (excluding the x y z cords and other things). But that doesn't change the one thing this actually enables admins to do. And that's to edit players who are offline now too.

I favored this way of doing things because of 2 reasons. It enables more than one feature and it requires me to change less things for now. In the future, I plan on making use of the databases and also stripping the dependency on an actual mob. How? Load the data straight from the save file and when they are done doing whatever they are doing (be it editing or rewarding) check to see if they exist in the players list currently. If they do, apply it to their vars and save. If they don't, edit their savefile.

I tried rewriting the whole thing from scratch the first day. Primarily because I saw a lot of gotos and it started to dig under my skin. Halfway through the "main" I noticed there were some calculations that involved organizing players that I didn't understand since I don't play it much and I don't do rewards. So, I ended up deleting it all. And I say main because there's many other procedures it apparently uses. And there's an alternate use between key and ckey within some procedures. I actually had to add the saving of the key var to the savefile for the offline rewarding.
In response to Xirre
I was under the impression that this Fake Player would exist as an NPC in the world, but all you really wanted was a savefile editor?
If the mob exists when the user logs in, assign the client to the mob, freeze all actions if a moderator or admin is modifying them.

Quite easy really.
For Eternia's offline awarding all you really need to do is load the post counts from the savefile, then save the offline reward somewhere and apply said award when the person logs in next. There's no real need to complicate it this much, as the logs are stored independent of the savefile and are easily accessible without the player being online.

You can grab the variables you need directly from the savefile very easily (if you look at how they're saved).

The issue becomes that the list of people with unread posts isn't going to include said people.

When I was working on it (before I lost the progress I made) I decided to just ditch the text-file logging stuff and move to SQLite, having player logs all stored in their own database then having the post counts all stored in a main index database that could be easily sorted regardless of a person's online status.

You don't really need to change the logging itself immediately though, you really just need to do the index file part of it, and using SQLite will let you stop using the insanely slow and unoptimized sorting routines that the Eternia source code has for sorting the list of counts by who has the most (by using the 'ORDER BY' query sort).

Once you've actually provided a means for the admins to determine who actually needs to be checked it's a simple matter of loading their logs up and working as they would if the person was online, the only difference beyond that point is storing the reward somewhere (you could use the same index file that stores post counts to store offline reward numbers) and simply applying it when the person loads their character up -- without ever having to try to handle the reward process without a client.
To add on, you should definitely move the logging to SQLite, appending large amounts of text to large text files gets insanely resource intensive when it's being done at the frequency that Eternia does it. Outside of the terrible UI design, the logging functions eat up the most resources in the game. The sorting routines being used to manually sort the stuff don't help either, being able to utilize SQL queries gives you access to some pretty awesome tools such as sorting, searching, and manipulation.
As for what to do about a player logging in during the process, nothing special. When the process reaches the point where the reward will be applied, simply double-check if the person is offline or not, if they are you send the reward to the offline reward database, if they're online you apply it to them as you normally would.
In response to Nadrew
Nadrew wrote:
For Eternia's offline awarding all you really need to do is load the post counts from the savefile, then save the offline reward somewhere and apply said award when the person logs in next. There's no real need to complicate it this much, as the logs are stored independent of the savefile and are easily accessible without the player being online.

That's something I'm going to do when I use your SQL saving in the future. Whoever initially designed this thing made it a pain the literal ass to change up. Everything is everywhere and everything is repeated.

You can grab the variables you need directly from the savefile very easily (if you look at how they're saved).

As much as I'd love to do that, that's a lot of typing for something I'm going to delete in the future when I decide to rewrite the entire thing.

The issue becomes that the list of people with unread posts isn't going to include said people.

?

When I was working on it (before I lost the progress I made) I decided to just ditch the text-file logging stuff and move to SQLite, having player logs all stored in their own database then having the post counts all stored in a main index database that could be easily sorted regardless of a person's online status.

I saw it and read it briefly. I stopped reading it since I honestly just wanted to get the feature done for now and then probably take some time to finish your work something later this month.

You don't really need to change the logging itself immediately though, you really just need to do the index file part of it, and using SQLite will let you stop using the insanely slow and unoptimized sorting routines that the Eternia source code has for sorting the list of counts by who has the most (by using the 'ORDER BY' query sort).

That sorting this is practically what is stopping me from doing this in a simpler way. I don't want to touch it until I have someone who knows why it is the way it is. :/ And I'm being kind of too lazy to sit down and just read it over and try to understand why they're sorting it like that. There's no comments lol.

Once you've actually provided a means for the admins to determine who actually needs to be checked it's a simple matter of loading their logs up and working as they would if the person was online, the only difference beyond that point is storing the reward somewhere (you could use the same index file that stores post counts to store offline reward numbers) and simply applying it when the person loads their character up -- without ever having to try to handle the reward process without a client.

My initial plan was to have them load the variables from the beginning (which is why I said they have things repeated all over the place. They're constantly referring to a mob for these variables) and then when they are done rewarding or editing, check if the user is online and apply said changes. If the user is not only, apply it to their savefile.

Sadly, this would require me to change a lot of vars. The amount of work it would take to do that... I might as well rewrite the whole thing to fix any poor practices that were involved in the code.

Kaiochao wrote:
I was under the impression that this Fake Player would exist as an NPC in the world, but all you really wanted was a savefile editor?

It's practically a savefile editor. Yep. This is the easiest way, for now, to keep the current way they reward while I work on simplifying it in the future. It won't even consume much anyways.

A.T.H.K wrote:
If the mob exists when the user logs in, assign the client to the mob, freeze all actions if a moderator or admin is modifying them.

Quite easy really.

I may end up just rewriting the whole them tomorrow when I wake up. I really don't feel like trying to solve this login/logout issue. Although, I have yet to go searching for their Login/Logout code. It's just I hate having code that runs all over the place. It just gets so damn messy.
In response to Nadrew
Just to add: Honestly, Nadrew. If I didn't have to worry about the current logs and the sorting.. I'd have rewritten the whole thing long ago lol. I'm constantly thinking: "Now, what if I mess something up?"
Page: 1 2