killswitch

Like I said, the islands can be found on ofp.info <-That's a hyperlink. You can click it. Go ahead. And I consider that site to "have a good server".

Make sure you replace both the GMR.pbo and whatever "effects config.bin" you had with the newer ones. And, if you aren't already doing it, Â do place them in a mod folder either as described by the readme or a mod folder of your own choosing. (I have mine in mods/xplo/AddOns and mods/xplo/bin instead of GMR_exploMOD/... )

Like others have suggested, nice islands are: Skye, Trinity, Saruago and Hellden of which the latter has a somewhat large "city". Also, have a look at "Phaeden's Island", which I believe has the largest city-like area. For desert-like areas, there's always the two "Lagadishu" versions, one mentioned above (BHD Island) and sgt Gunnery Highways "Mogadishu". Don't forget Umf:s "Jelhalabat Island" or CAT-SH*T-ONE:s Afghanistan, as mentioned above. Get them all on ofp.info and see which one fits your fancy.

bis_weaponpack is contained in the O_WP.pbo file you should have in your Res/AddOns folder. In other words: that is not the problem, unfortunately...

How about adding 40 mm rifle launcher smoke grenades to JAM? For marking purposes and the likes. These seem to exist IRL: M713 red smoke M715 green smoke M716 yellow smoke ...and a basic "white smoke" grenade would be nice too. I whipped up a version of the BIS M16GL myself just to test, and it's quite feasible. Combine it with the "blocking smoke trick" in JAM and I believe we have something  *Edited since my original thread was properly deleted to keep the forum tidy. I agree. Thx placebo Â

Anyone else having this problem? Yep. Tried one on http://ofp.info/ and on the ONS site. Both instances of bison_0.9.zip were corrupted. Â Using WinRar 3.20 (the latest as of this writing) *EDIT: tried downloading the bison_0.9.zip from the Northstar site again. This time, the archive turned out fine. The Internet works in mysterious ways...

This seems to be a 1.92 beta "feature", unrelated to the explo mod. *EDIT: Please disregard this. It is a feature of the explosion mod related to all vehicles having been furnished with an extra ammo load to make them explode. See later posts in this thread. Again, it's not 1.92 or a bug therein.

Glad to be of help! And since you now have it, I will remove the link and file so as to not spread a "beta" of the mission too wide. Good luck in your endeavours!

Murphy, I took a gander at the mission and did a bunch of optimizations: Preloading of models Added some "dummy" civilan types so that their models/texture loads on mission start. You had a few of them already, I just made the collection complete. Optimizing and streamlining the spawns Changed the spawn in a few ways:<ul> [*] Only spawn a zombie if it is dead or not existing (the latter meaning the mission just started). [*] Otherwise, just move it to the new "spawn" spot. [*] Move much of the unit initialization scripting from the createUnit call in spawn*.sqs to the zombie.sqs script. [*] On creation, the zombie.sqs sleeps for a random time so as to not eat CPU as soon as a zombie is created. This lessens the load when 7 new zombies are created almost at once. [*] Zombies are only createVehicle:d on the server. [*] For now, live zombies that should "insta-move" are setPos:ed on all machines. Not sure if this is correct or if setPos:ing also should be done on the server only. Other small fixes Added a gamelogic and called it "Server". The spawn scripts needs it. I could have used one of the game logics already in game, but one named "Server" is intuitive. Tentatively called "Skye Virus 3.01" (*EDIT: removed the link since it was really only intended for D.Murphy Man, the mission maker) Looking forward to a "The Nogova/Malden/Everon/Saruago/Ia Drang Virus" and rabid birds chasing me... Â

