Rendril

[quote name='Kafuuka' date='04 November 2009 - 09:31 PM' timestamp='1257363060' post='46628'] We do? I never accepted that. And estimates about cost are quite depending on how efficient MD code is. [/quote] 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 name='Kafuuka' date='04 November 2009 - 09:31 PM' timestamp='1257363060' post='46628'] 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. [/quote] Seconded.

This feature will allow you to "publish" your battles for others to view. Advantages having this: -Allows you to show proof of battles rather than sending mails which can be forged -Players can learn from watching battles -It allows you to archive a battle replay which would normally be erased by the next day -The full battlelog is provided There has a been a concern brought up that it could be a slight spoiler. I do not consider it a spoiler, if an MP3 attacks another MP3 with a rustgold, it is not exactly a spoiler. I feel this provides a learning mechanism instead. If it is too "spoilery" I can implement checks on certain creatures and exp/MP-levels. I have placed a live version of this in the rope at the paper cabin and at the signpost and in the labyrinth entrance. Post your suggestions for where it should be located in the event that it is implemented. There has been a suggestion to but it in the signpost at the Marble Dale Park, this seems a good palce to me due to the proximaty of the Sparring Grounds. The viewer is still in testing, and more features are to come. It will currently limit you to archiving only 1 battle. There will likely be bugs, please tell me about any you find. Planned additions: -Checkbox to choose whether to have the battle publically viewable or only to you -Archive limit of probably 3 or 5 battles -Removal of an uploaded battle -Renaming the battle (could be a problem in case someone posts foul language) -Removing the names of the participants Many players expressed their desire for such a feature, please tell me your thoughts.

There was a bug that let you gain principles you didn't have (yes so you could get all 10) It should now be fixed but apparently there are archers who cannot target. Please rememeber this is a test, do not start panicing about your archers having changed, there is no statement that this will be their final form.

[quote name='No one' date='03 November 2009 - 06:27 PM' timestamp='1257265621' post='46515'] Ok, tell me this: when you do the "retrieve(@vk);", you are getting the "values / user" or "values / script owner" ? [/quote] I depends on what you are storing. Other editors do not have acess to your storage, you can even name them the same. [quote name='No one' date='03 November 2009 - 06:27 PM' timestamp='1257265621' post='46515'] I just thought of this: If there is already a function that checks the keys, then ... it can be done without too much problems to first check the initial way then to check in the tables. That way, if the new way is better it can replace completely the old method without crushing the system [/quote] Exactly, lets hope there is only one function [quote name='No one' date='03 November 2009 - 06:27 PM' timestamp='1257265621' post='46515'] aaa ... aaaa, i guess so The reason that I put 2 table is to try to remove the redundancies. If there are 2 identical keys ... it will save space, if all the keys are different ... it will lose space. As for 2 different tables ... well ... consider that actually there is an "n-n" relation between user and key. And that relation is done through the 3rd table : "user_keys". Another reason for using tables ... it can speed up the search for keys, it will allow listing of keys / user or keys / owner or the other way around ( user / keys ). As for space saved ... consider this : all armor, all WPShop, all MDShop as keys, lets say 200 items 200 * 20 chars average = 4000bytes for each player , but all these keys are stored once, after that , each one will only this : (uid, key_id, last_access_timestamp, system_key_flag) and all these columns only if you want to implement new functionality. Also consider the new functionality that are opened with this approach, not only the space occupied. [/quote] Duplicate keys are not allowed, that is why they are stored in an associative array to begin iwith. I see what you mean for the extra table with the compound key. 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. 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.

Use only 1 button and 1 if() statement. Chewett posted about this in the Form! topic.

Tell me if we found a sufficient workaround for what you needed. I will not post it here due to heavy exploitability.

