[QUESTION] Ingame error: npcs falling to ground from WMOs

[Magnus]

This issue sounds exactly what I discovered now. Somebody found any solution ?

My case:
I copied in Noggit the dock from Ratchet (ratchet_dock.wmo) to another place I wanted to have a new harbor.
I use TC and recreated all maps, mmaps, vmaps for the server.

Than I spawned some NPCs on the dock. They stay, that's not the problem. But they don't move.
- If the NPC has random waypoints, he just stays on it's spawn point. Didn't try to move.
- If I make individual waypoints (a way to harbor and back to the dock) the NPC is walking but if he comes over water (means water is under the dock) he is falling through the dock into the water and continues to walk back to harbor ^^.

First I thought that's maybe a normal behaviour either of client or server. But than I spawned the same NPCs on Ratchet on the same dock. And there everything is working fine.

So I guess if have to set somewhere in the ADT a flag or something like that to make the WMO marked as solid.

Any ideas ?

[Amaroth]

Server side maps, vmaps and mmaps need to be updated. You have changed map on client side, fine, but don't expect that server will somehow change it on its own on its side too .

[Magnus]

?

I wrote:

I use TC and recreated all maps, mmaps, vmaps for the server.

[Amaroth]

Than you haven't updated (re-generated) them properly. Wth was that topic about thet... I can't find it, nvm.

I have noticed that when having part of map in 1st MPQ and part/newer version of map in 2nd MPQ leads to having data extracted only from 1st MPQ and data from 2nd one is simply skipped during generation. So, if you are extracting map data from map files which are being split across more MPQs, and thats just case anytime you modify blizzlike map, it can help a lot to put all data into just one MPQ. Friend of mine once told me that modifying blizzlike MPQs can corrupt them, I have personaly never tested it, but I keep a whole non-used client just for extracting purpouses, to make sure that all map files are together and are extracted properly.

#TC extractors.

[Magnus]

Well, I was working quite a lot with TC map extractors and have added some loging functionality and the ability to limit the creation process to only a specific map etc. At that time I just was curios what's going on inside and it was quite interesting. I learned a lot about adts.

Therefore I'm quite sure that all patches are read in the way they should.

Additionally I can see ingame that the new maps are working. Because I also changed some ground terrain. And on the ground players and NPCs walking fine. With wrong (old) maps they sometimes fly over or walk beyond the map.

If I understand you right you tell that if data (map) in a higher patch has newer timedate the TC extractors may extract only this one from the older patch with lower number. Did I understand you right ?

But that would be a heavy bug in the extractor because that's the basic of MPQ patches.

But let's make another brainstorm:

Is it a serverside issue or is it a clientside issue ?

Personally I think it's a clientside issue (if it is, we don't need to think about map extractors longer).

Why I'm thinking so:

When I add manual waypoints to a NPC they are saved in the database. I can also visual check them by a GM command. The waypoints are correct. So I guess the core is nothing else doing than sending these waypoint coordinates to the client. With other words: The core is sending correct coordinates to the client. Regardless on any maps.
So the client receives the coodinates of the NPC and is trying its best to move the NPC over terrain and objects like dock wmo. At this point the server core is out of the game. It's the client who handles the movement of the NPC. Therefore if there is a bug, the bug should be in the adt.

This is my understanding what's happening. Would like to hear your opinions.

EDIT:
And btw, the map extractor of TC was able to read only till patch-5. At least in Jan 2015. Don't know if they fixed it ever. If not I made this:

Code: [Select]

diff --git a/src/tools/map_extractor/System.cpp b/src/tools/map_extractor/System.cpp
index a573f9f..7d90f36 100644
--- a/src/tools/map_extractor/System.cpp
+++ b/src/tools/map_extractor/System.cpp
@@ -100,6 +100,15 @@ const char *CONF_mpq_list[]={
     "patch-3.MPQ",
     "patch-4.MPQ",
     "patch-5.MPQ",
+    "patch-6.MPQ",
+    "patch-7.MPQ",
+    "patch-8.MPQ",
+    "patch-9.MPQ",
+    "patch-a.MPQ",
+    "patch-b.MPQ",
+    "patch-c.MPQ",
+    "patch-d.MPQ",
+    "patch-e.MPQ",
 };
 
 static const char* const langs[] = {"enGB", "enUS", "deDE", "esES", "frFR", "koKR", "zhCN", "zhTW", "enCN", "enTW", "esMX", "ruRU" };

[Amaroth]

"If I understand you right you tell that if data (map) in a higher patch has newer timedate the TC extractors may extract only this one from the older patch with lower number. Did I understand you right ?

But that would be a heavy bug in the extractor because that's the basic of MPQ patches."

But it is so. When I had my modified PvPZone02 map in patch-3.mpq (yes, I was using that blizzlike one), map files were extracted only for blizzlike content from patch.mpq where original PvPZone02 files are stored and those custom put into patch-3.mpq were completely ignored. Don't ask me why, but it was so and the only one thing which truly solved that for me was putting my modified map into patch.mpq itself. Extractors did read and use patch-3.mpq, but by than they were already "done" with PvPZone02 and weren't even checking for more of that map's data, apparently. Just btw, as far as I know it is not that in common that in MPQs in Data folder (not in Locale folder) are duplicated data. All files I have ever seen were only in one of MPQs and had no other version in another MPQ, but I might be wrong in this case.

"When I add manual waypoints to a NPC they are saved in the database. I can also visual check them by a GM command. The waypoints are correct. So I guess the core is nothing else doing than sending these waypoint coordinates to the client. With other words: The core is sending correct coordinates to the client. Regardless on any maps."

