Search results

By the way, you may have noticed that the in-game deformation sliders seem to have a more nuanced and precise range than mine.

Well, that turns out to be a temporary illusion; if you click on Done and go back to the face editor you will see how they stick to one of the eight available positions, even if they weren't lining up before. Smoke and mirrors.

Three bits, available range from zero to seven. Middle point being three, later remapped (or well, normalized) to negative to positive one.

So 0 is -1.0, 3 is 0.0 and 7 is +1.0, I believe. Not a lot to work with, but I guess nobody has noticed until now. :)

Veledentella said:

Any information if it is possible to do the above?

Click to expand...

The deformer sliders end up being normalized values in the -1.0 to +1.0 range, I think. So it depends on the actual values one puts in the skins.txt file as a mod developer.

Because my tool lets you set any field to any possible value within the available range you can probably contort faces more than usual, mainly because the in-game sliders have a set of restrictions where if slider X is bigger than A slider Y must be limited to B. You don't have these constraints here.

We have all seen the pygmy heads when the face codes are zeroed out or used in special code troops. Now you have full control about that, careful about choosing skin texture indices outside the normal range. It probably won't crash if the game is clamping the values correctly, but you never know.

Give it a whirl and let me know what you guys think.

Just for completeness, Earendil told us on Discord of a handy tool from 2019 by Marnid called MB Studio that seems so support previewing troops using the OpenBRF library to load assets, it can probably work in tandem with mine: https://github.com/djaessel/MB-Studio

The ModDB pages were seemingly deleted, but maybe there's a way to reupload the precompiled version somewhere. If not, the source code is still up.

I haven't really been up to date with what has been going on here, but I'm slowly catching up. A lot of great utilities and fun advancements since 2017. Props to you, guys. ¯\_(ツ)_/¯

There we go, I think it does all I ever wanted it to do. Have fun with this.

Improved the thingie a bit, now the buttons behave like the ones in the game.


It also supports dropping a custom skins.txt and choosing a race from the list to get the right mesh names. It's ugly, but everything is more or less in place.

By the way, and a bit off-topic, but I can't be the only one hating the XenForo move and subsequent reorganization of the TW Forums. Previously you could see everything from the main page, The Forge was one click away, now it feels like there's categories upon categories of nested boards to the point one gets lost, and the fact that the modding section is segregated from the main one is also a bit backwards. Normal people won't look here, while previously you'd see a lot of cross-pollination of curious players and visitors.

I generally like what Janus does, and I also know SMF as a forum system was obsolete and hard to maintain. But this is absolutely atrocious, and a great way of killing your healthy community. I am sure that there are other factors at play here, like the recent Discord-for-everything fad, and that it's been a while since the games came out, but I'm pretty sure this one is at the top. It's not just blind nostalgia, it is legitimately worse conceived and implemented.

One example; I have been trying to format the table and every time I type 8) the forum silently turns it into an emoticon. Doesn't seem like there's anything like the [nobbc][/nobbc] tag from the old system, there was also a checkbox to toggle if you wanted automatic smiley conversion, now it does it every time.

Quick heads up; changed/shortened the URL from https://swyter.github.io/mab-tools/face.htm to https://swyter.github.io/mab-tools/face, please update your bookmarks. Sorry for the inconvenience.

Improved and expanded the format and explanation of how to use the information in the table, hopefully it should be more approachable now.

Hi, Eärendil brought me here. The neg^multiplayer_is_server thing is very misleading. This is processed by the Python-based compiler when generating the weird lines that end up in the .txt files and it only works at all because the bits of both numbers don't touch.


The game sees the same M&B operation code / opcode. So what? Why? ¯\_(ツ)_/¯

An exclusive OR (XOR) works like a plain OR whenever both bits are not one, see the truth table here and compare XOR with OR. So using this for flags is a bit like falling sideways while going down a rail but sticking the landing; ^ technically produces the same result, but when you want to combine flags in a bitfield with the rest of a number you really want to use the | operation to merge all the 1 bits from top and bottom into the same number, you don't really want that your bits return zero whenever the top and bottom bits are one, even if in this case does not happen, so you don't get this unintentional behavior with these particular module system numbers.