[quote name='Kafuuka' date='03 November 2009 - 12:48 PM' timestamp='1257245289' post='46481'] 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. [/quote] I suspect there is a single function for it, but each scene could be checking for a key in its specific way. I am not saying this is what it does, just a possibility. I genuinely hope it is being checked in the preloader queries. [quote name='No one' date='03 November 2009 - 01:41 PM' timestamp='1257248465' post='46485'] OK, give me an example of the storage thing. Remember, i want a storage across clickables, across "players that click on clickables". Other problems would be : - what about the "noob scripters" giving keys before learning to delete them. - how can you make this storage protected from others ? [/quote] As far as I know, the cross-user storages are not finished yet. Here is an example that uses all object, this user. If you want it with all users, you will have to manage the user id's manually, it might be easier with just the ucrrent methods. [code] //get the stored "keys" retrieve(@vk); //make a new blank array if it doens't already exist if(@vk == null) @vk = array(); //giving the user a "key" @vk[] = "my-key-name"; //checking if user has the "key" if(in_array("my-key-name", @vk)) echo "you have the key!"; //save the "keys" back in storage store(@vk); [/code] [quote name='No one' date='03 November 2009 - 01:41 PM' timestamp='1257248465' post='46485'] considering that a tables can be created I suggest a structure like user_keys (uid, key_id, last_access_timestamp, system_key_flag) indexes : -> (uid, key_id) -> unique -> (key_id, uid) -> to have double access to keys, starting from user and from key Even if the "system_key_flag" will be redundant, it will help the purge. "last_access_timestamp" is there specially for purge but it can be also be available as read-only value so that we know when it was given. keys (key_id, owner_id, key_name, timestamp) indexes : -> (key_id) for unique column & fast access on values -> (owner_id, key_name) for fast list / filter of keys by owner & uniq values -> (timestamp) to make a cleanup of a table that will reach a few millions or records [/quote] [quote name='No one' date='03 November 2009 - 01:41 PM' timestamp='1257248465' post='46485'] Rendril: nobody said that it will be easy, but what do you suggest ? keeping track of the keys it is a huge task that could require huge resources. And ... when do you think that the array is too big ? It already has 1k for each player (as you state) and most of if from names of keys instead of ids (redundancy). Not to mention that some of them were introduced by hand, witch mean that there are mistakes. [/quote] I suggest the same method that you and Kafuuka are advocating. However, unless you can show a huge difference in costs I do not think it will be done. [quote name='No one' date='03 November 2009 - 01:41 PM' timestamp='1257248465' post='46485'] Remeber that the MDStore and WPStore both could be changed to keys, along with a lot more features. Also, for programming part ... the migration to separate table can be prepared by creating functions that check for keys. So, changing the function will have an effect on ALL locations where keys are stored. [/quote] I believe the MDStore and WPStore already work on keys. We are assuming there is a global key-checking function. If there is, great. If not, it means a massive game overhaul. [quote name='No one' date='03 November 2009 - 01:41 PM' timestamp='1257248465' post='46485'] So ? it will take some time, but it should be changed. Fixing keys took a lot of time, why would "takes a lot of time" mean "not to be done" ? [/quote] That's not what I meant, I'm saying the tradeoff isn't good enough. Please correct me if I am wrong in this estimation: Most key lengths will not exceed 30 characters nor will they fall below 10 characters (taking prefix length into account) so we have an average of about 20 characters for a key, that means 20 bytes. In the current method that means it is storing twice that due to the asoicative indexing, thus 40 bytes. Can you explain why you gave 2 tables? I'm not sure why both are needed. The way I see it these are the fields that would be needed: key_id (long - 4 bytes) user_id (long - 4 bytes) editor_id (long - 4 bytes) key_name (string - 20 bytes average from above) last_access_timestamp (long - 4 bytes ) system_key_flag (boolean - 1 bit) Usage per row = 36 bytes (I hve omitted the 1-bit boolean) So, 40 bytes compared to 36 bytes. This is a pretty big increase, 10% is no small matter. In 1mb of keys we save 100kb. But this is without taking into consideration the MySQL overhead, which does not come cheaply. MySQL does its own indexing and storing of additional metadata tables for faster querying. This alone makes the table method cost more than the redundant key sotrage. Correct me if I am wrong, but I think additional tables and indexing take much more than the 4 bytes saved. Please don't misunderstand. I am in favour of the method you suggest. I just haven't seen sufficient cause to warrant a massive migration. If you can provide conclusive reasoning for how it is remarkably better, we can take it to Mur.

It shows the outcome of the battle. In your case you recieved 137.8 VP and 0.106 energetic immunity. This isn't related to the MD Script, can someone move it to the appropriate section?

It goes beyond clickables. The scenes themselves are affected by keys. If you have the key for Golemus, you can use the gate to get in. The key for Loreroot is what makes sure the guards are not there. I think that being out of tutorial mode is managed by a key too.

What about the concatentaion that I use in all the sample scripts with keys? I have no intention of typing out the prefix all the time, especailly if it can change at the drop of a hat

Deleting all keys K requires an exhaustive search of the player table to find exactly who has the keys. Granted, it would be done infrequently but it's still a big process. How would you search for the has_keys() function in the script? Using a regex? If so what would your delimiters be? The only guarenteed ending bracket you can take is ") or '), there are a multitude of function calls that end in the same way. Tell me if you have some other idea in mind. The possibilty of a player opening a clickable set for deletion is there, but from what I understand there would be no script for the input wto be sent to, they would jsut get an error message or something saying it expired. It shouldn't be anything to worry about.

It's not a simple case of just adding a table for them. As I addressed earlier, in the worst case it means every scene in MD needs ot be edited. While I doubt this will be the case, it is still a big change. If there is enough of an outcry for a dedicated key table, Mur might make one. I am not convinced of a table being needed for this, the solutions cost as much as the leakage if not more. The best is perhaps the multidimensional array with ID integer stored alongside it's key name string sibling.

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? At least we adhere to mutual exclusion when dual-threading [color="#FFFFFF"]Those of us who get this joke need help[/color]

