mikero

download the latest dll (7.35 or better) which 'fixes' this issue. --- background: bis moved goalposts here (in a good way) the += >binarised< operator is so unreliable and subject to host of reasons where it' can't work versus can work, that bis now convert it to a simple = IN THE CPP file, where they can. 'where they can' is when the original (in your case) muzzles= exists in the same pbo I do same, with some differences, i will find muzzles= at any nested depth, while bi restrict it to just one. Be that as it may, neither tool can replace the += operator if it can't be found. And again, the difference here is I warn you of the unreliability of that operator (if it can't be found) the latest dll treats it as a warning only, not a warnings are errors. This should satisfy the needs of most people.

There are reasonably clear instructions in the readme's accompanying my tools. You were told this on EVERY splash screen of EVERY tool of mine that you installed. start programs->mikero->depbotools->any.exe->documentation. you can navigate to the very same files by: c:\program files (x86)\mikero\depbotools\some_exe\documentation the 'documentation' can become rather extensive depending on the complexity of the tool. for the simple ones, 'documentation' simply means 'readme.txt' ---- the default conversion is to 8wvr (unbinarised, arma format). This, is equivalent to the exported wrp that would have been made in the other direction. Ie Terrain Builder (or visitor3) > export. you can also discover this for yourself by simply typing: convertwp in a dos prompt it will give you the syntax required on the command line to make the magic happen. The uninitiated, the 'syntax' is in what's known as 'bachus_naur format'. Any dos tool worth paying for, from anyone, closely adheres to it. Learn how to read it once, you read 'syntax' forever. in your case: convertwrp NameOfWrp 60 will produce a NameOfWrp.pew ---- absolutely. Its already in front of you in the config.cpp/bin that came with the wrp. These 'classes' have nothing to do with the wrp itself. ----- as for satmasks and etc, this tool was written for arma1 and 2 where a recovered satmask served no purpose because there was bugger all you could do with it to improve the resolution it already gave you. While this comment applies equally to arma3, the goalposts have changed a little, in that, you are supposed to additionally, manually paint the satmask with roads and bulding shadows etc. An excellent tool from PennyWorth already exists to regenerate satmask out of the layers folder of the wrp you're interested in.

just to be very, very, clear about this. A binarized file does not have #includes. The contents of the include file have been binarized into the main file and the include itself is no longer relevant. The exception (if you want to think of it that way) is description.ext. The description.ext is only ever binarized at mission load time. Up to that point, include files ARE relevant. So what pboProject does is check that those includes exist and that when mission load time happens, there are no other errors either. To do this, it binarises description.ext and throws the result away, because it's only interested in discovering if there will be errors when you hit show time. ---- dedmen has also correctly pointed out the use of .h OR .hpp include files. _because_ under normal circumstances, everything in the universe gets binarized, it's assumed (correctly) that .h and .hpp have no business being in a pbo because they serve no further purpose. But, (there's always a but). There are some circumstances where you do need include files, and description.ext is one of them. To satisfy the demand for NOT placing useless crap in the pbo, but retaining what is useful, YOU get a design choice. All .hpp files will be included OR, all .h files will be included. Which one you decide you need is up to you.

>The PBO is created without any errors. of course. most, nearly all 'pbo packers' are wyswig, they neither look for errors, nor do they binarise anything. >ErrorMessage: Include file macros.hpp not found. well the bottom line here is that my tools DO binarise mission.sqm, they DO check description.ext is correct. And you are suffering with poorly constructed includes. the above error is simplicity itself, macros.hpp either genuinely doesn't exist at all, or, it's not in the same folder when attempting to include it. eg whatever file is saying #include "macros.hpp" then that file MUST be in the same folder as the include! >#ifndef VANILLA well, I am guessing here, that your fixed up include stream was 'fixed up' because a) the order of includes was important. and/or duplication was found. My tools will not take prisoners. It simply will not make a pbo if there's even the slightest fault. Bis can sorta/kinda ignore issues if they want, and your mission will sorta/kinda work. But with my tools there are no mysteries why things went bang, in-game.

