Homer Johnston

I haven't done it successfully yet, but I have learned enough that I should be able to. A few topics need to be understood: 1) Generic binary-file manipulation in your language of choice. For C++ I use similar processes as this tutorial: http://www.angelfire.com/country/aldev0/cpphowto/cpp_BinaryFileIO.html 2) Endianness, hexadecimal, reading bytes, how to look at a file with a hex program and understand it: http://en.wikipedia.org/wiki/Endianness#Diagram_for_mapping_registers_to_memory_locations (PEW is little-endian, so bytes containing numbers are read "backwards"; e.g. a "ulong" in hex may read 0B 00 00 00, which would equate to an integer value of 11 ... ) 3) Floats: converting bytes to an actual number, IEEE encoding (this allows you to find specific numbers in the hex file, to understand the file contents - try making a small 16x16 terrain and edit one vertex height, then find it in the .PEW and hex-edit it :)): http://www.h-schmidt.net/FloatApplet/IEEE754.html 4) The PEW (POSE v60) file structure: http://community.bistudio.com/wiki/POSE_v60_File_Format http://community.bistudio.com/wiki/Generic_FileFormat_Data_Types If you open up a PEW with a hex editor you can theoretically follow the PEW File Format, passing through it section-by-section, byte-per-byte. You just have to make a simple test island with some objects and examine things for a while until you match things up. Make sure you match up the "Data type" with the bytes you're looking at. It took me a few nights to figure things out. If you're curious for more info or explanation, I will try. :) As a simple example, this is the PoseHeader, with the file length: Pose Header parts in hex [Edit] Another idea that is really tempting is to abandon road networks and use roads as individual objects - in fact, "road networks" are only for Visitor/PEW's. Once you export to WRP, I believe all roads turn into individual objects just like trees, houses, etc. The benefit of this would be to allow for custom road pieces (in turn making it infinitely easy to lay down curved paths). The downside is that you could not use Visitor scripts (i.e. smoothroads) on roads created this way... for this reason I'm not pursuing it now, but it's an idea I'm keeping in mind...

to do which part (or parts), exactly? :)

I'm a little late to be of any use, but everything others have said is correct. The only other thing is that my tool assumes your roads are in the CA namespace, i.e. P:\Ca\Roads2\ Anyways, I've started thinking about what else to do to the tool for the summer... I've learned how to do binary file operations with C++ (i.e. I can read/write in PEW's now). I think I'm going to *try* to cut straight to the point and make it open/save your actual PEW file - example, start up tool in ArmA, load PEW (probably have to manually type in the filepath the first time), RoadTool loads roads in-game, draw roads as you wish, save PEW. It seems like it's possible... I should know for sure fairly soon. Cheers,

Unfortunately, I think I'm going to have to disappear for about a month... it's complicated, but basically I have deadlines for other things in life for the end of June (moving apartments, projects with other people who are moving away, other odd things) I have been doing a lot of other general coding-learning, and I think what I'm going to do is rewrite this tool from the ground up with everything I've learnt so far. I still plan on having something which will completely replace all usage of the Visitor tool, sometime this summer. Thanks for the kind words guys, they make it worth it :) I'll certainly post any updates, but they will be sparse at least until I find a new place to live near the end of June...

v0.11 Beta: this is not a new release and will not be posted on the first page (although it should be fully functional, I think). This is to demonstrate a possible new camera script - I ask for volunteers to please download this, try it out, and give me any feedback to improve it before the weekend. TEST VERSION http://dl.dropbox.com/u/4621600/RoadPainter_v11_CAMTEST.zip I want to know: - Does it feel easy enough to get used to and use? (it took me a few minutes of moving around with it to get used to it - how about you?) - Do you have any ideas for alternate control schemes which might work better? (bearing in mind that most road-laying will probably be done from a top-down view, so I'm trying to keep the RTS-style mouse-panning instead of operating it like a first person view) How to test: 1) Load in editor as usual 2) Use WSAD to control camera pitch & direction 3) Mousewheel controls camera height (and influences pitch slightly as well)

Thanks T_D, that could help! I will be looking into that. Cam controls are relatively easy, you guys will see them at some point, when I get around to it... Whatever gets the job done. ;)

If you know how to/learn how to make your own custom objects for your island, this will be no different than making any other custom object. Learn how to use Oxygen, make your own texture, and then make your own road piece .p3d to include with your island addon.