[quote name='Kafuuka' date='02 November 2009 - 07:23 PM' timestamp='1257182610' post='46414'] 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] Each clickable being accessed would needs its own copy of the array. It means every load would have to regenerate the same array. PHP has a way of making globally available variables but I don't think in the way we need it. [quote name='Kafuuka' date='02 November 2009 - 07:23 PM' timestamp='1257182610' post='46414'] 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] This is could be done. In the clickable access it performs an extra SELECT to pick up what players hold the key. But what keys would be selected, all those created by the edior? How would cross-item key sharing be done? [quote name='Kafuuka' date='02 November 2009 - 07:23 PM' timestamp='1257182610' post='46414'] 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. [/quote] That is the problem, there is [b]no key table[/b]. Keys are stored as a serialized array in the player table.

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

Storing an integer identifer is not the problem (well, it's a rather small one comparitively) The problem in my view coems from trying to select keys held by other plqyers, not the one accessing the item. I don't know MySQL's performance ranges on the tables but I am fairly certain that scanning 30k+ records, multiple times, will not be cheap.

I wish I could have devoted more time to this quest. Can you tell me what my final score was?

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.

I agree, it is not satifactory. But the solutions proposed are as expensive as the extra keys, if not moreso.

An excellent outline, you beat me to it again Form validation is of great importantance, never assume that the user gave correct input.

I posted elsewhere abotu the way the keys get stored. I do not think storing the editor info is a feasible solution right now. In concept it is simple enough: Take the one-dimensional array and convert it into a two-dimensional array of depth 2 or more. But there are 32k living accoutns on the server. To go through the entire player database and restructure the key settings would take a substantial amount of time. Remember the time it took just to delete the inactive accounts? But now, what if something goes wrong? What if the array conversion algorithm hits a snag on an unexpected key input? Easily avoidable perhaps but it adds tiem to the conversion. Now once the keys have been completely restructured what happens to the keys that already exist, who will be the editor? Not the player-defined keys but the keys which let you move around MD. I suspect Mur created a global has_key function on the locations but is he didn't, every item would have to be redone. That means access to Loreroot main entrance, the hidden entrance (again), Sage's Keep, exit from tutorial mode to name but a few. My suggestion is to prefix the editor name/id to the key server-side thereby killing 2 birds with one stone, no need to self prefix your keys (although it would still be advised) and it allows an editor to search for the keys he created. You will however lose cross-key sharing. To rememdy this, there can be a decided shared key function which reuqests the sharer ID as a parameter. --- There will not be an option to select ALL keys you have given because of the way the clickables work. They can only manipulate the keys of the player accessing them at the specific time. If you are very interested in having such a list, make one yourself and keep it in a storage. What many are not considering is that the storage can perform the same function as the keys, in fact I don't think we really need keys because the storange can handle it all. RJ, there is still such a function, have a look at the manual for [url="http://magicduel.invisionzone.com/topic/5498-key-control/"]key control[/url] The fucntion you are refering to is mds_has_rpcq_keys()

Form text box can easily be done, you can use anything HTML has. I'll post an example using both <textarea> , <select> and maybe radio/checkbox. The thing to be careful of when accepting user-typed input is that it is safe for consumption, don't assume the user sent it correctly. Another note, allow a certain level of tolerance for the input, not all will make it the exact format you want and speaking from my own experience, I make typos on a constant basis. Once the button is pressed and the script loads again, it will have done so with the key in the user's possesion. For a simple text input try using just that [code] <input type="text" name="answer" /> [/code]

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.

The keys are stored an a serialized array, the structure cannot be changed easily. It affects every location you can access. As I said, there is no "creator" stored for a key. While a good idea it is not an easy task ot implement. You would also be charging an additional overhead on the server of now storing 2 values for every key, effectively doubling the key-use anyway. Maybe a simple solution is to append the editor ID and if desired, an expiration date for a key.

[quote name='Chewett' date='01 November 2009 - 05:33 PM' timestamp='1257089639' post='46296'] so this will remove what key? all keys of that name? from everyone? [/quote] There are no "all keys of that name", you can only have one instance of a specific key, addign more of the same name does nothing (it overwrites it thus eliminating duplicates) And only the person accessing the clickable can have keys removed or given. [quote name='Udgard' date='01 November 2009 - 05:46 PM' timestamp='1257090383' post='46297'] Yes chew. And rendril, I think no one means, can we remove keys without needing the player to go to a clickable where we store the key taking script. If they need to go to a certain place where we store the script to take keys, then it will take extra work to tell them to go there. While taking keys can be done for those who finished the quest by just adding the script there, key cleanup for those who never finished it will be a bit problematic.. [/quote] The player must be there in order for their keys to be accessed, that is why there is no ID parameter for the key functions. You do not need a dedicated clickable for them to go to simply to cleanup keys, just implement it in the last leg fo your quest. As for people who do not finish the quest, you are correct, there is no way to guaretntee that the keys will be remvoed at present. For example, they might never return, or might not do a quest of yours again, and even if they did you would have to remember to remove very ancient keys...