mikero

Linux tarballs for all tools are available in both toolsets Free Road Test Tools were updated to the latest subscriber snapshot in /*July 2016.*/ August 2017 Over 80 updates to the code have occurred since the last release. This averages more than one update per week. That might give you pause to think what you are missing out on, not being a subscriber, The major improvements to this free release are support for type73 p3ds, plus crunching maps far less painful. Obfuscation and/or compression are disabled in the free versions, and some dozen additional tools (such as dep3d, moveFolder) are not in the free toolset. for a full list of tools and what each one does visit https://community.bistudio.com/wiki/Mikero_Tools The Subscriber Tools contain more than twenty different exe's to ease the burden, chief among them Make/ExtractPbo PboProject . will create dozens of pbos in one button push with savage error checking and obfuscation (optional) Rapify/Derapify/LintCheck : all cpp, rvmat and mission sqm's ConvertWrp: to pew MoveObject: absolute must for repathing p3d's, wrps, and rvmats Eliteness: An all in one gui that works from ofp cwc thru to Arrowead. You can inspect the inner contents of p3d, rtm, pbo's, fxy,wss, wrp, pew and etc etc. :Powerful lintchecking on most file formats to checkfor corruption and or missing files. :Make and extract pbo's, wash the dishes and make coffee too. The heart of all mikero's bis tools is dePbo64.dll. Updates and improvements to this dll average once/week for past 7 years. Updates to exes rarely happen. mirrors for the free toolset: snakeman pmc Enjoy

Sorry for late reply, i was SURE that I already had!!! Obfuscating a wrp is not recommended. Too many things can go wrong. There is nothing in a wrp worth protecting. Instead obfuscate the layers it uses in a separate pbo, and obfuscate all the buildings in others. Make sure, of course, that you reCrunch the wrp pbo LAST. This must be done anytime you alter any of the other pbos the wrp pbo uses.

all credit to dahlgren who did the hard work. the arm64 toolset is now available for subscribers wish to use it.

use the all in-one installer

the all in one installer on the website should resolve all issues

the syntax of the sqf expression inside the EXEC call is faulty. a missing ; ,or ), or whatever. Or, it's not possible to use a specific sqf function during game load.

There should no longer be any issues with my tools on win10 systems. Just check you are using the latest tool set from bytex. Subscriber AND free are both fixed. That said, I have no doubt you have some problem with them. the best thing you can do is ADD to the PATH variable in your user environ string: C:\Program Files (x86)\Mikero\DePboTools\bin There are splash screens of the settings on this page or page 14

removed

folks this is an update to correct the WRONG display screens for the environment path settings. 'mikero tools' is totally, utterly WRONG. you need to edit the existing PATH variable and add the following: C:\Program Files (x86)\Mikero\DePboTools\bin

i have no idea where you got the above versions from, the free tools are currently Rapify.1.82.7.45.Installer DePbo.7.46.0.17.Installer They can be found here: https://mikero.bytex.digital/Downloads 

@bhcluster. apologies. The url on the first page have been updated.

assuming you're using the subscriber version of my tools Mr Bullet, simply download the auto updater from your personal webpage (it's the blue download button). It will indicate Any tool that's out of date and give you the option to upgrade it. the error message you display above always happens when my dll is not compatible with the exe tool you want to use

not even going to bother answering that.

latest releases of pboProject and the dll 'allow' text config.cpp and mission.sqms. Irrespective, the files themselves are still checked for errors before being accepted.

early this week, am putting some finishing touches in other areas and testing all of them first. the major reason for cpp of course is to now 'allow' >and detect<!!! that the config is using evals that can only be known at game load time. Most are normal and can be binarised, but there's a trend these days towards using statements like scope=__EVAL(something strange;};