Thanks for the input; I'll see if I can put a dialog back in for placing with manual X,Y, Dir coordinates. :) On another positive note, I've spent all evening doing some trial and error with a hex editor, and have finally started to understand the PEW file format a little... another couple evenings of experimentation to get my understanding solidified, and then I'll need to learn some more advanced file writing techniques in C++... and then after a few weeks of work, hopefully you won't need the manual X-Y dialog because exporting from ArmA & importing everything to PEW could be a one-button-process without using Visitor at all ;) it's starting to get pretty complicated at this point though, and could take a pretty long time - I have no idea what exactly I'm getting into yet. Then if that concept all works I'll be able to get to work on an ability to save/load your progress in the Painter tool...

Should be fixed; thanks ebanks for guinea-pigging an updated .exe for me :) Download link re-enabled.

Link temporarily disabled; give me a day to figure out why that happened (I'm pretty new to C++ :p) Thanks for the heads up!

Updated root post contents: - v0.1 (beta, non-preview) now available for download - new youtube tutorial video This is a buggy release. There's a lot of bugs that I know about. There's a lot that I don't. Feel free to share them all :) If you have ideas for other improvements, say them as well; this tool suffers from the fact that its designer hardly actually uses it, so he may be oblivious to its flaws. This weekend I'll try to post an update which will allow for camera-rotation, and maybe some small fixes.

This isn't dead! But I'm also not releasing it just yet. I had some personal-life hiccups a couple of weeks back which derailed my personal projects a bit. I also needed a break from coding tons of SQF, so I learned C++! Since last update, I've learned enough C++ to write my own program which will replace Leopotam's, so that I can better customize it to my needs - this means saving and loading data, and fixing that odd error message Visitor gave when importing. With the in-game tool, I can now place key-parts, draw road sections starting from their connection points, and attach key parts to the end of road sections (in short: draw roads just like Visitor). The export button automatically writes each section to a separate file so you can draw several sections, hit export, then go import them sequentially in Visitor. A few simple images to demonstrate: Selecting/placing a keypart Some road sections named R1, R2, R3 ... blue dots are keyparts What happens when I press the export button What I can't do yet: -move entire roads by dragging/rotating keyparts Why I haven't released anything yet: -learning C++ / writing my own app -trying to learn PEW file format -I wrote the entire tool in far too big of a hurry last month, and have been having trouble cleaning it up (messy code, bugs and instability); I've been slowly rewriting large portions of it -I've been playing too much Mount & Blade Warband :o As always, comments or suggestions are welcome. I am really desperate for help on a way to write roads directly into a PEW - I just don't know enough about deep binary file contents to understand that BIKI page and match it to what I see when hex-editing a PEW. There are very few people in the community that know how to do this... maybe someone with a Computer Science degree would know more. If anyone has any tips for me, please share!

I don't know if this is the solution or not - I am just thinking out loud - but try using satmap/maskmaps that have 2^n dimensions. i.e. downsize your 1280x1280 textures to 1024x1024, or upsize them to 2048x2048.

Did you try saving it as a terragen image, re-loading that, and editing it as a different file type instead? Photoshop will work, but it is very difficult to visualize the 3D aspect of the terrain while looking at a grayscale image...

Hm, I think it is correct to say this: Whenever you export to PNG, Wilbur will always scale all Z values to the full range of 0->65535 (black to white) in the resulting image. Tallest mountain will be completely white, deepest valley will be completely black.

Do you think it's possible T_D? I don't know anything about the PEW file format, how "accessible" it is... or what road networks look like in it. If we could automatically inject roads & keyparts from txt files, then I suspect road building would become a matter of days, instead of months... :o

Just to make sure my first post was clear on the 0-65535 topic: Using a PNG file with a full range as close as possible to 0 --> 65535 is best-practice. The reason: If your Visitor map has a height range of -50 to +450m (500m), then each value from 0 --> 65535 in the PNG will increase in height by 0.0076m (500m / 65535). This means you get very accurate control over the height. If you were to scale the PNG pixel values down to, say, 0 --> 500 to "fix" it in Wilbur (thus leaving values 501 to 65535 unused), this would mean that when the PNG was used for Visitor, the minimum height resolution would be 1 meter (and you would have to specify a max height of 65535 in your PBL). If Wilbur imports a PNG with heights from 0 to 65535, it is a good thing. What you need to know, is how to get wilbur to display the terrain heights as something that makes sense to you. PNG is a "dumb format": gray intensities cannot be negative or contain decimals. Wilbur can probably display the 0-65535 range on another scale for working with it, but I don't know how... Worst case scenario - do as Gnat says: load PNG into Wilbur, save as new type (Terragen or HFZ maybe?), then work on it as the more-flexible format instead. Export to PNG again when done. Wilbur will always export any format to a PNG with the lowest point as black (0) and the highest point as white (65535).

It is possible that you don't know how everything works: A heightmap PNG, or 16-bit grayscale image, only contains pixels. Each pixel has a "brightness" value which ranges from 0 (black) to 65535 (white). In other words, there are 65536 different shades of gray for each pixel in your PNG. An ideal heightmap always has at least one pixel which is completely black (0) and one pixel which is completely white (65535); this allows for the most detailed terrains, using every value possible. When you import a PNG into Wilbur, this is all it knows: that 0 is the bottom, and 65535 is the top. Wilbur simply assigns Z values equal to the pixel values, so when you import a black/white PNG into wilbur, I think you will get heights from 0 to 65535. When you import a PNG into Visitor, the PBL file tells Visitor to scale this 0-65535 range to your minHeight maxHeight values. Can you describe exactly what you mean by "ruined"? After you do this, then I'm sure someone will be able to help you find a good solution.

Thanks Shezan... There are a few things mentioned in my last post which I would love to have help with, from you or anyone who is capable of it: 1) Create an addon for all road parts (basically, copy out the roads from Lester's/MapFact's Editor Update but use a HOMJ_ tag instead of MAP_). Thanks Sgt.Ace for giving me a start for this! 2) Create an application which can inject roads into a PEW file (maybe if you're Albert Einstein). :p 3) Create a very basic command window application to allow this: ArmA sends one of the following strings to the clipboard: ARMA2_HOMJPAINTER^WRITE^P:\FILENAME.TXT^LINE1^LINE2^LINE3^... ARMA2_HOMJPAINTER^READOUT^P:\FILENAME.TXT [*]The application will wait to see the ARMA2_HOMJPAINTER tag in clipboard data, and either write or read data as specified, using ^ as a separator [*]The application will then send one of the following strings to the clipboard for ArmA to read: ARMA2_HOMJPAINTER^RETURN --- tells arma that the write operation is done ARMA2_HOMJPAINTER^READIN^LINE1^LINE2^LINE3^... --- tells arma file contents If you, or anyone, wants to give any of these a shot then just post so here, and keep me informed with any progress you are able to make. :) Also if anyone could actually do item (2), they would soon be a god to all island builders...

A wall-of-text update for anyone interested. Roads are created in the following stages. It is more similar to Visitor: create key part. create road section (a name to contain all pieces between two key parts). select which road section you want to edit. - if section is empty (starting new), you will be prompted to click near a side of any keypart to start there. - if section already contains pieces, you will continue adding to it. [*]Keyparts can be moved/rotated with the mouse. Any drawn road sections will not move with the key part yet, but hopefully will later on. [*]Unfortunately, key parts still have to be placed manually in Visitor. If only we had our own program which could inject roads into PEW's. :( [*]The beta release will only support terminator and straight pieces as key parts (which apparently is all you *need* anyway). If there is demand, I will implement T's and X's (or other pieces??) in a future version. [*]Export will involve: entering destination path (default "P:\RoadPainter\"). press "Export Roads". - All road sections will be exported to separate files that match their name. - This will probably take about 1/10 second for each section (to ensure none are "skipped" by windows clipboard) [*]Camera controls will be: - rotate with A, D - change pitch-angle with W, S - change height with mouse-wheel. I have around half of the above working. Keep your fingers crossed, hopefully next week there will be a tutorial video followed by a release. Current plans for future versions: Create my own addon which contains and enables placing of all A1/A2/Community roads. Map view which shows all road sections, labelled. Ability to save/load progress (I will need to write my own application for this which will take some time, because I am new to C++...). Test/implement Leopotam's algorithm; try drawing sections automatically with placed points.

sounds like I need to give L3DT some more learning time, some day. ... or just spend all my time working on tools and let you guys do the actual island making, heh.

I guess for now I don't really need to focus on giving my tool the ability to place crossroads then? ... maybe just terminators. Definitely unusual.

the "non-standard" road parts on Chernarus are to be expected, since there's tons of extra roads they gave us in Roads2.pbo that Visitor3 can't use (frustrating...). It's interesting that they used a "sloppy" method themselves though. I guess they must have been subject to some limitations of their own tools after all. :p

interesting, I guess it's just a graphical glitch, but does Chernarus use crossroads & have this same issue?

A long time ago I spent many hours trying to find a way to do this. Photoshop seems to have trouble working with 16 bit images, but I think it is possible in the more recent versions if you know how. I think L3DT will allow you to place BMP overlays and edit the terrain in 3D, but the trial/free version is a bit limited, and I found it a bit hard to use. I guess this is why BIS developed the smoothroads script... it doesn't do what you need? We badly need a Visitor scripting command-reference. :( If only Buldozer could modify terrain vertices in 0.01m increments instead of 1m and 5m :(