mikero

re bis binarise THREE 1) processing paa files takes 6 minutes. processing png equivalents takes 6 years. get rid of them. Use img2paa (if bis haven't broken it) or pal2pace to convert every single png/tga/bmp file in your project. delete the png/tga/bmp. (except of course the source\folder) 2) your command line for binarise is hopelessly 'wrong'. you (and addon breaker) have confused binarise as to where the virtual name space is; binarise is in a forever loop reprocessing the temp folder inside your mytag\. Create a p:\temp folder or a p:\potatoes for all that it matters, and destroy p:\mytag\temp. it will come back and bite you later. 3) binarise is in another forever loop trying to deal with the contents of the source folder. there's nothing in there that's useful. move it somewhere else, or simply use pboProject to do all these messy things for you. ---- oh and congrats on your successful use of personal tools 2.5.1 A lot of people are going to run with that information and some more detail from you will help them. eg, cmd line, binpbo or pboProject to achieve that miracle. I also use bis binarise 2 for arma3 maps (but for very different reasons).

if you choose to ignore error messages when you first installed depbo, that's entirely your choice. the only reason you're not ignoring the above error message is because you can't. re-install the tools and pay attention. because pboProject is even nastier and will not take prisoners.

it is referred to as the comref for 02script and comes with personal tools 2.5.1. for arma2

ouch

> result = buldozer_LoadNewRoads "P:/whatever/whatever/data/roads/"; that presumes your Pdrive is in fact P:. if not, do something about it. also you should be using lappihuan scripts, not editor.sqs

god knows why

and your problem is??

update to subscriber tools: 1) arma3p now extracts argo dlc (malden) 2) the dll polls 1/day to check for updates. 3) ALL pbos are now versioned automatically and appear in the rpt

yes. it's all in the documentation start programs->mikero->every tool->documentation it's up to you to take the trouble to learn how to use my tools, not, up to me, to teach you the basics

no. you cannot. compression prevents the thief 'seeing' text using a hex editor. Some files can't be compressed, and it would appear wrps are one of these. just use the -Z option to stop it happening

it's probably compression causing the issue.

updated links on the 1st page topic to free tools mirrors and new home for the subscriber tool set

changing initworld= in your map's config also has the same (and less damaging) effect. From then on, if you're map is available in mod\somewhere\addons it becomes the default, by default

it's never solved if, the environ path= has changed, OR, you are running as admin.

your original problem was rapify not found. This can only ever be the environ path= you seem to have fixed that. xcopy is an identical reason with a different cause,. the windows\system32 path was not present in the environ path for reasons unknown. permission blocks sound like exactly what they are. with the added wrinkle that an admin pdrive is not the same animal as a user pdrive. At worst it doesn't exist, at best, it's different files. my tools will not run as admin. this is intentional. It protects you from some interesting times.and a great deal of tears.

you are running AsAdmin OR, similar to your initial problem, your environ path is wrong.

You ignored the error when an install went bang. In this case the dll. Do what it tells you to do.

what's surprised me here is buldozer isn't reading THE config.cpp/bin for THE wrp being displayed. Immediately followed by "it can't" because: 1) it won't have the class it inherits from (stratis, caworld, whatever) and 2) the config won't necessarily be adjacent to the wrp, so won't find it. So, since clutter, per se, is not baked into the wrp, there's nothing to display, hence, the need for pasting config data to something it must read. Although not related in any way, it is a similar cause to the minForestSquares issue that binarise (in this case) needs to know about. Nice investigative work, nice proof of concept, and a hell of a bonus for people needing to twiddle their clutter 'on the fly'. The incidence of bin config being altered by updates is currently quite low, so anyone taking the trouble to apply this patch should be confident of being able to 'set and forget'.

MikeroUpdater; due to circumstances, i had to change to a different web provider. This gave me the opportunity to make subscriptions fully automatic. For existing subscribers wanting their regular updates you need to go here First Register with Maverick using top left button with your subscriber email address, then follow instructions on the page above. You can always contact me on skype, discord, or email. They are in my profile. For people wishing to subscribe, the old, klunky paypal method has gone away with a shiny new automatic system here.

there's no reason to do any of that. syswow, sys32 and system are only searched if the exe cannot find the dll immediately in the same folder as itself. You appear to be over-complicating a very simple issue. rapify, according to your initial problem, cannot be found. This has nothing to do with the dll, or where it is. rapify.EXE cannot be found. And the only reason why that can ever be possible is your PATH= is wrong in your environ string. it is, that simple. if you run as admin, you are using a different environ path.. but bottom line here is PATH does not contain mikero's\bin folder. Nothing more, nothing less. --- i strongly suspect I am being trolled here with a pile of nonsense. So I won't be replying further.

the dll in the bin folder is not 'global'. It is local to the tool.exes in the same folder. you should have got an error message when installing that dll if your environ path exceeds 1024 characters. if so you have to do it manually. also the tools themselves will not run as admin. this is intentional. the only reason 'rapify.exe' cannot be found is because the path\to\bin is not in the environ PATH=

you either haven't installed them, or ignored the warning message when you installed the dePbo64.dll

why on earth would I offer this for free?

tanoa_map_objects.rar is what you're interested in, and thank you for your comments. it was recently updated to provide origami models of bulldozers and wrecks. Only to discover that bis released these as a pbo (not ebo) a few days later.

pboProject updated for map makers. handles 'missing forest icons' discovery of more p3d types that need land classes to operate 'correctly' when baked in wrps, streetlamps, towers, blah....