Clientside Cache Files
 

My title probably sucks.

Anyhoo, savelines/savevars() clientside is good and all but it would be great if there was an additional option to cache/encrypt them i.e. clientside scripts could read them but players won't be able to open the file up in wordpad to see their actual contents.

The reason being for this is that I want to save alot of basic information on the clients computer once it's received e.g. quest information/progress. Saving it on comp would save additional triggers later on but I don't exactly want players messing around with descriptions.

With my luck, something like this can already be done so If anyone has any ideas/criticisms/abuse: go for it :D.

base64encode() would be sexy if you could use a key. If I looped all my encryptions a certain amount of times, would that work as a type of key? ^^

I guess.. (key?)

Make an md5 of the data sent to client, with a key added of course. Store the md5 in clientr flags or in server files, and then check it when the player logs in. Players would still be able to view the files but they would not be able to edit them without the check failing.

Personally I haven't found a reason yet to actually save text on a client's computer.

I think it would be useful to save all text-based data which needs to be read but doesn't exactly matter if it's tampered with. Stuff like quest info (with diary progress), weapon descriptions. I think it would be better than triggering the information or storing it in clientr. variables.

Weapon descriptions would have to be updatable. And quest info might be good, but only if its customizable, otherwise you would just store the strings somewhere.

Btw, for quests, I think its best to use a weapon object for each quest so they can have their own scripts, events, stage detection, etc.

It would be a one off download for the main chunk of information. It shall receive a version number. Minor revisions (spelling errors etc) could be appended to the file. When a new version is available, it checks whether you have it and downloads it if you don't.

My quest system will differ greatly from that as well..think SCUMM style :D

Oh god Inverness...why did you just say that :cry:

Next a weapon for every spell, for every skill and for every weapon ^^.

:: explodes ::

Gentlemen, we can rebuild him. We have the technology. We have the capability to build the world's first bionic man. Zero will be that man. Better than he was before. Better, stronger, faster.

You better not make every body part use a different WNPC!
You will blow up Graal :(

Nah, he'll probably make every body part use a different wNPC and the head a DBNPC.

I was actually going to make a hierarchical object-based Zero but your idea is better!

So cruel...
So cruel...

Back on topic.

I nominate this thread to now be about:
Adding a key to a new or existing set of encode/decode functions.

I have to hand it to you people, few have managed to piss me off so quickly. If you have a problem with my suggestions give an answer, get the facts, or shut your mouth. You all obviously lack enough knowledge to make a proper opinion. Take your bad sarcasm somewhere else.

Any decent quest is going to need a script, perhaps not each with their own weapon script but rather a class, that form of modularity is easy enough.

Use your NPC-Server.
ANYTHING stored on the clientside has potential to cause problems.
I'm sure that the NPC-Servers can handle what you're asking it to do.

I agree with this. You got serverside memory, use it.

got!

I agree, best is to store data that should not be modified on server-side, and private modifyable data on client-side (like if you do some tool for saving comments about other players). If there is too much clientside data then you can still use md5 for making a checksum on the data and store the md5 checksum on serverside. You would need to update the checksum when you modify the file that should be protected.

Stefan, we need a way to delete client flags on logout so stuff isn't saved that will just be overwritten by an independent system.

I don't limit myself so much ^^. One weapon can easily handle a quest system without the need for other weapons/classes to handle quests.

Geez dude. Chill pill ^^.

As for everyone else, What I want to store clientside would eventually be alot (i have alot of item descriptions/stats for instance) but it's the kind of data that only needs to be updated once in a while. Instead of chunking up clientr. variables (like Zodiac) or triggering this information, everytime it needs to be accessed. A md5 / checksum can be used on the cache file to make sure it is still valid. If not, update it.

It was just an idea but I'm going to follow through and test it a bit because I do see some potential :D

You don't need to store such information on clientside. Graal is not going to explode if you send a couple hundred bytes more to the client than normal.
So you would prefer to script the event detection and all quest stage scripts of every quest on your server in one weapon? That would look extremely bad. It is much better to use classes.

You don't seem to realize the depth of programming required for a good quest so you try to oversimplify it, stop.

You seem so ready to narrow your field of vision. What sort of programmer instantly goes, "Can't be done! My way is better! You suck! You obviously have no talent at all!"

I mentioned what I'd base my engine on. It can easily be done but you obviously shut your mind before I begun so there's no reason to even try to bother explaining to you.

I said it would look bad, I never said it wouldn't function. Why cram all quests into one script when you can divide them among classes and load them when they're needed. Modularity at its finest.
A wise man once said, "assumption is the mother of all ****-ups." You're assuming far too much.

By the way, join me on #Scripting if you will, forums take too long :(

I may as well post my quest system idea for I would like some feedback.

Basically, i want to make a quest-enhanced mus item system. Basically, the items store what they can do for the quest. For example, a quest key would have an entry to open the ol' cellar door in it's vars. Instead of storing quests in a centralised storage area, the scripts are stored in files/vars.

Another example would be a carrot, a stick, some string and a horse. To solve this problem, you would tie the string to the carrot, and the string and carrot to the stick. You now have a 'Carrot tied to a stick'. This new object would have a var which says it can be attached to the horse: You now have a ride able horse ^^.

Unfortunately I have to go right now (lift out the front but i'll expand soon)

Hmm, they way I prefer it to be is having a quest object check when it needs to do certain things and then manipulate everything else for the quest. Like for example. If you're on stage 5 or so, the quest would use a timeout to check if you've reached a certain location, then it advances stage. Stage 6 has a script that spawns a certain boss enemy and a loop is used to check the status of the enemy. When its dead the quest advances to stage 7 and you get your reward, then the script is unloaded now that the quest is complete.

Inverness, you obviously haven't seen major issues that happened with certain servers that did as you said.

It is much better to use wNPCs as entire systems (Such as a quest system) then use "modules" that you insert via ways of a class, serverside text file, database, etc.

A weapon per item/quest type system is a thing of the past! It is what almost all new scripters do.

Really, tell me why its a bad idea to have a class for each quest? Function conflicts are not a problem.
A quest must have its own script one way or another.

PS: Get on AIM >_>