Problem while using Arma2P

[glowbal 13]

Hello,

After a long break I decided to pick up my island project this upcoming holiday again. However I again ran into the same problem that made me take a break; I can't seem to figure out how to unpack my PBOs into the P drive. I've followed Bush his tutorial to the letter, read other tutorials and readmes, however when ever I run the Arma2P.2.5.1.cmd I get an error saying it cannot find the path/files/path. I would take a screen shot if it was of any help but it's in Dutch.

Now when I try running it as administrator, it says P drive must be set. Yet, the P Drive is there and installed.

I have Arma2 installed here:

C:\Games\Bohemia Interactive\ArmA 2

Same with OA, disk and Sprocket versions.

And I did a fresh install off both the tools and P drive. Anyone can help me out here?

[bushlurker 46]

Hi Glowbal

... well, that doesn't sound too great...

There's obviously something fundamentally wrong - just a question of figuring out what it is...

Firstly - disable "User Account Control" UAC) on Windows - it's problematic, and you shouldn't have to be fussing with "administrator mode" during any of this...

On to Arma2P - which, like all Mikero's tools, is powerful, VERY unforgiving and picky and... talkative...

If there's something wrong - it'll fail - but it'll usually tell you why!

Please post that screenshot of the Arma2P DOS window - even if it's in Dutch - it almost certainly gives a clue as to what the problem is...

Basically (I think)... Arma2P...

Reads your registry and finda where your game assets are located, then it looks down those paths, finds the individual .pbos and it unpacks them, derapifys the config.bin, and dumps them on your P:\CA\folder, one at a time, in a set order...

It should automatically locate and unpack everything...

If you're getting a "cannot find the path/files/path" error then obviously that's not happening...

That DOS window should give us a clue...

Post a screenshot, we'll take a look and take it from there....

B

[glowbal 13]

I just did a reinstall of BIS tools, P drive and Arma2P, got the same errors again.

[bushlurker 46]

That looks like a successful run to me...!

