madrussian

I just went in and found that specific plant from my testing again. You need MAP_EU (Mapfact Editor Upgrade), which lets you get to (correct me if I'm wrong), many of the default ArmA2 objects not normally accessible. Under "MAP: EU-Plants", select "B b_salix2s". Of the bush types, that's the meanest looking vegetation I can find! Broad at the base and taller than a man. A complete sea of these things will block out player sight easily. But try for yourself on the ultra-flat airstrip of Utes. Cut and paste away the hearty "B b_salix2s" and make the mass of bush so very thick you can't possibly see through it! Then place one enemy AI on the other side, facing you. You'll be dead in seconds! :eek: Very interesting results KeyCat. :) Fascinating to know the solution may be more complex than just view-lods. Concerning view-LODs specifically though, do you suspect that grass/clutter is more the problem, or rather actual placed plant objects? Based on my limited testing, I'd say there's definitely something going on (or rather not going on) with individually placed plants. If we could solve that part, at least in a pinch we could sprinkle some plants about and at least mitigate the all-seeing AI x-ray biotics, until a comprehensive solution is achieved. Where is old Durg, these days? And Durg, if you are reading this, care to weigh in? :D

OK, after some more thought, now I am totally confident I can make my functions work with just the default ArmA2 location types. Thus we should be able to remove the config all-together in the DAC Script-Only version and avoid any crazy CBA dependencies, or any other dependencies for that matter. @Silola If this sounds good to you, it's all a very mild change on you end. Just changing the location type from "DAC_Zone" to "Name" and doing a setVariable on the newly created location to identify it as a DAC zone. I'll need to make small updates to a couple of my functions as well, but it should be totally do-able. Kind of silly on my end that I didn't think of this method sooner. :D In the end, I think complete standalone DAC Script-Only version free of any addon dependencies will benefit everyone, including those running MP servers, those that need to tweak something in the code for a certain mission, etc, etc, etc. Everyone should be happy. (Well I guess there are always some people who are never happy. :p ) Please do let me know what you think. :)

You're post inspired me to start a thread on the matter (AI x-ray vision and view LODs in ArmA2). A while back I did some messing around with the default ArmA2 vegitation, to my dismay. If anyones interested, it's here. btw- Good luck with the mod. Can't wait! :)

@Xeno I share your desire for both DAC PBO version and DAC script-only version, each with the most minimal of requirements. Btw though, who are these "some people simply don't get the idea why the situation is how it is" people? I hope you realize everyone involved is working toward the best solution possible, but I'm not completely sure I understand your whole meaning... and why the "thread baillout"? :eek: Hmmmm... After thinking on it a bit longer, I may have come up with a way to eliminate the "DAC Locations" config portion requirement all-together. No promises at this point, but if we can get rid of that "DAC Locations" part: If we can make this happen then Silola, we then have completely free-and-clear addon free version for script-only DAC? :)

Good call Silola. :) I just thought of this same thing a few minutes ago while catching up a few posts back. Just so we're all on the same page, the config stuff I needed looks like this: Needing these locations types for my functions, I worked in concert with Silola, who added code to create these locations every time a DAC zone is created (and updated every time an existing DAC zone is updated). Then my functions detect these locations and go from there. So why not use one of the location types provided in default ArmA2? (i.e. "Name", "NameCity", "RockArea", etc?) Good question. Here's why: To cut to the chase, my functions require that the only locations of these types present were created by the DAC. If I were to use the existing provided locations, there would be absolutely no way to be sure that someone else (i.e. someone else's addon) didn't create them. This cannot be understated. Thus the reason for these "DAC specific" locations. So what can we do at this point to achieve a DAC script-only version? Well, one solution would be to just create a small PBO with only the locations? I'm guessing some are thinking that will defeat the point entirely? :p Here's a real possible solution: Maybe take this very small "DAC Locations" part of the config and have it exist both in: 1. The PBO version of the DAC and 2. CBA (newly added there) That way the DAC PBO version can remain standalone, and DAC Script version takes on CBA as a requirement. If all parties are agreeable, of course. :) Finally the same identical "DAC Locations" data in both places (DAC PBO and CBA) shouldn't hurt anything. btw- Thanks for creating CBA. Despite what I said earlier in jest about "maybe we should be incorporating CBA into the DAC hahaha", I do use CBA all the time. Very handy stuff indeed. :D EDIT: I just thought of one concern regarding adding the "DAC Locations" config portion to CBA. We'd need a big fat disclaimer (in CBA docs) that states something like: "These location types are used internally by the DAC. To avoid potential conflicts, do not create any instances of DAC locations unless: 1. You are the mission designer 2. You know what you are doing Detecting them once DAC creates them is obviously fine." btw- The ten DAC_Utility location types are actually meant to be used by the mission designer.

