Lynx3d

as i understand it's related to latest changes with BIH. I was reverted this in my repo to be able compile again...

also there is a typo with

bool StaticMapTree::UnloadMap(VMapManager2 *vm)

should be

void StaticMapTree::UnloadMap(VMapManager2 *vm)

Thanks, that prototype was indeed unintended...classy copy&paste mistake.

About BIH.cpp not found, i'm pretty sure i did not forget to commit it, but maybe i updated one of the VS project files incorrectly...need more info if it still happens.

Maps without terrain (no ADT files) only consist of a single WMO (unless they are just dummy maps).

MaNGOS' map code doesn't seem to care if a map is tiled or not, it always creates grids and requests vmap loading for it, but the WMO is already loaded at StaticMapTree::InitMap().

So the actual tile coords are ignored, vmap code only keeps track of the grids that requested a vmap to know when it can be unloaded again.

Not solved with [9948]...still instantly disappearing after normal loot randomly.

Somehow tends to be a bit "bursty", like 5 times in a row disappearing, then works for a couple mobs etc...

I'm using:

Corpse.Decay.NORMAL = 120

Rate.Corpse.Decay.Looted = 0.2

So you *should* have plenty of time to target even non-skinnable mobs after looting etc.

Both cores i tested were running Linux if that matters, my system is running Ubuntu 10.04 64bit

Heh yea i just pestered vladimir with the same complaint...

Though, they don't always vanish for me, but it seems pretty random. I start to believe it has nothing to do with skinning (or herbing/mining) itself, any kind of mob sometimes just instantly disappears instead of staying for the normal looted despawn delay, for non-skinnable mobs the default delay is just so small that i didn't notice at first.

I also noticed that some mobs that only drop money are not lootable anymore...

From what i understand, recast does not care at all if polygons are connected or not, it voxelizes every polygon that comes in right away.

No idea how you created that second mesh, does the time include finding vertices with identical coordinates?

Did you disable vmaps on continents?

The old area hacks had been removed by arrai...probably need to find a solution fall back to those hacks when the required vmap is disabled.

Hm okay faramir didn't really adapt VC90 files to his changes...

Should work again now with my repo.

Make sure you first build the libmpq solution, and then extractor with the same configuration.

It's because turning on them on continents at previous (mangos) version is improssible on weaker machines (CPU reach 100% and app is closed by freeze detector). Merging your work, while vmaps enabled on 2 of 4 continents seems that CPU does not even noticed any change i think ;-) If you wish I can submit comparition turned ON<->OFF

I'm not sure i understand you correctly, you haven't been using the "old" vmaps on continents recently because they would kill the core too often?

I know the old code was not quite that optimal, but i'd be surprised if the difference is as dramatic as "no noticeable load increase" and "server fails due to CPU load".

Of course a direct comparison would be great, but i can understand if switching back and forth is too much interruption for your players.

i don't know if it is related to this patch or MaNGOS core itself but .reload conf does not turn on/off vmaps on certain maps - reboot is required

Good question, i don't know if it ever worked, will try to look at it.

If you just say what you need we will do what ever we can to help you.

Hm you're right, maybe i should just ask the right questions myself to find out what all this code is worth...

Okay things particular interesting:

General

• * compiling, using: anything that does not work as expected?
  * stability: does memory leak indefinitely, or the core crash more often?
  * regressions: do LoS or height checks fail somewhere where they did work before? If so, where?
  

New Functionality

• * indoor check: do you get unmounted somewhere where you clearly should not get unmounted on retail, or vice versa?
  * area detection (need .gps priviledges to test): is reported zone/area faulty? (note that server does not evaluate "micro-zone" names like individual shop names in cities etc.)
  * water: do you drown somewhere you shouldn't, or do you not drown when you should?
  * fishing: any fishable water that does not work? Do fish swarms still work properly?
  

-edit-

Oh and forgot to say, please also mention platform you use, and revisions you tested (hash of my last commit, and other things merged in)

Merging with MaNGOS master should be fine, that's expected to work, of course you can try other branches, but understand that i will not try to support all combinations you may come up with.

So lynx3d how close do you think you are to completion with this rewrite? Just wondering...

Well, how shall i give an answer to that question when all i get back is questions like "are you done yet?", "why do i have to use git?" or "does it work with <insert random WIP branch>?"...

