dinger

The Chain of Command is proud to announce the release of UA 1.1 Official CoC Downloads Page http://www.downloads.thechainofcommand.net/ The CoC Give grateful thanks to the following mirrors GranQ (SFP) has posted a Torrent: http://thepiratebay.org/details.php?id=3509573 From Rhodite at Got Flashpoint http://www.gotf.net/news.asp?id=408 OFP.INFO http://ofp.info courtesy of Raptor, http://OFPC.DE: ~43 meg Zip file Mirror from <a href="http://ofp.4players.de/" target="_blank">Ofp.4players </a> UA setup exe file The Chain of Command announces the release of v.1.1 of Unified Artillery, a collaboration between the Chain of Command, DKMM, BAS, SFP, SEB, WGL, PUKF, and many other members of the OFP community. UA 1.1 adds new features and weapons to the highly successful Unified Artillery 1.0 engine. Artillery Pieces contained in UA 1.1: WEST: SEB M252 81mm Mortar BAS M101 105mm Towed Howitzer DKMM M109A6 155m SP Howitzer PUKF M270 MLRS SFP CV90 AMOS EAST: DKMM M46 130mm Towed Howitzer CoC M55 152mm Towed Howitzer HWK 2S19 152mm SP Howitzer HWK 2S19M 155mm SP Howitzer Additional units: Forward Observers (East and West) COBRA units (east and west) SFP ARTHUR Cobra SFP CV90 Forward Observer Vehicle bridge to make WGL 81- and 82-mm mortars work with UA. Transaction-based dialog system Dialog: http://www.dslyecxi.com/screens...._49.jpg New Effects: Fuzing/Explosive effects by WGL Fuzes: QUICK, TIME, VT, DELAY, SMOKE and SENSOR (Guided, Terminal Homing, Sensor-fuzed) Shells: HE, WP, SMOKE, ICM, DPICM, RAAMS, STRIX, SADARM, ILLUM WP Demonstrated: http://www.dslyecxi.com/screens...._30.jpg Fire Modes: Time On Target, MRSI, and many more ToT mode demonstrated: http://www.dslyecxi.com/screens...._12.jpg Single Player Missions: New intro missions, copperhead tutorial. Breathtaking demo cutscenes 4 Multiplayer Missions (require WGL, some require islands in WGL pack). For a thorough analysis, with screenshots and videos, visit the preview at: http://dslyecxi.com/shackposts/ofp_cocua11.html http://www.thechainofcommand.net Files In Operation Flashpoint\@CoC\Addons\" CoCDKMM_M46.pbo" CoCHWK_2S19.pbo" CoC_Arty.pbo CoC_Cobra.pbo coc_fed.pbo CoC_M55.pbo CoC_NS.PBO DKMM_M46.pbo SFP_ARTHUR.pbo SFP_ssg120.pbo "SPMissions" in Operation Flashpoint\Missions\The_Chain_of_Command\" cocshield.jpg" coc_ua11intro.noe.pbo coc_uaintro.Noe.pbo coc_uatut1.abel.pbo coc_uatut2.Abel.pbo coc_uatut3.Abel.pbo coc_uatut4.Abel.pbo coc_uatut5.Noe.pbo coc_uatut6.Noe.pbo coc_uatut_clgp.Abel.pbo Overview.html UA1_1demo.Noe.pbo (Requires CoC Tomahawk Pack) "MPMissions" in Operation Flashpoint\MPMissions\The_Chain_of_Command\" co21_checkpoint.occasus.pbo" (requires WGL + WGL Island Pack) co27_hamilton_perimeter.occasus.pbo" (requires WGL + WGL Island Pack) PointyEnd.avignon.pbo" (requires WGL + WGL Island Pack) PointyEnd.Eden.pbo"(requires WGL 5.0) "WGL5_Mortar" in Operation Flashpoint\@wgl5\Addons\ WGL_UAMortars.pbo (requires WGL 5.0) "Editor_Missions" in Operation Flashpoint\users\coc\UA11Template.Intro UA11Template.Intro\description.ext UA11Template.Intro\mission.sqm

As far as I know, thanks to the efforts of those in the thread, compatibility with 1.99 has been established. The only question is if there's a version out there with the bug fixes I mentioned above. I probably have local versions of the files with the fixes in them, and, for something like a busted 81mm I/A mission, that would be rather useful.