If your aim is to quickly generate unit arrays for DAC's unit config, the original Zonewriter is still going strong and should work for this purpose. Not sure about it's other features though. IMO, that's probably the best call. Both PBO version and full script version, for those times you need to dive in and change something. Of course, it's really Silola's call. :) On a different note, what's with all this talk of adding the DAC to CBA? Maybe it should be adding CBA to the DAC?!? ...half kidding :p

Very cool mission so far. I agree that the roads (and the compounds for that matter) could use some dynamics. This mission is sreaming for some DAC overlays!

Hmmm, I think it makes pretty good sense as it is... a PBO! In terms of MP: 1. When using DAC as a script pack, all the client machines have to pull down all that data every time you start a game. Lots of data too. 2. However, as a PBO, it's already on everyone's machine, so no need for a big transfer every time. Why undergo the unnecessary delay? Seems like a "no brainer" to me to just go with PBO. DAC is hugely important. Nobody should have a problem downloading it... Maybe I am missing something?!? :eek: EDIT: Yo DMarkwick, just saw your post. ;) When going "external", you still need the big PBO loaded. The "external" portion is just the config files. So there's another point favoring keeping the PBO... it's really quick to just transfer those small size config files (and not have to transfer the big-daddy PBO). EDIT2: Very good point there. It's kind of a bitch to have to have to crack open the DAC PBO to see and mod the code (even for simple personal mods, etc), and keep re-packing it after every tweak. Yeah, the more I think on it, maybe both PBO and seperate "full script-pack" option would be useful, as each has clear distinct advantages. :)

Maybe the release of DAC 3.0 and OA will be two nice shots of adrenaline to your dev effort. :)

Tremendous congratulation Silola on unleashing the DAC monster yet again! Many thanks for all your hard work and dedication, my friend. You never cease to amaze. :) Now with the dawn of 3.0... let the good times roll! All of us may now buckle down, and brace for the impending explosion of new DAC missions!

Try not to be an idiot. Silola (and others to a much lesser degree inc me) have put a tremendous effort into this massive project. You must have absolutely no idea what-so-ever regarding the long hours involved. When release does come, take a minute and look at all the vast network of intricate code. Could you produce this? How long would it take you?!? :eek: Also, don't forget, Silola is not getting paid for any of this. Just providing perhaps the single most important ArmA2 mod system to you, free of charge, and on a silver platter. Think a bit next time before you post something like that. ;) Edit: One more thing to chew on. When Silola releases something, you can rest assured that it's 99.9999% perfect. That's the code, documentation, everything. Of course, all of us would like the latest DAC released sooner. But it's always worth the wait because when you finally get it, you know it will work as advertised and the documents will be detailed, clear, and professional. On top of all that, Silola has always provided excellent "customer service" on the release thread to make sure nothing goes unexplained. So let's cut the guy as much slack as he needs and just hang in there. The reward will more than make up for the wait. btw- Sorry for calling you an idiot. Got a little POed there. :p

Who want's to make a bet? When Red Dead finally ships on PC, we will NOT get a proper sandbox editor... How cool would that be though if they prove me wrong? :D

Correct if I'm wrong, but even though it's stand-alone, you'll pretty much at least need original ArmA2 though, because all the mods will need the content and assets from original ArmA2.

