Okay, so after spending several weeks figuring out how to add custom walls and doors for house customization, Mythic breaks it for me with a patch. Dunno what patch it was, but I was doing a core update. Got everything merged just fine, compiled the new core and was able to log in. Everything was stable, so I committed the update. Now I found out that the custom walls and doors I added are screwed up. When you try to add them during house customization, they "delete" the tile right behind them. So if the wall faces north to south, the tile behind the wall to the north gets "deleted". This makes all the doors and walls invalid placements. I tried adding them manually and noticed that when I placed them, I couldn't walk behind them. So which packet got changed that screwed with the Z level? That's got to be the problem, right?
- Thread starter tass23
- Start date
This is just a guess, but:
Do you need to change the map sizes?
6144, 4096 OLD
7168, 4096 NEW
I have found that with the updates map areas are gone (Primeval Lich area removed), or screwed up....dressers 1/2 way across the world...REALLY OSI?!?!?!
If worse comes to worse, use your older map/static/staidx with the newer client.
Do you need to change the map sizes?
6144, 4096 OLD
7168, 4096 NEW
I have found that with the updates map areas are gone (Primeval Lich area removed), or screwed up....dressers 1/2 way across the world...REALLY OSI?!?!?!
If worse comes to worse, use your older map/static/staidx with the newer client.
This is still an issue....Red, I haven't changed anything on the maps or statics...just updated the core to support .net 4.0 and clients up to 7.0.30. I got a PM on here awhile back with some suggestions, but alas those didn't work either.
Could you please post a screenshot? and one pic of the walls you're adding?
I will test this.
I tried adding wall via your instructions, but I can't see my walls at all. I may have done something wrong, or it could be that damn client issue.
I'm using client (7.0.34.6 and 7.034.15)
What I've found so far is that it seems that the client is the "holder of the keys", meaning even though we all can see the body.def/tiledata.mul/innards if you will... that eventually these will be gone and it will all be via the client and squashed .uop(s). I ~could~ be wrong..and I ~SO~ hope so!
Here is how I came to this conclusion:
Tileart/Gumps/Animations:
It use to be that you could add tileart, then the gump within the correct ranges, and then "link" them via the tiledata.mul with flags (wearable,artA,armor,etc) and quality settings (quality-4) and set the animation to the gump number -50k (or just the animation number with mulpatcher), and set up the body.def with the /gump number -50k {anim#} hue#/...and all would be golden.
Now....
When you set the anim# in the tiledata for the gump -50k, it ~will~ give whatever animation is already set. If there isn't any animation there and you add animation..it ~still~ won't show this new animation. This is with every conversion I could think to test: body.def, bodyconv.def, equip.def, stitchin.def, mobtypes.txt, gump.def,etc,etc.
This is also the issue for the custom mounts; the client is "setting" this tileart 0x000 can be mounted as animation # 0x0000.
I'm using client (7.0.34.6 and 7.034.15)
Code:
45 9 1119794 20502 20506 20523 20504 20503 20508 20522 20505 20515 0 0 0 0 0 0 DraíochtWalls
45 3 0 0 0 0 0 0 0 0 0 0 20512 20514 20509 0 0 0 DraíochtWallsWhat I've found so far is that it seems that the client is the "holder of the keys", meaning even though we all can see the body.def/tiledata.mul/innards if you will... that eventually these will be gone and it will all be via the client and squashed .uop(s). I ~could~ be wrong..and I ~SO~ hope so!
Here is how I came to this conclusion:
Tileart/Gumps/Animations:
It use to be that you could add tileart, then the gump within the correct ranges, and then "link" them via the tiledata.mul with flags (wearable,artA,armor,etc) and quality settings (quality-4) and set the animation to the gump number -50k (or just the animation number with mulpatcher), and set up the body.def with the /gump number -50k {anim#} hue#/...and all would be golden.
Now....
When you set the anim# in the tiledata for the gump -50k, it ~will~ give whatever animation is already set. If there isn't any animation there and you add animation..it ~still~ won't show this new animation. This is with every conversion I could think to test: body.def, bodyconv.def, equip.def, stitchin.def, mobtypes.txt, gump.def,etc,etc.
This is also the issue for the custom mounts; the client is "setting" this tileart 0x000 can be mounted as animation # 0x0000.
I don't completely understand this yet, but here is the changes in the clients from 7.0.7.1 to 7.0.34.6 to newest 7.0.34.15.
http://rapidshare.com/share/8A4D1B91F3D110C44E5BC62BADE61119
The individual text files were too large to upload here. Hopefully someone can make heads or tails of this.
http://rapidshare.com/share/8A4D1B91F3D110C44E5BC62BADE61119
The individual text files were too large to upload here. Hopefully someone can make heads or tails of this.
Do you know which client the changes with body.def etc. took place? (Seems to be working ok in client 7.0.23.1 so probably some time after that, but I'd be curious to know the latest version of the client that will work). Also, something else that has changed - the client used to read MUL files from the installation directory (as read from the system registry) no matter where the client.exe was located. Now the client reads its client files from the same directory as client.exe and no longer gets it from the registry.