Synide

You mention you reduced your 0.0 LoD to about 8.5k... Approx. how many sharp edges? Also, are there many Alpha portions on the model? 20 Sections is getting abit high imo, if you have double sided glass with 20 sections that can easily turn into Hundreds of sections in the ODOL. Section counts & glass are the killers. I know it can be a shame to squeeze it so hard but try getting the section count down to around 10 maybe 15 at the most.

These are the Thermal Imaging values. Typical values for a weapon maybe something like... htMin = 300; htMax = 1800; afMax = 0; mfMax = 0; mFact = 1; tBody = 100; or htMin = 60; htMax = 1800; afMax = 200; mfMax = 100; mFact = 0; tBody = 0; Bare in mind the above values are just 'common' values used by 'some' weapons. You may vary them as you like. See Thermal Imaging for more info. The parameter for 'selectionFireAnim' in the config.cpp must match the 'selection' name for the polygons in the model or the 'selection' name of the 'proxy' in the model. Not sure about the rest of your queries.

You can replace the 'original' with your model. But, usually you shouldn't do this because it may affect other addons that maybe reliant on that specific model etc. etc. You should do it the way Gnat mentions and create your own unique class variant name that inherits most of the properties/attributes of the 'original' BIS variant and then just overrides the portions you need to override. If you've taken this into account and still want to completely override the previous class implementation then doing something like the following would override the model.... class CfgPatches { class SyWeapons { units[]={}; weapons[]={}; requiredVersion=1.02; requiredAddons[]={"CAWeapons_E"}; }; }; class CfgWeapons { class M249; class M249_EP1 : M249 { scope=2; model="\sy\weapons\sy_m249"; picture="\ca\weapons_e\data\icons\m249_iron_ca.paa"; displayName="Sy M249"; irDistance=100; magazines[]={"100Rnd_556x45_M249","200Rnd_556x45_M249","30Rnd_556x45_Stanag","20Rnd_556x45_Stanag","30Rnd_556x45_StanagSD","100Rnd_556x45_BetaCMag","30Rnd_556x45_G36","30Rnd_556x45_G36SD"}; }; };