I don't even remember. FWIW, I have the old files here. If you have the broken version, what's the file length on UATut4.pbo and UATut6.pbo? Is it by any chance 45,559 and 49,018 bytes?

The writing on the side of the Obelisk has always been there. If I recall, it reads: Catena Imperii Recordemur eos qui pro nobis ceciderunt. (just an Easter Egg for anyone who cares). The intersession crash is due to a longstanding bug that I understand was isolated in 2006 or 2007: when the number of global variables exceeds something like 4096, the engine implodes on loading the next mission. ArmA introduced the ability to assign variables to objects, or rather to define properties of objects; in OFP, we had to use self-modifying code and global variables to achieve the same. UA produces a lot of variables.

And by the sound of it, be sure to wear SPF 3,000,000 while testing.

you can go for a hotfix (1.11), at least for testing purposes. Bn880's right, there's probably a self-modifying one in there. The ?IsServer one is the one you're supposed to find; the addeventhandler is the one to convince you you've found the nasty one. The next one, if it exists, will be an intermittent failure. So if something breaks, let me know and we can look. I might have documented these somewhere.

Hehehe I forgot about those beauties. Yeah, there's probably one or two more stashed somewhere really nasty. I'm on the road for the next couple of weeks, but between the lot of us, we might be able to work something out. -Dinger

