cctoide

Can anyone please share their experiences trying this? I had the A2 Buldozer.exe working (more or less, it'd refuse to work unless the working dir was my prefix dir), but using arma2oa.exe in Buldozer mode, I can only seem to open an island I had created previously, and not the one I created yesterday (and could visualize fine with the old Buldozer). I've tried checking and rechecking everything and everything seems to be right. It loads, I can even see the island I'm loading, but it crashes immediately. I don't have any objects defined for this island yet. I tried checking arma2OA.RPT and the only errors that pop up before the access violation don't seem to be relevant as they appear even when it doesn't crash. edit: As always, five minutes after posting about it I manage to fix the problem. Nevermind, it was my own mess-up.

I don't have access to the game right now to try it but from the teaser screenshots it looks like a damn good island. Certainly makes me want to check out World Tools once my island gets past the concept phase.

Actually, after thinking about this later it's probably not the RVMATs in Layers, but your terrain texture RVMATs. Those would be the ones in your_island\Data, and if you used the Chernarus textures they're probably called cr_sterk.rvmat, cr_trava1.rvmat, and so on. In those RVMATs in the Data folder, Stage1 should go to a _nopx.paa file and Stage2 to a _co.paa file. The corresponding entries in your Layers.cfg should have a path to an _mco.paa file along with a path to the RVMAT. My hypothesis is that when changing the paths on those RVMATs for your island something went wrong and you ended up with procedural noise in the texture. I'm not sure that's what actually happened, though, since usually one of the tools should have flipped out and refused to work if that was the case... but try it out and see if everything's OK, try comparing your materials to a previous island without this problem. You can get Eliteness from here, and there's some instructions here. I believe originally it was a tool for messing around with the console versions of OFP, but it got expanded to work with lots of BI file types... I mostly just use it to look inside binarized configs and RVMATs. UnRap might do the same, I'm not sure as I haven't used it.

That looks like noise, like a procedural texture somehow got into your ground texture RVMATs. Off the top of my head I can't come up with a reason for that happening, but maybe check the generated (binarized) RVMATs out with Eliteness?

I'm planning on modeling some buildings and I've been looking at the released ArmA 1 models to see how BI did it. I've gotten decent results with my own models so far but I'm left with a few questions... I've noticed most BI buildings, except very small ones, are usually divided into "cube units" - the building facade is divided into a series of repeating elements. There's a door element, a window element, a pillar element, and so on. I assume this is so all these repeating parts can be textured using the same UV space, but I'm curious to know what sort of workflow they used for this. I tried replicating their method by modeling my elements out of a plane and welding them together to form a facade, but this makes it harder to add trim and other parts before stitching the model together, which leads to my other question... Is it bad for a building model to be made of several separate elements, instead of one or two contiguous meshes? Some of the BI buildings have windowsills, roofs, etc. as separate elements, but dum_istan3, for instance, is made up of a single mesh for the main building and a second one for the staircase. As long as the separate elements intersect eachother slightly wherever they meet, will it look OK ingame, or does it mess with shading/performance?

Thanks for your input. My main doubt was about the workflow BIS used so that each element of a building could reuse a single section of UV space. The whole thing smelled of box modeling, so I went ahead and tried doing that. I think I have a decent workflow for getting similar results. I started out by very roughly box modeling the house, getting the basic shape down. Here I made sure that the faces on both sides of the box have identical dimensions, so one side has 3 3,45m segments and is 10,35m long, the other has 4 3,45m segments and is 13,8m long, so all of those faces are interchangeable with eachother. Next I detached the faces and cloned them (the original face stays where it is, since the position data is needed later), then made my elements out of those - a window, a double window, and a door. With these selected the Align tool can be used to align them to the original detached faces (works nicely since the edited faces retain their original pivot point, the corner vertices align perfectly), slotting them into place. They can be cloned and aligned as needed to make the desired facade, and then reattached to eachother and their corner vertices welded to make a finished building out of "units" that can share the same UV space since they're topologically identical. I haven't quite got to the UV mapping yet since I can't get TexTools to work, but I imagine after this it would just be a question of stacking each element properly and then creating the texture. Update 13 June: Alright, I've got pretty good results with the above method like I said, and I think I've got the texturing side of things figured out. It is indeed possible to copy UVs between topologically identical objects in Max, by copying the Unwrap UVW modifier from the mapped object onto an identical but unmapped object. Also, so far, attaching all the elements together and welding the corner vertices together doesn't seem to mess with the unwrap (joy!) so it should all work out in the end. I'm attaching a snapshot of what I've managed to accomplish so far. It's nothing fancy but it might help someone trying to make buildings BI-style. Ignore the mapping on the sides of the windows and the windowsills (and the fact that some squares don't line up), I've only worked on mapping the elements as repeatable squares so far. I used the copy-UVs method from the single window on the ground floor to the identical single window on the other side.

