paranoid_giraffe

I've tried several times with several different settings and I cannot get it to binarize with 8192x8192 data. Is there some other setting I can tweak besides the mapframe properties?

Rebuilt and layered at 32x32 with other res's at 4096x4096 and it works fine. I'll try to rebinarize at the higher res but wait a long time

I've gotten it to stop freezing, etc, and I can rebuild and generate layers without freezing or crashing. These are my mapframe and file properties. rasternew.tif 8192x8192 16 bit 132 MB mask_Ico.bmp 8192x8192 24 bit 197 MB sat_Ico.bmp 8192x8192 24 bit 192 MB I even schwacked a few km off the sides to make it a nice round number for cell size ratios for testing. Still doesn't binarize, but everything else is fine. I delete everything in P:\temp, I manually clear the layers folder before making new ones, and I export a new .wrp every time, but it still hangs. I don't know what would have changed, because a few days ago I was iterating through terrains fine until I decided to switch to 8192x8192 resolutions. I even have pics to prove it worked on different resolutions. I am at my wit's end

Instead of hard crashing and closing, TB is now just freezing instead. This is what I found in the Arma3Tools.rpt, snipped to the time I was using the TB program. Any advice would be greatly appreciated. This is after I set it to compatibility mode, Windows XP SP3 2017-07-20 10:08:23,949 [INFO]: p:\steam_appid.txt exists and looks good. AppID=107410 2017-07-20 10:08:23,951 [INFO]: FileName adjusted - TerrainBuilder.exe 2017-07-20 10:08:23,951 [INFO]: filePath validated 2017-07-20 10:08:23,952 [INFO]: process ready to be started 2017-07-20 10:08:24,762 [INFO]: Unable to retrieve all process info: Access is denied 2017-07-20 10:08:24,763 [INFO]: at System.Diagnostics.ProcessManager.OpenProcess(Int32 processId, Int32 access, Boolean throwIfExited) at System.Diagnostics.NtProcessManager.GetModuleInfos(Int32 processId, Boolean firstModuleOnly) at System.Diagnostics.NtProcessManager.GetFirstModuleInfo(Int32 processId) at System.Diagnostics.Process.get_MainModule() at Launcher.runInternal.StartProcess(String fileName, String workingDirectory, String arguments) 2017-07-20 10:08:24,763 [INFO]: Process started: TerrainBuilder.exe Any advice to stabilize this program would be greatly appreciated. EDIT: I've gotten it stabilized for the most part using the windows compatibility troubleshooter, but it still won't binarise for some reason

My goodness, you have saved me from a lot of stress. Should I run pboproject in compatibility as well? It's still hanging after attempting to binarise

Although I am a noob to making terrains, I have been somewhat familiar with the work flow for using TB for a couple months. I still don't understand all of the texture sizing and what they mean, but this program crashes more than a drunk old lady. It has crashed today probably a few hundred times. I am trying to make a 20km x 20km terrain using a geotiff (8192x8192) that I converted from a .ter in QGIS, originally exported from World Machine. I have no problems using lower resolution data, but what is the point of making a nice looking terrain if your height map is a blocky low res mess? TB crashes when I load the program, it crashes when I rebuild my terrain, it crashes on the final step of trying to generate layers, it crashes when I save, it crashes when I move the mouse, it crashes when I try to reimport sat or terrain maps, it crashes when it tries to generate a .t4w file, and it crashes when it generates a .wrp. Keep in mind, this is all before I've even added any objects. If I am lucky enough to make it through without crashes, then mikero's tools hang indefinitely while trying to binarise (yes, I left it go for 3 hours before I decided I wasn't being impatient). None of this happened when I used 4096x4096 resolution for scale testing. Are there any good practices to use to avoid such frequent crashes? How do you make large worlds with a good resolution if it crashes on high res data? For reference, I used to use a i5-4670k and 16GB of DDR3 RAM. The program never seemed to use much CPU power or memory anyway but I recently upgraded to an i7-7700k with 32GB of DDR4 RAM, and have seen absolutely no improvement. Has this program always been this unstable and difficult to use? How do the devs even use it to make a map when hardware is capable of handling a heavy load but the software doesn't work? Is this my fault or TB? This software is incredibly infuriating and inconsistent to say the least.

@.kju Thank you for providing simple instructions. My 6 years of programming is limited to Matlab and Excel macros, so I have never had to use cmd for anything important. @mikero I am not trolling you, I was just following instructions I was given without prior relevant knowledge that they required. I google'd "environ path", etc, but that does not help if you don't know for what answer to search. Regardless, thank you for ridding me of the awful addon builder

I went into regedit and set path to the /bin folder for both deogg and depbo, reinstalled the other .exe installed files, as well as copied DePbo64.dll into the syswow64. Excuse me for not catching on exactly all that quickly. What little programming I know is self taught and I am not exactly familiar with a lot of terminology. Unfortunately that did not change the error I was getting.

Well, dePbo64.dll is in the bin folder, even though it stated(?) that it wouldn't be. "There is no requirement for this dll to be global (eg system32), if all exe's use their auto installer." I used all of the auto installers, and all of the respective .exe files and .dll files are in the bin folder. The auto installers are also all placed in the downloads folder. There must be something I am doing wrong still. I've also installed the microsoft dlls just in case. I've uninstalled, deleted the Mikero folder, and reinstalled everything, and I am still getting the same error. I don't know if I am doing something extremely obviously wrong, or what, but I'm going crazy

Hey mikero, I am having an issue packing my addons. My folder structure: /anc /anc_afghan /anc_main /anc_roads When I pack the subfolders separately (each gets its own pbo) it tells me rapify is not recognized as an internal or external command, operable program, or batch file. When I pack the root folder, it tells me the pbos cannot be packed due to an error with MakePbo.exe. The same error it had with rapify.

My folder structure: /anc /anc_afghan /anc_main /anc_roads When I pack the subfolders separately (each gets its own pbo) it tells me rapify is not recognized as an internal or external command, operable program, or batch file. When I pack the root folder, it tells me the pbos cannot be backed due to an error with MakePbo.exe

Update: deleted the configs out of all of my .pbo files and there is no more error. Obviously it goes without saying I can't use anything from my mod now. So it's obviously a config error. There is a problem with all of the config files. It says that the config file is not in the specified location but they are all in the correct location. I deleted them one by one and it gave the same error for each config file in all four pbos

I have been using the terrain builder and addon builder tools for a small bit of time, and haven't had this problem before, ever. It doesn't seem that there is any ubiquitous fix either. This is what is says in the .rpt: It says that the include file is missing. What does that even mean? This never happened until last time I packed the addon. Now, even when I unpack the working backup version I have and replace the files and pack the addon with the working files, I still get this error. I cannot seem to find any way to fix this. Any way to work it out? Edit: Everything was fine in terms of file structure, but packing it this time just broke it. There's nothing different from what I can tell.

AHA!! It worked! Thank you so much!

So after unpacking all of the PBOs, I need to go into each folder and put the ca, CUP, or dbe1 folders in the P:\ as in P:\ca? My current configuration is P:\cup_stuff\core\cup_terrains_ca_structures_e\ca