Kafuuka

Going into semantics: I never said you said it is an FPS, I said IF you claim it to be an FPS... Back to serious business: people stealing your lollipops is way more annoying than getting spanked. And everyone that goes to RP because they can't stand loosing in battle is prone to bunnying/godmodding. Which ends in being ignored, lectured or outgodmodded (yes this can happen, especially if the one doing it actually has the silence spell, but it is not required); they loose in RP, which is a hard thing to do since death can be the most epic roleplay (if never resurrected that is). I doubt those people are the ones who debate on the forum for the very same reason: debates require at least one party to change their views. I also said that at mp3 there were few good rits, before the tokens. I know there are more possibilities at mp4 and now with tokens and changing abilities... but that mostly supports my argument. The fun is in finding counter rituals. A couple of people test the new abilities, make new rituals and counters. If a newer person or one who has less time attacks one of the new rituals, they'll see how good it is and will be prone to copying it. At that point someone who knows the counter is bound to attack them sooner or later and poof free knowledge of the counter is granted. You've had the most fun in months because there are new rituals possible, does that not imply that you already tried all the evident old rituals, and the less evident and even most of the really tricky obscure ones? Your idea about commenting fights is similar to what Tarquinus mentioned with [post='46582']"don't ignore the system".[/post]

One of the things that annoy me, is advertising and begging: "Please become my adept." "Please vote for my friend, whose name I will not specify, to become king of ..." "Please look at my thread where I invented a new creature." "Please look at my trade thread, which is actually an attempt to rip you off." "Please give me free stuff." "Please do my quest." <- guilty of this one At one time, after spending time, effort and silver coins on a quest, the final stage was 'get me three adepts.' I could either demand my coins back or try to solve this simple thing... except that every person I asked already got asked to be someone's adept 10 times, in the last hour! Sometimes people even ask me to become their adept, after noticing that I managed not to fall into the 'free inside information' scam for almost a year, what makes you think I will do so now? Needles to say there are now three very inactive alts adepted to one unfortunate player, so sue me. And the not specifying names, that's not me who invented that, people really assume I know who their 'friend' is. My train of thought was something like: oh look, someone wants a favor... someone needs to learn how to spell, and perhaps include all details, I wonder whose friend he is and if that person knows people spam in their name, without attention to spelling, or details like who I am supposed to vote for, perhaps they are lucky I don't know who they are... oh well, DELETE. Quests... for some reason the quest list doesn't seem to work. The week I announced my quest there I got less players than the other weeks. The shiny golden Q button works marvelous though. Also, what happened to spell documents? They were the inexhaustible reward thingy that was usually tied to relatively easy quests, without the need to be the first and only solver. Quests involving WP are supposed to be the hardest kind, and creatures and coins are limited in supply too.

[quote name='dst' date='09 November 2009 - 02:07 AM' timestamp='1257728833' post='47023'] Cut the cr**! If i read one more time about how MD is a RPG and not a PVP I will delete the entry instantly! Is is THAT hard to understand that it's NOT a RPG? Or at least not the common RPC you are all used with? Hey! I might even call it a FPS! After all i chase players all over MD to get a decent amount of xp these days! Shish...Who are the most known players? I will tell you: the grinders. Except Z and Tarq nobody from the so called "good RPers" are as known as the grinders. And they are know because they were also RPCs. Sorry but as I already said a thousand times: combat system is superior to RP system (which actually almost doesn't even exist). Shish...again... [/quote] MD is not just an RPG. However if you claim it is a FPS you are making the same mistake as people claiming it to be an RPG. MD is a lot of things: roleplaying, creature battling, wish point gathering... The reason good grinders are 'famous', is quite simple: they are good because they know how to beat your rituals and do it regularly, how can you not notice them except if you never do any battling? For roleplaying it is much more difficult. It takes at least two people to roleplay, or one shizo. When both people are good, they will produce an interesting story, which others might notice and participate in. If one is good and the other goes ooc or godmods, then you will most likely see the former person getting angry, going idle or giving advice on RP, none of which is good roleplay. And all of it requires you to read it, which you wont unless you are at least a bit interested in RP. So RPers will notice RPers, while grinders and everybody who at least has a single creature and is level 5 will notice grinders. (which excludes me, jay!). Also: the fighting system doesn't look interesting to me. You all talk about 'tactics' but all i can see is a few creatures with useful skills, which means a limited number of possible useful rituals. For mp3 it didn't even require any thinking at all, since every headscontest you would get attacked with the best ritual that was available at that time. The dozens of people that did train months to win HC at mp3 before I went to mp4 all used the same kind of ritual, so if I wanted to have the best ritual, all I needed to do was copy it. Certainly the RP system is lacking too, but don't be praising the battle system like it's the only thing that is perfect in MD. It is not perfect; nothing will ever be perfect because that would imply Mur wouldn't need to work on it anymore and the concept of the game is that everything is constantly changing.