I'm not sure, but I think "no entry" errors may cause configs not to be binarized properly. I'd look at that section of the config and fix the entries it's complaining about. Apart from that, you extracted your A2 vegetation in the prescribed way, right? (i.e. "P:\CA\plants2\clutter", not "P:\CA\plants2_clutter") Does that clutter .p3d exist in the place it's expecting it to be? edit: Heh, you posted while I was typing this up. Try either adding the SparseWeedsClutter surface character, or changing CRMudGround's character to something else, then see if the binarization error goes away and if it makes any difference. Then you can try and fix the other errors until there's nothing in the log... if it still crashes then, it might be something's wrong with the satmap/mask tiles.

I had to play around with lots of different combinations of files in P:\ until Buldozer ran properly. Try restoring the original BI Tools shader files in P:\bin, and copy \ArmA 2\Dta\product.bin to P:\Dta\product.bin. I think that was how I got mine to work.

Unfortunately no, but you can choose how many subdivisions the leaf planes should have. ngPlant is slightly more flexible when it comes to that (it even lets you use .obj, apparently), but it's also harder to use than tree[d].

I haven't done much with playing sounds from scripts, but couldn't the sound-playing loop use spawn{} to play the sound instead of playing the sound itself, so that one spawn{} process starts as the other is ending? You could edit the sound file so it fades in and out, so if they overlap it's not as noticeable. First thought that comes to mind is the 3ms rule interfering with the script, but I'm not sure what part of it is taking that long to run. Maybe other scripts are getting scheduled in between iterations? Regardless, this seems like an awesome addon. I love really technical addons, and the amount of thought put into this is nice. I'd consider lowering the volume on the substation humming, though. Could be annoying if you have to be near it for a while.

Thanks a lot for the scenes, I've managed to get a generated branch properly diffuse and normal mapped. Looks great. Also, I found a couple other generators that look pretty good: ngPlant seems to be basically a fancy 3D L-system interface, it's slightly more flexible than tree[d] though the preview isn't as good. This might be good for generating smaller plants (e.g. fern leaves, weeds, etc.). You can have as many branches and sub-branches as you like, and more than one branch per level. Branches can also be triangles, quads or tubes. There aren't "leaves" per se, they're just branches with a different mesh and texture. Exports to OBJ. No restrictions on output that I can tell. powerPlant looks good but I haven't managed to get it running, the batch script it creates tries to run it via a command that doesn't exist, even though I have Java installed. Will check it out later, I guess.

Hey again. I've been playing with tree[d] since my Max attempt turned out rather crappy, and it's a lot better than it seemed at first glance. Branches look a bit mechanical sometimes, but that's probably due to the settings used. The images above seem to me like they could be used on a polyplane right away. Only issues are that the lighting doesn't seem to be editable, the built-in RTT is limited to 512x512 for some reason, and you can't really do the normal/spec maps properly off of the above images. It exports fine to OBJ and I was able to load it up in Max. After some fiddling with the alpha on the leaf textures it looks just like the tree in the program, however I can't seem to recreate the lighting. It also seems like you lose the random leaf color variation when exporting, as they're all mapped to a single texture. I'm not too experienced with Max, though, so all of that might be fixable, and then you could use your projection baking method to get polyplane textures. It generates pretty good trunks and branches, too, so you might be able to use the exported mesh as a base for the ingame trunk model. It's a pretty awesome little program and it's great they're giving it away even though it's apparently been worked on for close to ten years.

I hope it's OK to bring this back up, since it's a reference thread... here are some photos I took. They're probably a bit useless for textures since I took them before I started modeling and knew what I needed, but I think they're OK for reference purposes. I can get you the original 10MP images if you want them. Walnut tree trunk and scars (thumbnail, click for full size): Walnut branches: http://xs.to/image-02D2_4BEBFE4C.jpg http://xs.to/image-7839_4BEBFE4C.jpg http://xs.to/image-4E79_4BEBFE4C.jpg Freshly cut chestnut tree stump: http://xs.to/image-2453_4BEBFE4C.jpg Edit: Also, I noticed a previous thread about the Arbaro tree generator, I found one which seems to be slightly more user-friendly, it's called tree[d]: http://www.frecle.net/index.php?show=treed.about

