Mikero's Dos Tools

[aussie battler 94]

@mikero

 

I have run out of space in the "-Z Exclude From Compress" box. Would it be just too many characters?

I was thinking that my choices are either:

 

+ Shorten every *.sqf or
+ Do the quick, dirty way and just exclude *.sqf in the "-X Exclude From PBO" section.

Is there another work around?

Love your tools, they have saved me packing so many mistakes. Have a great weekend :)

[mikero 79]

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

 

[aussie battler 94]

Thanks @mikero Maybe the "-Z Exclude From Compress" code is just starting a new line. I have so many .sqf lines in the exclude.

With all the scripts I am running it surprises me that my mission still starts up.

Thanks for your fast help, I appreciate the support.

[mikero 79]

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

 

[aussie battler 94]

Cheers @mikero

 

That helps me allot :)

Have a good one.

[Sir Nutty Walrus 9]

Hi im having an issue with pboProject when im trying to export my map in arma, its the only error ive received and the config is not the problem neither is the layers config. Anyways a error pops up saying the following

 

 

 

 

 

I think its probably the p drive but not sure, any help thanks!

 

 

 

 

 

 

 

[.kju 3245]

best join the arma discord and post in the terrain makers channel

[mikero 79]

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

 

[shukari 28]

Short question... i updated my makePbo and dePbo to the newest free version and now some of my macros are broken. Like:

#define PUBLIC_NAME_CAT(D_NAME, CATO) \
    displayName = D_NAME; \
    scope = 2; \
    scopeCurator = 2; \
    editorSubcategory = "EdSubcat_TB_Supply_##CATO"

Now, ##CATO is no longer replaced because the change with things in " "
 

// ERROR: INIT_TEXTURE MACRO create error -> circa Line 32 Expected ';' or ':' or '{' after classname

// #define INIT_TEXTURE(CLASSE,SKIN) class CLASSE { \
        class TBMod_warlords { \
        serverInit = "params ['_vehicle']; if (call TB_fnc_isWLMission) then {{_vehicle setObjectTextureGlobal [_forEachIndex, _x]} forEach (getArray (configfile >> 'CfgVehicles' >> (typeOf _vehicle) >> 'textureSources' >> 'SKIN' >> 'textures'))};"; \
        }; \
    }

This also dont work anymore... i think because the SKIN in " and ' but the error say something different.

[.kju 3245]

remove the quotes from a string when you want to replace part of it

and use a quote macro if you have to

[shukari 28]

@.kju

for the first example i now use 

editorSubcategory = EdSubcat_TB_Supply_##CATO

