Romolus

Agreed, that some things require more effort than others, but that's not the point the op was referring to as far as I understood. The point as I see it, is that once you want to do a bit more than just clicking around in the mission editor, things become complicated in ArmA and that the op feels that while there is some knowledge about those things, he feels that it's pretty much inaccessible for many. And I can see that he has a point there, although I think the conclusion he draws from it is different from what I think is the issue here. And that's where we start to disagree. Like Soul_Assassin mentioned, even mission making starts to get complicated very fast and to a point where you really benefit from at least some basic understanding in programming. I agree that you can create quite interesting missions without anything that requires some kind of programming, but that already ends when you want to use some more sophisticated triggers or init lines. Just have a look in any mission-making related forum here or on OFPEC and you'll see that even the most basic topics that come up there are things where it gets to putting scripting commands into triggers, init-lines or script files. It's obvious what people are struggling with when they start out, in my opinion. And this was already true even for the OFP demo. People with even minor knowledge of programming had it way easier to figure out what was going on in those demo missions, while many who didn't already had a feeling that they were left out and no one really was sharing info. (Somene still remembers LustyPooh's forum? *nostalgia* ). But if you had some ideas about programming, you could just open up the files and see for yourself. It's just the most efficient way to learn those things. Once a programmer knows the concepts, he just looks at (highly technical) refs/specs and other programmers code, because everything else is way less efficient. You don't see rocket scientists discuss things in layman's terms either. So my advice is: If someone's struggeling with mission making, scripting or don't see how configs really work, then don't just run searching for the next tutorial that covers the specific thing you need. Since even if this feels like a fast way to learn things, you're cheating yourself from learning the principles and getting a much better understanding of how things really work. With a tutorial, you maybe learn one specific thing if you're lucky and the tutorial is good. But if you learn the principles, you learn how to manage a whole set of problems. If you already do some mission editing, scripting or config work, I bet that you're not really unsuitable for learning some basic programming and it won't really take any longer than searching a tutorial for every single issue you're facing. For modeling and texturing, I would say the same applies: Try to learn the basic principles instead of trying to find a specific tutorial that seem to exactly match your problem. Because most of the time the issue isn't that specific, but more general. Don't get discouraged by the difficulties of modding. Start easy, one step at a time, make sure you get into the basics and things will get much easier over time That's mainly because the modeling crowd is mainly here, while the scripting crowd is mainly at OFPEC. Just count the posts in the forums here and at OFPEC and you'll see. Always was that way. But while you're right that people usually fail to see that there's more than one area, this certainly is true for both forums. I've seen solutions on OFPEC that I thought only a programmer could come up with :D. (I'm one myself for a living, so don't get me wrong there) Uh, easy, easy. You really want to go into that discussion (again)? First, I think it's ok to assume that we're all here for our personal enjoyment, because we have fun with the game and in modding it. So I really think it should be up to everyone's self to decide what to focus on and how. Everyone's already working hard in their day job, so pulling that line about working hard here where people come in their free time, is a bit unfair, don't you think? Second, maybe you should have a look where the idea of a forum comes from (beside it being some software on a website) and you'll see that the idea of a forum includes talking pretty much. If you see the exchange of ideas and opinions as little or no gain, then maybe that's not the fault of a forum :) I would be interested in your opinion on why there wasn't much interest in the OFP campaigns in ArmA. I think you're artificially dividing those groups. In my experience often people fall into more than one of those categories, so I think you can't really make a clean cut conclusion like that. Especially when people do those things in their free time, I think it's only natural that they try to enjoy their work. (Well, even if one doesn't and is a bit masochistic he would enjoy it by definition, would he? :D) (@mods: Now what's the point of including smilies in the 5 image limit of a post? Someone might take me too serious without a smilie here and there :p Oh, I get it. You mean I should write shorter posts :D)