Proof against what? That picture could easily be interpreted as three robed men having a drinking party. Some of them even mistake books for firewood! Usually one would invoke Ockham's razor here, but if we closely inspect the position of Zleiphneir in the picture we can see he is actually hoovering 0.5 meters in the air. Now, I've seen him do some funny stuff, but levitation?

[quote name='Rendril' date='04 November 2009 - 08:36 PM' timestamp='1257363413' post='46630'] You yourself said this would not be a frequent occurence. Imagine scanning a table of 30k rows just to remove 1 key on a regualr babsis... [/quote] Infrequent as in 'not every hour' yes, but frequent enough if you compare the number of keys purged to the total number of keys. Actually, how long would a query on 30k rows to find all players that have one (or more) keys take? And for deletion (guessing that takes a bit longer).

[quote name='Rendril' date='04 November 2009 - 02:28 PM' timestamp='1257341303' post='46586'] As I showed in the estimate above storing them in tables is likely to cost more then the current method. Our desire to put them in a table at all, coems from the need for efficient key cleanup. We accecpt that the deleting is happen infrequently.[/quote] We do? I never accepted that. And estimates about cost are quite depending on how efficient MD code is. [quote]So while it might save stoing a few unsed keys when it happens (for a large deletion cost) in the tiem that the quest is running, it will be used more resources. There are many quests that runs months without being finished, and some keys might be used for things indefinitely. It just isn't showing itself ot be a good tradeoff. In fact, from what I can see, the best action is to simply start storing the keys in an indexed rather than associative array. At key creation you run a loop inm linear time to detect a duplicate. [/quote] If you really want to optimize it, you could always store a single boolean for each keyname: permanent. Only put the ones that are temporary into a second table that keeps track of uids for keys. Downside: you need two new tables (although a table of booleans is hardly expensive) and everytime a key is given, a check must be made if the keyname exists (if it doesn't you don't know if it is permanent or not) and whether it is permanent. If all key functions are global functions, this isn't difficult to program, but all currently existing keys should be registered, which seems like an annoying thing to do. Anyway, this discussion seems to rely too much on what the current MD code looks like. Which means we'd better persuade Mur to read this.

Same question applies: is there a single function for adding/removing a key or is it hardcoded for every single key? It's hard to believe someone would actually do that.

Yes there is a flaw If you put the keyname into a String variable, no simple reg exp will find it but instead you need something close to an interpreter, which is too much work for sane people. Then again, did Mur ever claim to be sane? You could demand keynames are never put into variables but are always spelled out completely, but that is quite a loss in scripting efficiency. eg. [code]@va = 'keyname'; mds_has_rpcq_keys(@va);[/code] cannot be verified with only 1 regular expression. Enforcing is not a requirement, but it will decrease efficiency because people are inherently lazy and thus liable to ignore labels and the cleaning.

Are you implying each clicky has its own code and changing how clickies work means doing the same job a hundred times?

