Lemongrass

You are partially right. The in memory implementation would have to be implemented session bound, which means, when the player drops a item it is stored with a UID in his session, if he quits the game, his session would get saved and all UIDs that have not been logged yet would be sent to the database. As for the server crash, since a server crash also does not save the session, the inventory will be like he never dropped the item and therefore, no log would be needed. And yeah basically it is a combination of the ideas.

I agree that this would be a lot better with a receiver getting logged. But to your solution I would say, that this should happen in rAthena in an in memory process. Since the dropped items will not be stored as dropped if the char/map server does not save the user's session this should not be a problem. So I would say leave it for the 10 seconds or whatever the disappearance time of an item is in the memory, like you said with creating a UID for this and after it got picked up store it into the logs, because at this moment you can already tell which case happened and only run one query for it. That would also solve your server start problem which is far more complex than you stated, because you would also have to revert the step that was done to the user's inventory etc.

I know this one comes late, but I do not really get why we need this... If you want to look up where a certain item has gone just walk through the itemlog. I did this very often for some stolen items, but I did not care if it was exactly the same item like the one that was stolen I just looked it up via account and item ID. I do not really care if the card I gave back to the original owner had been dropped by a monster he killed or something like that. I think it would be a nicer way solving such issues by putting more information about the items that are traded/dropped into the item log if there really is a problem, but I think every information is already in there, correct me if I am wrong. That does not consume as much performance and is not as complicated as the current solution... The only important things for such cases in the logs would be: Item dropped Item dropped by looting type monster Item traded Item sold through shop Item sold through auction Item sent through mail Item stored into guild storage With this information you can find everything with the item log without needing some UID. The problem is that if we implement UIDs to prevent item duplications is that it costs a lot of performance and that rAthena might miss out some bugs that will stay in the code until someone fixes them without knowing or by accident. I think that this is not a good solution either.

File Name: Ragnarok Violet Content File Submitter: Lemongrass File Submitted: 25 Nov 2012 File Category: Conversions Content Author: Lemongrass, Gravity This upload contains the unpacked content of the game Ragnarok Violet for iOS. I unpacked those files by myself but I do not own any copyright or anything for them. The copyrights, if there are any, are owned by Gravity. Click here to download this file

your system does not support jOGL or the drivers are not in the java classpath.

I would change the console output from: if (char_per_account == 0) { ShowStatus("Characters per Account: 'Unlimited'.\n"); } else { ShowStatus("Characters per Account: '%d'.\n", char_per_account); } to this: if( char_per_account == 0 ){ char_per_account = MAX_CHARS; } ShowStatus( "Characters per Account: '%d'.\n", char_per_account ); Since the word "unlimited" could be missleading for some users.

As you might be able to read from your console output, Brow Edit 2.0 is not yet supporting GRF version lower than 2.

both using the same base and job level, not to mention skills?

SELECT atcommandlog.atcommand_date, atcommandlog.atcommand_id, atcommandlog.account_id, atcommandlog.char_id, atcommandlog.char_name, atcommandlog.command, atcommandlog.map FROM atcommandlog LEFT JOIN login ON( atcommandlog.account_id = login.account_id ) WHERE login.group_id > '<insert group id here>'; Should solve your problem.

I know that it differs from compiler to compiler and architecture to architecture. It was not ment to be a flame post, but rather to somehow mention it. I know it is a trunk branch and it is no problem for small bugs or mistakes to be in there. I do think that the team does an excellent job, I just wanted to point out, that lately those commits are getting more frequent and for the developers to maybe have a closer look again before hitting the commit button. I also know that if you do a commit, you can miss out some of the lines or files that have been changed, but as I said it is not really the point of the topic, it was only to mention it. So please do not bother with it anyways and do not see it as a flame post. As stated above I am also very impressed about the development team doing their job. And since you pointed out that they are on a really high level of professionalism already, it is very difficult to get their level even higher. I know that you want to get rid of the whole PRE-RE branch, but that would mean a loss of a lot of users and with them a whole load of test persons and servers that use rAthena and I think that this would not really benefit rAthena or their developers at all. Yes I do have scripted some things and I also know that mistakes can happen easily and I did not mean to offend neither the team nor you with my post. It is something I just wanted to mention, because just like you I think that rAthena is currently on a high level of professionalism and these commits are something that damages this reputation. I know that there can be mistakes and I do not want to blame them for anything at all, it is just my personal opinion since I am also working on this kind of jobs in real life. So I am sorry if I offended the rAthena development team or you, I did not mean to.