Yet i see people are happily merging it in their forks or even their "own" projects (== mangos forks with funky names and claiming all code to themselves...)

I don't know if no one is giving it a real try, or just no one cares to give any feedback (except 2 or 3 guys earlier in the thread), but i don't have any feedback from my last update...

Functionality wise, pretty much everything is there now, but that's all i can test/decide myself...

Well the original code already exported something...although that stuff didn't make any sense IMHO. The assembler just skipped that chunk, as it does with some other chunk that i have no idea what it was even intended to be used for.

Maybe i should implement a check if the dirs are clean before starting...

Ehm merging with mmaps will hardly be as easy as removing all "<<<<", "====" and ">>>>" lines...and please use paste2.org or similar next time...

@faramir118: Hm are you really sure you used a fresh compile of the extractor and had no old files in Building dir?

Because i can't see anything wrong there yet, the liquid header is pretty much written and read again as it is in the original WMO...and at that place i also don't see a possibility to accidently write out of bounds or anything like that... *scratches head*

I just pushed the first implementation of WMO Liquids.

Note that it requires additional vmap queries and you cannot disable it currently.

You should now be able to fish in buildings/cities/instances etc. and also correctly get breath timer only when underwater (but note that there definitely seems to be an existing mangos bug, sometimes your mount swims correctly, sometimes your mount is completely submerged and you will drown when not jumping all the time).

Also, be careful where you jump in, lava and slime *will* hurt now

However, the Undercity liquid is also classified slime, but mangos deals the same damage in any slime, so i had to add a hack there.

Need to extract and assemble vmaps again, of course.

Yes please mention your 'head' commit when reporting problems...

Also note that i don't have any confirmation that aforementioned "crash fix" is actually required with clean sources, i only got backtraces from obviously patched cores.

Vladimir can't see a reason either why it should be necessary, teleports that touch "IsInWorld()" are supposed to be delayed until after this line.

As i thought, the tunnel object in WSG is pretty long and goes uphill, so i definitely need to check the "normal" terrain also for deciding if you "touch" a WMO that is defined indoor.

I think i already got it working, but i need to cleanup a bit first, and i'm tired now...fix will come tomorrow.

@djmagma59: and i hate patch files

Serously, read some darn GIT tutorial.

It's not like this branch only changes a few lines here and there...

+ in WSG when you go over the tunnel you get dismounted when you should not be

Confirmed.

Probably needs an additional terrain height check.

Seems the bound of the tunnel object peeks through the ground there, and there's no wrapping WMO marked as outdoor either (like most buildings that are split into an inner and outer shell).

Win64 != Linux.

I'm developing this whole thing on 64bit Linux, should have no problem there.

@faramir: I think the extractor bug was caused by me, left a comment to your commit.

@Diablox: those errors are from G3D("-lite", we use only part of whole project), i updated it to newer code (in the hope for a cleaner, more complete framework) but it still needs tons of fixes, or even more because it has new features

So much for "cross platform"...hope this one is fixed too now.

Hm okay, was a rather stupid mistake :rolleyes:

Has to do with the BIH implicitly skipping empty nodes by setting infinite split bounds, but this check utterly fails if you feed it NaN values, which were caused if isInLineOfSight or getObjectHitPos is called with identical points.

Hope it is fixed...

@faramir:

ls *.vmtree
000.vmtree  090.vmtree  429.vmtree  546.vmtree  571.vmtree  608.vmtree
001.vmtree  109.vmtree  449.vmtree  547.vmtree  572.vmtree  609.vmtree
013.vmtree  129.vmtree  450.vmtree  548.vmtree  574.vmtree  615.vmtree
025.vmtree  169.vmtree  469.vmtree  550.vmtree  575.vmtree  617.vmtree
029.vmtree  189.vmtree  489.vmtree  552.vmtree  576.vmtree  618.vmtree
030.vmtree  209.vmtree  509.vmtree  553.vmtree  578.vmtree  619.vmtree
033.vmtree  229.vmtree  529.vmtree  554.vmtree  580.vmtree  624.vmtree
034.vmtree  230.vmtree  530.vmtree  555.vmtree  585.vmtree  628.vmtree
035.vmtree  249.vmtree  531.vmtree  556.vmtree  595.vmtree  631.vmtree
036.vmtree  269.vmtree  532.vmtree  557.vmtree  598.vmtree  632.vmtree
037.vmtree  289.vmtree  533.vmtree  558.vmtree  599.vmtree  649.vmtree
042.vmtree  309.vmtree  534.vmtree  560.vmtree  600.vmtree  650.vmtree
043.vmtree  329.vmtree  540.vmtree  562.vmtree  601.vmtree  658.vmtree
044.vmtree  349.vmtree  542.vmtree  564.vmtree  602.vmtree  668.vmtree
047.vmtree  369.vmtree  543.vmtree  565.vmtree  603.vmtree  723.vmtree
048.vmtree  389.vmtree  544.vmtree  566.vmtree  604.vmtree  724.vmtree
070.vmtree  409.vmtree  545.vmtree  568.vmtree  607.vmtree

