Jump to content

Recommended Posts

@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 :)

Share this post


Link to post
Share on other sites

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

 

  • Like 1

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

 

  • Like 1

Share this post


Link to post
Share on other sites

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

 

 

Screen_Shot_2019-01-08_at_12.51.32_PM.pn

 

 

 

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

 

 

 

 

 

 

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

and use a quote macro if you have to

Share this post


Link to post
Share on other sites

@.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 by shukari

Share this post


Link to post
Share on other sites

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

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

 

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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...

Share this post


Link to post
Share on other sites

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

 

 

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites

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.

 

 

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

the issue is acknowledged and is being worked on

  • Like 2

Share this post


Link to post
Share on other sites

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.

 

 

Share this post


Link to post
Share on other sites

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

 

Share this post


Link to post
Share on other sites

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.

 

 

  • Like 1

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now

×