I am attempting to get Buldozer set up properly as the visualizer for O2. I have Buldozer working perfectly with Visitor, but when I launch it from O2, I get a brief shot of the model (which remains if I don't give Buldozer focus) which quickly fades to black. The Buldozer text still shows at the top, and if I click RMB it switches to "Anim", so the program is working. The "External Viewer" option in O2 is as follows: "p:\buldozer.exe" -buldozer -noland -cfg=Buldozer.cfg I thought it might be the HDR part of the engine somehow bugging out and applying PP effects when I didn't need them, so I tried setting postFX=0 in Buldozer.cfg, to no avail. I also thought it might be due to viewing BI's sample models for ArmA 1, so I tried creating a simple box and tried previewing that. No difference. I have the bin.pbo from the current version of ArmA2 extracted into P:\bin, with the config debinarized. Dta and product.bin are also in the right places on the P:\ drive. Using the default \bin folder from the BI Tools installation produces the same result. Any idea as to what's wrong? I'm wondering if I missed a step in configuring the BI Tools somewhere along the line, but I can't spot it. Thanks in advance for any help. Edit: Solved. Had to do with my graphics card, which is a one-slot, two-cards SLI solution. Go to the Nvidia Control Panel, "Manage 3D settings", Program Settings tab, and hit "Add". Navigate to P:\ and select Buldozer. In the list below, change "Multi-GPU performance mode" to Single-GPU. Buldozer should now work properly.

I'm no expert map-maker, but here's the first issue that comes to mind... The problem with very large islands in the game (apart from the colossal amount of time it takes to make them from scratch) seems to be that it's limited (maybe just by Visitor?) to importing heightfields no larger than 4096x4096. This means the larger your island is the blobbier the terrain will get, since you have to up the cell size. You might also run out of shades of gray to represent small altitude differences and end up with stair-stepped mountains... I don't know if these issues would apply when merging pre-existing maps, but I'm working on my first island and I've noticed that even for a 10x10km island a 1024x1024px heightmap makes for very blobby terrain and any attempt at proper terrain features at that resolution makes terrain vertices pop up in the air, making for ugly sawtooth crests.

Hello. I'm following this tutorial in an attempt to get to grips with Visitor 3, but I've hit a problem. I only now noticed the tutorial is for A1, but with the mess of tutorials out there it's hard to figure out which version they're referring to. Anyway, I have my island project set up, with the directory structure and files all in place. The terrain works fine, I got to the point of setting up RVMATs and textures and creating the layers.cfg, but when I try to import the satellite and mask textures, after selecting the last file I simply get the error message "Error loading p:\", where p:\ is whatever I have defined as "path to realtime viewer working dir". I can't seem to find anyone else with this problem. I've tried setting the path to a series of possible places, but none work, and it won't tell me what it's having trouble loading. I'm using arma2.exe in Buldozer mode for realtime visualization, and I've replaced the bin folder on the tools drive with the 1.05 bin.pbo. I'm on Windows 7 64 bit, and the tools drive has mounted properly. Any ideas as to what I might be doing wrong? edit: Disregard, problem was a class declared in the wrong place in layers.cfg, though I'd never have gotten there on that error message. Another question I have is whether I am supposed to use arma2.exe for visualization, like a lot of V3 tutorials seem to do - it seems when I do this, it looks for the map relative to the location of arma2.exe, so if I have my map in p:\MyMap it will only find stuff properly (like terrain texture RVMATs) if I copy the map to ...\ArmA 2\MyMap. Is this correct?

Ah, those seem to work. The IR one still doesn't, but I suppose that's because they were originally only meant to go on players, and the IR glow would have been too distracting. I'll just use a colored one, since it lights up on NVGs just as well. It's not exactly what they did in the real-life operation I'm trying to recreate, but it works. Thanks!

Quick question: is it possible to spawn a glowing chemlight by script? I googled for several combinations of "ACE 2", "spawn", "chemlight" and "glowing", but couldn't find anything about this. I can spawn the chemlight magazine fine, but then only the model glows, there's no light effect. I intend to use them as markers for a makeshift runway, but first I need to check if they're visible by pilots on approach. It's probably not the most realistic use for them, but I'm not sure there's a better way of doing it for now. edit: Hm, it seems the IR ones aren't even visible from more than a few meters away, so I'll have to find another way.

I realize that ACE and the sequel inherit the WGL mod's features for the most part, but are you looking at tomes such as Tactical Gaming Done Right for potential new features, or is the feature list restricted to recreating ACE1? In particular the bit about how being able to keep both the rear post, front post and target in focus when using ironsights being unrealistic seems like it would be worthwhile to implement, making the fancier sights more useful... I take it DOF isn't easy/possible to mod in A2 though?

Yes, generic question because I wasn't sure whether redoing the content was just your own option or if it had to be done that way because of restrictions, seemed like a big fuss over what was going in when there was already a large amount of assets. I'll shut up now.

I've seen several discussions related to ACE regarding content donation. I'm curious what the status of the content included in ACE1 - vehicles, essential models, units, etc. - is. Would you have to get permission from the donors again, or do they have to be changed to work in A2, or do you just want to start with a blank slate? From what I've read, it's not quite as simple as just taking the ACE1 content and running with it, right?

If any map makers are at a loss for ideas, one of the communities I play with are fans of Afghanistan-style maps. We played the Avgani map for ArmA extensively. Now the creator of Avgani appears to have left the community, so an Avgani map for A2 seems unlikely. Some people in the community have suggested a Helmand Province style map would be great for the servers. A desert map with significant elevation changes, preferably of a relatively large size, with a few cities thrown in, but mostly made up of fields and small farming settlements. If anyone's willing to create a map in the style of Avgani, though, that'd be great too, a bit larger if possible with more suburbs and routes of approach to the main urban area.

A fair point, maybe punching and kicking malfunctioning electronic equipment should be added as a feature! :p

Okay, I'll give you a bit that, while not "thin", was pretty puzzling to me when I was figuring out ACE for the first time. I don't know if the "ACE Features" page on the BI wiki is meant for end-users, but I read it a lot back then, and it contains useful information. I respect the work put into it and the information it contains, but the formatting is a bit weird, and I remember trying to decipher the part under the "Rucksack System" heading more than once. I don't know if it's meant to be more of an explanation of how the code behind the ruck system itself works, because at the time it didn't seem very relevant to using the rucks ingame. It explains stuff in terms of "pack dummy magazines" and "end use magazines", and how using the inventory creates and destroys them, but I never got much out of the explanation there, though I was able to figure it out easily ingame. Further down the page there's some text about an update to the ruck system, and code samples, so I guess this part was created with a more technical purpose in mind, which would be okay as I have done some programming before, but it quickly becomes a mess of acronyms. In particular, it starts out with "Pack dummy magazines (PDM) to represent stored end use magazines (EUM) in a 1:1 ratio" but never explains exactly what they are. This is perhaps a long-winded way of saying that I found that section confusing, but on the whole the Features page is useful. For ACE2, however, a small PDF booklet or website would be nice; I might even work on something like that provided I have the time when it comes out. Edit: An "ACE2 guide" might face one problem, though: if you're going the modular way, it means some widely-used modules that add functionality might not fall under a base-package guide. It's hardly a huge problem, but it would be something to take into account. For the most part, though, I feel making such a guide would be mostly a matter of writing the copy; everyone more or less grasps the basics after a few rounds with ACE, assuming you're playing with people who're willing to teach the newbies. An official "gospel" would just help solidify understanding of the mod and avoid guesswork and superstitions caused by not knowing how things actually work.

Something that might be nice for ACE 2 is slightly better publicity... I don't mean in terms of advertising the mod, since everyone who wants it knows what it is already, but in terms of download sites and web presence. When I first got into ArmA1 and saw ACE mentioned I googled around a lot, but finding the proper place to get it from and keep it updated took a lot of searching and asking around - I wasn't very deep into the community. There seems to be an official-ish ACE site at ace.usmc-warriors.org, but it also looks dead and lacks any download links or mentions of ACE 2. When I had to update to 1.19 I also had to search around until I found I could download it from Armaholic (though at the time their file was corrupt). It might just have been bad searching on my part, but it seemed to me I had to trawl obscure parts of the community to find the files. It was pretty late into ArmA's lifespan, though, just a few months before A2 - the original game sat on my shelf for a long time before I finally found decent servers and ACE. Also, better documentation would be a plus, but I suppose the team is already swamped in feature requests and basic functionality, so it gets sidelined. I learned of a lot of ACE features through reading long infodumps in wikis and forum threads from people who figured out things - a lot of stuff probably didn't get used because people couldn't find anything on it.