Intel

No, I meant Trial's.I know about the wrong data problems, but that's why I never had it in my server, meanwhile for some reason in another server I had to use Trial's fix. Very weird.

That fix really perplexes me. In a server I am working, there was this "cannot find tree" problem when warping and instantly moving and I know, for sure, there are no maps with wrong coordinates or wrong accumulation data. In my server, instead, I never had this issue (we even have a mount way faster than the elephant skin), until we worked on the sync position stuff and I fixed it like this: (notice the commit message as well lol)

Check in input_main.cpp, in void CInputMain::Move(LPCHARACTER ch, const char *data) { const float fDist = DISTANCE_SQRT((ch->GetX() - pinfo->lX) / 100, (ch->GetY() - pinfo->lY) / 100); if ((false == ch->IsRiding() && fDist > 60) || fDist > 125) { /*const PIXEL_POSITION & warpPos = ch->GetWarpPosition(); if(warpPos.x == 0 && warpPos.y == 0) LogManager::instance().HackLog("Teleport", ch);*/ // It may be imprecise sys_log(0, "MOVE: %s trying to move too far (dist: %.1fm) Riding(%d)", ch->GetName(), fDist, ch->IsRiding()); ch->Show(ch->GetMapIndex(), ch->GetX(), ch->GetY(), ch->GetZ()); ch->Stop(); return; } Also check the accumulation in the run.msa file (the file is not always run.msa. To check the correct file, open motlist.txt and see the msa file linked to the run animation) To check if the accumulation is correct:

There's no lycan in the presentation, indeed.. Anyway, whoever they are, they claim to have both versions (latest and the one before it, and apparently they may also sell you the previous version of Aeldra, not the latest though).

Oh I am not a modeller or anything, I just know the theory, but how to really do it, no idea ahah

Changing the mov speed of the player doesn't change the actual movement speed of the mount. You'll have to change the animation speed trough 3dsmax, therefore changing the accumulation for the run animation.

If you are his customer his latest files are compatible with both clang and gcc (and you can switch with a single script) (In general, switch the compiler in the makefiles and follow the errors. You'd need to recompile some libs, like cryptopp. DevIL maybe, format for sure if you use it) Btw I never had issues with this core crash, but I wouldn't bet on it to leave it like this ahah

Question: do you, perhaps, use gcc? And does this core happens even when just shutting down the game? Because I used to have this whenever I shut down the cores: Never when online though. Recently I changed to clang17 on FreeBSD 13.2 and.. this does not happen. I would also add: same code, with freebsd 11.1 I never had these problems. Since 12.2 I had started having this.

You do realize that the presentation in the website is the latest version of Aeldra? In addition, I am pretty sure Flourine is not involved in the new Aeldra. I would also add that there may or may not be an ex Aeldra's dev in the team (I cannot confirm it, so take the last thing with a grain of salt).

Ah they put it on top, for both, makes sense ahah The range I do check it server side though

Probably need to do gmake dep first

This video was presented to me yesterday and vietnam flashbacks came back to me to the first time I found out about this. Three years ago I thought it was just my client, maybe this part was deleted when it was not supposed to, but I guess it's not. Why does this work, I have absolutely no clue but it's amazing that it behaves like that. Let's get to fixing it. Open PythonPlayerSkill.cpp and add: DWORD dwMotionIndex = pSkillData->GetSkillMotionIndex(rkSkillInst.iGrade); DWORD dwLoopCount = pSkillData->GetMotionLoopCount(rkSkillInst.fcurEfficientPercentage); if (!pkInstMain->NEW_UseSkill(rkSkillInst.dwIndex, dwMotionIndex, dwLoopCount, pSkillData->IsMovingSkill() ? true : false)) { //Tracenf("CPythonPlayer::__UseSkill(%d) - pkInstMain->NEW_UseSkill - ERROR", dwSlotIndex); return false; } after: if (pSkillData->IsFanRange()) { if (pkInstMain->NEW_GetInstanceVectorInFanRange(float(dwRange), *pkInstTarget, &kVct_pkInstTarget)) { It should look like this: Literally the end.

I've done it depending on the quest category, but even this is pretty nice

Those are not the files for the quest arrow. Only one is: std::string g_strEffectName = "d:/ymir work/effect/etc/direction/direction_land.mse"; The file name is saved in PythonBackground.cpp. You have to change the mse and the images used in the mse. The how to edit an mse file is above me.

Yeah, I immediately had you and that discussion in mind when I found this lol Syreldar also showed me the directions used for the dungeons in the official. All under 255. Legit multiverses aligned for this thing to never be discovered before lmao

So, @ Syreldar was making a quest for a server I am working on and, he noticed that after the value 255, the direction set was not working properly. For some reason, dir is an int almost everywhere, except his declaration in the struct and the two lua functions. I understand the int in the spawnmob function as a parameter, for the -1 thing to decide to make it random, but then, it should be a number between 0 and 359 but somehow they decided to go with an 8bits representation number (BYTE) So here we are fixing another korean mistake.. Go to regen.h, and replace: BYTE direction; with uint16_t direction; Go to questlua_dungeon.cpp, replace: BYTE dir = (int) lua_tonumber(L, 4); with uint16_t dir = static_cast<uint16_t>(lua_tonumber(L, 4)); both in dungeon_spawn_mob_dir_ac and dungeon_spawn_mob_dir (not needed but for consistency at this point..) Go to char_manager.cpp in: LPCHARACTER CHARACTER_MANAGER::SpawnMob(DWORD dwVnum, long lMapIndex, long x, long y, long z, bool bSpawnMotion, int iRot, bool bShow) add: if(iRot > 359){ iRot = 359; } before if (iRot == -1) iRot = number(0, 360); and that's it.

[Hidden Content] 25.38.195.218 should be a const char* ("25.38.195.218") and the third parameter it's of type size_t (in this case the size you want to copy the source, the ip, to the destination, +1, aka sizeof("25.38.195.218")+1) If you want to copy strings/chars to a char[] I would suggest strlcpy: [Hidden Content] [Hidden Content]

void CDungeon::SendFlagList(LPCHARACTER ch) { for (auto iter = m_map_Flag.begin(); iter != m_map_Flag.end(); ++iter) ch->ChatPacket(CHAT_TYPE_INFO, "%s: %d", iter->first.c_str(),iter->second); } Since we've done the c++17 version, this is the c++11 version if someone needs it

If anyone is interested in some light reading: [Hidden Content] Also this can be very helpful as well: [Hidden Content] EDIT: Almost forgot, The Cherno on YouTube:

That's weird, I also use MySQL 8.0 (only database, not actual linking, though it shouldn't matter) and: [mysqld] user = mysql port = 3306 socket = /tmp/mysql.sock bind-address = 127.0.0.1

Even with a backup there's no guarantee it would be stable. You could just install MySQL 8 and fix the errors that come along, for example guarding table names with ``: int iLen = snprintf(szColumns, sizeof(szColumns), "id, owner_id, `window`, pos, count, vnum"); the cache query gave me errors with mysql8 until I edited window with `window`, same in QUERY_ITEM_SAVE and RESULT_SAFEBOX_LOAD

I just had used the level to show drop from common drop items with the level difference chosen in common_drop_item.txt. You posted two different functions. The first one is the target info, the second one is where the items are actually dropped (that you should not touch). Let's say I set an item from level 75 to 99, a player level 74 won't see the item in the info drop list: while (it != g_vec_pkCommonDropItem[bRank].end()) { const CItemDropInfo & c_rInfo = *(it++); //LEVEL CHECK if(iLevel < c_rInfo.m_iLevelStart || iLevel > c_rInfo.m_iLevelEnd) continue; TItemTable * table = GetTable(c_rInfo.m_dwVnum); if(!table) continue; int rarity = CalculateDropRarityCommonDropItem((c_rInfo.m_iPercent * iDeltaPercent) / 100, iRandRange); if(rarity){ vec_item.emplace_back(c_rInfo.m_dwVnum, 1, rarity); } }

Added/Completed a new option to the MultiFarm block: Possibility to block dungeon's access to other players in the same PC. Let's say you want maximum two characters. First and second will finish a dungeon, a third character will have the cooldown of the first one (or theirs, if it comes from another PC and the character's cooldown is longer). Compatible with the Dungeon Info. This type of cooldown can be expanded for other stuff (we have a daily tasks system where, per PC, you can only complete 6 in total) This option is included with our UniqueID system (presented at the bottom of the MultiFarm block spoiler).

Of course it makes sense, if you edit it (otherwise just clean it). Also, technically, they can drop from a dog. std::vector<CItemDropInfo>::iterator it = g_vec_pkCommonDropItem[bRank].begin(); while (it != g_vec_pkCommonDropItem[bRank].end()) { const CItemDropInfo & c_rInfo = *(it++); if(iLevel < c_rInfo.m_iLevelStart || iLevel > c_rInfo.m_iLevelEnd) continue; TItemTable * table = GetTable(c_rInfo.m_dwVnum); if(!table) continue; int rarity = CalculateDropRarityCommonDropItem((c_rInfo.m_iPercent * iDeltaPercent) / 100, iRandRange); if(rarity){ vec_item.emplace_back(std::make_tuple(c_rInfo.m_dwVnum, 1, rarity)); } } uint8_t CalculateDropRarityCommonDropItem(const uint32_t pct, const uint32_t randRange) { uint8_t rarity = 0; if(pct <= 0){ return rarity; } const float realPct = static_cast<float>(pct)/randRange; const float minimumPct = 1.0f/randRange; if(realPct >= 1.0f) rarity = 1; else if(realPct < 1.0f && realPct >= 0.05f) rarity = 2; else if(realPct < 0.05f && realPct >= 0.0025f) rarity = 3; else if(realPct < 0.0025f && realPct >= 0.00125f) rarity = 4; else if(realPct < 0.00125 && realPct >= 0.00025f) rarity = 5; else if(realPct < 0.00025f && realPct > minimumPct) rarity = 6; return rarity; } I can assure you, rarity will not be 0 and a player lv60 would see the drop if the range is that high (although it would be very very very very low)

Added two systems: Items Affect (Blend Renewal) 800€ Multiple Item Prices (Shop-Ex Renewal2) 300€