And although it is so simple we have dozens of threads that hold questions about these easy steps. For me it is an easy task too, I do get your point, but it is not so easy to understand for everyone. And what I wrote in my last post in nothing else than the standard stable branch for projects(trunk/stable+additional branches), that is nothing special or something I came up with. It is a standard way of handling such projects. And because you said they have to test it for PRE-RE and RE, from what I can see at the changelog not everyone of the developers test their sources and/or read compiler warnings and such things. I came across a lot of "woops missed something" commits since the beginning of rAthena. I know that such things can happen, but they are becoming more frequently lately. Anyhow it was only a suggestion and if the community and/or the development team does not like the idea, they do not have to implement it. Best regards, Lemongrass

I would suggest to create a certain branch for PRE-RE and to tell the users to use that one for PRE-RE features and to only update it once or twice a month or if some huge and important updates are done. That would clean up the sources and database files a lot and it would make it also easier for the PRE-RE server owners, because they would not have to do a lot of settings for the renewal features like it is now.

Ich hoff mal, das war jetzt nicht auf mich bezogen, denn ich kann keine Konkurrenz klein halten wollen, da ich keinen Server hoste. Wie auch immer, ich habe lediglich gesagt, dass ich gegen einen puren deutschsprachigen rAthena SVN bin, um das vielleicht auch klar zu stellen, ich würde auch mit helfen, falls einer zu Stande käme, nur macht ein bilingualer SVN für mich keinen Sinn, sondern diese Übersetzerei würde erst dann Sinn machen, wenn die ganze Community in allen vorhandenen Sprachen teilnehmen würde.

*bump for the weekend*

So as you might have noticed, I have posted a problem with the documentation of the map cache format yesterday. http://rathena.org/board/tracker/issue-6860-map-cachetxt/ So it was not a real problem for me, but right now I have got a real weird logical issue. I looked through the whole source and debugged a lot of it, but I do not really get, why the map cache is read correctly, although the standard supplied map cache is in a different format. What am I talking about? I tried reading the map cache the way the source does and I ran from one problem into another. The way rAthena source reads the map cache is exactly as documented(since todays bugfix): uint32 file size uint16 map count [map count times]{ char [12] map name uint16 map width uint16 map height uint32 compressed data size byte [compressed data size] data } Well besides the documentation issue, that I will report after this topic is solved, which is again: struct map_cache_map_info { char name[MAP_NAME_LENGTH]; int16 xs; int16 ys; [color=#ff0000] int32 len;[/color] }; vs But anyway. My real problem is as follows: If you view the map cache with a Hexeditor you can see almost clearly that the structure of the file cannot fit to this description and not even to the source with which it is read! I found out that the structure has to be like this: uint32 file size uint32 map count [map count times]{ char [12] map name uint16 map width uint16 map height uint32 compressed data size byte [compressed data size] data } Otherwise you will not be able to read the file correctly, not even the first map("alb_ship"). So how is it possible that the source can read it, even if it is in a wrong format?

Hast du auch das "configure" Skript schon ausgeführt?

Nein eher ein Problem von Grundverständnis. .bat sind Shellskripts für Windows .sh sind Shellskripts für Linux Putty ist ein Client mit dem man sich von Windows auf Linux verbinden kann Alles in allem, du startest ein Windows Skript auf einem Linux System, was nicht funktionieren kann.

As in one of the latest revisions a TXT file for the level penalties was added and this is basically a renewal functionality as also mentioned inside this file, I would suggest to move it into /db/re/. I know that this feature could also be a benefit for non renewal servers, but the internal organization should be clearly structured. Thanks for your attention.

Richtig. Lässt sich auch bis zu 127 oder so mit Beistrichen fortführen. Wichtig ist, dass immer die Anzahl der IDs und die Anzahl der benötigten Menge gleich groß sein sollte. Sprich wenn du ein weiteres benötigtes Item einträgst, solltest du auch die benötigte Menge dafür eintragen.

