Rendril

I think there was a post somewhere about this already. My notebook was also erased, around the time the "reward codes" section was added.

I think Real Life is a game by the same people who made "Sleep".

Some people are soulbound, it makes sense to me that they might share eachother's cubes. Shadowseeker, I think your idea is a good alt-combat mechanism. Show and record whose cubes your cube is comprised of, similarly to how WP's show who gave them. The issue that still presents itself is the incredible influx of cubes for each new player. Is it a problem that every player might have a cube item?

Would cubes have great value or be almost worthless? [quote name='Muratus del Mur' date='15 November 2009 - 03:07 AM' timestamp='1258247237' post='47494'] Issues that slow me down: - what happens on the long run, 50k players means 50k new items, cube (as trade item) infaltion will be hight. - what happens at mp4, mp5, will get an other cube, of course not, then how will it go. - what will be the rewuirements and tasks to activate the cube to continue story mode. I am thinking of making it a puzzle based on the awsome device shadowseeker sent me [/quote] Quite a few things spring to mind: -Make them untradeable -Getting another cube simply merges it into/replaces your current one Alternatively: -A player can assemble bigger cubes to perform some cool ability...maybe start with 9[sup]0[/sup], then 9[sup]1[/sup], 9[sup]2[/sup]...etc -Allow a player to collect cubes and they can "relive" their story mode, see the other persons, or unlock new story paths? Giving cubes value would lead to farming alts for accumulating cubes and a newbie could easily be ripped off for their cube. But since the is that person's specific cube, it could have value only for them while none to others. Equipment cannot be traded, and if it could it would only have limited value to those unable to get some piece of gear for lack of VP (apart from some equipment that isn't available, but there isn't enoguh of that for every one ) It only really holds value for the the person who buys it, maybe something similar could be done?

Most of the empty items are not even seen because the requirements are not met by the viewer (usually a password input) In most cases it is because of the recent update which ended up clearing out many clickable, while someone where never whole to begin with. Filtering might work to a certain extent, such as if the script is more than 6 months old, but as Kafuuka said, it boils down to the human element to control it. What about this as a remedy: Rather than deleting the script, it becomes public domain. Lets say after some length of time, if the script is not password activated or hasn't been edited (in the case of passwordless scripts) then it is able to be edited by a third party, who will then gain "onwership" of it. Or perhaps, a script maker can allow who would be given editing rights to their script, or to change the ownership themselves. Regardless, something I feel would be very useful is a centralised location that lists what script you have running (would also like this for storages) You might forget about that shorter twig, in the bushes behind third maple tree that you edited a month ago to perform a test, of give an alternate quest route but the quest is now over etc. This would serve as a good management system.

Have you tried seeing if it happens with different resolutions? I hae always noticed it on the arrows at the Splitted Pass Halt, they almost look as if they move forward. Perhaps and intended effect. I'm guessing it's just a scaling or recolouring mistakes.

Thank you to all. Friday the 13th and it's a long day ahead

A note on reseting the array, you could use: [code] if(@va == null) @va = array(); [/code] Though in reality it will never need to be executed more than once. This part[code] foreach(@va as @vk => @vv) { echo "<br> @vv";//VN: @vk => [/code] Is getting executed regardless of whether there is a key held or not, you can put it after the if-statement.

Now that I think about it, you could juse a single content section to store the whole upprcase alphabet and use the string content as the array of characters it is. ie: [code]echo @content[0][1];[/code] If you really feel like it, make an assocative array so you can call it by @va['a'] Anyway, I find it easiest to use chr()

Lower casing the script provided better security the way the protection worked before. Right now it has very little security effect because of everything being blocked anyway. And Cutler, isn't kludging workarounds the best part of coding

[quote name='Chewett' date='09 November 2009 - 01:04 AM' timestamp='1257721452' post='47011'] Now the code works, thanks all the people who DIDNT! test the code i managed to get access to debug it all [/quote] I have enough faith in you to not need ot test the code

I don't think that would work, since there are line breaks

It might be related to the login anomaly. A byproduct of the new encoding?

I hope you don't plan on writing the uppercase alphabet into the content section...

It's a security precaution that unforunately forces the script to be lower-cased. There are simple workarounds you can do, and the best one I suggest is jsut rename the Loader2.html Anyway, you can get around the lower-casing in many ways. chr() Will output a capital letter given the right code. You could use strtoupper() Or write yoru own function to make it shorter [code]function u(@temp){ (prepare function) return strtoupper(@temp); }[/code] That way you call upper case just by using u() In the extreme cases use chr(int - 32), though it would be less portable. And another extreme example is seperate the content sections into letters, and call the url as [code] @temp = '<a href="http://www.the-cript.com/cutler/' . @content[1] . 'oader2.htm">' . @content[2] . 'uzzle ' . @content[3] .'rcade 1</a>'; [/code] Don't do the above example if you value your [color="#FFFFFF"]in[/color]sanity

My entire notebook was erased as well. I think it happened when it was given the upgrade to have a reward codes section.

I did a complete overhaul for the battle archiving. It should now be using less than a tenth of the size. Rolling log and flash is back up, and the full log displays when viewing combat results. It is still located at the rope in the Paper Cabin and signpost in front of the Labyrinth. Are there other suggestions for where to put it? If not, I will place it at the signpost in the Marble Dale Park once completed. It will likely run into a memory issue once too many fights are uploaded, I'm working on restructuring the storages now. Any ideas for better menu layout/access?

I found out yesterday that the storages have their functionality done. Tested with aoau and aotu. Here is how to use it [code] //give @vs the storage's ID @vs = mds_storage("storage_name", "storage_type"); //to save @storage[@vs] = array("data", "that", "I", "am", "storing"); //to load @va = @storage[@vs]; [/code] You do not need to call any save routines, the MD Script will do it for you. The descriptions in the manual are obsolete and need to be changed, but you can refer to them for the storage types avaiable.

Added, that was sorely missing

I think it's generous to assume it happening once or twice day. Now that I think about it, it will be much more than 30k rows. Each player has their own multitude of keys, I would guess no less than 5 at least, maybe 10 or more. Imagine a table of 300k records...

Due to memory limitations and the size of the battles, I have had to remove the flash and rolling log for now. It will still be displaying the full logs. I plan for the final version to include the flash and rolling log, please bear with me until I restructure the storage.

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