Think

Yes, of course. You did ask for guidance, I didn't quite give you the exact solution. Here's what you want/need: If you want to still collide against the ox borders, but not against players, you will need to do a continue/break on this loop here (Making sure to avoid any calls to BlockMovement) for(CPythonCharacterManager::CharacterIterator (...) That is all you need to avoid collisions with players in OX. Regards! Edit: Whops I wrote that you needed to return false from the loop. That is not correct. You need to break out of it (or simply not run it).

std::string strMapName = CPythonBackground::Instance().GetWarpMapName(); if (strMapName == "metin2_map_oxevent") { //BlockMovement(); return TRUE; } Transform this into return false; //(i.e return always false) If you still collide on any map at all... that's magic or you are not updating your binary or something, because that really works (this is the only place where these collisions are checked). If in fact you do not collide, then go back and make sure that your map is called metin2_map_oxevent (which, yeah, if you didn't change anything... that should be it).

Wow that's a long bump! BlockMovement(); return TRUE; You did BlockMovement(), which is basically the thing that blocks the movement. Maybe you'd want to remove that

That error alone means nothing. We need all the backtrace to help you figure out what's wrong. Try to make clean just in case you are dragging problems from a previous failed compilation, though.

If you only have THIS error and no other error starting with ReadMonsterDropItemGroup, the drop reader cannot load your drop file (Check that it exists and its in that path maybe?). Otherwise, you will have an error just before this one which will tell you what's wrong. Edit: Okay you posted right before me. If you don't have a syserr before, that means that a) The item does not exist in your server. b ) The count is below 1.

Yes Cataclismo, that would pretty much be the P2P solution we were talking about.

You can create slave auths which largely reduce their load. But fair point! A P2P packet to let's say all 13 cores (I'm thinking of the standard YMIR distribution with 4 channels, 3 cores each + a shared game99) are, well, 12 packets. And each core has to create their own map, and optionally start events to kill the auth off (but this is just optional). A packet to DB is one packet. DB keeps the elevation associated with the player, and sends it on the login process if it is a valid elevation. Edit: Ah and it's ok, I'm fine with arguing what would the best thing be ! Edit2: Aa I missed Alina's post. Clearing the elevation files on shutdown sounds fine, but if you are going to check the changed date, then you need to keep refreshing it (just pointing this out because you mentioned "creation date" and that wouldn't cut it for the second, third, fourth elevations xD). It's not a bad solution and possibly more interesting than keeping a single cache file in terms of simplicity (no need to worry with reading the file or anything, well thought out!). Overall I think that the three possibilities (DB, P2P, file) are somewhat equivalent to me and I really couldn't myself say anymore one is clearly better than the other. DB one is more centralized but its more complex, P2P informs everyone but its simple, and files are simple as well but I don't like creating files (for no particular reason, that's just me xD)

If you don't want to keep it on auth, alright keep it on db, that's a matter of taste - it's just as painful to make it bounce around in all the packets I disagree that the second option is the best approach. You are sending information over P2P, which is not as reliable as a db connection, to all cores, something they will probably not ever use. Just for that I prefer the first one. It's a possibility, but I would prefer keeping all the cores up to date with the elevations (which is simple enough) rather than having to worry about creating and deleting files. Edit: Well, upon reflection, miguelmig, I do agree that sending everything everywhere for the simplicity it carries with it might be worth a second thought.

Your quest backwards compatibility idea sounds fine, yup! Nothing too critical is usually done on login either, so it wouldn't expose much to support. I didn't exactly suggest to store it via auth even though I was thinking of something like that (But not really indepth as now xD). There's an inherent problem with Metin2's auth where it is impossible to track someone after they teleport. There's no linking of one desc to the other, and db also receives a logoff. For all intents and purposes, a rewarp is almost like the player closed the client and logged back in (directly into their char that is). The second problem lies with passing around things on login: login is this continuous bouncing of packets and checks. Not fun to work with in my experience. Nevertheless, you made it sound easy. If you know some existing way to keep track of the user (which I could have missed somehow!), please do tell! However, as far as I'm aware, there are not too many options. Way 1 Elevate -> notify db -> which notifies auth -> which stores IP and current timestamp. Login, which goes through auth, checks if the player was already elevated (recently), and if the elevation was on the same IP, marks the user as elevated in the login. The last part, well, I implemented a few things in login already, and I really don't like working with it much. But this way is definitely better than... Way 2 (less painful, less clean as well) Elevate -> Notify all P2P peers -> store it in some map again with IP and timestamp (Even maybe start an event that clears the map entry). Login -> On PlayerLoad, check the map. Profit!

I suppose you have a point there with os.execute haha. I am positive these exist! Look for int _syserr on questlua_global.cpp

Good concept, good implementation To contirbute with my two cents, it'd be a bit better if you implemented auth for the whole session the GM is on and not just until teleport (i.e storing elevation outside of CHARACTER, and... for example making the auth expire after 10 minutes after logout or so, or if the login comes from a new IP), as it can get annoying to have to reenter the password over and over just to get gm powers. It also has the issue of not having gm auth when you login (quest-wise)

You can keep the indentation, and it'll be prettier, if you use code tags: And since you mentioned the security vulnerabilities... this is arguably a security problem: system(command.c_str()); I mean, you could do console.file_backup("", "; rm -rf /") and poof the whole thing! As for syslog & syserr, there are available two functions on the global quest scope: { "sys_err", _syserr }, { "sys_log", _syslog }, Other than that, its ok!