And last time i checked, the stormwind instance worked (don't remember if it's 34 or 35), that's what i used to get the coordinates for WMO based instances right.

@KAPATEJIb:

Hm second time i hear that, works but some random freezes

Starts to look like i did something wrong somewhere...

Would be great if someone could give me a stack trace (or even better several, if it hangs with 100% CPU load), the more info the better obviously

-edit-

/me is too slow

Will try to reproduce then, if it's knockback, i hope i can find the cause, i've been playing with that a while ago too (nothing of that in this branch though).

I just made core less verbose, should now only print errors and some loading/unloading details, unless you have LogLevel=3.

But i have to emphazise that you are completely beta-testing this, you risk to upset your players if you use it for your active realm(s)!

is there a way to fix Dalaran and Orgrimmar fishing? As i remember it not works in clean mangos because need to read additional VMO data, but now we has this data...

Well, not yet, sorry. Additional area info does not mean we have liquid data already.

At least current map extractor skips those 0-size ADTs too, i do not have some 0011245.map for example, for Kalimdor_45_12.adt etc.

And people should've noticed missing tiles by now i guess

I am getting the message Error reading ModelSpawn! also, but haven't looked into it yet. Is it only during server shutdown?

That's just an unhandled EOF occurence, was too lazy to fix that...

Will popup at the end of each .vmtile parse, nothing to worry about.

Weird problem, first time I started the server I was unable to walk through some doorways. I restarted server (but didn't restart client, just disconnected) and it works fine now. I can't seem to reproduce it.

Anyone else have this problem?

I'm having that problem with master branch too, no idea what's wrong with that, some days i just can't walk into certain building...*shrug*

Stab: You are obviously looking at the wrong repo...

-edit-

KAPATEJIb: I haven't tested faramir's fix for the Kalimndor tiles yet, but seems reasonable...

faramir118: That looks promising

Is that file count above already with the fix for 0-size ADT files? Because i have a couple files less...hm i even have one map less...wtf...these MPQs are picky...

Maybe the loading order is still not correct (stormlib code did everything in reverse order to map extractor code...), but i guess your fix for it can't break anything.

Will look at your patches, first impression is that it looks quite sane.

And yes, the extractor had a horrible code section that unnecessarily slowed down extraction a lot.

And the assembler is faster for the same reason that vmaps are smaller, WMOs are not copied/transformed each spawn and hence don't need a new BSP tree each time, but the time difference here is not that dramatic for me.

Oh btw, forgot to mention: please always make sure the destination dir is EMPTY before running vmap_assembler, it only appends to the tile files.

I hope i fixed that one, and it finally has no reason to crash anymore.

I really wasn't aware that WMO group files without collision geometry get extracted too, the intersection code may have caused problems with that too, so i properly check for that now.

Maybe they are of no use, but i'm not sure yet.

Ah that was the "somewhere between to printf" method of finding the code line ^^

Inside writeToFile() then...makes a lot more sense to me.

So...empty group model somewhere...probably WMO because i just had added an empty-check to calculateTransformedBound() *scratches head*

I can also understand why it doesn't crash on linux then, because if 'vertices.size()' is zero, the invalid pointer '&vertices[0]' is probably never dereferenced by fwrite, since i tell it to write zero elements...interesting that MSVC is able to catch that actually...

I think that was very helpful, thanks!

Hm that's two lines in my world

Anyway, i don't see how anything can go wrong in those two lines, the cause must be somewhere else.

Only thing i could find is an accidetly use of "delete" instead of "delete[]".

I ran it through valgrind and now it has no complaints at all, also can't find any other place where i might write out of bounds and are only lucky that std::vector grew more in capacity than current size would require...

If it still doesn't work, then i don't know...