Yiv

As a quest function this release is not really necessary. You can do this using the quest functions provided by the core by default. function checkItem(index, count) local partyMemberPids = table.pack(party.get_member_pids()) local invalid = false for _, pid in ipairs(partyMemberPids) do q.begin_other_pc_block(pid) if pc.count_item(index) < count then invalid = true end q.end_other_pc_block() if invalid then break end end return not invalid end function removeItem(index, count) local partyMemberPids = table.pack(party.get_member_pids()) for _, pid in ipairs(partyMemberPids) do q.begin_other_pc_block(pid) pc.remove_item(index, count) q.end_other_pc_block() end end By the way: The code optimization during compile time should know wether it's needed that the value returned by the operator is needed or not. If not the optimization should be aware of that and optimize the code in a way that both ways behave the same and therefore have no performance difference. Otherwise if it's needed, you're right of course and the pre-increment operator is better talking of performance but if you need it you won't have another way anyway and this does not matter. Regards

Just try it. It may work without any changes. If not, then report it here and we'll see. Regards

Both solutions should work fine. I think the solution posted by Socialized using the returned iterator by the erase method should be better. I at least would change my code posted above to this: void CQuestManager::CancelServerTimers(DWORD arg) { for (auto it = m_mapServerTimer.begin(); it != m_mapServerTimer.end(); /**/) { if (it->first.second != arg) { ++it; } else { auto event = it->second; event_cancel(&event); it = m_mapServerTimer.erase(it); } } } Regards

Try to replace the CQuestManager::CancelServerTimers method in questmanager.cpp with this one: void CQuestManager::CancelServerTimers(DWORD arg) { for (auto it = m_mapServerTimer.begin(); it != m_mapServerTimer.end(); /**/) { if (it->first.second != arg) { ++it; } else { auto event = it->second; event_cancel(&event); m_mapServerTimer.erase(it++); } } } Regards

He said that, because you say, it's simple but if you say that, you should be able to do that

Hello LeNnT, I told you, that I wrote to ChuckNorris, and he deactivated your topic until the conflict of stealing parts of my code and selling as yours is solved. You can place your statement for this in a private message to me and Chuck. By the way, the system we're talking about is now released on elitepvpers by me: [Hidden Content] Regards

​Why did you add the new map LevelByVnum and not just implemented the CPythonNonPlayer::GetMobLevel(DWORD dwVnum) like this: BYTE CPythonNonPlayer::GetMobLevel(DWORD dwVnum) { const CPythonNonPlayer::TMobTable * c_pTable = GetTable(dwVnum); if (!c_pTable) return 0; return c_pTable->bLevel; } Regards

There's no quest function for that, you'd have to make your own, something like this: // Syntax: npc.move(map_index, local x, local y) int npc_move(lua_State* L) { if (!lua_isnumber(L, 1) || !lua_isnumber(L, 2) || !lua_isnumber(L, 3)) { lua_pushboolean(L, FALSE); return 1; } LPCHARACTER pkNPC = CQuestManager::instance().GetCurrentNPCCharacterPtr(); if (!pkNPC) { lua_pushboolean(L, FALSE); return 1; } long lMapIndex = lua_tonumber(L, 1); long lX = lua_tonumber(L, 2); long lY = lua_tonumber(L, 3); LPSECTREE_MAP pkSectreeMap = SECTREE_MANAGER::instance().GetMap(lMapIndex); if (!pkSectreeMap) return 0; if (pkNPC->Goto(pkSectreeMap->m_setting.iBaseX + lX, pkSectreeMap->m_setting.iBaseY + lY)) { pkNPC->SendMovePacket(FUNC_WAIT, 0, 0, 0, 0); lua_pushboolean(L, TRUE); } else { lua_pushboolean(L, FALSE); } return 1; } IT'S UNTESTED! Regards

What's about using PaymentWall in Germany? You have problems because of taxes? Can you register as a private person without any VAT-no.?

#bump

Dear community, since some days we're noticing that our database core is crashing from time to time. The last relevant messages in syslog are these: Apr 8 11:59:33.728741 :: ITEM_AWARD: load id 0 login vnum 1966080000 count 6553600 socket 0 Apr 8 11:59:33.728788 :: SIGNAL: SIGSEGV Somebody knows where the problem is? Btw.: I checked player.item_award but there's no item with such a vnum... Regards