For Immediate Release. The Chain Of Command, in conjunction with SEB, Ballistic Addon Studios, Decisive Killing Machines and Project: UK Forces announces the release of Battle Kings: The Chain Of Command Unified Artillery 1.0. The Chain Of Command Unified Artillery (UA) combines models from many of the top Operation Flashpoint addon studios with a single command and control system to deliver to the OFP world the first true, fully functioning artillery system. CoC UA main page CoC Main Download Site offline (we've blown our bandwidth!) Mirrors (more to come. If you would like to mirror, contact us): Blackdog's Mirror (help test his bandwidth!) http://www.ofpec.com/addons/addon_detail.php?ID=440 http://flashpoint.nekromantix.com/downloads/CoC_Arty_100.zip http://www.ofp.info In conjunction with the release of UA, PMC has released a new version of their 30-mission CoC Command Engine campaign, fully integrating the Unified Artillery addon: http://flashpoint.nekromantix.com/downloa.....r5.rar  UA Features: [*] Persisting shells and rockets that fly ballistically to their target, up to 32 kilometers away (and, should the need arise, even farther). [*] Painstakingly detailed fire and recoil effects. [*] Neural network based targeting system for low overhead and high accuracy. [*] A single, unified command and control system. [*] Streamlined Mission Editor deployment: just place the objects on the map and go. No scripting required. [*] Built in Functions for one-line scripted operation of artillery. [*] Laser Designator/Rangefinder support. [*] 10 missions included. [*] Can support user-made dialogs. [*] Dynamic structure enables additional modules (CoC and third-party) to "plug in" to the UA core features and interface: no need to update the .pbo to add new units! [*] Required Monolith object graces the landscape of OFP. [*] Multiplayer compatibility for all features. Vehicles in CoC_Arty: SEB M252 Mortar BAS M101 Towed Howitzer DKM M109 Paladin (SP Howitzer) UKF M270 MLRS Other objects/units: CoC_Radio CoC_Obelisk CoC_ForwardObserverW CoC_ForwardObserverE

yeah -- you need to put the following line in your description.ext: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> #include <CoC_FED\FED.hpp> or just copy the description.ext file from the template mission.

It is not completely in Czech. The title is clearly English.

Well, if William hadn't said referred to Armstrong as a "he", it very well could have been his daughter.

No need to allude to violence, I wasn't being condescending before, but I'm rethinking that choice. When a discussion boils down to a difference of fact, no amount of shouting is going to change it. The only way to change it is to go out there, test and prove. "Trial and error" is only when you attempt things without grasping the science of them. That's why we have the scientific method. Yes, I appreciate that MP testing really sucks, and costs a lot of time and resources. For this reason, there are a lot of areas of MP usage that are still vague. But if you don't want to test stuff in MP conditions, then you have to rely on those who have. And if it so happens that they're full of crap, I'm sorry. I wouldn't expect BIS to write a definitive guide to MP: if they did, very few people would read it, and of those who did, most wouldn't understand it. Besides, and here's the rub: most of the things we're doing involves stuff the good folks at BIS have less experience with than we do; ArmA has 700-odd commands -- you can't expect anyone to know in detail how well they work in every conceivable situation. And Heaven forfend asking one of the programmers to describe how the whole system works in multiplayer. Crashdome is probably right: you shouldn't need a Ph.D. to figure out how things work in MP. That's why Bn880 felt OFP needed CoC_NS. But I don't seriously expect BIS to make our lives easier in ArmA, especially with such novelties as JIP. They've got their priorities, and we've got ours. init.sqs: usually, yes. if there's no pause, and if there is enough time before the game starts (since lines in .sqs files are attributed a slice of game time, a really, really, really long init.sqs may not make it all the way through). Waypoints "On Activation" and locality: I have locality problems with most things involving AI.

actually, any scripts called from init.sqs without a ~ pause will execute immediately, and therefore pre-sync. So at the very least, put ~.00001 if you wonder about this, put in some debugs to your current mission: a player sidechat "HELLO WORLD" right before you PV stuff, and see when things go. You and I can pontificate about who's right all we want, but _evidence_ really shuts people up. As for the further problems -- I can't honestly say I know the answer. "It's worked for me" is what I usually say. But when transmitting stuff, I try to load up a few datagrams at a time: if you PV stuff at the same time, it tries to go out at the same time. Since in the absence of a >200 ping, OFP seems to sync at 5 Hz, I find (after a ~(random 1)) one-second spacing to be nice and conservative. Such systems send hundreds of PVs without problems (we've tried to break it). Triggers and the rest are probably in the same boat. Triggers with their condition set to "TRUE" fire once every half-second or so: plenty of time for things to drift in and out of sync: someone could walk/drive/through a small trigger on one client, and not through another. Even with a condition other than "TRUE", and the trigger firing every frame, you could still get things mixed up, as the position updates only come through 5 times a second: so while locally someone may appear to walk through a space (and fire the trigger), on other machines, he'll appear on one side, then on the other. These are getting to the level of limitations of the network. It's true that the reality portrayed on any client is different from the reality anywhere is in the world. This is only a problem for ontological realists.

I eat with my hands; I see no need for a fork yeah, okay, some good ideas there; Fer had some interesting ones too. So, I'm going throw in my two sense based on a couple observations on the current state of things. Feel free to ignore me. Currently, standards are done to greater or lesser degrees in the mature "OFP Mod system", where the "Full conversion mods" apply -- to varying degrees -- a set of standards on the addons they select. But addons have to be "selected" for this; sometimes the addon maker is even asked permission before such an honor is awarded. These "standardized mods" are or are not successful not because addon makers "buy into" them, but because people play them. People play them because they're simple: one download and everything's taken care of. So standards or "guidelines" should not be geared to whether the addon makers use them, but whether people play them; and that means standards that are useful are ones that the player knows will work, and work simply. If you're going to have a system that adheres to standards, simply having a .pbo signed by the "standards authority" isn't enough -- you have to put that fact on the main description, on ofp.info, or wherever, and even use those standards to organize addons. But there's something else about full conversion mods: Even with that simplicity, the overwhelming majority of OFP players have never used a single addon. (the FP1985 posters are the very nut of the hardcore). Why? Every step you put in between "pressing start" and the thing working reduces your audience enormously. This brings me to the current "standards addons". Every time standards are brought out, that same old battle horse of JAM comes out, and people bicker over why it wasn't successful. Here's why I really didn't like JAM: It broke things. An addon maker using JAM has two choices: A) Bundle JAM with the Addon (as many do) or B) Rely on an external dependency. B) adds a big step between "pressing start" and the thing working. A big step means that many, many people simply aren't going to download the addon: it's too complicated. And the addon maker has to field a whole bunch of PEBKACs complaining that "the addon is broke". A) works for the addon. But JAM is a shared resource, and has been updated several times. Not all the addons that bundle it are updated. What happens when I want to play a game with some friends who are using an older addon, and I go to install it? things get overwritten. Or, if I use a later version, backwards-compatibility might be broken (or simply not thought of). I know; we have similar problems with CoC_NS (or rather, it's probably just me who never seems to have the latest version). But the lesson here is that external dependencies are bad for standards. If the addon wants to use JAM and CoC_NS, great. If they want to use their own network transport, so much more power to them. Finally, there's the question of ensuring standards compliance without overwhelming those tasked with assessing addons. I'm not convinced that having "other mod teams" do it will work -- that'll encourage elitism and bad blood. (generally when someone asks someone to do something "for the good of the community", they usually mean, "for my greater glory") But the idea of "assessing addons" might work, if you put all the work in the addon maker's hands: make them document the polys and LODs, how many textures, and what resolution they're at. Have them specify the format and bitrate of sound files, and the max number of simultaneous voices their addons uses. Have the config guy indicate what AI detect and engage ranges are used, what the ROFs are, and anything else likely to eat up CPU or bandwidth. Also get that poor config character to write up correspondence tables between RL ammunition types and in-game effects, armor thicknesses and values. Have the scripter explain what events use MP-enabled functions, and hence traffic, and what traffic there is. You'll still get problems (especially in configs and scripting), but the very effort of documenting an addon to a standard will take care of many of them; and if the system is flexible enough, you'll find plenty of room for "exceptions within the spirit of the rule". Then you can have your "standards authority", whether a peer or a standing group, look over the documentation, make sure it's clear and fair. When approved, the documentation goes in a file with the addon, and the standards label on the cover. You put that out there, and it won't be in anyone's interest to "Cheat" on standards. But will it be in anyone's interest to adhere to standards? It depends on what the end user wants. The best standard doesn't always win. At least you can force people to make missions for their addons. (Speaking of which, when we released UA 1.1, we did with a bunch of missions, some of which don't cause a CTD. A couple of those require islands available in the WGL Islandpack. I'm proud of the dude who posted to the thread that he wasn't going to download the addon, because some of those missions required non-stock BIS stuff. And people wonder why there aren't enough missions for addons)

Boo No missions included? Not even a forum island? What good is it spamming LOL rockets everywhere without a juicy target, like an IRC village? Peter Pan is great and all, but what we all want is Wonder Woman and her invisible jet. Hiss

Tom's Hardware had two articles today. One on how some games set up to be addictive (think MMORPG), and one on how drugs and LAN parties mix. The reporter (Aaron McKenna) goes to one such party: From the Article: Just a warning -- there's plenty of colorful language and disturbing imagery in that article.

Crash -- no of course I'm not calling "abusive" anything I wouldn't do. there's a lot of things I wouldn't do because I'm too lazy or not interested in. And I do things that are abusive too, from time to time. And, sure CoC_NS isn't a silver bullet. I don't use RemoteCall for artillery fuzing, for example, because it doesn't give me the bandwidth or response I need. So I write my own transport, and it's one that can be much more abusive. But what I am trying to say, is that when I have PV break, a lot of other things are breaking too. For example, the OFP environment reacts much differently when someone with a ping >300 (well, >200, but we'll give some slop) is in game, as the whole MP system starts to break down. This "breakage" is not always noticeable until we start doing a lot of things that require these handshakes. then the packets pile up, get lost, and things go awry. Suddenly bullets aren't flying any more, people can't get into vehicles, then suddenly die when they're shot five minutes before, and in short, all network hell breaks lose. Still, I'm curious about other "breakage" scenarios, since we all need to use PV or some variation on it quite regularly.

