Jump to content

Rendril

Member
  • Content Count

    612
  • Joined

  • Last visited

  • Days Won

    11

Everything posted by Rendril

  1. I hope you don't plan on writing the uppercase alphabet into the content section...
  2. 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 a
  3. My entire notebook was erased as well. I think it happened when it was given the upgrade to have a reward codes section.
  4. 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?
  5. 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.
  6. Added, that was sorely missing
  7. 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...
  8. 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.
  9. [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] Sec
  10. 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 "s
  11. 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.
  12. [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 th
  13. Use only 1 button and 1 if() statement. Chewett posted about this in the Form! topic.
  14. Tell me if we found a sufficient workaround for what you needed. I will not post it here due to heavy exploitability.
  15. [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
  16. 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?
  17. 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.
  18. 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
  19. 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
  20. 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.
  21. 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]
  22. [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
  23. 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
  24. 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.
  25. I wish I could have devoted more time to this quest. Can you tell me what my final score was?
×
×
  • Create New...