If there was a serious error, Arma2P would simply have stopped, but that window shows it creating your little "configs-only CA folder" - (in that P:\WRP_PROJECTS" folder)... that's pretty much the last task Arma2P does - then it reminds you to copy it into your namespace and reports - "Success - press any key to continue"

I reckon it probably ran OK...

Check over your P:\CA folder - are all the pbo's unpacked properly there? - look in the P:\WRP_PROJECTS folder - is there a "CA" folder in there??

Sounds like a successful setup to me!

I'd suggest you move on to testing it now... you could head back to my tutorial if you like - the next thing it advises after this setup procedure is a quick run thru Sgt Aces Tutorial... that takes about an hour and should see you thru to a basic terrain successfully in-game... if you get that far without incident then I reckon you can consider yourself properly setup...

B

[glowbal 13]

There is no WRP_PROJECTS folder, neither did it unpack any of the PBOs. The entire P drive just stays.. default. As it came with the installation.

All the text in that window shows up within 1 second as well. So I recon it didn't unpack anything.

Translated a bit of the text:

Access denied.

Access denied.

Access denied.

Access denied.

Access denied.

The system can't find the target file.

The system can't find the target file.

And a bit futher on:

Can't find file co.txt.

***** Not reconnised as an internal or external command, program or batchfile.

Can't find file - *p3d

0 files copied

File name is invalid

****** Not reconnised as an internal or external command, program or batchfile.

System cannot find path

System cannot find file

System cannot find path

Can the problem be my game being in another folder then the default installation one (games instead of program files)?

Edited December 22, 2011 by Glowbal

[bushlurker 46]

... right - so that's not the end of about a 20 minute or more unpack?

Hmmm... that'll be the "access denied" bit at the top I guess....

then you have Arma2P looking to it's own installation folder where it makes a list of stuff it's unpacking - in this case "Beta" (it's found a beta folder) and "Exp" (expansion = OA)... it's looking for those files - but not finding them...

This and the administrator thing might be part of the same issue - the fact that you have Mikero's tools within C:\Program Files (x86)... with some settings of Windows security and User Account Control you're prevented from writing to folders inside C:|Program Files - it's considered read only... I wonder if that could be part of the issue?

I guess it's worth a try - Arma2P can be run from any location... Try moving your Mikeros Tools folder to just plain C:\ - or even make a Mikero's Tools folder on P:\ itself - that should also work ok...

Next - make absolutely sure you have all the files required for Arma2P in the same folder - there's a picture of folder contents in my tutorial...

Third - make sure UAC is off - under "User Account Settings" in Control Panel... move the slider to the bottom, click Ok out of there - then reboot!

Then - give Arma2P another run from that new location - see if theres any change in behaviour...

It looks like it's going through all the right motions, just not being allowed to access the actual files...

Can the problem be my game being in another folder then the default installation one (games instead of program files)?

I think Arma2P checks the registry to see what you have installed and where it is... so a non-standard install folder shouldn't matter.....

B

Edited December 22, 2011 by Bushlurker

[glowbal 13]

Thanks for your help. I figured it out! I think I got it all working now, as I got the unpacked pbos on the P drive.

I moved the folder with Arma2P + requiered files to my "games/bohemia interactive" directory, ran it from there and it worked.

Appriciated the help, Bushlurker!

[Robbo_72 10]

I've got all my mapping tools/drive setup

Installed ArmA 2 CO/BAF/PMC, BI Tools 2.5.1, 1.6 patch. All runs great.

P drive is physical.

But.....

Trying to run ArmA2P 2.5.1a and get the following result:

I have checked folder/P drive permissions, UAC disabled and up to date files for ArmA2P (ConvertP3D 1.59, DePBO 3.82, ExtractPBO 1.81)

Running ArmA2P from C:\Program Files\Bohemia Interactive\Tools\ArmA2P\Arma2P.2.5.1.cmd

Game is installed in E:\ArmA 2

Re-installed BI Tools to no effect, same error, same place.

Any help?

Cheers

Edited February 13, 2012 by Robbo_72

[mikero 79]

try installing (and running) arma2p from a folder off P: (personal tools can stay where it is)

[Robbo_72 10]

Installed and run tools from P: with same results:

Is it possible the tools are freezing while tgrying to create new folders?

Authorised/System/Users/Admins all have full access to P:\

Edited February 14, 2012 by Robbo_72

[.kju 3245]

It seems you are inside p:\mikero rather than p:\ - is that so?

[Robbo_72 10]

Yeah, You saying I should run them from the root of P:

Ok, Installed tools in root of P:.

This is how the directory structure of P: looks before running ArmA2P.2.5.1.bat

After running, Same error:

Folder structure after running batch file:

Uploaded with ImageShack.us

Cheers

EDIT I: Fixed images

EDIT II: Running Windows 7 x64 SP1, Trying to think outside the box here, My registry has zero references to '.pbo' and 'depbo.dll', So I dont think there is any conflict, not sure if that helps

Edited February 14, 2012 by Robbo_72
Fixed images + updates

[.kju 3245]

Thanks. For some reason it cannot create an a10 folder inside p:\ca.

Can you post the explorer view of what you have in that folder atm please.

[Robbo_72 10]

Hi again,

Here is a screenshot of the directory structure before running script:

Here is a screenshot afterwards:

Same errors:

Running Windows 7 x64 SP1.

Ran script as admin and normal.

UAC disabled.

I have made sure there are no registry entries for '.pbo' and 'depbo.dll', all clean.

Permissions look good.

Confused.

[Robbo_72 10]

my replies have been held, sorry about the delay.

I have replied twice with screenshots and both have been held, not sure why.

PM'd a mod, no reply yet

[Robbo_72 10]

Ok, I've managed to get it working.

I uninstalled BI Tools Drive, Cleaned the registry of any references to 'P:\' and removed the physical P:\ drive from the system.

I re-installed BI Tools drive to default Documents/ArmAWork and installed the Mikero package, Restarted the system and ran the ArmA2P script. It seemed to work fine.

I'll add my P:\ drive back and edit the 'mapdisk.bat' to point to the new location (edit the references in registry too if needed) and reboot to see if that works.

Very weird.

[bushlurker 46]

Hi robbo....

Sorry I missed this problem earlier - I've been reinstalling my entire system too! Including a separate drive for my terrain dev stuff - just like you're aiming for...

It's a good idea! The Dev drive does a lot of churning as it's working - making layers folders with 25,000+ files, etc... makes sense to give it a space of it's own, away from the rest of your system.....

But... I think you're missing the point slightly, and that's what's causing a little confusion...

The P:\ drive is a Virtual Drive - it doesn't really exist - nor should it!

The actual location of the contents of P:\ - where P:\ actually exists, is in a folder called "ArmaWork" alongside your actual BIS Tools...

If you installed your tools to somewhere like C:\Program Files\etc or C:\users\myname\documents\etc - then that's where your P:\ drive actually is! That's the drive that'll actually be doing the churning!

Mapdisk.bat will make it appear that you have a P:\ drive - that's good! The tools want and expect that!... but the actual physical location of the files will be inside wherever you installed the Tools, and therefore that "ArmaWork" folder to...

You can see where this is going by now I'll bet.....

If you want your Dev stuff - including the actual physical location of the "P:\ drive" contents - to be on a separate drive, then install the actual tools themselves to that drive - and don't call it "P:\" !

It's well worthwhile getting this set up properly before you begin serious work... it'd be more fuss to rearrange things afterwards, so here's what I'd suggest.....

Blank, wipe or format your special "Dev Drive" and mount it - NOT as "P:\" - mine is a spare 500gb drive mounted as "F:\"

Install the latest 2.5.1 BIS Tools package to a folder on F:\ called "BIS_TOOLS"

(As each individual tools package installs - make sure the install path is correct - they should all install to F:\BIS_TOOLS\Something...)

Name the drive "Dev Drive" and reboot...

When you come back after the reboot - you should have an F:\ drive called "Dev Drive" with all the tools in their folder - plus you should now have a "Virtual" P:\ drive - also called "Dev Drive"!

Take a look at the contents of that Virtual P:\ - now take a look inside F:\BIS_TOOLS\ArmaWork...

You see?..... P:\ is a "mirror" of the contents of F:\BIS_Tools\ArmaWork

You'll do all your work in P:\, but it'll actually live in F:\...

Since F:\ is the separate physical drive you wanted in the first place - you're sorted!

Next step is to make a folder on P:\ - call it "Mikero" or "DOStools" or whatever... you can make a separate folder inside there called "Arma2P" if you like.....

Unpack Arma2P in there, and follow through with the usual Arma2P install procedure...

Fingers crossed that all runs according to plan..... another reboot... and - you're done!!!

From now on - you treat P:\ as if it was a real drive, but remember that it actually lives on F:\, beside the tools...

Doing everything again is a hassle, I know - specially if you've been struggling with this for a while, but it's worthwhile getting everything stable and properly setup, then you can get on with the fun stuff!!!

Let us know how you get on!.....

B

Edited February 15, 2012 by Bushlurker

[Robbo_72 10]

Cheers fellas, At long last I can get cracking with this.

Still got lots to do, But i'll start my own thread for that.

Got your tuts bush, look good mate, should help lots.

EDIT: shifting 12.6GB 182,612 items....ouch!

Edited February 15, 2012 by Robbo_72

[Echo4Romeo_Tempest 10]

**EDIT

I figured out the problem but I'll leave the post here in case others find it useful. Apparently the Reg Query command is stored in sys32. I'm running 64 bit windows 7, so the .cmd file was looking for Reg Query in my SysWow64 folder (I assume) which does not "include" that command. To fix this I had to set my syspath to sys32. To do this:

-Click the Start Panel

-Highlight Computer then right click it

-Select Properties

-Select Advanced System Settings in window that pops up after last step

-In the advanced tab select Environment Variables

-In the bottom window, labeled "System Variables" find "Path" Variable, select it and click the "Edit" button

-Add the following line, in hole, to the beginning of the "Variable Name" box:

%SystemRoot%;%SystemRoot%\System32; 

------------------------------------------------------------------------------------------------------------------------------------------------

ORIGINAL POST:

Hi all, I've been trying to get this to work for hours and keep running into one issue after another.

I have made a clean drive (D: in my case.) then installed the tools to D:/BISTools and now have a P: drive in D:/BISTools that has the contents of the ArmaAWork folder inside of it (that is, D:/BISTools/ArmaAWork . . . P:/ is of course a virtual drive which is actually the ArmaA work folder...) So I think I have all that right.

I'm currently trying to run Arma2P.2.5.1 from a folder inside of P:\ but keep getting this error:

'REG' is not recognized as an internal or external command, operable program or batch file

And then says Fail and Press any key to Continue.

Opening up the .cmd file and doing a search for Reg, I found it most often used in this sort of statement:

For /F "Tokens=2* skip=2" %%C In ([b]'REG[/b] QUERY "HKLM\SOFTWARE\Bohemia Interactive Studio\ArmA 2" /v "MAIN"') Do (set _ARMA2PATH=%%D)

Now I'm not a programmer , but I can assume Reg Query is supposed to be locating a registry key? HKLM\SOFTWARE\Bohemia Interactive Studio\ArmA 2 in this case. Is there a syntax error in the code? Looking it up I found the proper syntax is

reg query <KeyName> [{/v <ValueName> | /ve}] [/s] [/se <Separator>] [/f <Data>] [{/k | /d}] [/c] [/e] [/t <Type>] [/z]

Edited February 24, 2012 by Echo4Romeo_Tempest
figured out the solution :)

[.kju 3245]

What windows version are you running mate? Are you admin or only an user account?

[Echo4Romeo_Tempest 10]

64-bit windows 7. Issue ended up being that the .cmd was looking in the wrong place for the Reg Query command (looking in syswow64 instead of sys32.)

Solution posted in the original post. I'll probably be back with another issue.

---------- Post added at 08:28 PM ---------- Previous post was at 08:21 PM ----------

So as soon as I fixed that problem here is another -

I get a few minutes through the unpacking and get this error:

DePbo No Memory
Fail

I have 8 gigs of ram!

Though my resource monitor is telling me 6 gigs of it are currently Cached. Is my system just refusing to free up that cached data for newer more relevant data or is it refusing to write it somewhere. I have no idea.

Apparently it keeps getting caught up on extracting dubbing.bpo. Which has been a known problem so I'm trying to find the solution.

Edited February 24, 2012 by Echo4Romeo_Tempest

[mikero 79]

Nice piece of detective work. Reg key queries are standard fare. The code you mention above is stolen directly from bis (Dwarden) and is used by them to fire up arrowhead beta patches. Those scripts are very clearly aware of wow64.

To not be able to access system32 commands (and dll's) on a 64 bit system would be extraordinary since only a smaller percentage of applications are in fact 64bit and the hugest majority of bat and cmd files are 32bit sensitive. Sounds more like a strange, initial install, of win7.

btw. the only sensible option available for most windows users is to run as administrator (especially arma2p) since the access rights in windows (UAC) are so screwed up that every file everywhere is read only. Window$ are aware of this issue and have not had a clear solution since first introduced in Vista. Judging by the Skype fiasco and a similar contempt, it's unlikely to ever be fixed.

dubbing.pbo is 1Gig in size. That's how much memory it needs + perhaps another 20% to process it. One solution *might* be to (temporarily) remove it from the arma addons folder and extract it separately using ExtractPbo. One, well known memory thief is Skype version 5. it consumes 7 GIG !!!! if you let it. Another is Steam and another is any svn/git caching tools you might have.

Edited February 25, 2012 by Mikero

[Echo4Romeo_Tempest 10]

Thanks for the response.

Yeah, I went ahead and set my rootpath to syswow64 and it worked fine as well so I guess it was just that I didn't have a rootpath set up in my environment variables.

I finally got the script running but as I said above I keep getting an out of memory error. I've tried running it as admin to no avail, but I'll play with my UAC, which should already be off, and see if I can get it to work.

I read in the bug tracker on devheaven that someone had a similiar issue a year ago and using the -F parameter to ignore errors allowed Arma2p.cmd to ignore the errors and move past it instead of stopping. I'm not very familiar with command line usage though, is there a way to use this parameter with the script .cmd/batch file?

Here are my computer specs if it matters -

Operating System: Windows 7 Home Premium 64-bit (6.1, Build 7601) Service Pack 1 (7601.win7sp1_gdr.110622-1506)

System Manufacturer: INTEL_

System Model: DQ45CB__

BIOS: BIOS Date: 02/08/08 17:50:03 Ver: 08.00.10

Processor: Pentium® Dual-Core CPU E6800 @ 3.33GHz (2 CPUs), ~3.3GHz

Memory: 8192MB RAM

Available OS Memory: 8124MB RAM

Page File: 1919MB used, 14325MB available

Windows Dir: C:\Windows

DirectX Version: DirectX 11

Card name: NVIDIA GeForce GTX 560

Display Memory: 4062 MB

Dedicated Memory: 2014 MB

Shared Memory: 2047 MB

Current Mode: 1920 x 1080 (32 bit) (60Hz)

Edited February 25, 2012 by Echo4Romeo_Tempest

[.kju 3245]

Echo4Romeo_Tempest you need to skip the one file.

Either CTRL+C once its stuck or move out the dubbing.pbo temporarily from a2\addons to somePlaceElse,

before you launch Arma2p.

[Echo4Romeo_Tempest 10]

Thank you! CNTRL+C didn't do anything for me, but removing the file did. Thanks again!