for the second example i should use a QUOTE macro like the one from ACE3/CBA (#define QUOTE(var1) #var1)?

#define QUOTE(var1) #var1
...

serverInit = QUOTE(params ['_vehicle']; if (call TB_fnc_isWLMission) then {{_vehicle setObjectTextureGlobal [_forEachIndex, _x]} forEach (getArray (configfile >> 'CfgVehicles' >> (typeOf _vehicle) >> 'textureSources' >> #SKIN >> 'textures'))};);

is this right?

Edited March 13, 2019 by shukari

[mikero 79]

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

 

[TroyT 6]

I have an issue that just popped up with PBO Project.  When I crunch an addon I get the following error:

 

scanning for pbos to make....
preprocessing BSF_Community_Addon\addons\BSF_Misc.pbo
<scanning files to pack>
................................................................................
</endscan>
creating texheaders.bin
'MakePbo.exe' is not recognized as an internal or external command,
operable program or batch file.
makepbo failed
BSF_Misc.pbo not produced due to error(s)
Job(s) completed in 0secs on Sun Jul 07 15:44:32 2019

The output log gives me:
 

""H:\Games\SteamLibrary\steamapps\common\Arma 3 Tools\Binarize\Binarize.exe" -texheader "BSF_Community_Addon\addons\BSF_Misc" "BSF_Community_Addon\addons\BSF_Misc"" 
15:54:38: Extensions:
"</texheaders>" 
"MakePbo.exe "-PsgFW" "-X=thumbs.db,*.txt,*.h,*.dep,*.cpp,*.bak,*.png,*.log,*.pew,,source,*.tga" "BSF_Community_Addon\addons\BSF_Misc" "D:\Games\ARMA3_Mods\@BSF_Community_Addon\Addons"" 
"BSF_Misc.pbo not produced due to error(s)" 

After several attempts, I got this:

""H:\Games\SteamLibrary\steamapps\common\Arma 3 Tools\Binarize\Binarize.exe" -texheader "BSF_Community_Addon\addons\BSF_Misc" "BSF_Community_Addon\addons\BSF_Misc"" 
15:44:32: Warning: memory usage limited by a page file. Current limit 37241 MB, wanted 43282 MB.
15:44:32: Increasing your page file size might improve game performance.
15:44:32: Extensions:
"</texheaders>" 
"MakePbo.exe "-PsgFW" "-X=thumbs.db,*.txt,*.h,*.dep,*.cpp,*.bak,*.png,*.log,*.pew,,source,*.tga" "BSF_Community_Addon\addons\BSF_Misc" "D:\Games\ARMA3_Mods\@BSF_Community_Addon\Addons"" 
"BSF_Misc.pbo not produced due to error(s)" 

 

I've been using this tool extensively and this just cropped up.  Any ideas on how to proceed?

I have an active premium subscription if that matters.  If there's a better place to ask this question, please let me know.

[mikero 79]

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

 

 

[HazJ 1289]

Hey @mikero - Having multiple #include in the description.ext file causes the mission to crash on server start, the issue is something to do with the way they are packed, not sure what exactly causes it. Maybe some formatting? When I use another PBO packer, no issues. The PBO is created without any errors.

#include "Sounds\description.ext"
//--- Header contains the mission tite.
#include "Rsc\Header.hpp"

//--- Styles
#include "Rsc\Styles.hpp"

//--- Parameters contains the mission parameters.
#include "Rsc\Parameters.hpp"
//--- Ressource contains the dialog ressources.
#include "Rsc\Ressources.hpp"
//--- Dialogs contain all the interfaces (dialogs).
#include "Rsc\Dialogs.hpp"
//--- Titles contains the titles (overlay).
#include "Rsc\Titles.hpp"

 

 

EDIT: Not my code. I guess there are strict rules when using MakePbo.

#include "macros.hpp"
#include "Configuration\Header.hpp"
#include "Configuration\CfgSounds.hpp"
//--- Header contains the mission tite.

//--- Include Identities (OA/CO Only).
#ifndef VANILLA
  #include "Configuration\Identities.hpp"
#endif

#include "Configuration\Parameters.hpp"

//--- Styles
#include "Rsc\Styles.hpp"

//--- Parameters contains the mission parameters.
//--- Ressource contains the dialog ressources.
#include "Rsc\Resources.hpp"
//--- Dialogs contain all the interfaces (dialogs).
#include "Rsc\Dialogs.hpp"
//--- Titles contains the titles (overlay).
#include "Rsc\Titles.hpp"

 

EDIT 2: I spoke too soon. Instant crashing. I get:

ErrorMessage: Include file macros.hpp not found.

The file exists, in root and in Configuration folder (just in case). Even though it isn't called from there.

[HorribleGoat 1473]

I remember something something includes dont work in binarized missions or something like that. Not 100% I remember right though.

[HazJ 1289]

43 minutes ago, HorribleGoat said:

I remember something something includes dont work in binarized missions or something like that. Not 100% I remember right though.

They do. Just not when packing with Mikero Tools...

[mikero 79]

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

 

 

[Dedmen 2714]

On 7/26/2019 at 6:42 PM, HorribleGoat said:

I remember something something includes dont work in binarized missions or something like that. Not 100% I remember right though.

external includes don't since 3DEN.

 

On 7/26/2019 at 7:26 PM, HazJ said:

Just not when packing with Mikero Tools...

Uhm.. Have you removed *.hpp from the exclude list?

[mikero 79]

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.

 

 

[zephyrsouza 123]

Was packing fine with an older version of Mikero Tools, I am now on 2.59.

Whe packing I get this error "In File ML700_Weapons\Grenades\config.cpp: circa Line 127 array[]+= cannot be found"

This never was an issue until now.

 

Config reads as

 

class cfgWeapons 
{
	class ThrowMuzzle;
	class GrenadeLauncher;
	class muzzles;
	class Throw : GrenadeLauncher 
	{
	
        muzzles[] += {"ML700_frag_grenade_muzzle","ML700_krak_grenade_muzzle"};

        class ML700_frag_grenade_muzzle : ThrowMuzzle
        {  	
			minRange = 20;
			minRangeProbab = 0.07;
			midRange = 30;
			midRangeProbab = 0.25;
			maxRange = 35;
			maxRangeProbab = 0.91;
			magazines[] = {"ML700_frag_grenade_magazine"};
        };
		class ML700_krak_grenade_muzzle : ThrowMuzzle
		{  
			minRange = 20;
			minRangeProbab = 0.07;
			midRange = 30;
			midRangeProbab = 0.25;
			maxRange = 35;
			maxRangeProbab = 0.91;
            magazines[] = {"ML700_krak_grenade_magazine"};
        };
    };
};

Any idea what I can do to get PboProject to stop screaming about what seems to be a standard to add throwable items to an array?

[.kju 3245]

the issue is acknowledged and is being worked on

[mikero 79]

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.

 

 

[HazJ 1289]

Reading my own comment regarding #include, I just remembered another thing though it's been a while so it's either Mikero Tools or another one but thought I'd share anyway. For some reason, in .hpp files (inside classes), using true or false keyword causes issues with packing. A simple fix is to either change to 1/0 or add the #define to the top of the file.

#define true 1
#define false 0

 

[mikero 79]

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.