Skarn

That is useful. Guys, turn on subtitles

If you leave it even on one adt, it will appear in Noggit and get saved to all again. An option would be to use fileinfo/loadinfo on all surrounding ADTs.

Ask Miton. That's quite an obvious solution in that situation.

No. Extract, import back.

Switch you FuTa to grayscale mode and reinject those images. See what happens. If it does not work from the first time, try fresh adts - FuTa for transfering alphamaps and heightmaps, fileinfo/loadinfo for models. All the software should be in WoWDevKit.

They are a part of ADT. Basically, it is 1-3 grayscale images (per every paintable texture layer) stored in the ADT to define where you have the texture and where you do not (roughly speaking). There are quite many ways it can be presented in the client. I will tell you 3 types now. In some old zones sometimes you have unflagged alphamaps that are 63*63 image per every chunk. Last row and column of pixels is filled with shit. Usually just copied last line. It looks like nothing related to the screenshots that were provided. Usual (small) alpha is 32*64 (it has less columns and one pixel of 64x64 map used in Noggit kinda gets sretched to the second one, so the image looses the quality). The do not fix thing we talked about before is also usually presented based on the same small alpha principle but also crippled by not having one row and column of pixels at all. Big alpha is one true 64x64 map. I do not claim this 100% correct, I could have forgotten something since the last time I had a look into it. Okay, enough of theory. You image seems to be either small alpha that was saved as big alpha or big alpha saved as small alpha. Try exporting alphamaps with FuTa and show them here, so we can tell you more.

His Noggit crashes, not the game as far as I understand.

Huge thanks to you and Relaxok from me for posting this resource.

I see big alpha read as small alpha.

Since Northrend, yeah. There is no reason to keep usual alpha. Usual alpha is 32*64 (stretched image, one pixel is two pixels in a row if covnerted to 64x64, that also explains decrease of the quality ingame after you save in Noggit). Big alpha is 64x64.

There is currently no way. Until Noggit learns to read and save big alpha. Your adts are now in small alpha. When you add small alpha to big alpha map or vice versa = crash. But there also would be an option for conversion but it would require a separate tool to be coded. If you need infomation on this theme, I can provide more.

Yes, there is. It is called Loadinfo and Fileinfo. It must be in the CMD folder of WoWDevKit.

Try flying around without water, model and terrain rendering. Get to the crashing ADT. If there is not crash, start enabling render elements one by one in the following order: 1) Terrain, M2 models, WMO models, Water. When you find the reason for a crash (and if you do it) report it here. Maybe there would be a way to help you.

What's the crash message?

Yeah, that was my idea. Programmers are often not interested in that kind of stuff, they just like messing with code and WoW modding is often just a programming practice for them without interest of making a project. And by the way, what does Modcraft has to do with all of that? I am more than sure that it will never be brought into life on Modcraft because of well... reasons why this website exists. And besides, Steff said a lot of times that his opinion on any money in modding is negative, thus not even worth discussing, especially here.

I had that idea a while back and I even installed some donation system here (not visible for users). I thought that we could donate some money together to encourage some programmers to code some tools. But the problem here is the way money would be delievered to developers. What if to say two guys worked on the same thing? That could turn into a conflict when they decided what percentage of the offered sum each of them gets. There are many possible problems with that concept. Another reason it is not set up here is that I personally do not want to deal with other people's money, at least in the current situation. I am more than sure that some people would be claiming that we are taking some money for ourselves while they were to be sent to programmers. Regarding lies I keep hearing about myself now, thanks to efforts of some people, you do not even need to guess that this would happen. It still would be better than coding that for free. In that case you'd get at least some reward. Of course, it is not likely to cover a price of an actual software development of that kind. Between projects would be easy. The available donation system here can handle multiple funds. So, to say you have one separate sum for Noggit, another one for something else and so on. The community decides what should we gather money on. But the developer distribution still remains an issue. It could work, in my opinion, but requires a lot of thinking over. And I am open for ideas on that matter actually.

I had that idea a while back and I even installed some donation system here (not visible for users). I thought that we could donate some money together to encourage some programmers to code some tools. But the problem here is the way money would be delievered to developers. What if to say two guys worked on the same thing? That could turn into a conflict when they decided what percentage of the offered sum each of them gets. There are many possible problems with that concept. Another reason it is not set up here is that I personally do not want to deal with other people's money, at least in the current situation. I am more than sure that someone people would be claiming that we are taking some money for ourselves while they were to be sent to programmers. Regarding lies I keep hearing about myself now, thanks to efforts of some peoplem, you do not even need to guess that this would happen. It still would be better than coding that for free. In that case you'd get at least some reward. Of course, it is not likely to cover a price of an actual software development of that kind. It could work, in my opinion, but requires a lot of thinking over. And I am open for ideas on that matter actually.

Hello, Model Changing. I really need some help. I know we have quite some members who attempt or already successfuly mod WoD. I have currently faced a problem that there are no WoW.exe with GLUE/XML check removed for version 6.2.4. I also received some questions about it from our and Modcraft's users but could not help. So, I want to ask you guys if someone has it to share it publicly on MCnet. The help would be appreciated. I would not mind other things that you might be using for WoD modding, but that's up to you. Thank you in advance from me and other people who are interested in having this file.

It is not hard to do. Just rename all the DBC files to something else and change their header. Do the hex edit of the wow.exe. That would cut down a huge part of usual patch stealers because they do not know things more complicated than adding a listfile from WoW. And skilled people who actually are capable of cracking it no matter what you do are usually not interested in stealing. So, that works perfectly and is really fast to do. I agree, but in reality it probably won't happen because there is an extreme lack of motivated and interested programmers.

That's exactly what I meant in other words, thanks.

You are right. The thing that matters is who would be able to open those patches. I have no doubt that you, me and many other experienced guys would do that without any problems but usually those who actually want to steal the content from some server are noobs who can't create something themselves or just stealing some retroporting work. Against those something harder than listfile breaking works like a charm.

That's the same technique that is used for decrypting patches. Find known files by headers (DBC), there you can get names for maps (not only), so you already know how the path to WDTs, so you read them and find out what ADT files you have. From ADT files you can get the list of used M2s and WMOs. Inside WMOs you also get a list of M2s and Textures, Textures in M2s and so on and so forth. It is a step by step process. It would be relatively easy to code in 010 editor if there was a commandline MPQ unpacker that works with custom listfile information, but there is none. Anyway it would not be a very serious task for a decent programmer who can use Stormlib and make some standalone tool. And that is, by the way, the same method that people use for stealing listfile-free patch content, so it turns that way of protection into some kind of cure against noobs. For real protection, one would need something more complicated, and there are better ways actually.

You could release it as is and someone might fix the park.

There is a script mfbo editor that fixes that. Doing something manually in 2016 is weird.