Boom! <pause> Pop...fizzle... Hehehehe... I love this mod :-D Found a couple of bugs, though (1) The green smoke shells don't have any picture in the gear part of the briefing. The fix: add <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> picture = "smokeshell"; to the class SmokeShellGreen in the config.cpp:s CfgWeapons. As a reference, here's the SmokeShellGreen from the official BIS commented 1.91 config: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">     class SmokeShellGreen: SmokeShell     {         //--         /*!         \patch 1.78 Date 7/23/2002 by Viktor         - Fixed: Green smoke shell has its picture in the gear         */         picture = "smokeshell";         ammo = SmokeShellGreen;         displayName=$STR_DN_SMOKE_GREEN;         displayNameMagazine=$STR_MN_SMOKE_GREEN;         shortNameMagazine=$STR_SN_SMOKE_GREEN;     }; (2) Some of the scripts in the GMR.pbo have goto:s that reference non-existing labels. Often, there is a 'goto "exit"' without a "#exit" at the end of the script. Take hit_tank.sqs: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_tank= _this select 0 ? (not alive _tank):goto "exit" ? (not canfire _tank) or (not canmove _tank):goto "getout" goto "exit" #getout ? (not (commander _tank  in _tank)):goto "exit" ~ 3+ random 3 _tank stop true ~ 3+ random 3 commander _tank leaveVehicle _tank ~ 0.5 + random 0.5 driver _tank leaveVehicle _tank ~ 0.5 + random 0.5 gunner _tank leaveVehicle _tank _j= (random 100) ? (_j > 50  && _j  <= 100):commander _tank allowFleeing 0;driver _tank allowFleeing 0;gunner _tank allowFleeing 0; ? (_j >= 0  && _j  <= 50 ):commander _tank allowFleeing 1;driver _tank allowFleeing 1;gunner _tank allowFleeing 1; exit Rewritten and with no need for gotos: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_tank= _this select 0 // Rewrote the two following condition expressions to get rid of unnecessary gotos ? (not alive _tank):exit ? (canfire _tank) and (canmove _tank):exit #getout ? (not (commander _tank  in _tank)):exit ~ 3+ random 3 _tank stop true ~ 3+ random 3 commander _tank leaveVehicle _tank ~ 0.5 + random 0.5 driver _tank leaveVehicle _tank ~ 0.5 + random 0.5 gunner _tank leaveVehicle _tank _j= (random 100) ? (_j > 50  && _j  <= 100):commander _tank allowFleeing 0;driver _tank allowFleeing 0;gunner _tank allowFleeing 0; ? (_j >= 0  && _j  <= 50 ):commander _tank allowFleeing 1;driver _tank allowFleeing 1;gunner _tank allowFleeing 1; exit

Suma/BIS, a few things you may want to take a look at: First, something about a respawn problem when killed in an armored vehicle driven by an AI: Respawning in mp, after being killed in a vehicle . Also, there's a possible unintended behaviour of preset param1 and param2 values in a dedicated server config not overriding the default values of a mission's description.ext: Cti dedicated server Thirdly, the "laser designator not really usable in MP": Laser in mp not working Number four, and last: the Bradley is blind, unlike all the other tanks/IFV:s. It has irScanRangeMin and Max set to 0 due to the M113 having that. Giving it back the 500/4000 m limits from class Tank would put it on par with the others and, I believe, improve the game immensely. It's an easy fix. Don't know how it will affect any official missions/campaigns, though. Just thought I'd collect them here in what looks to be (one of) the 1.92 beta report thread(s). Regards.

Try this as a server config file (you may name it "sample.cfg", "server.cfg" or whatever you like) <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">// add a line password="{password}" here to assign a password for this //session, which everyone who wants to join the game will need in order to //connect //password = "XXX"; passwordAdmin="*****"; // Admin password hostname="Anders SFP and BAS Server."; motd[]= { "Welcome To Anders Swedish Server.", "Hosted by myself.", "Specs: PIII1GHz, 512MB DDR etc." }; //Rate stuff MaxMsgSend=384; // Default: 128 MaxSizeGuaranteed=512; // Default: 512 MaxSizeNonGuaranteed=256; // Default: 256 MinBandWidth=131072; // Default:131072 MaxBandWidth=512000; voiceOverNet="false"; //maxPlayers=6; kickDuplicate="true"; // Same playerId = someone connnecting and on the server both may have pirated copies. Ban material. motdInterval=5; Â Â Â // Show the lines in the motd with n sec separation voteThreshold=0.33; // when one third agrees, this is enough to confirm a vote reportingIP=""; // Don't tell GaySpy we're here voteMissionPlayers=0; // start voting when <n> players connect class Missions { }; Also, just like benu said, describe the process by which you concluded that you don't have a problem with addons. I believe you do have some sort of addon problem there.

