bn880

Thanks for coming guys. And it was my pleasure coming in to booby trap our weapons crate, by accident.

Since we have this Addons At Ease forum here and it doesn't get 100% attention I thought I'd post this here for BIS eyes: We have a lot of people playing a lot of missions or trying to, where they get missing addon warnings and error messages. This is followed by them not knowing where to get the addon and which version it might be etc. Auto Addon Server resolves this slightly, honestly not much more than that. And AAE has too many requirements to scoop up the lazy addon makers, such as myself. Now, here is my idea; if we could have a central addon database, maintained at a single site like BIS or OFPInfo or elsewhere, where each addon, each variation of an addon, and each mod, has a unique numeric serial number or index assigned to it. The serial number would function like a MAC address does for NIC's, no duplicates allowed ever, everyone must sign up for it at the same place. Now, in the cfg patches section of a config, people could type in that serial number at the end of the name of the addon, so that people can write this number down, type it in to the OFPEC addon cross reference, find it, click on the link and DL the addon from a server. This is how I think each row for each addon may look like: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> <index/serial>, <name>, <version>, <maker/team> , <date>, <released>,<relaced by index>,<DL locations> unique integer, string, string, string, date, boolean, unique integer, string(s) 0000001, "Bn Tracers", "1.24", "bn880", 08/09/2005, true, 0000000, "http:\\blah blah" ^ this is all a rough draft and idea. Now, if each addon and mod has a seperate and unique serial, we can fairly easily decentralize the download locations to dozens or hundreds of servers. SQL queries can easily be run on the entries to search for addons. I do not have any of the web server for this written, nor do I plan to work on this personally. However I think it is a valuable thing to consider, to have ONE central place to find every addon ALL the time. The addon makers could apply for their addon serial number before they publish the addon, so that they have time to insert the serial in the cfgPatches section. Each entry in the DB would need to be administered by someone, as with most other submissions. An admin could take in a request for a serial, create the entry, and send back to the addon maker the number. This can extend to Armed Assault, and probably as far as Game2... :-* Thoughts? Actuallty remember, when ArmA comes up a lot of addons will be repacked for the new updated engine, a great time to serialize them. The main thing I am concerned with is that this be kept without any requirements for registration besides: author or valid team member submits their addon/mod, it is not an exact duplicate This is not about requiring things of addon makers, for approval, this is to give them a tool to identify their addon globally, to make it easier for lazy users such as ourselves.

I'm thinking these captures are older than the latest ones we saw on the official site, and if I remember they de-glossed the armor already. But I could be wrong (again), maybe they really don't understand the concept after all.

3. "You are nutjobs" But we already knew that, of course the real blame always lies in the ones who start wars, that's the only way to prevent all this shit in the first place. What else can be done, nothing really unless you plan to rally 20-100 million people somewhere to overthrow a government, US. UK etc...

WHERE ARE YOU GOING< ARMA IS COMING IN A FEW MONTHS.... hehe

Everyone knows that it's old.

Work never allows that! Get back to work. Ya okay, I think we might even have our proper server up this weekend. Finally.

Can anyone say skinny dip with Russian girls? Too hot... no war effort... mission failed.

I acknowledge your observations. However I think that we can look at these MP branches like we look at tastes in music. Most people will stick to one genre. A few will be open to several, and almost no one is good with everything. The solution to this is nothing. Just like in people listening to music, the best you can do is make each genre attractive and hope to gain an audience. No one dies from a separation (correction, from this separation), however I think there is a bit of taunting between them. We won't need much help in Mp when ArmA comes out as long as we get enough people. So if ArmA offers enough interesting features and fixes, we will be able to fill each aspect of Mp with plenty of people. However I do not know for certain ArmA will be that good to us.

Nutjobs.

