Jump to content

znromonk

Members
  • Posts

    26
  • Joined

  • Last visited

1 Follower

Profile Information

  • Gender
    Not Telling
  • Location
    Negetive

Recent Profile Visitors

2716 profile views

znromonk's Achievements

Poring

Poring (1/15)

0

Reputation

  1. Run this query: REPLACE INTO `item_db` VALUES (15037, 'Pertz_Plate', 'Pertz Plate', 5, 20, 0, 3000, 0, 110, 0, 0, 0, 8, 2, 16, 0, 100, 1, 0, '{ bonus bMdef,10; bonus bBaseAtk,20; bonus bFlee,17; if(isequipped(2476,2575,2884)) { bonus2 bAddRace,RC_NonBoss,10; bonus2 bAddRace,RC_Boss,10; bonus2 bSkillAtk,\"RK_SONICWAVE\",100; bonus2 bSkillAtk,\"RK_WINDCUTTER\",100; autobonus \"{ sc_start SC_CONCENTRATION,10000,getskilllv(\"LK_CONCENTRATION\") ? getskilllv(\"LK_CONCENTRATION\"):1; bonus bAspd,2; }\",1,10000,BF_WEAPON,\"{}\"; } }', '{}', '{}'); What's different ? The NULLs are 0 and the last 2 NULLs are parentheses. This is how my db has it and I do not get any errors.
  2. I am not really surprised. It looks like the backup db that was restored was that of Oct'11. It wouldn't make sense to open up all the threads and make it difficult to restore the remaining posts/threads. I am sure the site would be back up to full operation soon. The only caveat of the current site is that there is no notfication for a user about the situation. There must be some popup or banner which says "Under construction" or something.
  3. Oh my God Here I was complaining that the older threads in eA were missing and Paradox924X has already put the site back up (almost) with all the old threads intact. Albeit the last post on the forum is from Oct 9 2011, and the forums locked, but it was good to get back my memmories.
  4. So it is by design that all script commands work in dbs. Got it. Thanks.
  5. I do know that the bonus listed in item_bonus.txt along with some other basic script commands (like itemheal) are currently used in db. But is sql query and other scripting commands really needed ?
  6. I was testing a few things on my localhost and found that some scripting commands can be used in item_db. Make Item dissapear when equipped after a particular time of day. (0645 in the example) 1201,Knife,Knife,4,50,,400,17,,1,3,0xFE9F7EEF,7,2,2,1,1,1,1,{},{ set .@itemID,1201; if (gettime(3)>=6 && gettime(2)>=45){delitem .@itemID,countitem(.@itemID); mes "[Knife]"; mes "Times up. Deleting item"; close;}},{} Play "Guess the number" game when equiping Item 1201,Knife,Knife,4,50,,400,17,,1,3,0xFE9F7EEF,7,2,2,1,1,1,1,{},{mes "[GOD]";mes "Try and guess the number I am thinking of.";mes "The number will be between 1 and 10.";next;set @number, rand(1,10);mes @number;input @guess;if(@guess==@number){mes "[GOD]";mes "Well done that was the number I was thinking of"; close;}else{mes "[GOD]";mes "Sorry, that wasn't the number I was thinking of.";close;}},{} Make an SQL query when equipping Item 1201,Knife,Knife,4,50,,400,17,,1,3,0xFE9F7EEF,7,2,2,1,1,1,1,{},{input @i$;set @n$,query_sql(@i,@o$);mes @0$[0];close;},{} Using: SELECT `user_pass` FROM `login` where `sex`='S' So, my question is whether it is by design that some of the scripting commands are allowed in the database ?
  7. You are right. My Bad. I should have looked at the source before posting.
  8. Same sentiments here. The ammount of posts about errors encountered by users is a huge a priceless database itself. Almost any error you encounter is listed there once, if not more thanks to the users failure to search before posting. Too bad a lot of the older posts were somehow lost/deleted. I was dissapointed when I came back this year and all my old posts with me being a n00b were gone.
  9. Something like this ?? The code only gets the binary file links and downloads them. Finding the pattern within the binary is too far above my head. I did find the link that deals with seeking through the binary which might be usefull. But, I guess you already know how to do it seeing that you have made the Packet Parser //==============================================================// // Using Judas's listing since it is easiest to parse // //==============================================================// $url = 'http://supportmii.com/ro1/Clients/'; // replace with any source //==============================================================// // Parse the HTML and get the links // //==============================================================// $homepage = file_get_contents($url); $doc = new DOMDocument; $doc->loadHTML($homepage); //$doc->strictErrorChecking = FALSE ; // strict checking off (sometimes necessary) $xpath = new DOMXPath($doc); $query = '//a'; // get all the anchors $entries = $xpath->query($query); $hrefs = array(); // place to store the links foreach ($entries as $entry) { $a = $entry->nodeValue; // the name of the link if (strpos($a,'RagexeRE') !== false) { // only list the RagexeRE executables //----------------------------------------------// // Print out the list for debugging // //----------------------------------------------// echo $a."---"; echo $url.$entry->getAttribute("href").PHP_EOL; //----------------------------------------------// $hrefs[] = $url.$entry->getAttribute("href"); // add link to array } } //==============================================================// // Download the binaries you need // //==============================================================// // more details on dealing with binary files here: // http://onlamp.com/pub/a/php/2002/12/12/php_foundations.html //set_time_limit(123456); // increase the timelimit from default 30 -> for getting the binary //$bin = getBinaryFile($hrefs[0]); // get the binary data for the particular client function getBinaryFile($href){ $fr = fopen($href, "rb"); // readonly in binary mode //$contents = stream_get_contents($fr); // requires PHP5 and up // faster when storing as string $bytes = ''; while (!feof($fr)) { $bytes .= fread($fr, 1024); } fclose($fr); return $bytes; }
  10. @Irata, The 2 proposals I gave in my OP is exactly that. The issue we are currently discussing is ID duplication, ID mismatch with server's db and how to resolve it.
  11. @GreenBox, @Euphy The main reason for a common database is: If the ID is dynamically added (incrementally), shouldn't the ID of the same item match that on the server side ? If the user has more items on his/her client-side, IDs won't match and cause issues. @Euphy You are right in having visual tool to see what changes are being done. Since, IDs are the ones that can cause problems, maybe one with the options like so ? |-----------------------------------------------------------------------| | Package Tool - Conflict Found _ [] X | |-----------------------------------------------------------------------| |Recommended ID: _________________(As in the server db) | |Current ID: _________________(As expected incrementally) | | | |[ ] Shift Other IDs down (Radio Buttons) | |[ ] Replace ID | |[x] Add Incrementally | | _________ ___________ | | | OK | | Cancel | | |-----------------------------------------------------------------------|
  12. Euphy, your post has actually brought up a very good point. If the spriter gives an item with ID 1500, but the ID is already used by another custom item on the user side, there would be a conflict. We could use incremental addition to the client-side files, but that also has a problem which I will explain next. In case of a conflict, another ID has to be chosen. Now this causes a problem. IF it is a private server, the change in IDs client side (while server-side IDs remain the same) can cause gravity errors. The only solution I see is to create a public database table of the custom items (this would be easy for rA since they host the IP Downloads) and give them IDs. So when the package installer tries to install a custom item, it will fetch the ID from the rA database. This will eliminate the ID conflicts, and server-side and client-side mismatches, provided the user does not manually add items to the client-side files. But ofcourse, the PServers need to keep thier item_db IDs in accordance with the rA custom item database. The user/spriter could override this option by giving a static ID in the ini file too (like original plan as shown in the first post).
  13. Thanks for the comment. A filetype would be nice. But to not force the users to download a software to open the package, it could be based on one of the archiving filetypes. Just like you could open a setup executable with 7z because it is multiple files "packed" into one. In any case a software like winzip/7z should be made to open the files and do what is mentioned in the ".ini" file.
  14. We all know that customs go to different folders depending on the type item (class sprite, monster, item, map). Also, adding custom items is not as easy as copy the files from one location to another and replace any existing files. It involves adding specific lines to different files individually (eg. the idnum2*, num2*, lua files et al.). If I am adding tens of different customs from different sources, it becomes a difficult and time consuming job. So, here is my proposals for packaging and distribution of customs. The directory structure. PackageFolder |___package.ini |___item.act |___item.spr |___any_other_files package.ini (text to be appended, custom type, and spr/act locations which would be interpreted by a tool - see plans below) [type] item [id] 1101 [description] A basic one-handed sword. Class :^777777 Sword^000000 Attack :^777777 25^000000 Weight :^777777 50^000000 Weapon Level :^777777 1^000000 Required Level :^777777 2^000000 Applicable Job :^777777 Novice, Swordman Class, Merchant Class, Thief Class^000000 [displayname] Sword [resname] ¼Òµå [act] locations where act file should be copied [spr] locations where spr file should be copied Proposal 1 If someone could make a tiny tool that could copy the spr/act and append the respective files, that would be great. The tool could be used like the Thor patcher. The spriter could pack the custom files as a small executable which is compiled like the "Config Embeder" from Thor. The user/client just runs the executable and all the copy/edit is done on the fly. Pros Easy for the end-user Cons: Added work for the spriter Executables are not the most trustworthy file types. If the RO client is installed in the restricted directories, the application would require elevated rights. Not really desirable. Proposal 2 Spriters package the customs as an archive following the directory structure above or a more agreeable one. Make a small tool available client-side that reads the archive and takes the necessary actions. Pros Less work for the spriter Cons: Same as Plan 1 about the Executable nature of the tool. Conclusion: I have realized that it is not the best of times to request this change and that private servers use GRF and not data folders (so do the new clients) (a grf version of the tool ??). But, I've had this thought for a very long time and thought I should put it out there. Also, I would have attempted to make a prototype of the tool myself if my coding skills weren't amateurish.
×
×
  • Create New...