Yeah, if you are a marketer at Sony or Nintendo. The method: get all data sheets for all the components in the console. Then jot down all numbers referencing "bits". Finally, ask/bribe an engineer to "put these thingies together, you know, with that "X" thats rotated" "You mean add them together? The plus sign?" "Yeah yeah whatever. What do I get" "128" "Cool" j/k

Best thing about it: it's somewhat large (me, I dream of a island almost filling a 25,6x25,6 km "world grid). Hoping that the island has, get this, an interesting road network. Yep. Think "what chokepoint do we hold", "which march routes for the battallion to reach AA Sundance", "your mission is defence in sector between eastings 10 and 13 and the roads going west from the towns of Elmerville and Fuddstown". Looking good from the screenshots I've seen so far. Lets hope it does not have drastic elevation changes like in northern Nogova. AI pilots have a nasty way of jamming helos into the hills there when going from the northern airport into the main island. Also, I hope for some large, flat, open areas. Bridges! Wide enough for the AI to cope with them. Reading Cornelius Ryan's "A bridge too far", so I'm kind of high on bridges right now  Oh, also, in areas near road turns, don't put those "slightly harder to run down" trees and bushes. On Ia Drang, the AI very often has to ditch a broken jeep after a while if I send it out on a patrol along the road - he constantly hits trees and stuff and eventually the jeep is busted.

Easy one. <ul> [*]Make it compile and run on 64 bit processors and OS:es. This is a no-brainer. [*]Code it to make use of more than one physical processor, i.e. make it multithreaded. That way, people with HT processors will benefit, too. Also, "coding for DX9 feature set" is not mutually exclusive to "64 bit compatibility".

And that is exactly the intention. Big companies, much like spoiled brats grabbing everyones' toys, don't like the idea of a free market economy. It's all under the chapter "consolidation of power" in the book of corporate fascism. Or "freedom" as they have spin-doctored it to sound... Software patents are meant to further their control and stifling a lot of development. They are a different kind of hippies, dazed and confused by the $/€. Oh well, in time, they too, just like n*zis and commies, will be a thing of the past...

(Tested both 1.91 and 1.92b server versions) Hmm...it seems that the server software won't heed the settings for param1/param2 in the server config if the description.ext for a certain mission is set up to give you a list of values to select during the "lobby setup". This might (unfortunately) be an intended behaviour, however I belive it would be better if it did what you expected. So, BIS/Suma, a suggestion: Let the values for param1 and param2 as set up by the mission rotation list in a server config file be the default values, overriding the defValueParam1 and defValueParam2 as set by the description.ext of the mission. One can still change them during mission setup, but it might be useful if one wishes to have other values selected by default than what the mission maker has set. One could also imagine the need/want to lock these parameters from the server config, making it impossible to change them during mission setup. It might look like this: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> // Some server config file ... ... ... class Missions {    class Mission01 {       template="Mymission.Abel";       param1 = 3; // The value 3 will be preselected       param2 = 2000; // 2000 preselected       lockParam1 = true;       // cannot change param1       lockParam2 = false;       // param2 might be changed    }; }; ... ...

<ul> [*]Have the computers hostname set to something [*]Have said hostname and its corresponding IP adress listed in the /etc/hosts file. There are ways to let the dhcp client fix that dynamically, IIRC. [*]Have the nscd (name service caching daemon) service installed and running Oh, and get up2date spinning ASAP and keep the OS current.