And I don't want to sound mean, but don't think the precision argument has any merit in this case because you are not shifting/rotating bits left or right, they stay in place, and they are of the same type/size. Sounds a bit like programming snake oil.



In the table above, if you do an OR operation, as long as there is some 1 in the input (e.g. 1|1, 0|1, 1|0) it will output one, for XOR if both are one (1^1) will be zero, this is generally used to negate or toggle boolean variables easily. Turning True into False and vice versa.

TL;DR: Don't get me wrong, XOR is very useful for many other low-level and fun operations, but it shouldn't be used for concatenating flags. I can use other unrelated operations that also give the same result and look cool, but that doesn't make it right.


Hope that helps at least a bit.

Probably because the uninstaller ran during the next startup, or the environment variables (like %PATH%) got flushed after the logoff-logon dance.

How are you running cartographer.cmd? This is essentially telling you that vectors.lua does not exist, but if you take a look inside the .zip file it's part of the files. Are you extracting everything? Can you show a screenshot of the extracted folder?

Because otherwise here it seems like you still have a luajit.exe in your %PATH% from some other application that is launching instead of the bundled one. Press Windows key + R, write cmd then press enter, and type luajit and press enter and see what happens.

If that succeeds then you have a global LuaJIT instance. Try editing cartographer.cmd and replace @luajit with @.\luajit. That way it should pick up the local, bundled one.

Hi, sounds like you've been installing a Lua distribution like you would for Python and trying to launch Cartographer with it.

The short version is that this is a self-contained package with its own bundled version of LuaJIT.exe and vectors.lua, so you only need to double-click cartographer.cmd to launch it, as shown in the guide.


There are no library or software dependencies or anything, you only need to extract the whole thing and run it. If running cartographer.cmd throws some errors and doesn't work for you please post the logs or screenshots here.

Epic Games Store does support both modding tools and experimental versions of games, they even have early-access stuff. GOG also supports branches and at least downloadables/goodies. I already told people this on the M&B modding Discord server, but it's probably a logistical issue for TaleWorlds; they think it's too much work to ship them all at once.

I think it's a good idea to have feature parity for the same price, at least take advantage of the TaleWorlds account system to verify purchases from other stores and let people download files directly from the site (just like the previous trial-ware games) as a band-aid until the game exits early access. Or well, if you have the bandwidth just make the modding tools publicly accessible. They can't be used without the base game.

Ideally we'd have everything everywhere, the company is big enough to automate a release submission, as long as they share files. They should.

Yeah, «make» is a different program, the one that actually does the building and orchestrates calling the different programs. «qmake» in this case generates the recipe in this particular format (a Makefile in the same folder), but as you can see above it can actually generate «recipes» for other similar targets that aren't «make», like Visual Studio.

What I meant in my previous post is the equivalent of the «build-essential» metapackage in Debian and Ubuntu; it includes «make» and more stuff: https://tecadmin.net/install-development-tools-on-ubuntu/

This stuff can sound arcane and mysterious when you start using it. So I get you. Also, just for the record, for OpenBRF you need vcglib v1.0.1, more modern than that and it won't work.

Good luck, I know you can do it, don't forget to change the VCGLIB variable in openBrf.pro to point to the correct folder and the other fiddly stuff I take care in the Arch Linux thingie. ¯\_(ツ)_/¯

You actually need to use a third-party tool to do it because Valve has patched the official SteamCMD and Steam console versions to try to curb leaks and that kind of thing. Here's your only avenue, combine with SteamDB sleuthing and shake vigorously: https://github.com/SteamRE/DepotDownloader/releases

I imagine it has to do with Qt5 being the norm now. You can probably open the project with Qt Creator and give it a go at compiling, it should be more or less retro-compatible, I think. Maybe a few lines here and there need to be changed whenever it errors out. It probably won't be too difficult.

The packages for Mint seem to show up here. You'll need gcc or clang and some other common C/C++ build tools.

You can also see how the compilation, paths, icon and shortcut are created in the Arch Linux package version here, it also needs to install a specific version of vcglib, everything should be there: https://aur.archlinux.org/cgit/aur....=e50da5fdb7d622e164c32bb6915b6dac497810ee#n25