Honestly, I didn't take you as someone who is satisfied with a somehow "working" solution ;) For example, the old OFP island format was "working" for ArmA, but I think you agree that it was a pain in the ass and everyone was happy when we could do some "real" ArmA terrain. I didn't look into the ArmA2 file formats yet, so I'm quite a bit cautious about recommending to use ArmA tools to Mod ArmA2. In some cases waiting for proper tools could be better than going full steam with the old ones. Especially for terrain. Models and textures might not be that critical. But I think we're going offtopic there already. I think the main point here is that it's not really about the tools. Sure, us old farts from ArmA or OFP modding know how to even bend the old tools to work for ArmA2, or write our own, but that's not the main problem for someone just starting out with modding on ArmA2. The main problems someone probably has are like: "What's that UV mapping thing everyone is talking about?", "What the hell is that shader stuff about?", "Why do I end up with twice the polygon count as others and my model still doesn't look as good?", or "What's all that bracket stuff in the configs?", or maybe even "Err, what's a variable again?". And you don't really learn that from following an ArmA2 specific tutorial. Once people understand the underlying principles, it takes them only a small effort to figure out how to use the tools (even the old ones) from looking through the forum or the Biki, or maybe even just tinkering with them a bit. But the less they understand the principles, the more they'll struggle with the info they find here. More people who are seriously interested in taking on mission making :) (And maybe BIS to really fix the AI vehicle issues, since those almost completely ruin the combined arms idea the game is so outstanding for) People toy with addons, but they play much longer with missions. Gameplay is much more defined through missions than addons. So if you ask me that way, my answer would be: Missions :) Edit: Oh and way more free time of course ;)

+1 for the Manfroto from me as well. But don't forget a decent head for it, as a bad head ruins the nicest tripod :)