Predominently, what are the models when you look south from the position you experienced the fps drops. Perhaps use Kju's DevCon and make a hand written list of models that you're 'seeing' from that position. Alternativley, pop open in V3. Place the cursor approximately where you were standing when you got poor fps and take a screenshot. Then drag-select all the buildings south of your cursor and export these to a text file using the 'ExportObjects' script. Post this text file somewhere (not here as it's probably too big) so we can get an idea of what you are 'seeing' when you face south. Also, bare in mind that while Mondkalb's models are pretty good they are a bit what I'd term resource hungry or 'heavy'. Individually, in itself this wouldn't be an issue but if you have 1000's then it may be an issue for your map. This could equally be true of the other building model packs you're using. Remember, a map is the sum of it's parts...

Ctrl-E (Export Active Layer) while you're on the 'heightfield' layer, select XYZ from the dropdownlist combobox. Probably a good idea to change options to Y-up as well. While L3DT can import & export xyz/xzy... V3PE can only import as a standard option (V3 can both import & export outta the box). But you can export the necessary terrain grid height values to a textual xzy file with V3Script. Alternatively I could hack up a quick tool to just dump the elevations data from a .pew to an xzy file... or ask Mikero or T_D todo it... :P. If you guys wanted that sorta thing you could have just asked... myself or one of the other knowledgeable chaps in this area hanging about could'a done that literally years ago for ewes.

arrg, perpetuating the spelling mistake... the valid LoDProp 'damage' was added a long time ago... it should be used. damage=tree class=tree should be class=treesoft or class=treehard As Bush said, one of the 'foliage' like .rvmat's from 'ca\data\penetration' should be mapped to the 'foliage' topo faces in your FireGeo LoD. And, 'ca\data\penetration\wood.rvmat' (this is probably the more important one to specify) should be mapped to the trunk, stump & root faces. See, O2PE Manual for more information.

Should do... the .p3d file format hasn't changed since then and the c++ sdk architecture for modo is com-like with interface, implementation, vtables etc. so quite robust. It should 'just work' and if it doesn't it wouldn't take long to fix. Ok, the little shortcut buttons on the 'modo Modes' toolbar at the top of the default ui layout for 601 would probably disapear 'cause they changed the internal name of it but I'd imagine that'd be the only thing that would prevent this 401 era .lx plugin from working completely.

Polygon Type of 'Face' only. eg. No Subdivs, Curves, Catmull-Clark poly's etc. Triangles and/or quads. Visibile 'Mesh' item's. See the Statistics tab on the right of the standard layout. You mean Oxygen right? Anyhoo, are there any error messages in the modo log? (System>Advanced>Event Log) when you try to export. If there are no errors and the .p3d is still not opening in O2PE then perhaps you wouldn't mind sending me the .lxo (not the .obj) synide at rocketmail dot com.

Generally for those types of model (static, non-animated, non-in-game-editor-placeable) they are mostly added to the terrain during a map's development and usually don't require a specific CfgVehicles or CfgNonAIVehicles config definition. Sometimes people with walls or fences do make config's for them so as to attach effects to them when things happen. Mostly, for sidewalks/walls... you wouldn't define a config for them.

That would be nice... preferably with pictures, :j:. But, at least some high level overview of the mechanics, other things that would of interest are the aspects of what the replacement VM had to cover in order for it to be accepted as a candidate. What other VM's were potentials and why they were not adequate. I'll not bore you with my preferences regarding this topic but it would be nice to get some feedback regarding the broad brush strokes of the implementation/system architecture. And, will this influence the other product down the road?

Initially I was a bit sceptical by your decision to go down the JVM path but after mulling it over for a little while and doing a bit of research I'm pretty much ambivalent about which VM you use. I'm just happy that you've finally decided to move away from a proprietry implementation and thus (hopefully) reduce your cost of ownership of the subsytem so as to redirect resource and architectural thoughts and efforts into other subsystems. Good-on-ya though for biting the bullet had to be done sometime. I am still curious though as to why you chose a JVM route over CLR/CLI? Cheers, Sy.

It's the model snapping feature that models can have and as you've discovered it's particularly useful with visitor/buldozer. Yes, you can use this technique with your own mlod's and Yes, you can use it with A2/OA. I don't believe there's any good reason for you not to use the technique with A2/OA content you may create. Imo, it should be a QA point on at least any model that is usually part of a greater whole. eg. portions of pipe, roads, bridges, fences etc. Also, it is possoble to implement more than just these visitor related snapping points and create other points-of-interest conforming to your own convention that your own in-game scripts can utilize for faciliting placement and/or various manipulations that you may desire. But, of course that's alot more work on your part. Cheers, Sy.

selectionFireAnim is the config property that defines the 'selection' that is animated during firing. Btw, your 'muzzleflash' could infact be called anything you like... so long as all the bits-and-pieces are defined properly the engine doesn't care what it's called.

Ask someone you have on skype and is already in this channel to add you to the 'ArmA2 Tool Makers Channel'. There are people in there that have already made use of 'callExtension' extensively and others that know the .pew file, c++ etc., etc. Although I'm sure you could probably glean what you need from this DH page... Official support for 3rd party plugins (dll's).

Not at all. Tbh... after thinking about it I probably won't move back to using the P:\<YourPrefix>_<YourAddonName> setup as opposed to the P:\<YourPrefix>\<YourAddonName> method primarily because I like the physical folder demarcation between the different lumps of content and it replicates BIS's own setup.... P:\ca. Yesterday I installed the A1 tools package then uninstalled afterwards. It did go looking for config's all over the place... These A2 tools packages no longer do this anywhere near the same extent.

In your 'ShadowVolume - View Cargo' LoD does it have double-sided poly's, triangulated, with all sharp-edges? In your 'View-Cargo' LoD what are the details of the .rvmat(s) (if any) you have mapped to the inside?

That's cool... I agree with ya... if the problem isn't presenting itself anymore then I guess I'll just start using your method. At the end of the day as long as it works in game and isn't inefficient does it really matter how it gets there?

