Jump to content
Bohemia Interactive Forums

mikero

Member
 View Profile  See their activity

  • Content Count

    372

  • Joined

  • Last visited

  • Medals

  • Medals

Posts posted by mikero

  1. Posted

    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.

     

  6. Posted

    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

  11. Posted

    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

     

  14. Posted

    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;};

     

  15. Posted

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

    • Thanks 1

  16. Posted

    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.

    • Thanks 1

  18. Posted

    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

     

  19. Posted

    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.

     

     

  20. Posted

    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.


     

  23. Posted

    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

  24. Posted

    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.

     

     

    • Like 1
    • Thanks 1

  25. Posted

    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.

     

     

×