Overreaction? Naaa....If they attacked the executive authority (that's what the forces are there) they earned the few sticks on their backsides they recieved. Problem is that (as usual) it is turned around 180° by some idiots in offices, who never had to stand infront of a mob Non-leathal punishment is totaly conform with human rights as a method of riot-control or penalization in trouble areas... Have you ever watched riot-controls at football games??? If that is torture what the squadies did, then you will see a lot of "torture" during the woldcup here in germany. I can link a police video from a nuclear-transport which demonstrants tried to stop by force. There was more batting involved there...but this may offend s.o. or what? Wow, surprised this kind of talk is even allowed on the forum. Think before you post maybe? These kids were protesting with rocks against soldiers with body kit.... the only time the ycan be beaten somewhat is to dispurse them if they refuse or to arrest. Neither is the case in the video.

I'd like to watch it, but for the most part the 60 channels I have here only show events of their country, so US or Canada. Booring.... Nice time to try operation disinformation, hint hint.

Well I agree with Kegs, if this is all much smoother than our current OFP with that kind of detail, then it changes things _completely_. I think half of the people here don't even realize the power of CAS or AFV's have when used with a realistic engagement distance.

Thumbs up on the graphics.

We at The Chain of Command are pleased to inform you that version 1.1 of our Network Services has been released to the public in Addon and script format. The addon version has a very simple Installation procedure which involves the placement of the CoC-Server object on map. After that you gain access to all the Functions and Resources provided in the system. 1.1 DOWNLOAD The CoC Network Services originally devised for "in house" use allow Operation Flashpoint scripters to transfer any data necessary to any specific network node in a networked OFP session. The scripter can send data by simply calling one function and designating a target pre-processed function on the destination node/machine. The system is designed to allow for fastest transfer of small to large data between the specific network nodes. Supported network send data is: [*]Boolean [*]Group [*]Number [*]Object [*]String (passed in as Character Arrays, see ReadmeCoCNS.txt) [*]Array (filled with nothing or any of the above in any combination) [*]Multi-Dimensional Array (filled with nothing or any of the above in any combination) Once the handshaking process is completed each machine has an array with information on every other machine in the session/mission. The server is always in the first entry of this array. The CoC Public Array system build into this CoC-Server allows for the definition of publically shared arrays to be transferred over the network when the function fPublicArray is called. We hope everyone enjoys the benefits of this pack either in Add-on or Script format. Also check out the CoC Unified Documentation system: UDS

Ohh, no the local variables can't be used like that as they don't exist on the remote nodes in the remotecall script. You can only translate local variables into the remoteCall string using format[], however you can never pass vehicles in remoteCall, only an index to a vehicle. Remotecall basically passes strings, no chance to send objects in strings. Have a look at the main document here, it will tell you what you can pass in remoteCall http://www.thechainofcommand.com/docs/LIBNETWORK/CoC_LIBNETWORK.html middle of page

That usually happens when you send bad data across, espeically if you try to send data that a function won't send anyway. Perhaps one of your remotecall commands is buggy and ends up being "". Make sure to use NS 2 it can be downloaded on the documentation page.

Exactly! What's next? Allowing jumping like in AA? Gonna reinstall Rogue Spear....Aaaaahh good times. GOOD TIMES! I'll second that! R1 and R2 were the days... then came OFP I really hope neither ArmA nor Game2 give this much bad taste for their old community (us), as RvS and this new PoS have for the old Rainbow community. Our last hope is on BIS

Just put on the Darth Vader outfit if they are too friendly. Instant results. That is unless they go that way too.

Well after long discussions, it also appears to me that the MD5 hash will be the way to go with this. Main point being, serialized tags: backwards compatibility will suffer. OFP has some weird behaviour with making backward compatible tags so that missions do not report missing XYZ addon V1.0 or 1.2 etc. A global solution can be made quite well, if we take your MD5 work tug2000 and coulpe it with Mikero's AddonScanner, plus some centralized DB for MD5 hashes and dependencies. Mikero's addon scanner would need to be modified to work like AAS, open all PBO's in OFP subfolders, detect all the necessary tags from their configs to match tags to PBo's. Once a single PBO is matched to a tag from mission.sqm, it's MD5 has can be obtained, and all dependencies can be found at the hash DB. Additionally we would store the PBO data once it is scanned. And only re-scan new or modified PBO files, so that we do not waste people's time. We are 40% done a unified solution this way anyway. All it takes is for people to work together to a common goal. Also, the best way to make sure the mission does have all the PBO's it needs is to store an additional MD5 list file in the mission folder/PBO. This file would be managed by the external exe launcher.

I wanted to quote Spinor here on the same issue, as it is very clearly showing the need to separate two aspects of addon hosting in the community:

Good to see people being warm to the idea. 1) My view on this would be, every time you make a change you get a new serial, this is kind of a hard fact of the solution. This IMO is the only 100% reliable and fool proof way of ensuring people have the right stuff, with the minimum of confusion. It will be up to the author to decide whether or not the addon is backwards compatible, and to flag the old serial as depricated. The old entry in the central DB will have a pointer to the new serial, and it will be a linked list in that way. The thing to keep in mind is that the process will be painless and a serial is just a number, we would probably have an enormous capacity in terms of serials, like several billion numbers in 10 base. 2) Certainly I see your point, however as it looks right now, it will be up to the addon makers to decide if they wish to break up their addons into several standalone PBO's and to request serials for each. That's the problem of allowing a breakdown of an addon/mod, you often need to grow each individual piece, and need a lot more testing to ensure each eas truly capable of running without the other. Having said that, it is theoretically in BIS's capability to write an addon/mod interpreter which automatically has a capability of breaking down an addon into standalone pieces. (scripts being the only immensly unpredictable factor, especially if an addon maker does not consider that the pathscould change) Theoretically. I am certain BIS doesn't have the time to do this, but I hope they implement a centralized serialization and distribution/acquisition of addons!

Well I don't know exactly about your idea as it's really a similar way to solve something different? What I am aiming for here is for the user to know 100% which addon he/she needs to get when they get a missing addon message (currently it's not that easy). This by the unique serial number in cfgPatches, and it requires no additional software to be run. With an MDS, I am unsure as to how the user will know what they require. However, I am not saying your project is a bad idea nor am I trying to deterr you from working on it. I would be happy if BIS could pick up on the idea of 100% addon identity match via mission.sqm, and a download/info database which is linked to that via AA GUI.

Hello and Happy New York, I mean Year... Here is my little winter project for the OFP community: OPERATION DISINFORMATION 1943 V1.4 07012005 Required addons: [*]FDF 1.4 Full MOD Thanks to: FDF Team for their great immersive WW2 Mod Zeus team mates for providing an area to test the mission, and people to test with, especially Loozy boozy who spent numerous hours on testing with me . (www.ILOVELOOZ.com) Joni, who is just great. And thanks to everyone else who was a total plonker. This mission, has to be experienced. I can't tell you much more. It is cooperative and contains a week of my time after being inspired by FDF 1.4 and winter in general. Enjoy. I mean, ENJOY IT NOW! --------------------------------------------------------

Well yes, the plan is for the identifier to exist in the mission file, as it will be appended to the current cfgPatches of the addon, such as: addOnsAuto[]= { "bn_tracers_<serial>", "finmod_<serial>", "coc_ce_<serial>"} (as an example) But for this to be automatically linked inside AA to a download location would be amazing indeed. I figure only the lookup database has to be centralized and administered at BIS, the actual download space can be decentralized and offloaded.