Bah. I've never had trouble with PVs not synching. And I like to think I know something about it. Your problem sounds like you're PVing before the game synchs. If you want to PV in an init.sqs, or anywhere else, send it after mission start. The way to force this is ~.0001 Otherwise, it will transmit before synchronisation. Oh yeah, and if you've got PVs failing in mission other than that, you have bigger problems to worry about.

The goalie does look a little stiff in his posture -- almost as if he were waiting for a bus.

I think this is in the addon pbo as a hard variable. I'll check though -- we may have left it open. Otherwise, you can play with tacfire.sqs to get the results you need. I'll post on that. the SFP ARTHUR is another COBRA unit. A COBRA unit will transmit a fire mission when it detects incoming rounds. It won't care about BDA. If all suitable assets are busy, the COBRA (actually tacfire.sqs) will stack the mission for when it's free. So if you fire into a den of COBRAs, they're all gonna order a response. The script is super-simple. The debug messages should be removed in the next build. The first one means the selected ammunition type is not available. This has been removed in the next build. (UA 111) The second probably means that one of the units (such as the russian towed howitzers) has a bug in the magazines.sqf file (array not up to spec). That should be fixed too. UA artillerymen don't fair too well in face-to-face contact. Sometimes we keep them on careless so they point the barrels in the right direction. Sometimes that doesn't do to well. Please do, this one is new to me!