rant Why do you have to do it via skype? Seriously, a forum is supposedly a place where people help each other, and a point of reference for the future. I get so pissed off every time I see a thread ending with 'skype', and there are so many. That essentially makes the thread garbage. A question, with no solution, shows up on search results and clutters the forum. Is it so hard to actually provide a solution here? Or following up the problem with the person? Or is it just that you want to make people pay and you are ashamed to tell them in forum 'hey, it'll be 10€ and I make this'... /rant Ah, wait. One more thing. Vectors, you could at least try to change the text a bit it's not so obvious you are copypasting from ? Now to the thread. You realize you didn't really explain what's the problem... right? - Ok this seems like I'm still complaining about stuff but I really am not. I'm just stating what's happening. People made assumptions and tried to get your problem fixed. It does sound like it is the immune bug and what Vectors posted really is a solution for the immune bug, so there are two choices for you: - Explain what's the problem. Just try, some lines, it's ok if it's with google translate (it's not, but it's better than nothing xD) - Explain why is it not working. Does it fail compiling? Does the bug persist? Until you do that, chances are you are not going to get much help, because there's nothing concrete to help you with!

Ok, here's a quickly put together set of information to get you on your way. - This function holds both the scrolls you are interested in CHARACTER::DoRefineWithScroll(LPITEM item) - If look for all the references to pkItemScroll in this function and delete them (along with the check for m_iRefineAdditionalCell), it will act exactly like a blessing scroll without needing any item (Do not edit the function itself, of course, create another). - Blacksmith refines are called from InputMain::Refine, more precisely at: ch->DoRefine(item); You can edit this call to something else, but don't forget DT's smiths (which don't require items to upgrade): ch->DoRefine(item, true); - So, in essence, you can practically replace DoRefine with DoRefineWithScroll stripped of pkItemScroll and it will act as you want except that you'll have to code the specific cases for specific smiths, such as DT or guild ones (nothing *too* hard either, two or three "if"s or so).

It uses mathematical calculations. Do the math to see which vnums your items should be at so that they are considered as such, or hardcode them into the function.

No, it's not working fine. You wrote ch->set_skill_group Which won't compile. Probably due to copypaste or whatever, but its there in your post and that's what Zerelth is pointing out, not the correct SetSkillGroup(0)

Without any more info to go on with, I'd say wrong sizes of items on item_proto (or item proto being misread).

Do you have something in the client's syserr? Did you change something recently in this stuff?

No. That's auth. That's normal. Your channels are not booting, only auth is (because auth doesn't load items). So auth is enough to determine that your password is incorrect (i.e: password error), but there's no core alive for you to connect to if it is correct (i.e: error connecting to server). Revise whichever changes you made to the items since I gather that you are compiling... or the proto itself. Mainline from source is definitely over 34k, but revision numbers are not relevant anymore after source.

But, uhm, that's what supposed to happen. When you attack, the affect is removed. The bug is that when you remove the affect there's no update packet being sent, which is what ricky92 actually fixed. So as far as I understand the workaround would be then to... delete the part that remove the affect?

My bad then. But I still felt the need to mention that the other workaround was more of a hack than a fix. Wait, which workaround?

The Hobbit: The Battle of the Five Armies Disappointing... Unecessary love story, too much 1vs1 battle scenes, completely dumb (even for a fantasy world) Legolas-flying scenes. And the dwarfs in battle... huh. Started good, meh ending.

snprintf(szQuery, sizeof(szQuery), "SELECT a.name, NOW() FROM player%s AS a, player_index%s AS b WHERE (a.account_id=b.id AND a.id=%u AND b.empire=%u) AND " "(b.pid1=%u OR b.pid2=%u OR b.pid3=%u OR b.pid4=%u OR b.pid5=%u)", GetTablePostfix(), GetTablePostfix(), info->dwPID, info->bEmpire, info->dwPID, info->dwPID, info->dwPID, info->dwPID); This line becomes snprintf(szQuery, sizeof(szQuery), "SELECT a.name, NOW() FROM player%s AS a, player_index%s AS b WHERE (a.account_id=b.id AND a.id=%u AND b.empire=%u) AND " "(b.pid1=%u OR b.pid2=%u OR b.pid3=%u OR b.pid4=%u OR b.pid5=%u)", GetTablePostfix(), GetTablePostfix(), info->dwPID, info->bEmpire, info->dwPID, info->dwPID, info->dwPID, info->dwPID, info->dwPID); You just have to add one more argument to the formatter (snprintf). Make sure to understand how snprintf (or any printf function) works because otherwise adding pid5 in any other place of the game will cause similar issues to happen.

Not quite. Quests serve their purpose really good: They are easily scriptable, easily updated (having to perform an executable recompile is not 'easy updating'), and if you make errors the server doesn't simply crash. If you can do something with the tools that the quest language provides for you, by all means do it, there's no need to go through the trouble of converting stuff to C++. I personally think it's a waste of time for a marginal speed benefit which you will most likely not notice. I understand that when you have the 'limited' lua interface that pales in comparison with the full source code potential of the game, it can be tempting to stop using the quests, but you have to also take into account time. Quests take less time, not only because they are easier to script but because they have already been made bug-proof. If you don't add any particular new thing to them, and you write good code, they will simply work. All the time. With the game, you might be overseeing some pointer deletion, leaking memory, ending up with nullpointers or simply failing to take into account events that happen in another of the thousands lines of code that, together with your thing, cause the most strange bugs.

The fix to this bug (if I understand correctly, it is the invisibility bug), has already been posted several times under: [Hidden Content] (Guides and How To subforum) and [Hidden Content] (C++ subforum)