In your example images your building 'P:\usec_b1b'. binarize.exe will go looking for a config.cpp in this folder. It will then go looking in all subfolders of P:\usec_b1b for config.cpp's. It will then step UP to P:\ and go looking for a config.cpp. It will then go looking in every subfolder of P:\ for config.cpp's. There's nothing wrong with your setup Gnat. In fact I used to build exactly the same way as you and sometimes on the rare occassion I still do. Your 'method' has nothing todo with luck mate. It's the intended default method of building that BIS provided for you by way of the implementation that BinPBO exposes. The point is, YOU are managing your own build drive WELL. It's when you start working across multiple sets of 'similar' but subtly different entire config systems with multiple people that things CAN (but not always) go awry. The objective of using a P:\GNT\ namespace is to lessen these issues. Finally... just for a second... have a think about 'P:\ca'. What is it Gnat? It's a MOD it's BIS's default MOD. Nothing more nothing less. It's all their created content nicely apportioned off from the rest of the branches of content on there internal P:\ drives. Which for lack of a better term well call a 'namespace'. The 'ca' namespace. If you extract a BIS .pbo what do you get? a pboprefix of 'ca\weapons', 'ca\weapons2', 'ca\tracked', 'ca\chernarus'... etc., etc. You don't get 'ca_weapons', 'ca_weapons2', 'ca_chernarus' do you? Let's also consider that there are alot of config's in the 'ca' namespace. How many would there be in the VBS2 namespace or any other they may have on there development drives? I surmise alot. Perhaps they might even look something like... P:\ca\... P:\vbs2\... P:\toh\... P:\cc\... The objective of the method of building whereby you drop a 'ShellLink junction' of P:\ca into your own P:\GNT is to lessen the possibility of issues and to emulate the setup that BIS themselves use.

Until 1 of your builders drops another folder + config's into P:\ that's completely unrelated to your mod then binarize will parse that too. That was me mate... I convinced a number of people back in '07 to use this build method primarily because a group of us were building for several different mods and groups of people all at the same time off of our P:\ drives. It became a nightmare. So, I analyzed the hell of it all and came up with a solution that was actually very manageable, at least from our perspective. The upshot was that you were safe in the knowledge that when your root was 'P:\MOD1\...\' you knew that binarize was only going to go looking for config.cpp's inside the 'P:\MOD1\...\' namespace. The next day when you were working on 'P:\MOD2\...\' again you were safe from 'config' contamination from 'P:\MOD1'. And, so on. It wasn't much todo with ladders at all. But, more todo with class inheritance and keeping a sane demarcation between entire ecosystems of config's, similar but subtly different models, scripts & other resource data. Myself and a number of others were using this method to build and getting great results but most importantly, high reliability and consistency. In mid 2008 there were soooo many people struggling with build stuff I basically got sick and tied of seeing every 2nd thread in these forums relating to build issues. So I whiped out a document to try and get across a reliable method. Your weird and wonderful from my point of view is practical and prudent. While you've never had a need... I and many others have had a need. I could set it up my way in less than a minute on anyone's machine and with LinkShell it's even easier, ya don't even need to copy anything anywhere. Bare in mind too that your 'easier' does not necessarily equate to 'better'. Both our methods have valid uses. Unfortunately, I guess I'll never be able to convert you to the 'dark-side' of the force - :)

I'd imagine he'd probably facilitate the persisting of his 'drawn' roadways out to a file (or db) now that legit .dll's can be utilized with the game.exe so that 1. this could be fed to v3 and 2. you could continue editing your drawn roadways from where you left off. I'd agree with that too... It's my understanding that during binarization that if the models that are 'planted' on the terrain have a 'roadway' LoD this is effectively pushed into an 'image' of the terrain that amoung other things indicates to the engine that 'hey there's a road-like area over there' which inturn feeds to the AI subsystem.

Multiply your way (i think someone at BIS probably thought it up before you ;)) by several seperate mod's + upteen one-off compilations and tell me your way is easy to keep in some semblance of ordered sanity. It's fine & valid to build everything from the root of your P:\ drive using the 'P:\<YourTag>_<YourPBOName>\...' method but once you start building across multiple config.cpp/model.cfg branches it can quickly turn to mustard. It's difficult enough trying to bug-fix someone's build attempt remotely only to find that binarize has parsed someone's obseqeous config.cpp from some deep folder because they're using P:\ as the root instead of P:\<YourTag>\ as the root. Don't get me wrong though... For the new people & people who are never intending to work on anything other than there own stuff the BIS preferred build method is fine. Sorry to jump on the bandwagon Gnat but both build methods have there pros & cons and are appropriate for differing use-case senarios in my opinion.

under ca\roads_e