>If there's a better place to ask this question direct to me on discord in either the arma, or dayz channels or, since you're a subscriber, you can raise a ticket direct at bytex >'MakePbo.exe' is not recognized as an internal or external command The environ path has not been set. This is done whenever you install the depbo dll. A warning message would have told you if that couldn't happen. The more common cause is, you are running as a different user to the one you installed under, OR, (much much much more common) you are attempting to run my tools AsAdmin. My code explicitly prevents that happening to protect you. >memory usage limited by a page file. this is bis binarise, not me. The cause of this occasional error is unknown. It _appears_ to be connected to a non power of 2 paa or png image. If you're getting this kind of error I strongly suggest joining the discord channels where there are experts who've been there,. dun that, and can help you with bi's strange messages.

>and pay for other tools that i dont need ho ho ho. https://github.com/pennyworth12345/A3_MMSI/wiki/Why-use-Mikero's-Tools%3F

First of all, convertwrp is only meant to be available to subscribers. It's current subscriber version is 1.81 (not 1.78) as for the dll at 5.24!!! the latest free version is 7.16 and the subscriber version is 7.23. You have such an old version of the tools it surprises me they work at all. To answer some of the mysteries you've mentioned above: Type 73 p3ds are arrowhead/Arma3, and are handled by the free dll version quite well. Your dll would not even know what what it is so must reject it. And again, although fortunately for you it has no consequence when converting, The type 41 mapinfo objects and beyond were only introduced recently and are simply ignored in earlier dlls with no pain involved. So your choices are to update your versions to the latest free ones, and pray that your convertwrp remains compatible, or simply become a subscriber. Both methods are available to you at: https://bytex.market/products/item/weodpphdknnzm70o0h8q/Mikero's Dos Tools

my tools are ALWAYS backward compatible with all versions of the RV engine, including xbox and even the very first cwc beta. Both, Eliteness, pboProject, and, makepbo will create (and sign) xbox files for you. https://armaservices.maverick-applications.com/Products/MikerosDosTools/default problem solved

