animander

Helvantis By Animander Description: Helvantis is a fictional Germanic Eastern-European nation in a winter climate, designed to add a little more variety in terrain types and climates currently available for Arma 3. This is the first terrain that I've ever made, so it is far from perfect and there are certainly some rough patches, but it was an excellent learning experience for me. I hope some of you will get some enjoyment from it. Features: Roughly 100 km^2 Heightmap resolution of 5m/p A variety of locations from thick forests and open fields, to heavy condensed urban areas. Several large towns, including one large sprawling city several kilometers in size, and one city of ruins. Large variety in elevation from valleys to mountains Screenshots Credits & Thanks: Big thanks to Sumrak for granting me permission to use some of his custom objects. Pabst Mirror for lots of technical help Bourbon Warfare for testing and general support Rquirements This terrain uses Arma 2 objects, so All in Arma Terrain pack, or A3MP is required. Changelog V1.1 â—¾added server key â—¾fixed waterline bug in one specific location(removed pond object conflicting with another one that was too close) â—¾fixed miscellaneous little issues Download Armaholic Page

No problem, sorry it took me so long to get it updated for Arma3 patch 1.6

I've been trying to figure out this issue for quite a while now, and have completely run out of ideas on how to fix it, so I'm hoping someone here has an idea on what's causing this. I built a custom map for Arma 3 with Arma 2/OA/PMC objects/buildings. When I load it into A3 and play on it everything works perfectly fine for the duration of time I'm playing on it, but after I exit it, one of two things happens: 1) If I try to then switch to a mission on any different map, arma3.exe crashes. 2) If I try to close Arma 3, instead of shutting down normally, Arma3.exe crashes. In both of these situations there are no error messages, just "Arma3.exe is not responding." If I remove every object and just load an empty terrain with only surfaces and clutter objects, everything is fine, but when I add the objects back, the crash on exit/map switch returns. This tells me it must be something with the Arma 2 objects, but there are plenty of other maps out there using Arma 2 objects in Arma 3 and work just fine, so I don't understand where the issue could be. I've checked the .rpt file after my Arma3 crashes, but all it tells me is the cause of my crash is the map name, so that doesn't really help me. I should probably note that this only happens with my map and not any other that I've tried, and happens on multiple machines that the map has been tested on(all 15+ people in the arma group I play with). I'm hoping someone here has some ideas on what could possibly be doing this, any help would be very much appreciated. Here are some technical details about the map incase any of this is relevant: Map resolution is 2048x2048 with 5m/p = 10240mX10240m All objects are from Arma2/OA/PMC Roughly 800 000 objects on the map I pack the .pbo with the most up to date version of Mikero's pboProject. It reports 0 errors. If there's any more info anyone may need to help diagnose the issue I'll be happy to provide it. Again, much thanks to anyone who may be able to help.

In classLegend, you're line bia_myisland\data\gdt_grass_green.rvmat[]={{0,255,0}}; should actually look like this: gdt_grass_green[] = {{0,255,0}}; You need the class name of the material you defined above, not the filepath. Double check that all your file paths are correct. Also, I'd advise you to re-name all your textures to a unique name, and rename your classname "gdt_grass_green" to something unique as well. These names are already used by vanilla Arma stuff and can cause conflicts.

Arma has a poly count limit of roughly 20 000 verts/faces per object. The reason you got those errors is because your objects exceed that limit. In the second case where you split some of it up into a proxy, that proxy object still exceeded the limit so you still got the error. If your aircraft still has too many verts even when you split it up like that then it's probably way too detailed and you'd be better off with a less detailed model to work with.

I worked on it for a couple hours nearly every day for about 3-4 months. After that there was another 3-4 months of testing and/or tweaking things sporadically when I had the time and felt like doing so.

No immediate pans to make any further changes, but I'm not ruling it out in the future. The new project is not a winter map, it's a different type of climate. I'll probably post something about it on these forums when I have enough finished to be worth showing. In the mean time, the ALIVE team released an update today with support for Helvantis. Those of you who were asking for this have your wish granted! Big thanks to the ALIVE dev team for doing this.

If it's related to distance, then it sounds like a missing resolution LOD maybe. Check your .p3d and make sure there isn't a res LOD with nothing in it.