Dear community, as I found out that there's an error in player.item_award (or not directly in it but the function of it) I wanted to ask if someone already fixed it? The error works as following: - Itemshop writes the item into player.item_award with a socket2 value (e.g. 300 for a unique item as 5 hours using time) - Player takes item but the socket2 is not written into player.item so the item doesn't have a use time (0 minutes) - Item purges If nobody fixed it maybe someone could fix it? Regards

Dear community, from one day to an other (I didn't changed something related to that ) I receive a multiple definition error of functions/variables defined in the main.cpp. I don't know why :S OBJDIR/test.o: In function `ContinueOnFatalError()': /eos_src/game/src/test.cpp:66: multiple definition of `ContinueOnFatalError()' OBJDIR/main.o:/eos_src/game/src/main.cpp:159: first defined here OBJDIR/test.o: In function `ShutdownOnFatalError()': /eos_src/game/src/test.cpp:70: multiple definition of `ShutdownOnFatalError()' OBJDIR/main.o:/eos_src/game/src/main.cpp:183: first defined here OBJDIR/test.o: In function `heartbeat(heart*, int)': /eos_src/game/src/test.cpp:74: multiple definition of `heartbeat(heart*, int)' OBJDIR/main.o:/eos_src/game/src/main.cpp:242: first defined here OBJDIR/test.o: In function `Metin2Server_IsInvalid()': /eos_src/game/src/test.cpp:78: multiple definition of `Metin2Server_IsInvalid()' OBJDIR/main.o:/eos_src/game/src/main.cpp:364: first defined here OBJDIR/test.o: In function `start(int, char**)': /eos_src/game/src/test.cpp:102: multiple definition of `start(int, char**)' OBJDIR/main.o:/eos_src/game/src/main.cpp:699: first defined here OBJDIR/test.o: In function `main': /eos_src/game/src/test.cpp:118: multiple definition of `main' OBJDIR/main.o:/eos_src/game/src/main.cpp:444: first defined here OBJDIR/test.o: In function `__gthread_trigger': /usr/include/c++/4.2/bits/gthr-default.h:165: multiple definition of `max_bytes_written' OBJDIR/main.o:/usr/include/c++/4.2/bits/gthr-default.h:165: first defined here OBJDIR/test.o: In function `__gthread_trigger': /eos_src/game/src/arena.h:106: multiple definition of `total_bytes_written' OBJDIR/main.o:/usr/include/c++/4.2/bits/stl_tree.h:1335: first defined here OBJDIR/test.o: In function `__gthread_trigger': /usr/include/c++/4.2/bits/stl_tree.h:1335: multiple definition of `current_bytes_written' OBJDIR/main.o:/usr/include/c++/4.2/bits/stl_algo.h:2885: first defined here OBJDIR/test.o: In function `__gthread_trigger': /eos_src/game/src/arena.h:106: multiple definition of `main_fdw' OBJDIR/main.o:/usr/include/c++/4.2/tr1/hashtable_policy.h:346: first defined here OBJDIR/test.o: In function `__gthread_trigger': /usr/include/c++/4.2/bits/gthr-default.h:168: multiple definition of `udp_socket' OBJDIR/main.o:/usr/include/c++/4.2/tr1/hashtable_policy.h:346: first defined here OBJDIR/test.o: In function `__gthread_trigger': /usr/include/c++/4.2/bits/stl_tree.h:1340: multiple definition of `g_bShutdown' OBJDIR/main.o:/eos_src/game/src/main.cpp:364: first defined here Who can help? Regards

Well, buttons are no problems and I didn't speak about them I said something like mouse over E.g. in the inventory SetOverInItemEvent for tooltips. Thanks anyway! Other? Regards

Dear community, I'd like to know if someone could tell me how to call a function over ui.__mem_func__ (used in e.g. mouse over) with parameters? So if I have the function funcWithParams(self, par1, par2) and I know want to call it with ui.__mem_func__(self.funcWithParams) I want to give some parameters. I already tried this: ui.__mem_func__(self.funcWithParams, 1, 2) ui.__mem_func__(self.funcWithParams(1, 2)) ui.__mem_func__(self.funcWithParams, (1, 2)) Nothing works (except my workaround which is not really good!). Someone knows a solution? Regards