Jump to content

mikero

Member
  • Content Count

    353
  • Joined

  • Last visited

  • Medals

  • Medals

Community Reputation

72 Excellent

About mikero

  • Rank
    Staff Sergeant

core_pfieldgroups_3

  • Interests
    people

Contact Methods

  • Skype
    mike.andrew
  • Steam url id
    mikero

Recent Profile Visitors

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

  1. mikero

    Mikero's Dos Tools

    Here are the rules: There are two kinds of pbo: +A mission.pbo : contains a mission.sqm intended for use in mission space +An addon.pbo which uses engine space addressing. a config.cpp is required because of it's contents and because the engine must know the name of this addon. (the file name is irrelevant). >every addon requires < class cfgPatches { class NameOfPbo { The reason for the change is that people are looking for my watermark signature inside a pbo to check if the addon is 'good'. If found, they look elsewhere for basic issues knowing that my tools have covered the usual errors. people were using my tools as a stamp of authority that their addons were 'good', without having to do any work to ensure that they were. You can no longer use my tools to make 'wyswig' (-N) pbos. because wyswig doesn't look for errors. Great for you, terrible for the user of your addon.
  2. mikero

    Mikero Convertwrp

    turn on noisy option and after crunching again,. view->output. Buried deep in that output, you will find that message adjacent to the line in the config.cpp that it's upset about.
  3. mikero

    Mikeros Tools Makepbo Error

    for reasons unknown, your USER path= has been damaged. My path is ADDED to strings already there. You don't have any. Look at the original piccie above to gain some idea of what needs to be there for the microsoft xcopy tool. (google is your friend)
  4. mikero

    Mikero's Dos Tools

    this is correct HazJ. There is no such thing as 'true' or 'false' in the >>> BIS<<< compiler. To compensate, bis use #include "commondefs.h" (similar names dependent on engine such as a3. my tools unconditionally convert them to 0 and 1. The definitions above cause no harm in my compiler, but serve no purpose. Again, in my compiler. "so it's either Mikero Tools or another one" it's "the other one" 😎 Be that as it may, the above is good info because it traps many people. fyi: thing ="true"; // is NOT a boolean. it is a string. And it is returned as such by any of the sqf EXEC/EVAL statements. under these circumstances: if (thing) will *always* return true. (the string is not empty) and is the source of great gnashing of teeth for most people, when dealing with sqf in a cpp context.
  5. mikero

    Mikeros Tools Makepbo Error

    for some reason on your pc, debpbo64.installer.exe was unable to set the environ path. navigate your way to the 'System Properties' gui. (Win 10 likes to call it "edit the system environment variables'. Win7 you just click on control panel.) click on advanced tab, click on environment Variables button you need to add the following PATH in the the USER variables panel C:\Program Files (x86)\Mikero\DePboTools\bin (If any other text is in that path statement make sure you don't wipe it out) A few Win10 users are suffering from this issue, and i have no answers.Why it fails (silently) during an install. PS: update depbo64 to version 7.36.
  6. mikero

    Mikero's Dos Tools

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

    Mikero Convertwrp

    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.
  8. 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.
  9. 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.
  10. 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.
  11. 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
  12. 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
  13. 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
  14. 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
  15. mikero

    Mikero's Dos Tools

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