(not particularly aimed at you ])rStrangelove' date=' your post just seemed to point out the real problem) [/size'] The thing is, that was 11 years ago and GPUs just started to get serious. Back then, you could just throw together some polygons, slap a few pixels worth of texture onto them and you basically had about the same quality of what was already in the game. It was pretty much a one-man-job. If you started modding back then, it was quite easy to pick up the required skills, because there just wasn't that much you had to learn. Today you still have to learn the basics that you needed in 1998, but now you also need to learn what happened in those 11 years after that. That's 11 years of technology racing ahead! Nowadays game companies use a whole team of specialists to create the game assets and if you want to create something on a similar level, you have to be aware of the massive additional workload and knowledge that you require compared to 1998. With increasing complexity, it's only normal that things get harder to understand for someone who just starts to get into it. Those technical terms that freak out many new people are just required to manage such a complexity. If everyone would still use layman's terms for everything, one wouldn't get much done. It's the same thing in other fields that have been around for a while and built up a certain degree of complexity. That's what makes it all seem to be an exclusive club from the outside. Once you know the basics, you will find that you know how to ask for specific things and that people are much more willing to help out because first it's much less effort when people talk the same (technical) language and second because they see you made your homework and are not just on the desperate search for the "make pretty"-button. Look for tutorials on general topics that cover the basics, that give you a firm grip on the concepts and the lingo that is required. And there are quite a few of those around. Even if they seem outdated, those things are still the basics of what you need to know. There's really no shortcut there. You also don't need Photoshop or Max just because everyone seems to be using it. These days Gimp and Blender are more than up to what's required and there are also nice tutorials for both tools that cover the basics. This might not have been the case a few years ago, but today they certainly are. Everyone who's telling something different either doesn't know what he's talking about or is putting way too much importance on little things that don't really matter when you just want to do some game modding as a hobby. Right now there might not be a plugin for Gimp, but the files from the old TexView can still be used in ArmA2. And if you really need to read textures from ArmA2 for simple modifying, then you can always download a trial of Photoshop and use that with the plugin in a perfectly legal way until BIS releases a new TexView. As for models, Max has pretty much the same problem as Blender, since you still have to find a way to get your models into O2 or find a coder to write a plugin for direct export to an ARMA2 readable format. So if you really want to get into modding, do yourself a favor and start with simple things, make the effort to learn the basics and it will pay off. It's the only real entrance fee to that "exclusive" club :) PS Same applies if you want to get into scripting. Don't kid yourself, this is programming and you'll get the most out of it if you take it as such. Learn the basics of programming and you'll see that everything makes much more sense. Even for writing configs a basic understanding of programming is needed to see how the whole system really works. Once you have that understanding, it's just about looking into the BIS configs and see how things are done there. You don't have to go to uni and get a degree in CS, fortunately in these days there's tons of stuff on the net about those topics and even books that are easy to read :)

Oh just leave it alone for Pete's sake... The time that one would have to spend to convert the old stuff from Tonal to ArmA could easily be spent to come up with something better. So if you really want to spend such a huge amount of time, why not be creative and make something new instead? No one's keeping anyone from doing an african themed mod for ARMA.

May I ask how you come to the conclusion that only a multiple of 4 layers can be used for the layer mask?

See, that's what I mean. Without analyzing what's going on behind the screen, it's hard to say what's happening, even if you kept close to the numbers. That's because those numbers aren't absolute, but by simply applying them as rules, you treat them as such. Having guidelines for how to reduce the "section" count is fine for optimizing a model, but how does that give you guidelines to decided whether a certain model will fit well in a whole mod? If a model has a "section" count that's +50% of a regular model, but because of what it displays can't be modeled without an increased "section" count, do you include it in the mod or not? How do you know what kind of headroom you have in terms of that "section" count? Do you even know if something else also affects the maximum number of possible "sections" before framerates go down? How is the trade-off between let's say texture size, polygon count and section count? Is it better to have a bigger texture or more polygons instead of more sections? How do the numbers work out for such trade-offs? How many polygons, textures and "sections" are already used by your landscape? All those numbers are just general guidelines that help you to produce good models, but they don't really help you to judge whether a specific model fits well in your mod or not and they won't help you much with troubleshooting either.

I'm afraid, but I think there is no easy way to do this. For testing, the first thing you have to do is to get familiar to your variables. What I mean by that is that in a game engine there is so much going on, that isn't really apparent by just looking at the screen. So you'll have a hard time doing any meaningful testing at all when you don't know what's going on behind what you see on screen and how you can adjust it. Testing is worthless in an environment where you don't know the variables. There is no shortcut or easy way to this. What you see on screen is a result of a cycle that basically goes like this: The engine determines what needs to be shown and how, then the engine feeds the GPU with the data it needs to display exactly that. The GPU then tries to render what it gets from the engine. This happens with every frame and the engine takes note about how many frames per second are rendered and adjusts the data it sends to the GPU so that the fps stays in an area that is acceptable for the game. Now the first thing to understand in this is what kind of things affect how fast the GPU can render somehting. At this stage there are many variables that aren't really apparent from what you see at the screen in ArmA. You get a glimpse of those if you look at the performance analysis tools from nVidia and AMD (nVidia PerfHUD and AMD GPU PerfStudio). Just look at some screenshots of those and you'll see what I mean. If you have an idea what the numbers mean in those performance analysis tools, then you'll also get a pretty good idea about the reason why some models give you problems on the GPU end. Then you'll have to know how the data that gets sent to the GPU translates into the game assets that you know, like models, textures and all that. Only then you'll be able to tell what you need to adjust on a specific model to make it work well in your mod. Maybe your performance analysis tool shows that the GPU is sitting there idle, while you still get bad framerates. Then you'll know that the GPU end is fine and you'll have to look how the engine is dealing with your model. Maybe the amount of AI is keeping the CPU busy and it's therefor not able to send all the data to the GPU in time to ensure a good framerate. There is just too much different things going on that you'll have a really hard time to get a proper idea of where the problem is only by throwing random models at the engine and seeing how things look at the screen. The same thing goes for the rest of the mod. It's no use to test in a standard ArmA environment if the idea is to replace every ArmA model including the landscape with your own ones. Maybe the ArmA terrain taxes the engine and the GPU in a specific way and your own terrain does that different. You'll end up getting different performance when you'll test the same units on your terrain than on ArmA terrain. The GPU doesn't really care whether those polygons or shaders are from the terrain or some fancy unit. All it knows is that huge pile of data that somehow needs to be put through the pipeline to get rendered. If your terrain has a different terrain or texture grid, how the models and the textures of your terrain objects differ from the ArmA ones, how the density of the terrain objects differs from the ArmA ones, all that affects performance. You need a proper testing environment that closely resembles what your aiming for in your final mod in terms of how the engine and the GPU manages it. Otherwise your testing is flawed right from the beginning and doesn't return any meaningful results. You can't even judge how different your environment will be if you don't know the details of how things affect the engine and the GPU. You won't have any basis for the most simple judgment.

Phew, that's one big thing to ask and not really easy to answer For a whole mod and if you're serious about pushing the boundaries, I doubt that you'll get away with such a simple set of numbers. What you need is some idea of what the engine is capable of in the area that you're interested in. And I fear you only get that by testing it yourself since it doesn't sound like you're content with how things are in ArmA. Therefor also looking at the standard values of ArmA units and terrain won't help much. Rigging up sample models like spheres or boxes with different polygon counts, number of textures and texture-sizes is easy and quick to do. (Also don't forget the terrain and its objects.) With those you can put together simple missions or scenes like the ones you imagine for your mod and get an idea of how the performance will be. Every other way to come up with such numbers is pure guesswork in my opinion and you might end up with bad performance anyway if you put it all together in the end, despite the more rigorous checking. Maybe the engine gets much more taxed by the increased number of units than you would expect and you therefor might have to reduce the taxing in other areas also more than expected. Some things might not tax the engine that much more if used in higher numbers and therefor might not really need to be scaled like others. A game engine is a complex system of many factors and I wouldn't expect those factors to behave linear in any situation. So testing is the only way to find out how those factors behave for the situation you like to have. What you need to test the right things is some basic understanding how things work or might work in the engine and the hardware. What are the different things that the GPU gets fed with and how does it deal with those things? How are the current types of GPUs different in those aspects? How does the parts you know from the game assets translate into the things that the GPU gets fed with? This might all sound a bit complicated and maybe a bit too much for just making a mod, but I think that's the only way to get meaningful numbers with the precision that you seem to aim for. If you don't want to go down that road, I'd say just making sure that a model is generally done well and then doing your tests with the finished model is better than trying to come up with numbers for poly counts and LOD numbers by guesswork that might or might not fit what you want to do.