[quote name='Rendril' date='02 November 2009 - 06:56 PM' timestamp='1257184570' post='46420'] That is the problem, there is [b]no key table[/b]. Keys are stored as a serialized array in the player table. [/quote] Then [b]make one[/b], and keep it in sync. Obviously only Mur could actually make one, but that goes for the delete button too.

[quote name='Rendril' date='02 November 2009 - 07:12 PM' timestamp='1257185539' post='46421'] I somehow didn't see the post you made about the key storing over time. A script could be labelled so it knows to be deleted, but you would need to assign which keys belong ot it specifically. In some cases I want keys to be around for ages, some I want gone within days. The direct deletion trigger or expiration would be very useful, but how do we link them?[/quote] [quote name='Kafuuka' date='31 October 2009 - 11:22 PM' timestamp='1257027755' post='46236'] How it works: 1. create a label L 2. register keys K to L 3. create scripts S with label L Steps need to be carried out in order, but you don't need to do all of them. eg. no scripts, only a label. When deleting L, first all scripts S will be deleted, if any. Then all keys K will be removed from all players that have them, if any. Finally the label L is deleted.[/quote] And if you want a timer, you should add it to L. It is possible to enforce keys to be assigned to a label. Whenever the security check reviews a new script, it can search for the commands involving keys, eg. mds_has_rpcq_keys(key1, key2). It can extract the names key1 and key2 and check if those keynames exist for any label or for the label to which your script is assigned. The latter provides more security, but then you need to allow a label to be assigned to another label, if you want to use keys from that other label. One more possible flaw: if a script is deleted, but a person opened the clicky containing it before the deletion and pushes a button afterwards, that script is probably not stopped? This could be circumvented by delaying the deletion of keys until say 24h after the scripts are deleted. Not overly difficult yet quite an annoying thing.

[quote name='Rendril' date='02 November 2009 - 05:40 PM' timestamp='1257180036' post='46410'] You put forth a powerful solution but there is a big flaw, your assumption. With the way you have proposed it, there would be a player array with 30k entries. Even if we assume a mere 1kb per player info (counting name, keys, id etc) it would take 30mb at minimum. That is almost a percent of the server's total RAM, and only a minimal estimate. If 100 clickables were ot be accessed concurrenmtly that's the whole server taken down because it's trying to hold 300k rows in memory. Please correct me if I have misundertood what you meant.[/quote] Why would you put the same array into the ram multiple times? The one exception to this is multithreading. But even then you only need one copy to read from and you cannot have multiple copies to write to, lest you wish to risk data going out of sync. If there are 30k players, there will be 30k player objects. These objects hold things like keys, name, creatures owned stats etc. The key part isn't taking up the majority of that 1kb though. [quote]I'm guessing you were refering to the array of players who have the key. Anyway, there is no such player array. There is but a single player object.[/quote] That's why I said such an array should be created. There is no need to store all player data in it though. primary index is keyname, second column contains arrays of player ids, not player objects. Once you have the player id, you can retrieve the player object from the existing player array. [quote]The player object is select roughly in this way [code]SELECT * FROM players WHERE id = $id LIMIT 1[/code] This is a big generalisation on what the query looks like just to give an idea. Now, it will return a key array (an array of string) in the player object. In c++ style the has_keys() function does roughly this, where key is the string for the key and keys is the array of them. [code]if(keys[key] != null) return true; else return false; [/code] I know this is c++ code which wouldn't work, php supports associative arrays where you can define custom named indexes. The keys are stored that way in order to eliminate duplicates. [/quote] In similar fashion, with a second table for keys: [code]SELECT * FROM keytable WHERE key = '$key' LIMIT 1[/code] Will return an array of integers. You can use the same associative array type to check whether a certain player(uid) has said key, or you could print out all elements the array has and thus know which players have the key. If you want to transform uids into names, you can use the original table at the cost of an extra query.

Those queries should only occur when one deletes a quest (at least in this system, what the other thread is aiming at is interesting too... jolly good fun with dual threads, which I guess is my fault.)