Hier hast du ein 0815 Skript von mir. Ist ungetestet und ich hab seit Jahren nichts mehr geskriptet, also bitte bei Fehlern einfach Bescheid sagen. dragonia,37,43,0 script Cowgirl 123,{ // Beim ersten Anreden if( cowboy_quest == 0 ){ mes .name$; mes "Hallo Reisender, ich stelle Cowboy Hats her."; next; mes .name$; mes "Welche Farbe hättest du gerne?"; set cowboy_quest, select( .menu$ ); next; } switch( cowboy_quest ){ case 1: setarray .@needed_ids[0], id1, id2; setarray .@needed_amounts[0], anz1, anz2; break; case 2: setarray .@needed_ids[0], id1, id2; setarray .@needed_amounts[0], anz1, anz2; break; case 3: setarray .@needed_ids[0], id1, id2; setarray .@needed_amounts[0], anz1, anz2; break; case 4: setarray .@needed_ids[0], id1, id2; setarray .@needed_amounts[0], anz1, anz2; break; case 5: setarray .@needed_ids[0], id1, id2; setarray .@needed_amounts[0], anz1, anz2; break; case 6: setarray .@needed_ids[0], id1, id2; setarray .@needed_amounts[0], anz1, anz2; break; } mes .name$; mes "Ich brauche folgende Items:"; mes""; for( set .@i, 0; .@i < getarraysize( .@needed_ids ) ; set .@i, .@i + 1 ){ mes "^ff0000" + .@needed_amounts[.@i] + "^000000x " + getitemname( .@needed_ids[.@i] ); } next; mes .name$; mes "Mal sehen ob du alle Items hast die ich benötige."; next; mes .name$; for( set .@i, 0; .@i < getarraysize( .@needed_ids ) ; set .@i, .@i + 1 ){ if( countitem( .@needed_ids[.@i] ) < .@needed_amounts[.@i] ){ mes "Du hast nicht genug " + getitemname( .@needed_ids[.@i] ) + "s."; mes "Komm wieder wenn du alle Items hast."; close; } } mes "Wunderbar, möchtest du deinen " + getitemname( .cowboy_hats[cowboy_quest] ) + " jetzt mixen?"; next; mes .name$; if( select( "Ja:Nein" ) == 1 ){ mes "Wunderbar, dann lege ich gleich los..."; next; mes .name$; mes "Hier hast du dein Item, bis bald."; for( set .@i, 0; .@i < getarraysize( .@needed_ids ) ; set .@i, .@i + 1 ){ delitem .@needed_ids[.@i], .@needed_amounts[.@i]; } getitem .cowboy_hats[cowboy_quest], 1; // Wenn man nun wieder mixxen können soll, die nächste Zeile freischalten // set cowboy_quest, 0; close; }else{ mes "Komm wieder wenn du es dir anders überlegt hast."; close; } // Initialisierung des NPCs beim Mapserverstart/NPC Reload OnInit: // Name der für den NPC angezeigt wird set .name$, "[Cowgirl]"; // Namen verschiedenen Items setarray .@cowboy_hats$[0], "Rot", "Blau", "Weiß", "Schwarz", "Gelb", "Grün"; // Item IDs der verschiedenen Items setarray .cowboy_hats[0], idrot, idblau, idweiss, idschwarz, idgelb, idgruen; // Aufbau des Menüs set .menu$, .@cowboy_hats$[0]; for( set .@i, 0; .@i < getarraysize( .@cowboy_hats$ ) ; set .@i, .@i + 1 ){ set .menu$, .menu$ + ":" + .@cowboy_hats$[.@i]; } end; }

das ist wieder so eine "ouch"-aussage... wenn man kein "super" internet hat, sollte man dann einen server hosten? außerdem gibt es die möglichkeit das repository nur teilweise per checkout herunterzuladen. bei einer ordentlichen strukturierung hat dies keinen einfluss auf leute mit einem internet, das nicht "super" ist. also von dieser ansicht her kann ich deine aussage leider nicht unterstützen.

ich bin gegen ein pures deutsches SVN, wenn dann sollte man generell einen multilingualen SVN erstellen... würde meiner meinung nach auch mehr sinn machen, weil dann wirklich alle was davon hätten und nicht alle nur teile in ihre eigene sprache übersetzen, sondern es möglich wäre mit einer standard rAthena SVN seinen usern alle implementierten sprachen anzubieten. und ich finde, dass dies auch endlich mal etwas wäre, wo auch 0815 community mitglieder etwas zum projekt rAthena beitragen könnten.

i would love a "parseable" format for some of the doc files. Which would also give the possibility to update the html files as often as you like, but not only that, it could even grant custom tools the possibility to read these information(for example a script editor with auto completion for script commands). as for the html files i must admit that i have never used them since for me the did not provide sufficient information. i like the idea of storing some of the most important guides into these files though.

I would rather prefer, that the rAthena SVN version is merged into a file and this file is checked on startup and if there is a sql update file for that revision the server(s) should tell you at startup that you have to run these. That would require to save two values though: the last revision that was used the current revision So it can tell you all of the updates that have to be done to the database. But I would not run it automatically since you can never know if someone changes his database and these changes contradict to the newest updates.