@Q: Many important things aren't really fun. I agree with you that config info is sparse and that many people would appreciate if they could learn a thing or two. But such a thread might be best opened in the config forum and kept technical right from the start. Unlike this one. @Sickboy: I don't think we're actually talking about different things, only that you try to put the thread into a more technical tone than it was started in and ignoring the whole rest of the starting post. The original post had quite a one sided perspective from the point of config mod makers and others just pointed that out. Obviously the permission thing does have some relevance to the original poster because it is mentioned a few times in the original post. So I can't see how you come up with the idea that it doesn't have anything to do with this thread. If you read the original post, you might find that the core of it was to explain to addon makers that by separating the config from the model and textures, that and how integrating the config with the model fails This is what the original post was about and it includes the permission stuff that others commented on and you don't want to talk about. People pointed out that from an addon maker perspective, the reasons mentioned in the original post might not even seem so fortunate and that's what the whole discussion was about. So maybe it's the other way round and the technical discussion needs a separate thread like Q suggested? Also the issues mentioned in the thread are actual issues as Placebo's post in the addon forum shows. Those aren't old grudges from OFP times. Ignoring them and trying to drag such posts onto technical ground doesn't solve them and maybe makes things even worse. Actually, as I tried to point out, I think those issues are part of the problem with incompatible addons. I doubt that addons are incompatible because their makers didn't know better. So I think that for someone who tries to make them compatible with a config mod, should take those issues very serious and not just trying to concentrate on technical details. Even if those discussion aren't fun to read, I really think they are necessary and provide a way to solve things as long as people are open minded and don't just ignore each other.

