Jump to content


  • Content Count

  • Joined

  • Last visited

  • Medals

  • Medals

Community Reputation

70 Excellent

About mikero

  • Rank
    Staff Sergeant


  • Interests

Contact Methods

  • Skype
  • Steam url id

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. mikero

    Mikero's Dos Tools

    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.
  2. mikero

    Mikero's Dos Tools

    >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.
  3. mikero

    Mikero's Dos Tools

    >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.
  4. mikero

    Mikeros Tools ConvertWrp

    >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
  5. mikero

    Mikeros Tools ConvertWrp

    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
  6. mikero

    OFP Elite pbo resigner (xbox)?

    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
  7. mikero

    Mikero's Dos Tools

    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
  8. mikero

    Mikero's Dos Tools

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

    .xyz vs .tiff for heightmaps

    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.
  10. mikero

    Mikero's Dos Tools

    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
  11. mikero

    Mikero's Dos Tools

    the input box for compression will take up to 32,000 characters.
  12. 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.
  13. '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.
  14. 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.
  15. 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)