How to use Cobra units: A. Put cobra on map If any bad guys fire at a target within 1 km of the cobra location, it will call counter-battery fire on the firing unit. It's automatic.

shinRaiden's point was somewhat obscured by his "slippery slope" example. But I'll try to make it clearer: Engineering for a "Best-case scenario" is a recipe for disaster. someone brought up CoC Mines and our claymores in another thread. Yes, the Claymores do cause FPS chunders. It turns out, much of that is due to overloading the audio processing (hence I do have a solution). But when we built those mines, we did a couple things to make sure they "just worked": A) We measured FPS hit under "full game combat" conditions, and adjusted to what we figured was acceptable with some overhead for the unexpected. B) We tested to determine the maximum number of trigger-fired mines a mission editor could place before things started to get wonky. C) We got someone on dialup in Australia to connect to our server in Minnesota, and we tested online in those conditions. The reason why we never released CoC_Napalm was because, at the time of development, we got a cool effect that worked, provided everyone had a ping below 200. Anyone with a ping over 200, and it looked _really bad for everybody_. Addons have to "just work". If they don't "just work", people don't use them. If your group has one guy on a modem, or in parts of the world where they pay by the megabyte, and that guy has to download a huge addon that's not guaranteed to work, your group is not going to use that download. It sucks to say it, but I see it time and again: each step you require the end-user to make beyond hitting start reduces your audience by a significant amount. And if it means for a modem user, driving to a friend/business/internet cafe and spending half an hour downloading the thing from someone else's bandwidth, when that person gets home, the thing better work.

Manhunter -- I'm not sure, but an ammo truck will probably resupply a UA unit without difficulty. Heck, it may even be completely automatic. Otherwise, you can just script an addmagazine with what you want. As for converting units to UA 1.1, it's basically like 1.0, except that in the root directory there are two more entries: avails.sqf and magazines.sqf entries are the same as for the other UA root .sqfs. avails gives the options on the FED, and _should_ look something like this: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> [[6, [1,24]], [0,["I/E", "I/A"]], [0,["FWR", "AMC", "TOT"]], [0,["PARL"]], [0,["HA"]], [3, [3, 60]], [0, ["1 GUN", "2 GUNS", "CNT IL", "CRD IL"]]] each entry is [DEFAULT, [RANGE]] where RANGE is numeric for Rounds IE and Interval, and a series of Strings for everything else. the order of entries is: RoundsIE Missions MethodofControl Distribution Trajectory Interval Adjust Mode magazines.sqf has an entry for each magazine carried by each weapon type, and an entry looks like: ["CoC_Howi155WP", "WP", 3, -.3, 20000, [[.7, .7, .5, .8, .8], [.7, .6], 1]] "Magazine Config Name", "Display Name", FUZES, BurstHeight/Time, Max Range, [Effectiveness Params] FUZES = 32= sensor, 16 = delay, 8 = "smoke", 4=VT, 2=Time, 1=PD (so 3 = PD + Time) BurstHeight/Time: Positive number = height in meters to fuze (ideal), Negative Number: time (seconds) before (ideal) impact to fuze. Max Range = meters EFfectiveness params: Target Type, Protection Type, Effectiveness Coefficient Target Type: how good the given shell is (1=best, 0=never use) against a given target type [iNFANTRY, SOFT, ARMOR, ARTILLERY, STRUCTURE] Protection Type (1=best, 0=never use) [iN OPEN, IN COVER] Effectiveness Coefficient: how one round of the given ordnance stacks up against one round of 155mm To use the fuzing, you need to copy the call to fuze.sqs as it appears in the EH_Fired calls. You'll also need to load (on all clients) a function to handle the fuze effects. The function must be named: AmmoType+fuze (e.g., CoC_HE155Fuze). If you use the SENSOR fuze, you also need a "Guide" function (CoC_SADARM155Guide) to handle the shell in flight. that's it.

Well, the main reason you find improper lods, bad scripting and the rest is that OFP works without it, and most people don't notice it at first blush. BIS could do a better job, sure. But even when they reveal how things work, there are still a lot of people in the community who don't believe them.

Yeah TAC = Nuke. The Nuclear launcher only has TAC shells by default (you can add conventional warheads using addmagazine)