Modcraft - The community dedicated to quality WoW modding!
Featured => Noggit => Topic started by: henslock8 on June 03, 2012, 04:47:52 am
-
Hello, I am having trouble getting VMaps to work on Customized Maps.
I have been fiddling with Noggit in Durotar, I placed a simple building with some .m2's around it like in the picture below:
(http://desmond.imageshack.us/Himg849/scaled.php?server=849&filename=expic.png&res=landing)
After finishing and saving my work, I put it into an .MPQ named "patch-6" and I modified vmapexport.cpp in the source code to support Patch-6.MPQ. I recompiled, got the new Vmap extractor, ran it and let it finish, and replaced my old Vmaps in my server folder.
No errors recieved whatsoever...
So I log into the game and it turns out that Vmaps have enabled Line of Sight for ONLY the .m2's (that I added), however the .WMO has no LoS at all.
I am curious as to why this is ... I probably did something foolish but help would be appreciated :?
-
You did re-extract the maps before making the v-maps, right?
-
It's been awhile, the last time I worked on Noggit/PServers was about 2 years ago -- so forgive me if my memory is foggy ... I thought maps were used for discovering sections of the World of Warcraft in-game map. If so, then how do VMaps require Maps to be extracted properly? (If that's what you're getting at)
Regardless, I have already tried it and it does not work.
-
Perhaps they have nothing to do with them at all, but every time I extract v-maps, I previously extract maps anyway, so it was worth a shot. (Prior to your reply, I did actually believe they had something related, but obviously not :P)
I have no idea then, maybe, even though you edited the .cpp, try renaming it to patch-4, or patch-5... Never know, it might work :S
My V-maps work on custom maps (edited blizz ones) and even on custom continents (map id 5000+ for example), so I don't know why it isn't working for you :S
-
Well any kind of help is appreciated, so thanks.
It seems that only WMO's are causing me trouble, the M2's are absolutely fine :S
Someone else might have an answer hopefully.
Edit: Experimenting with other WMO's to see if I get the same issue.
Edit2: Different WMO's still give the same issue, no LoS with vmaps :(
Does anyone have any idea on why this is happening?
-
what u need to understand is noggit doesnt save WMO properly. ive spent days and days trying to fix this. its not getting fixed any time soon if not never. im sorry to bust ur balls on this news. its also the same when u spawn an npc on the WMO and have it walk on it. theyll just fall thru the WMO.
-
The question is.. why is there no bugtraker entry about this WMO collision problem?
-
its not getting fixed any time soon if not never. im sorry to bust ur balls on this news.
It's good to know I am not the only one with this issue.
Hmm... Soldan said he does not have this issue with V-maps, unless he was only referring to his M2's as well.
My V-maps work on custom maps (edited blizz ones) and even on custom continents (map id 5000+ for example), so I don't know why it isn't working for you :S
-
I got the problem too, with vmaps3.
With vmaps4, m2 dont work neither.
bugtracker/index.php?do=details&task_id=142 (http://modcraft.io/bugtracker/index.php?do=details&task_id=142" onclick="window.open(this.href);return false;)
for the tracker (fail project and cant edit, sorry)
-
I have done lots of debugging myself, using ArcEmu.
Maps, vmaps and mmaps generated fine. It all rendered without any errors and I added debug outputs to make sure my custom data was being loaded.
However it seems WMO's placed by Noggit, on Blizzlike or new maps, are completely and utterly fucked up. :)
I found some WMO's had partial to full collision when they are the only WMO on the ADT.
Other WMO's like cave's and larger objects had literally no collision.
The issue lies with the vmap generation, LoS is not found. I assume because the vmap data is incorrect that mmap data is also then not generated correctly.
In vmaplibMapTree.cpp function:
bool StaticMapTree::InitMap(const std::string & fname, VMapManager2* vm)
I found a constant crash that only occurs with this custom data.
if(success)
{
try
{
iNTreeValues = iTree.primCount();
iTreeValues = new ModelInstance[iNTreeValues];
}
catch(...)
{
printf("FATAL ERROR CAUGHT: %s", fname.c_str());
return false;
}
}
The try and catch was put in to stop it crashing. It now just refuses to continue the function when it decides to not work. I have no idea why the two lines of code fail, primCount(); just returns object.size(); - a vector. This does not return a valid value, it crashes.
I will continue experimenting. At the moment I am hackfixing with this global catch and by having a custom flag I put on creatures that allows them to ignore pathfinding and LoS checks.
It is not what I want but this seems to be the only solution I can use until someone with more expertise in C++ can figure out why the WMO's are so broken when placed through Noggit.
-
Value of iNTreeValues? I'd guess 0 or negative. What does the remainder of that function do?
-
Value of iNTreeValues? I'd guess 0 or negative. What does the remainder of that function do?
The full function:
bool StaticMapTree::InitMap(const std::string & fname, VMapManager2* vm)
{
bool success = true;
std::string fullname = iBasePath + fname;
FILE* rf = fopen(fullname.c_str(), "rb");
if(!rf)
return false;
else
{
char chunk[8];
//general info
if(!readChunk(rf, chunk, VMAP_MAGIC, 8)) success = false;
char tiled;
if(success && fread(&tiled, sizeof(char), 1, rf) != 1) success = false;
iIsTiled = (tiled != 0);
// Nodes
if(success && !readChunk(rf, chunk, "NODE", 4)) success = false;
if(success) success = iTree.readFromFile(rf);
if(success)
{
try
{
iNTreeValues = iTree.primCount();
iTreeValues = new ModelInstance[iNTreeValues];
}
catch(...)
{
printf("Caught fatal error!!! < MapTree.cpp, fname: %sn", fname.c_str());
printf("iNTreeValues = %dn", iTree.primCount());
return false;
}
}
if(success && !readChunk(rf, chunk, "GOBJ", 4)) success = false;
// global model spawns
// only non-tiled maps have them, and if so exactly one (so far at least...)
ModelSpawn spawn;
#ifdef VMAP_DEBUG
DEBUG_LOG("Map isTiled: %u", static_cast<G3D::uint32>(iIsTiled));
#endif
if(!iIsTiled && ModelSpawn::readFromFile(rf, spawn))
{
WorldModel* model = vm->acquireModelInstance(iBasePath, spawn.name);
if(model)
{
// assume that global model always is the first and only tree value (could be improved...)
iTreeValues[0] = ModelInstance(spawn, model);
iLoadedSpawns[0] = 1;
}
else
success = false;
}
fclose(rf);
}
return success;
}
It is difficult to reproduce but appears to occur when creatures try to move on these WMO's placed through Noggit.
Output from this function is:
(https://dl.dropboxusercontent.com/u/1102355/Untitled.jpg)
(https://dl.dropboxusercontent.com/u/1102355/Untitled2.png)
Here is a link to the 000.vmtree: https://dl.dropboxusercontent.com/u/1102355/000.vmtree (https://dl.dropboxusercontent.com/u/1102355/000.vmtree" onclick="window.open(this.href);return false;)
-
So the exception is a std::bad_alloc? Either RAM is full, or 97987 * sizeof (ModelInstance) > numeric_limits<size_t>::max(), which would be a huge ModelInstance.
Is there a ctor of ModelInstance that may throw?
-
So the exception is a std::bad_alloc? Either RAM is full, or 97987 * sizeof (ModelInstance) > numeric_limits<size_t>::max(), which would be a huge ModelInstance.
Is there a ctor of ModelInstance that may throw?
RAM is not full, there is 8GB free. It was compiled in 32bit so can't use more than 2GB RAM (?) but the server never uses more than 600-800MB RAM.
ctor = constructor?
class ModelInstance: public ModelSpawn
{
public:
ModelInstance(): iModel(0) {}
ModelInstance(const ModelSpawn & spawn, WorldModel* model);
void setUnloaded() { iModel = 0; }
bool intersectRay(const G3D::Ray & pRay, float & pMaxDist, bool pStopAtFirstHit) const;
void intersectPoint(const G3D::Vector3 & p, AreaInfo & info) const;
bool GetLocationInfo(const G3D::Vector3 & p, LocationInfo & info) const;
bool GetLiquidLevel(const G3D::Vector3 & p, LocationInfo & info, float & liqHeight) const;
protected:
G3D::Matrix3 iInvRot;
float iInvScale;
WorldModel* iModel;
#ifdef MMAP_GENERATOR
public:
WorldModel* const getWorldModel();
#endif
Note MMAP_GENERATOR is not defined.
Constructor definition:
ModelInstance::ModelInstance(const ModelSpawn & spawn, WorldModel* model): ModelSpawn(spawn), iModel(model)
{
iInvRot = G3D::Matrix3::fromEulerAnglesZYX(G3D::pi() * iRot.y / 180.f, G3D::pi() * iRot.x / 180.f, G3D::pi() * iRot.z / 180.f).inverse();
iInvScale = 1.f / iScale;
}
It shouldn't be that big - these are just normal WMO's like caves or buildings.
-
May you please check the type of exception thrown?
(catch (const std::exception& e) { std::cerr <<typeid (e).name() << ":" << e.what() ; }
-
May you please check the type of exception thrown?
(catch (const std::exception& e) { std::cerr <<typeid (e).name() << ":" << e.what() ; }
The following exception is thrown:
class std::bad_alloc:bad allocation
-
So, new ModelInstance[97987] fails.
-
So, new ModelInstance[97987] fails.
That seems like a stupidly large array - why would it need to be that big?
-
I am printing every time it is called now:
(http://i.imgur.com/RtzSnZW.jpg)
It appears to be created for every map loaded. This makes sense as it must be a root tree file that points to all the WMO's on the map.
The odd thing is that it is allocating the arrays fine as seen here. It randomly fails every now and then which will lead to a server crash when it tries to index a invalid position in that array from where it failed to create.
I do not see why the allocation would fail either - there is plenty of memory free.
Also it does not fix vmaps and thus mmaps on some these WMO's placed in Noggit.
-
Here is a temporary hackfix that works while Noggit remains private source and nobody who wants to can even try to fix it:
- Generate movement maps (pathfinding) and upload this data to the server, along with map data.
- Convert the WMO you want collision for into a M2 - this is difficult and is easier to just rebuild as a low poly model.
- Placed said M2 where your WMO is, and then delete the WMO.
- Now generate vector map data using this version of the map with only the M2 version.
- Upload vector map data to server, restore your client to the original WMO version for distribution to players.
This is a horrible, horrible fix and takes many hours for a single WMO. But it is necessary for dungeons and such...
-
Here is a temporary hackfix that works while Noggit remains private source and nobody who wants to can even try to fix it:
Did I not chat with you and said I will have a look? I realy dont like the sound of this sentence.
It seams that I am an lazy idiot who don´t spend any time for this community. I should reconsider my engagement.
If you know an solution, tell me what to change. Save code did not change since sdl in repo.
-
Did I not chat with you and said I will have a look? I realy dont like the sound of this sentence.
It seams that I am an lazy idiot who don´t spend any time for this community. I should reconsider my engagement.
If you know an solution, tell me what to change. Save code did not change since sdl in repo.
As many others have said, there is no reason to be closed source. It is annoying that we discover a bug and then have to wait for 1-2 devs who work on it as a hobbie to get around to it on their huge to do list.
That sentence expresses my frustration as you can tell. ;)
If the code for this part is the same then at least I can look at it.
-
And why not just tell me or Hanfer what you have found so we can fix it. As said no changes on save to open noggit repo.
For me the point is. Noggit is still open. The current version is out and everyone can look at it. And this was now for over one year so. No help, no bugtraker entrys. Nothing. Now as we dicide to start over on SDL everyone cry that we are so bad that it is closed.
The point is we want to clean up first before we open it again. Hanfer is also a big open source guy and it will again be open. But at the point we are happy with the codebase. QT development failed. We start over again with SDL. We forked it and at the point we are happy with our changes it will get again back to the public repo.
I also asked for help testing the 1.2 and 1.3 and expect Sergey NOONE answerd my posts.
The other point. I think there are only 3 till 5 guy now in the scene who would be realy helpfull, if they have access to the code. So if you want to help, just chat me on :) In irc or skype.
-
Find a way to fix this:
WMOs objects have three coordinates in the ADT.
The XYZ coordinates that set the position of the objects, and then some "upper" and "lower" xyz coordinates.
These coordinates must have a wide range of difference between the xyz position coords.
Problem is that noggit saves the upper and lower coordinates with very low values.
I had the vmaps problem with the stranglethon arena in a customized map, so i opened the blizz map where there is the arena in gurubashi, using the hex editor, and check the difference between the xyz position coordinates and the upper and lower coordinates.
I found that in the blizz map, the difference between the xyz coords and the upper and lower coords (for the strangleton arena) are aproximately:
x: +- 243
y: +- 190
z: +- 10
This means that if the x coord is 300, for example, the upper x must be aprox 543 and the lower 57.
Smaller wmos.. like walls or things like that, have an less range, like +-12 for X
(Noggits only set +-1 difference for all the xyz coords)
Properly setting this with an hex editor or taliis (previously veryfing properly the correct differences of the wmo in an blizz map), we resolved the issue of vmaps in our wmo. Is a pain in the ass to fix every wmo in the map (specially if resave our map)... but at least we know how to do it now...
However, the vmaps doenst work with the m2... still i dont know how to fix that.
Regards.
-
Ok,
I found ot that noggit is not properly saving the MCRF and the MCNK.nDoodadRefs + MCNK.nMapObjRefs variables, so the server doenst draw the damn objects and so, the vmaps doenst work.
MCRF sub-chunk
A list of with MCNK.nDoodadRefs + MCNK.nMapObjRefs indices into the file's MDDF and MODF chunks, saying which MCNK subchunk those particular doodads and objects are drawn within. This MCRF list contains duplicates for map doodads that overlap areas.
As both, WMOs and M2s are referenced here, they get doodad indices first, then WMOs. If you have a doodad and a WMO in the ADT as well as the MCNK, you will have a {0,0} in MCRF with nDoodadRefs and MCNK.nMapObjRefs being 1.
The client uses those MCRF-entries to calculate collision. Only objects which are referenced in the current chunk of the toon get checked against collision (this is only for MDX, WMO seem to have different collision). If a doodad entry from MDDF or MODF gets never referenced in a chunks MCRF it wont be drawn at all, WoW doesnt take the MDDF and MODF to draw the objects.
I tried to fix this saving the ADTs with an older version of noggit (rev 104) , and using the RefRep tool (both in the SDL an 104 version), but it doenst fix it...
The RefRep tool seems to screw the ADT structure, cuz when i tried to load the ADT in the Hex Editor using the template, i got an error and the ADT structure is not properly showed.
Hope that in the next version of noggit this would be fixed.
Regards
-
m2 work with the previous rev of vmap (vmap3)
(before this http ://github. com/TrinityCore/TrinityCore/commit/93d199f04382fe3c7f6f08f59fd2ad058568679a)
I am a very noob on c++, couldnt find where in this commit make it not work, but I think maybe we can downgrade some part of it?
-
Find a way to fix this:
WMOs objects have three coordinates in the ADT.
The XYZ coordinates that set the position of the objects, and then some "upper" and "lower" xyz coordinates.
These coordinates must have a wide range of difference between the xyz position coords.
Problem is that noggit saves the upper and lower coordinates with very low values.
I had the vmaps problem with the stranglethon arena in a customized map, so i opened the blizz map where there is the arena in gurubashi, using the hex editor, and check the difference between the xyz position coordinates and the upper and lower coordinates.
I found that in the blizz map, the difference between the xyz coords and the upper and lower coords (for the strangleton arena) are aproximately:
x: +- 243
y: +- 190
z: +- 10
This means that if the x coord is 300, for example, the upper x must be aprox 543 and the lower 57.
Smaller wmos.. like walls or things like that, have an less range, like +-12 for X
(Noggits only set +-1 difference for all the xyz coords)
Properly setting this with an hex editor or taliis (previously veryfing properly the correct differences of the wmo in an blizz map), we resolved the issue of vmaps in our wmo. Is a pain in the ass to fix every wmo in the map (specially if resave our map)... but at least we know how to do it now...
However, the vmaps doenst work with the m2... still i dont know how to fix that.
Regards.
i think this is the proplem and rather easy to fix.
there are 4 point info(vector3d) in each MODF entry, noggit handles the first 2 just fine, and the 3rd and 4th seems most likely the wmo's left-bottom-back and right-top-front boundary point(with north = back and south = front). with these 2 point it can draw a box, area out of boundary box means no collision at all.
i took a look into TC's wmo code, it doesn't generate collision outside this boundary box.
-
guys i figgured somthing might help if you need npc to fight on spawn wmo and not fall go to the creature template and change the npc movement type to 1 and inhabit type to 2 even if its 3 make it a 2 !!! and it do not work near ocean water only in land like when you spawn a necropolice up in doratar and spawn npc and make combat now they dont fall but when you spawn up ocean or water a ship or somthing they fal lol and in my custom map the wmo work fine even in ocean but only in my blizzlike map i have water wmo errors :lol: hope it helped you :D
and srry for my grammer hope you understand :cry:
-
It seams so easy to some of you, please can someone just fix this? I pay you!
For fixing noggit, fixing the extractor, or just helping me fix the vmaps with hex editor...
I beg you!
I tried to compile noggit, but cant even open it.
I tried to find the pos with 010 editor but didnt find anything.
And didnt find where to get the pos2 and pos3 in the extractor.
-
In current closed test version of sdl 1.3 we did some changes to fix this. But nonfeedback from testers in this point till now.
-
Hi Steff, thanks for your answer, it's great if the fix is already made!
Closed means we can't test it now?
Can you give access to this version? Or it's better to wait for the release?
-
We have a smal testing group with guys are able to also test the data.
So you have to wait till release with this,