[quote name='Rendril' date='02 November 2009 - 02:31 PM' timestamp='1257168708' post='46396'] The keys are an array of strings held for each player object. Storing an integer constant for the editor is feasible. I like it as a solution, but is it workable with the current system? The clickable has access to only the player accessing it. To have a function asking for "all players" means querying the database. If quertying the databse is acceptable (it puts a greater load on the server for MySQL overhead) then it could be done. [/quote] I assume the player objects themselves are stored in an array or another list type. Each player object has an array of keys. (I seriously doubt this is a traditional fixed length array, more likely a linked list.) Essentially: array_of_players[uid].array_of_keys[i] For different uids, the i-th key is not necessarily the same string constant. This means that mds_has_rpcq_keys("keyname") actually does (c++ style): for( i = 0; i < array_of_players[uid].array_of_keys.length() && !found; i++){ [indent]if( array_of_players[uid].array_of_keys[i] == "keyname" ) [indent] found = true;[/indent][/indent]} return found; A hashmap of keynames list_of_players_with_key["keyname"].list_of_uids[i] can be made. Each element of the hashmap is an object containing an array of uids (integer constants, references to player objects would work too of course). To output all players that have a certain key: for( i = 0; i < list_of_players_with_key["keyname"].list_of_uids.length(); i++) [indent] std::cout << list_of_players_with_key["keyname"].list_of_uids[i];[/indent] Generating the hashmap from the player array is a trivial double loop. After it is generated, every time a key is given or taken, a modification in both 2d arrays should occur simultaneously, keeping both structures in sync. Both of these operations are single loops, with the length of the loop depending on number of keys a player has and number of players that have a key respectively. This is also where having useless keys increases cpu time.

Care to explain how you estimate the expenses? My rough estimate for the label method gives a profit ~ 50% after one year. If you combine it with the solution in the other thread [post='46394'](delete button)[/post], it would break even after a year and yield 30% profit after two years. The parameters I chose for the estimate are not exaggerated in favor of my method at all. And I did not take into account that string constants often use more memory than integer constants.

I think there is a less invasive method to do this. I assume keys are stored as follows: every player object in the list of players, has a list of keys (string constants). It is feasible to make a list of keys (string constants) and for every key have a list of players ids (integer constants). This list can safely be generated from the first list (the first list is not altered), although the query might take a long time, but the process need only be done once. A new function could be made, returning a list of player ids that have a certain key. list mds_who_has_key(const String "key"); If you know the keyname, you can then print a list of people that have that key. You do not have to be the one who made/gave the key. Downside is this doubles the amount of variables stored for a single key. It would help [post='46236']the cleanup process[/post] though.

[quote name='Rendril' date='02 November 2009 - 12:48 AM' timestamp='1257119300' post='46344'] I'm not sure what you mean. I was talking about the server having to store more as well. It is not a heavy strain, no. But an unnecessary one.[/quote] Imo it is nothing short of a memory leak. The person who creates a key giving script cannot make a script that will take away said key with a 100% efficiency. It is a small leak, perhaps only a kilobyte a month... yet no programmer should be satisfied with that.

Keeping a list of keynames changes nothing to the keys themselves. If we assume the average key is possessed by ten players, using the list implies one more string constant is saved, increasing the load by 10% if a key is indeed only a string (I think I read the date is saved too, which implies the effective increase is less than 10%). If one in five keys (quests) expires within two months and the total number of keys is more or less a constant, then we can estimate after one year as: without cleanup: 80 permanent keynames + 6*20 temporary keynames = 200 keynames; loading = 10 => total memory used 2000 with cleanup: 80 permanent keynames + 20 temporary keynames = 100 keynames; loading = 11 => 1100 The values are guesses, but a key that is possessed by less than 10 players should not be the norm. Whether features or quests, the idea is that most of them are made for the masses. If a quest expires, two months is more than we usually give. At the moment most quests expire too, but given the script it will be more feasible to make permanent quests because there is less maintenance on them. Things people seem to forget: - keys should expire at the same time all scripts giving/taking the keys expire. - deciding which keys/scripts to clean up at what time is not the same as deciding how to clean them up. Without the how, the what and when is irrelevant. - the chances people set the expire date to never are only slightly smaller than the chances people forget to push delete after the expiration date. In general it are the same people that do not care about cleaning up or are sloppy and forgetful, that are either to vain or to neglecting to think ahead and decide a good expiration time.