No need to get agitated here. With no word I was comparing the amount of work it takes to create mod vs an addon. What I was comparing is the work it takes to use an addon in your mod and its alternative: To create the addon for your mod yourself. If no one creates the addons (and spends the time) that you want to use for a config mod in the first place, the only way to create your mod is to create the addons yourself. So by using existing addons you trade in spending months of work for an addon for the few minutes it takes to change the config and pbo the addon. That's the difference I was talking about. Well, if you followed the OFP modding community, you probably know that there were efforts in that area, but most time they failed because people just had different views. If you like it or not, but if someone creates and releases an addon that doesn't work well together with other addons, most time it's because he wanted it to be just like that. There is no obligation to make your work compatible with the work of others. And there is also no right to do what you please with the work of others just because you spend an equal amount of time for your own work. By using the work of others, you still save the time of doing it yourself, no matter how long you spent on the rest of your project. Now about having tons of incompatible addons: Isn't the reason why most people create config mods, because they aren't content with the individual addons they get from other people? So what that actually means is that you come up to someone who has spent quite some time to get an addon exactly how he wants it to be and tell him: "Hey, I don't really like the whole addon of yours, but I really do like some parts of it. Can I please take the whole thing apart to use it the way I think it should, instead of making the effort and redoing the whole thing myself?" Can you see how people might get offended by this? If the original creator thinks your idea is great or if it was only inability that made the addon so incompatible, you probably won't have any problems getting the permission to take it apart. In that case, I bet that the creator wouldn't even have anything against redistributing an updated version of the original addon, which according to what you just wrote should be even better than just including it in a config mod. Also, no one really hinders you to create a full mod like FDF or others, with your own models, textures and configs that work beautifully together as a complete pack with a campaign or some missions. All you have to do is to suck it up and spend the time that is needed to get it done. If you don't want to spend the time, then you have to arrange yourself with others and be prepared to make compromises. Which includes respecting the wishes of the people who you work with. So even if you just want to talk about making addons compatible with each other or getting rid of multiple versions of an addon, it still boils down to working together with others and therefor getting permission or paying respect. If you don't want to hear about those things, then you're free to do your own thing without much discussion, like I explained further up. No need for all those things if you do all the work yourself. Even if the whole community puts up some rules about how addons have to be compatible to each other, there's no real obligation for anyone to follow those rules. If someone likes to do things different, it's their choice, since it's their time they are spending. Every discussion about how practical it would be if that was different and how all could work nicely together or how much easier it would be for some people is moot since it doesn't even touch the real reason why things are as they are: People like to do things their way, so deal with it or do it yourself.

I honestly don't see the problem here. If the only intention is to make it easier to reuse addons within the permission given by the original creator, then your suggested system doesn't seem to help much. Even if someone releases an addon split up into two pbos like you suggested, it's still one released addon. And if you ask this person if you could use his work and he tells you that you can but without changing the addon, then this permission doesn't include just taking and redistributing a part of the addon. Obviously if someone releases an addon with a config, he wants to have the addon just like that. Including the model, the textures, the config and even the readme or the documentation that comes with the pbos. So if you really want to honor this permission, you actually have to include the whole package and not just a single file because it fits better with what you want to do. Same with the addon showing up in the editor. What's the problem with the original addon showing up in the editor? If you're creating a config mod that includes other addons, it shouldn't be a problem organizing your units in meaningful categories that show up in the editor without much clutter, so that a mission designer can use just the units of the config mod. If you're using someone's work and really want to honor it, why not just leave it there in the editor to be seen and played with just like the original creator intended? By hiding it, you also take away some of the credit. On the other hand, if you really asked and got the permission to take apart the original addon, leave away the original config, readme and whatever comes with the addon that you don't need or want, then what's the effort for just opening the original pbo, altering the config and packing it up again? The original creator spent months and gave you permission to use his addon and you're really complaining because of those maybe 10 minutes of work you have to do yourself? You don't even have to change the name of the original pbo and repath the models since as you're changing the configs anyway, you're obviously not interested in the original ones, so there's also no point in making your config mod compatible with the original addon. If you keep your config mod in its own mod folder, there shouldn't be any harm done. So all in all: If you get permission to take apart an addon, then the work that needs to be done to integrate addons in your config mod is minimal compared to the effort it took to create the original addons. Not much to complain about in my opinion. If you don't get permission to take apart an addon, then the suggested system won't help since you're already violating the granted permission by only taking parts of an addon as you please.

sorry for not replying after my initial post, things have been a bit busy since then. @Phaeden: Thanks for the heads up on this, as I was just about to abandon the idea of huge maps. Knowing that it worked for someone helped a lot for motivation. @Edge: After your post I've had another go at the settings by reducing the texture grid to 1024 instead of 4096 to speed up the texture generation and it finally worked. Right now I don't recall the exact initial settings I've used with the 4096 texture grid, but I'll do some more testing on this when I have the time to figure out what exactly went wrong and report back again. You made me start up the hex-editor again to see what exactly those various settings mean and figure it out once and for all. Thanks for that @mpantel and others: Binarizing the map usually takes care of converting the textures and rvmats, so that wasn't the problem. (It was the first thing I checked)

About the loading time and instabilities: Did you binarize the map?

answered in your other thread: Layers.cfg