dinger

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

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

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.