Yes, as far as I know, best practice is to link the _co texture in the texture dialogue box in object builder, and then the .rvmat in the rvmat dialogue box. Because the _co is already linked in object builder, you don't need to include a _co texture entry in the rvmat, it's just redundant. That said, here's a very basic .rvmat I've used before ambient[]={1,1,1,1}; diffuse[]={1,1,1,1}; forcedDiffuse[]={0,0,0,0}; emmisive[]={0,0,0,1}; specular[]={0.53660399,0.60000002,0.47999999,1}; specularPower=850; PixelShaderID="NormalMapDetailSpecularDIMap"; VertexShaderID="NormalMap"; class Stage1 { texture="p:\Pouch\PouchNormalMap_NOHQ.paa"; uvSource="tex"; class uvTransform { aside[]={1,0,0}; up[]={0,1,0}; dir[]={0,0,0}; pos[]={0,0,0}; }; }; class Stage2 { texture="p:\Pouch\PouchColourMap_CO.paa"; uvSource="tex"; class uvTransform { aside[]={1,0,0}; up[]={0,1,0}; dir[]={0,0,0}; pos[]={0,0,0}; }; }; class Stage3 { texture="p:\Pouch\PouchSpecMap_SMDI.paa"; uvSource="tex"; class uvTransform { aside[]={1,0,0}; up[]={0,1,0}; dir[]={0,0,0}; pos[]={0,0,0}; }; }; Now, as said before, you don't need the _co entry there when it's already applied in object builder. As well, if your object materials shouldn't have any specular light reflections(like wood or stone, or anything rough) then you don't need a _smdi texture either. Applying an _smdi texture to a material that's supposed to be rough will make it look wet or shiny instead.

The env_land_co.paa is for faking environmental reflections on a shiny surface. The reflections on things like really shiny metal, or glass, are not real reflections of the area around the object, but rather faked with this texture image, so you want this image to be a general representation of what your terrain looks like. If your object isn't supposed to be shiny enough for reflections, then you don't need this. Your rvmat looks ok from what I can tell, but I'm not an expert. Why do you think those textures aren't showing up? Maybe it's the textures themselves and not the rvmat. It might be a good idea to just copy one of the rvmats from unpacked arma3 content and use that, substituting the file paths for your own images.

I'm working on a new project right now, but I'm not ruling out fixing major issues that someone might find. Minor things that don't really impede map playability though are not really worth an entire update on their own. That said, of the things you mentioned, the wall/fence damage as I said is an AIA issue and outside of my control, and you didn't clarify what you meant by "terrain penetration," so I can't investigate that until I know what you really mean.

Goblin - glad you enjoy the map, but unfortunately, no, Alive does not work with it at all yet. I have no idea if they plan to index it at some point or not, I may get in touch with them and see if they intend to, considering a number of people have expressed interest in that.

IndeedPete - those are looking pretty good! The top images do look a little bit greyer than the others, but only slightly. I'm not sure what would cause a difference like that. The lighting values for Helvantis are identical to Stratis,. I don't understand a whole lot about how the lighting stuff works, so I just lifted the values straight out of the config for that terrain. Nummi - all of the stone walls are taken from AiA, so any of their damage behavior is in the hands of the AiA people and out of my control. This is the same for the trees. The ground textures do repeat a bit noticeably in some places, but I considered it not too bad to be worth re-doing the mask all over again. What terrain penetration issue do you mean? I haven't seen any mention of something like that. Gorogon - those objects are taken from AiA, I have no control over any bugs related to specific object types behaving weird, aside from removing that object.