Tbh, that proves absolutely nothing. Because that display function for waypoints only spawns temporary wisp NPCs (ID 1). Btw, those wisps have fly. Both NPC and waypoint coordinates are in 3d system, they don't care about ground height coordinate, so that you can spawn waypoint into something what might be just empty air for server and that waypoint wisp appears in place which is for server air is just how it works and is supposed to work. So, sadly, what you wrote and tryed means nothing in this case :X.

About sending data to client, you are slightly wrong here, too. Server knows where waypoints are, server handles NPC movement (by using vmaps and mmaps) between those waypoints and to client are sent results of calculations of NPC's movement. Which means that client may (or may even actually not) know coords of waypoints, but it has quite likely just absolutely no or little use for them (well, I believe client actually works with NPC movement a little bit too, but most of calculations would be still made by emu). NPC also needs more than waypoints to determine how it moves - it needs to know about collisions with other models, with gobs, with terrain... Letting client do so would not be very hack-proof, smart or responsible by both blizzard and trinity devs.

I have been working with custom and modified maps for years and whenever NPCs were moving oddly, it was server side map files fault. Server may know very well where waypoints are, but if it thinks that they are somewhere in the air, above a terrain or out of building's floors, it will just attempt to make NPC (if it is not flying NPC) move on something what server thinks should be ground/floor, to prevent it from flying effect. Sadly, on customized maps it is this what actually makes flying effects.

[Magnus]

Thank you for the interesting explanation.

I have to think a little bit about how to put all the stuff in one MPQ only. At least it would be worthy to give a try.
But just wanted to remember that some of the extractors never was able to read a file like patch-6.mpq f.ex. That was maybe also a reason for some confusion.

Before I do the MPQ compression stuff I would like to do another simple test:

I will copy the original dock.wmo in Ratchet and will put it a copy of it beside the other in the same adt. Than I will recreate the maps and check what's happening.
Possible results are: Both dock are not working, both are working or only one of it. ^^

The result may could proof if it is really a timedate based issue of reading different MPQs. Because than both docks would be in the same adt and than in the same new mpq file.

Do you agree ?

[Amaroth]

That might work (well, I am not entirely sure if I get what you want to do well).


My original issue with PvPZone02 files was that I have completely recreated WDT file, changed amount of ADTs and even their coordinates. On coords where original map was I had blank space, I didn't have even 1 ADT there. Both my ADTs and WDT were in patch-3.mpq, while blizzlike map was in patch.mpq. Sadly, extractors were still extracting that blizzlike version (I have figured that out quite simply - I have just checked tile IDs in map files names, from my ADTs were extracted no data, from blizzlike all data while those should not exist at all anymore). Re-moving my ADT and WDT data to patch.mpq solved that. I had also similiar problems with extracting data for my Stormwind map - again, outdated blizzlike files were being extracted, while mine were not.

So, find where (Kalimdor I suppose) map is located, in which MPQ, try to add your modified ADT into that MPQ so you really literaly overwrite blizzlike version. That should definitely work. Placing that modded ADT into another MPQ works for client, noggit, MPQ editor, WMV and whatever else, but it seems it doesn't work for extractors as it should, at least not in all cases.

[Drikish]

Hi there - the only way to stop npc's from running through wmo's is to generate M-maps for your server.
This generates a low res wireframe of vertices from the game world as a hole in chunks. The game then know a where, objects exist and calculates box movement according to logic. Aka if you jump off a wall the npc's will find a path down to you.

[Magnus]

Hi,
mmaps may solve a different problem but not this one in my case.

I can proof that. As for TC the mmaps are optional. I had just switched them off (be renaming the mmaps folder and may changing the config file ? I have forgotten ^^) so the core is using the vmaps only.

After that I checked the dock.wmo in Ratched. The original one by Blizz is still working while the copied one by Noggit is not.

In the meantime I found out that I also don't need to test this issue with NPCs. The GM command .gps shows all relevant information about this issue. Walk over the original dock and make .gps. It will show something like that: ground level -20, floor level +5. That is when the vmaps are extracted fine. The core recognizes that I'm walking on the dock on a level of about 5 meter. On the Noggit placed dock wmo you have always ground and floor level at f.e.x -20m, means the dock wmo is not recognized well.

By examining the adt file in detail I have seen this:
The original dock is referenced in all MCRF sub-chunks it is in like these coordinates of sub-chunks:
12/0 13/0
12/1 13/1
12/2 13/2 14/2

As you can see these chunks are exactly the L-shape of the Ratched dock.

Noggit does not save the dock wmo in the same way. I believe that's may why the extractor isn't working well after.

Amaroth's hint with MPQ didn't helped me in this case. I put my ADT in different MPQ, also patch, patch-2, 3 wherever it makes senses. But no change.

[Amaroth]

Juuuuust a question. What noggit version are you using? There have been some issues with WMO models in older versions which were fixed in SLD... 1.2? 1.3? Anyway, the newest version wouldn't hurt, if you don't use it.

[Magnus]

I use 1.2

With 1.3 and 1.4 I have only tons of problems and they save things in a very strange manner.

BTW: THIS issue I have tested with all 3 versions of Noggit already ;-)

[Amaroth]

With 1.3 and 1.4 I have only tons of problems and they save things in a very strange manner.

They do so for pretty good reason. Still, if you have tryed the same with them and it didn't work out, then I am just out of ideas.

[Steff]

pre.  sdl 1.3 dont save the wmo data right.  so wmo map calculation dont work.
copy map to ankther project.  save all adts once with sdl 1.3 or heigher.  run extractor on this adts.  trow then in trash.

[Magnus]

I just found the project folder when I was testing it with Noggit 1.3.

But I will do it once more. May I made a mistake. I have now so a lot of copies of folders for testing purposes.



EDIT:
Tested once more with Noggit 1.3 and 1.4 by recreating vmaps. Still doesn't work.