animander

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

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.