You can stack fence pieces end-to-end as much as you like, there's no issues with them clipping into each other a little bit, but if they clip a whole lot then there will probably be some graphical flickering. As for players getting stuck, as long as the geolod's match up and everything is matched end to end well, there should be no problem. As for the rock, if you want people to be able to walk over any part of it, the roadway lod can be just be a copy of the rock mesh(or a simplified one if it's really detailed).

That's true, but for the example of a chain link fence, there wouldn't be any sort of bullet splintering effect, so an empty fire geometry would be sufficient.

If you want it to prevent players from walking through it, it just needs a functioning geometry LOD. If the fence is low enough to vault over, then as long as the geometry LOD matches the RESLOD for the fence, it will also be low enough to vault over. What that actual height is, I don't know. It will probably require you just testing different heights in game until you see what works. If you want a really low stone wall that people can just walk over without having to vault, give it a roadway LOD on the parts that you want people to be able to walk on. Any surface of an object that players can walk on needs a roadway LOD for that to work. If a surface doesn't have a roadway LOD but it still "looks" like you should be able to walk on it, you still won't be able to. If you want a fence that stops players walking through, but not bullets being shot through(chain link fence for example) then give it a normal geometry LOD and an empty fire geometry LOD. Note that you still need to give it a fire geometry LOD, but just leave it empty. If you don't give it one at all, it will use the geometry LOD(or the view geometry LOD if you have one)as a fire geometry LOD and still block bullets. The important thing to remember is that the RESLODS are only what you see in game, but not what you're actually interacting with. You're actually interacting with the other invisible LODS(geometry, roadway etc) to determine collision, surfaces you can walk on, bullet hit detection etc.. Also, in the geometry LOD you'll want to give fences a property with name map and value fence, and another with name damage and value fence. The first one gives it a map icon for a fence on the in-game map, and the second one gives it the appropriate damage behavior when it gets damaged (like falling over when rammed by a vehicle, etc). Hope this helps.

I understand you intend to make all of the necessary RESLODS eventually, as you mentioned in your original post, but the LODS I mentioned are not RESLODS, but rather other types of LODS that are also needed. The term RESLODS refers only to the LODS that you can see in game that have decreasing resolution as you get further away, but there are other types of LODS that are invisible that are needed too. Just want to make sure that you're aware of these other LODS you need, and hopefully just misusing the term RESLODS to refer to all LODS and not just the specific type.

There's no problem with doing it the way you describe, as long as the p3d file names and directories stay the same as they are when you place them on your map. The terrain file just calls to the p3ds and takes any content that's in there, so as the p3d gets updated the terrain automatically updates those objects as well. That said, the buildings won't actually be usable in game at all until you do the hard boring work of making all the different LODs that are needed for a functioning building(Geo/roadway/path/etc).

you need to define the object as an arma object. select your object in blender, hit "n" to bring up properties window, and click the "make arma object" button.

if you want to use blender for modeling you should get the arma toolbox plugin for blender http://friedenhq.org/?page_id=251 It'll let you export directly to a .p3d, as well as do most of your other needed work directly in blender(assigning textures, .rvmat files, doing animations, etc)

Jinouga - I'm not sure, I haven't experienced any framerate issues like what you describe. Try redarmy's suggestion, as it seemed to help him out. IndeedPete - Thanks very much! Glad you enjoy it.

small update available, v1.1 changelog on first post.

Azer1234 - not sure what he used to make snow, but this is what a friend showed me: snow = "#particlesource" createVehicleLocal (getpos player); snow setParticleParams [["A3\Data_F\ParticleEffects\Universal\Universal", 16, 12, 8, 1],"","Billboard",1,2,[0,0,5],[0,0,0],1,0.0001,0,1.4,[0.06,0.06],[[1,1,1,0.7]],[1,1],0.2,1.2,"","",vehicle player]; snow setParticleRandom [0, [10, 10, 5], [0, 0, 0], 0, 0.02, [0, 0, 0, 0.1], 0, 0]; snow setDropInterval 0.01; paste that into the end of your init.sqf This will create a cloud of particles that fall around each playable character. The only downside is that it will still look like it's snowing even when you're indoors, but it looks great most of the time. Change the last number at the end to change density of the falling snow (setDropInterval 0.01 = lighter snowfall, setDropInterval 0.00001 = more snow, etc) redarmy - I'm not really sure where your ai pathfinding issues are coming from. Any issues with entering/exiting buildings is out of my control, it comes down to Bohemia's creation of those buildings. As for the airfield, I've played with ai there before and never had any issues like what you're describing. Has anyone else tried it and can confirm?

I just tried the dev branch version of addon builder and all of my rvmats are still not working when I binarize. If I don't binarize then they do work, so something is clearly wrong still.

Thanks everyone. redarmy - I'm not sure about AI crossing the bridge, I'll look into it, but since the bridges are Arma2 models I'm using from AiA, there's nothing I can really do about that. I have no plans at this point to make a land bridge of any kind. Lordprimate - The Arma2 ponds have always worked(sort of) in Arma3, they just need to be used in a certain way. The pond waterline bug is caused when more than one pond object is visible within render view at a time, so as long as pond objects are used individually and kept far far away from eachother, there's no issue. Sometimes the water will turn black in certain lighting/weather conditions(mostly if it's raining) but most of the time they look great, so I decided to include some. ParsonsVCB - yeah, that horizontal line you're seeing is caused by two pond objects being a little too close together, so from a certain altitude you can see both and it causes that to happen. I've already fixed it on my end, and an update will be out in a few days. As for the floating buildings, I'm not sure what's going on there. I just checked the map both in game and in terrain builder and they're not floating for me. Are you using AiA or A3MP? Can anyone else go to the location he marked and confirm if they're seeing floating buildings there as well? AntonioAJC - actually I used both, some ponds are just pockets of water below sea-level, and some are Arma2 pond objects.