There is no issue with using a real physical drive called P: nor a genuine, physical partition similarly called P: , nor a simple subst command, nor (surprise, surprise) a vnc\\ 'drive' There is nothing sacrosanct about P:\ by the way. It is not hardwired. It is simply a convenient 'label' to mean any drive:\ letter that gives you a thrill. Many folks use Z:\ for Dayz (either because it makes more sense, or so that they can keep the master config bin, stringtables, and shaders, quite separate from Arma3. (no P:\drive setup can share these across engines) The subst was there in the 'bad old days' because physical drives to achieve the same thing were a) expensive and b) couldn't be physically cabled to a pc's mother board which swallowed 'D:' for cd roms etc. There is almost no advantage in using it these days when drives and sata connectors are so cheap. And, the whole idea of having a separate drive (read backup) is appealing when your main drive goes bang OR, you simply want to move Bis Everything to another PC sans pain and suffering. (often as a result of C:\ going awol, or simply due to a shiny new pc purchase. The only real value of having a subst these days is to share the root of P:\ (eg C:\ArmaWork or god forbid, C:\ArmaTools). with programs that are hardwired to only download to C:\PinkElephant. Publishing your source projects to bis/steam might be one such example. I don't publish to bis anything so I don't know how flexible these things may or may not be. The other use is protecting P: from even being seem by admin mode (see below). BUT BUT BUT, and one more huge BUT. Bis binarise is exceptionally fragile to 'garbage' on your p: drive of any flavour. But, When making binarised wrps. It hunts every-single-folder on your drive: in a desperate hunt for land classes. It quite happily misinterprets badly named files, or cpp's with garbage, and crashes. (My tools prevent bis binarise from doing this search at all) But, When making animated p3d's it will desperately hunt all model.cfgs in each parent\folder all the way back to drive:\ (and can crash on anything.anywhere on that drive) But, When attempting to binarise a paramfile (rvmat eg), or convert tga/bmp/png to paa), it first looks at binmakerules.txt which often points to the wrong location. And, while not often, the convertor.exes themselves go awol with a drive:\ full of things-other than P:\Projects (p:\a3 eg, p:\MyProject eg). Again my tools block bis binarise from doing anything here at all. But, that ain't helpful if you're using Addon Maker. The long and the short of all these BUTs is you should avoid having *anything* on P: other than projects. When binarise crashes it can't tell you why. Because it crashes! You are left with a completeley innocent project of yours that is not in error and have no chance in hell of discovering why your pbo-making has ended in flames. You can, for instance, make six p3ds and all is fine, despite the garbage, and the 7th fails because, unlike all the others, it uses a FireGeometry lod, or a lodNoShadow (given only as silly examples). Due to LodNoShadow, or a fireGeometry lod, or a wrp of 80k x 80k (all given as silly examples), bis binarise has wandered off into places it would not go otherwise. You have no excuse, and no sane reason, to have any exes on that drive at all. To do so is to invite a crash and burn. And finally, to answer your question about directory junctions. They are compatible. A folder (not a drive) simply exists in two places. One to satisfy binarising/editing. The other to satisfy ease of publishing perhaps, an svn or git from other 'projects' or, in my case using the exact same project\code for dayz, arma2, and arma3. Caveat: be aware of the but's above. A subst puts an entire drive in two places, a symlink cherry picks folders into two places. One final comment about 'P:\ drives' in general. You should never, never, ever use admin mode (except of course for installing and setups). You are inviting any tool.exe to scribble over/ wipe out/ destroy all and any contents of at least that drive, if not all drives when they go bang,. You are inviting trojans, viruses and worms (often inserted into tool.exes), to party at your expense. In the specific case of a subst command, there are two p:\ drives, A: 'the user (you)' and B: Admin, who is a user just like you but with different (not better) privileges. One of these drives might not exist at all, might be the same, or might point to a completely different set of folders. C:\elephants vs C:\giraffes eg. you can wipe out most causal faults (runaway exe, or trojan) by simply NEVER creating a subst P:\ drive in admin mode.

helpful if you tell my what line 566 has, but i am guessing the config *cannot* be binarised because there is a sqx statement in there that can only be known after the game loads. There are TWO cfgHud.hpp's. you don't state which one is faulty but i assume it's the one that has EVAL expressions. EVALS in themselves aren't a problem. And neither, generally, are the sqX statements they contain. BUT this hpp file (and consequently the config.cpp that #includes it ) cannot be binarised because some of the sqX is only known at game time. One such example on line 306 is: pos[] = {0.5 , __EVAL(PosY0Center)}; PosY0Center can only be known after the game loads and binarised configs can only use pre known values. The subscriber version of my tools will 'allow' unbinarised config.cpps to be the pbo in the next release. The free tools are unlikely to be updated any time soon.

I have requested bytex to return your money.

three reply emails were sent to you as xxx. My isp says they were delivered (no reject, no bounce) my discord name is mikero#4692. this might be your quickest method of getting it fixed. However, if you want fast, interactive responses in general, from anyone, use the appropriate arma discord channels (such as tool-makers) rather than forums at all. I have no idea why you would want to put the bytex installers anywhere else but default. However, the downloads themselves are unlikely to be an issue. The installers do not run as admin, >except< depbo64.dll And still, despite the message above, you still have not told me about the PATH environment variable, nor, whether you typed the magic words: rapify and makepbo in a dos console

I've already asked you, by email, to contact me direct on Discord. You haven't. I've asked you to tell me explicitly that you altered the >>PATH<<< variable in the >>USER<< environment. You haven't replied. I've asked you to use a dos console on your PC to type the magic words 'rapify' and give me the result. You haven't. I've asked you to do the same for 'makepbo' and got no answer. You did not reply to Rof when he asked you want you mean by 'changing the installer's folder'. What else did you alter? We won't know because you wont even reply to what we ask YOU. But, you have done a great job of raising this same message to me, bytex, and two forums at bis, expecting (i assume) an answer that suits you better.

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.

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.

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)

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.

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.