From my experience programming in ODE something like a whopping 8 years ago, that physics engine is actually far from optimized. Using a modern physics engine would actually boost ArmA2 performance! Making rag-dolling etc optional would give a mighty performance boost for folks who only want physics applied to the things it's currently applied to (and who would disable rag-dolls). In addition to performance boost, the physics on already applied things like vehicles would run better and provide a more realistic experience. (i.e. No more flying tanks or things embedded briefly into the ground.) Using a modern physics engine does not have to kill game performance or break the bank in terms of implementation. Physics engines run in parallel to the game so removing the old-outdated-busted ODE and replacing with any modern physics engine, while it will incur some cost, should more than make up for the expense in terms of new players and modders (i.e. paying customers) into the fold seeking a modern optimized engine to play with. To summarize we the players / modders win in three ways: 1. For those who don't care about rag-dolls, they can turn them off and still see better general physics -and- a boost in performance. 2. For those that love physics, we can play / mod to our hearts content with the new system. 3. Perhaps most importantly, all of us will experience an influx of new players / modders moving onto the ArmA2 (3?) scene. More modders = a greater amount of content and more innovative groundbreaking content. Give the modders a full set of physics commands and they create primitives and connect them together with joint of all types, and then apply torque to the resulting objects and joints. We will see discoveries and innovations we cannot yet imagine, all usable in this wonderful open-world editor. What does BIS win? Well more income from all the new players of course! :) Then we the community win again because with all this new capital BIS can move forward and create wonderful new open-world sandbox products with surprising new and innovative features, and the cycle continues. There is indeed a business case for BIS to move forward with a desperately needed cost-effective physics engine replacement. ;)

Any news here? I'm sure many are really looking forward to this one... the possibilities are simply mind-blowing. Waiting for release of Arrowhead, perhaps?

Regarding your explanation on "fixed 24-man platoon", sounds very cool indeed!

IMO, moving beyond ODE to a real physics engine would be well worth it to BIS. Think of all the mod creators that would make the move! Aside from the dire physics, the OFP/ArmA engine allows for ultimate possibility. Why not add physics too?!? Seems like a good business decision to me.

Sounds pretty kick-ass King Nothing. :) By "fixed 24-man platoon" do your men stay dead or are they replenished between missions? If they are replenished between missions, is it always back to full 24-man strength, or rather more a "limited" replacement?

Good to hear! Impressive work so far.

Cool release. Not long ago, you were going to implement DirectInput mouse coords/buttons... that still going to make it in? :)

Is there more than one SMAW in the crate? I can't remember. Now as far as AA goes, I am almost certain there is exactly one AA launcher in that crate! :p You could always bust out the editor and just swap out some of the starting friendly soldiers. That should be pretty quick. Yes, you can definitely run into enemy outside the marked “mission areaâ€. In fact, you can start having enemy encounters not far at all from the insertion location. :D Kind of cool: When I was poking around in the editor, I seem to recall he has three different trigger areas that appeared to correspond with increasing degrees of enemy as you got closer to the objective. Like a circle inside a circle inside a circle. All I know from playing the mission is that the effect is brilliant! Should be easy to do in the editor. In case you are unfamiliar, download something that can unpack PBOs like Eliteness and then open the mission in the editor. Change the main playable unit to a sniper, anti-tank or whatever you like. Then walla! Click preview mission and have at it! ;) (Since this mission is highly dynamic, it may be slightly more complicated than that, as in he may be updating control from one unit to another or changing the loadout upon startup, but try to simply change the unit type first.) Have fun!

Well, first off I think they are outstanding as-is. But you can kind of keep track of them a bit too well imo. If they could submerge part-time, then even when you're in the water looking all around and don't see any sharks, hell they might be right below you for all you know! In any event, it's a great addon CSJ. And thanks for all that work you must have put into it! :)

One thing worthy of mention is Cipher's brilliant Difficulty scaling. Try lowering if you keep getting your clock cleaned. This is hands down the best mission I've seen yet for ArmA2... Good luck!

I'm just thinking about a lot of cover from a gameplay perspective' date=' but hopefully not at the peril of a realistic desert environment. ;) Sounds like we'll get the best of both worlds. Good to hear!

Did you happen to see a truck and crate near where you started? :) Not sure why you might have had only four guys though... did you choose the spec-ops option perhaps?