Perhaps. As a newcomer to the world of OFP editing and addon making, I strongly suggest you grab a glass/cup/bottle of your favourite beverage and start browsing the OFPEC To create an addon .pbo-file one uses Amalfi's MakePBO and lets it process the folder containing the files and configs that will go into your addon. :-) The information and files you need for either a face or a music addon is basically a config.cpp file and the data files themselves (.paa image files for the faces and .ogg audio files for the music). The magic lies in the configuration (config.cpp). Here's a thread over at  where I helped a guy put his music in a addon ("pbo-file"): Ogg Music for PBO? As for faces, well, I believe that would mean having a class CfgFaces in addition to (or instead of) the CfgMusic part. I can't tell you exactly how it should look, but I believe there are "face packs" out there. You could UnPBO them using the PBO decryptor and see how they are done. In essence, look around on OFPEC and browse the forum there. Use the search function, because all you want to know has been answered many many times before. Read a few tutorials, even if they don't seem to be exactly what you need. To be able to ask the right questions, you need to get the basics down. Things to search for would be "CfgMusic", "CfgFaces" Good luck!

Oh yes... I can see it now.... "Gimbal's Drunkards" and a version for us Euros: "Gimbal's Football Hooligans"... Â Anyway, love the FIA mod and the fact that it will be JAMming to the tune of inter addonmaker cooperation. Puts a big old smile on my face. Keep it up!

Yep. Remaining nags:<ul> [*] Resistance repair trucks can't repair. Its a config.cpp fix, would be very easy for BIS and greatly appreciated. [*] The Bradley (M2) is blind as a bat (irScanRangeMin=0, irScanRangeMax=0, both inherited from the M113. All other BIS IFVs/tanks have min=500, max=4000). Also easy to fix. BIS? Â [*] Buddy lasing while playing on a dedicated as described above.

Ah...I see. Thanks for the clarification.

Details, please. What mod? What addons does the mission use? Server specs (can't hurt)? Perhaps we as readers can recreate it by running the same mission?

A few questions on the maxPacketSize property: Is this the maximum number of bytes that OFP tries to put as data payload into a UDP packet? If so, one may have the following numbers as reference for tweaks: With a "normal" Ethernet connection that has a MTU of 1500 bytes, the maximum data size for a non-fragmented UDP packet would have to be (UDP header size = 28 bytes) 1500-28 = 1472. For people that, like me, connect to the net over an ADSL modem (possibly via a router), using the PPPoE protocol, the MTU is 1492 bytes due to the extra PPP header. That gives you 1492-28=1464 bytes of UDP payload. So, my theory is that <ul> [*]Ethernet: (MTU=1500): Â maxPacketSize = 1472; [*]xDSL/PPPoE: Â (MTU=1492): maxPacketSize = 1464; [*]56k modems: (MTU=576): maxPacketSize = 548; if I have done my math right, would be some kind of optimum? Also, Suma, the two numbers 1490 and 512 given in your example, are they the practical min and max numbers?

Indeed, exactly what does the "equalModRequired=1" mean? Does it mean that <ul> [1] server and client must have the exact same set of mod folders, i.e the equality check regards the name and number of mod folders, regardless of their content. Â Or... [2] client can have a superset of the mod folders the server is using? (E.g: server has finmod, client has finmod;i44demo) [3] they have the set of mod folders, like [1] Also, server and client implicitly checksums (i.e. without the use of checkFiles[]) the contents of said mod folders to make sure that not only do they have the same mods activated, but their contents are also equal? [4] Client has a superset of mod folders [2], checksums are done only on the contents of the mod folders the server requires, like [3]? If its like case 1 above, equalModRequired would be a sort of simple heuristics to do what Blake described, i.e. to do a quick check to see that the client has certain (possibly total conversion) mods activated. Question: assume I have both the FDF mod (base folder: finmod) and the I44 demo (i44demo) installed. For kicks, I rename the former to the latter and vice versa. Now I fix my shortcut to read ...-mod=finmod and try to connect to a server that also has ...-mod=finmod and equalModRequired=1. (No checkfiles[]=...) What happens? Will I be accepted (equalModRequred simply checks the name of the mod folder) or rejected (some file checking done, my finmod (containing the i44 demo files) is nothing like the servers finmod)