yes. in both cases you are 'allowing' the compiler to 'see' the macro defines. The rule is, "quotes" prevent any form of macro expansion. if you prefer, instead of using QUOTE (which you might find unwieldy with it's (brackets), you can: #define QT # serverInit = QT expression QT

unfortunately the image above is too small to read the error. As Q says, join discord for faster answers.

I am curious to know how on earth you equate HEIGHT measured in meters with an image file. Be it tiff, png, bmp, or spaghetti Icons with purple dots. What possible information could any tool (such as TB) glean from a 2 dimensional pixel image that could define, mountains, and valleys accurate to 10cm ? If you really do want to know more, read up on what the internationally used formats of xyz and the mutually equivalent asc actually contain.

At the time, i didn't think it necessary to provide an alternative of using an exclude.lst file. The exclusion btw, is wildcard specific. So, some authors call all their non-compressible sqf zThing.sqf, or thingy_z.sqf. You can then use a wildcard as in z*.sqf, or, *_z.sqf to replace all the rest

the input box for compression will take up to 32,000 characters.

it's stated in the splash screen of ever tool of mine that you install. start->programs->mikero->dos tools->nameOfTool->readme & docs you have a mismatched version between the free depbo.dll and some crappy stale copy of eliteness taken from somewhere ten years ago, or worse, some borrowed copy of the subscriber tools, and that is explicitly prevented. download ALL the free tools the engine operates in two modes. one that uses precompiled assets (such as config.BIN, or prebinarised mission.sqm). These are loaded at game start. Game Time refers explicitly to items that are compiled when you start a mission. Notably, description.ext. Everything in there is compiled on-the-fly with values such as pixelH which (probably) would not be known at game start time. I don't support the sqf format statement for use in exec/eval. It *generally* refers to a variable or variables that cannot be precompiled into a binary asset. There is no mechanism in a binarised paramfile (mission.sqm or config.cpp) that can read and store a variable. something= "Format(blah)" is not the same thing, 'something' is a constant, containing a string. I personally think i have a bug here when dealing, specifically, with description.ext. You might be better off first trying to get this mission working with addon builder which doesn't check for any errors. genuine, or otherwise. you can contact me further on skype or discord. anyone using exec/eval is worthy of all the help (s)he can get.

'working' versions of the free tools are here https://armaservices.maverick-apps.de/Products/MikerosDosTools/default They are robust, stable, tools and have been in existence for over a decade. But, if you're having issues with these, please tell me about it. That is correct. The *difference* between code in description.ext and any other type of paramfile is it can only be compile at game time. There *might* be some issue with exec/eval interpretation. pixelH, W_BORDER, and GUI_GRID_W are not defined in the above example code if any of these are generated from game-time values, that's where your problem lies. pixelH is notably suspicious. There is a reasonably good description of the limits of exec/eval, along with what it can do, in the documents that come with my tools. And, I congratulate you on using them at all, since most people are bewildered by them. Bis use them, heavily, but they are all compiled out of the code during binarisation which is why the community lacks any concrete examples of how they can be used.

your exec and evals are fine. But, configs are static entities, baked in concrete. desc.ext alters at game time. this may, or may not, be an issue.

folks. its a bug. Not occlusion, inclusion, exclusion or physx. A plain, straightforward bug, where ai can see you but you can't see them. It has always been a major showstopper for game play, and RozekPoland explained how it can be fixed in the top post (FireGeometry eg)

it was well known in ofp times and referred to as 'the broken bush syndrome'. You 'learned' never to go near broken vegetation while hunting the bad guys.

I congratulate you on a genuine achievement. I implicitly understood you wanted a different font appearance of some kind. My suggestion was simply to start with a small step. BI's 'proper' use of Unicode, specifically utf8 in the engine has been a win<>win for everyone. Fyi: the tga (and ultimately paa) produced is a bitmapped, proportional font, rather than 'typographic/scaleable' represented by trueType or equivalents. This is much more efficient for a game engine at the penalty of having to 'make' various point sizes of the same characters. Again, congratulations.

If you don't have the tool, you don't have the documentation. Your argument about 'ALL' is illogical. As and when I add new tools for subscribers you seem to think the documentation for it will magically appear in the free tool set too. If i update the tools that you DO have, that documentation doesn't occur for you either.

the notosans font is brilliant combining Japanese, Korean and Chinese glyphs all in one package. It already exists in arma3 as NotoSansCJK-Light, and contains 23 'codepages'. clearly bis made that using the tool you mention, so it must be possible. I have not made such a font so have no practical experience, but I'd suggest you first try your hand at a less ambitious character set to check if you understood the options and syntax.

>***Warning*** unknown mapinfotype 41 this is one of three new icon types for the 2d map generated by binarise from information in the config.cpp. Ie not from a p3d's geolod map=. minforestSquares, minRockSquares, minTownSquares the 1st two have always existed but a new icon is generated in addition to the originals. Naturally, and of course, the free version of Mikero's dos tools have no idea what they are. However, that code is future proofed in so far as detecting these unknown values are warnings, not errors. I have no plans to release a new set of free tools until a showstopper happens.

ALL my documentation is in start programs (BIG button, bottm left corner of desktop)->all progams->mikero->depboTools->'pick a tool'->docs,readme, and blah this was told to you on the splash screen of every current tool you have installed.

dertm is part of the subscriber toolset. But you can use any model.cfg (such as the one from samples) that contains an ofp2_manskeleton. What is provided in dertm is the skeletons for three different games. you only want arma3

when all else fails, read the documentation $pboprefix$.txt WAS, originally there to state a prefix, it's now used for much more important things. >Would I need all of this, or are you saying skip all of this and just put "class cfgSkeletons.ofp2_manskeleton" at the top and then done? when all else fails, read the documentation