@Observer: not all scripts should expire. eg. Someone could make a market script to finally get rid of all those willing to trade topics on the forum. That script should only expire if a better market script becomes available and I doubt that would happen at a predictable time. In general it is difficult to predict when a key/script will expire, unless you set a deadline for your quest and do not extend it... Imagine the server going down for maintenance at the last day, at such a time i would extend the quest 24h. @No One: Labels work similar to the list you mention. Makes me wonder if you read my post And yes Mur should be involved with this, especially since it requires changing the MD code, not writing MD scripts. However it would be nice to give him a list of solutions. Or we could brainstorm together on irc, since this is a problem that deserves priority.

[quote name='Rendril' date='31 October 2009 - 08:07 PM' timestamp='1257016079' post='46227'] So Kafuuka, what you are proposing is to "label" the scripts which belong to a certain quest which allows you to delete them in one call? Storages would also need ot be given a label which corresponds to the script's label, so that the garbage collector knows to take it down too. The problem with keys is that they are not editor-specific, in other words 2 people could be using a key of the same name (that is why I suggest using key prefixes in all your code) how would the cleanup know which ones to take?[/quote] I propose there to be some structure enforced. All scripts should have a label and there should be a list of keys that exist. As soon as one player has a key, or even is capable of receiving a key, that key 'exists'. Afaik this list is currently not implemented and without it there will be useless keys piling up without anyone realizing they exist, which is like a memory leak. To prevent this, it makes sense to assign key names to the label of your quest scripts too. At the time of writing a script, you know which keys you create and you can list them. When deleting all scripts with a certain label, a query can be executed on all players, to remove the keys in that list. (which is something you wouldn't want to do every second i guess, but then again who is going to delete many scripts in a short time?) This relies on people accurately listing the keys. Alternatively you can force people to register keys with a label before they can be given to a player. (Could be verified at the time the script is tested for security.) How it works: 1. create a label L 2. register keys K to L 3. create scripts S with label L Steps need to be carried out in order, but you don't need to do all of them. eg. no scripts, only a label. When deleting L, first all scripts S will be deleted, if any. Then all keys K will be removed from all players that have them, if any. Finally the label L is deleted. If you have cross-quest keys, you can put them in a different label. You could even put each key in a different label, thereby making it redundant. However using labels in a sensible way (ie. making as few labels as possible), you needn't worry too much about cleaning. In [post='46174']this post[/post] I outlined an example of a quest that should leave only one key on players at the end. However, if a player stops midways, they will have multiple keys. If at a later time you want to purge all remnants of the quest, it is very easy to forget the additional keys of players who gave up on the quest and only clean the end key. (afaik We can't use the required queries in MDscript anyway.) Two large issues: people using the labels wisely and people actually pushing delete once in a while. My solution thus is far from perfect, but at the moment there is no cleaning at all. I hope it can be improved upon so that we will not need code inspectors. There is already a fair bit of paranoia about plagiarism and cheating, code inspection would not help that at all. Reading undocumented code is annoying anyway. Storages: I'm confused how they work, so I'll get back to those once I figure them out.

You are making the assumption people will clean up things themselves. Perhaps all those who currently have access have the intention to do so and the skill, but at some point there will be people lacking intent and/or skill. Besides the road to hell is paved with good intentions.

Alts make this very redundant: everybody that wants to go through the trouble can read all the info.

I think it is best to split this from the main discussion about MDscripting. [quote]Kafuuka, you raise a very important point. The cleanup is sorely lacking for both keys and storage. Yes, the empty storage removes itself but things like "tests" with data in them stay behind, I think a storage list which shows the names of your storages would be useful (even if you just get them in an array)[/quote] The problem is simple. Every time a new variable or key is created, it increases the server load a tinsy bit. Memory/harddisk space and possibly processor time are eaten. cpu time? Imagine a query on all keys a player has. I have only one reason I can think of to make such a query, but that is one too many. Quests can be forgotten by players and creators alike, but the server will only delete the keys if the creator asks it. This is also true for scripts themselves. Ideally all creators are excellent, motivated programmers and take the effort necessary to minimize this. In practice most of us are liable to be happy if our scripts work regardless of efficiency. There a couple of guidelines which are valid for every programming language that has to deal with memory: -For every line of code that creates a new variable, there should be a line of code to delete that variable. -Use good names for your variables. Compare 'x143' and 'number_of_attempts'. Both of these guidelines are problematic. Only keys can be named. Quests are often one time only, thus requiring an end key to be stored as long as the quest exists. This implies that cleaning up quest scripts can only be done if you also clean the keys which then become redundant. If your script is spread over a dozen clickies, this isn't fun work and actually a process which can be standardized: if scripts can be labeled, then it becomes a straightforward idea to delete all scripts with the same tag. Deleting the endkeys (and others if necessary) requires a query over all players but is also programmable. Both of these are not doable in MD script afaik, but should be implemented asap to counter bloated code. In one step I would force labeling to be mandatory for scripts and keys. It is more work for Mur now, and more work every time you make a new key/script, but the maintenance will go down a lot.

I haven't yet looked at MDscript, but I did something similar for one of my quests, using php. For MDscript I would do something like: when starting the quest, give the player two new keys [i]Kafuuka_questx_started[/i] and [i]Kafuuka_questx_stage0[/i] whenever players advance the quest, delete the key [i] Kafuuka_questx_stagen[/i] and make a new one [i]Kafuuka_questx_stagen+1[/i] when it is finished, do not make a new stage n+1 key The only checks you need to make are: if the player is at the clicky to start the quest, see if s/he attempted it before. if the player is at the n-th clicky, see if s/he has key n. If there are different routes, you will have to make even longer keynames, eg. [i]Kafuuka_questx_stageA_pathB[/i]. If multiple paths/stages arrive at the same clicky, you'll have to check them one by one. It is impossible to have multiple checks to be true and this won't pose a problem. If you are paranoid and don't want people to guess your keynames, use something like [i]Kafuuka_bananas_questx_stagA_pathB[/i] but change "bananas" into a word that no one will guess. For cleanup there is only one problem: people that got stuck in the quest will have both the [i]Kafuuka_questx_started[/i] and [i]Kafuuka_questx_stagen[/i] key and are trickier to erase when the quest has ended.

[b][center]We, the Jury Members, proudly present you the winners of the second Paper Shaper contest.[/center][/b] [b][size="3"]First place[/size] 179[/b] Xavierson ++ bard songs (important for a bard/violinist) + interesting setup + good writing o clean presentation - distant past; more recent events? [b][size="3"]Second place[/size] 165[/b] Yoshi + Good roleplay + Integration into MD, balanced o simple formatting o story mode is not new, other elements are interesting [b][size="3"]Third place[/size] 160[/b] *Indiria Serenias* + Very emotional + consistent poetry and pictures + interesting story and possibilities - future plans? Congratulations to the winners. Your prices will be distributed asap. People who want to know their scores and the full comments can pm, I will try and answer within 24h. The above comments are only a very short summary. Also note that there is no use in comparing the final scores with previous contest, since we changed the score system a little (this version has a maximum of 260, last one 88). Furthermore I apologize for the delay, we experienced some technical difficulties. Many thanks to our sponsor Grido (and Blackwood Forest), our inspiration Kriskah Arcanu, our fans and all participants! And also my fellow jury members; it has been a lot more chaotic than it should have been, but we got through it Please keep in mind that this thread is meant for victory shouts, not comments on the organisation, use the meta thread for that.