-style-

I'd like to see all of the AI behavior go into a script file (or two) that we can play with. Â (formations, tactics, emotions, fire rates, take-cover-rates, movement/fire patterns, spray in general direction of enemy, run certain way when under fire, etc). Basically, somehow let us edit the AI as much as if you released the source code.. This way we could customize AI behavior for individual addons, units, or special soldiers. Be cool to be able to make the 'Afghani Militia' soldiers act realistically (cant shoot as accurately as their weapons would allow, terrible tactics, general stupidity), while the 'Army Ranger' units behave in a believable manner (advanced tactics, high precision, ...). AI organization: Something similar to a real life setup might help. Each soldier would have his own AI, The fireteam leader would have his AI, plus handle the fireteam's general tactics (fireteam's formation, for example). Then, the squad leader would have his own AI, and direct all of the fireteams (fireteam A: flank right, B: covering fire, C: man that pill box. Â general formation of fireteams). and so on, up the chain of command... Eventually, the theater commander would have a RTS type setup, and direct whole units around the island. Leader AI skill level (not rank) would determine how well the leader directs the groups under his command. Maybe have two skill attributes for each soldier: leadership/tactics and general shooting/fighting. (You could add in piloting/driving skill too, minimum levels needed for certain vehicles/aircraft, so that a fighter pilot could drive anything, while the average soldier would be limited to cars and trucks. Â 'Reaction time' could be determined by this as well: a novice tank driver may not be able to man the gunner position as efficiently/quickly as a elite tank commander) I think this would easily scale for MOD's, you wouldn't need to mess around with scripts and stuff like the CoC guys are doing. (no offense) Plus, each AI level wouldn't need to exert direct control over each soldier under it's command. Â The Squad leader might not bother assigning the fireteam's formation. Â Platoon leader definately wouldn't. The AI would function better this way, the fireteam would know what formation it should use because those soldiers are right there, they see units and obstacles the platoon leader doesn't. This would help at the squad level (any level) as well, especially if the fireteams are scattered or spread over a area (field,street,whatever) where differing formations between teams would help. This would help improve large battles, the squads would coordinate their efforts under a leading officer. Â It would get a lot tougher for players as well, because the enemies would really be able to flank and maneuver effectively. If the squad leader was hit, the squad would lose their tactics/coordination until someone takes the place of leader (insert confusion AI and stuff here). Â Because the other soldiers might not have 'leadership/tactics skill' at as high a level as the previous leader, this would give real bonuses to players who target officers, without resorting to cheesy scripts. Player's would have it easier in some ways too. Â You would be able to leave the small-scale micromanaging, like fireteam formations, individual target assignments, and that stuff to your fireteam leaders, unless you want to force a command. This would scale well going up to command of multiple squads. Mapping would be easier too. Â With a AI system like this, the defense of a base(s) would be coordinated without needing special scripts. Â The officer in charge at the base could request help from nearby bases automatically. The AI could coordinate patrols + scouting on their own. This would be very helpful when a base has lost people to a enemy attack, squads would be reformed by the AI, and new patrol routes setup, without a mess of scripts to handle every possible damage situation. (yes, mapper can make his own patrols and stuff, and choose whether he wants the AI to override his scripts. Â Personally, I would rather let the AI handle most of this stuff, and just give general 'suggestions' through scripts/mapping.) I don't know if this analogy helps, but comparing the officer's tasks to a RTS might make sense. Â At a small scale, squad leaders would need to coordinate their fireteam's efforts, while the theater commander would be coordinating the efforts of all forces on the island. The coordination AI could function just like some RTS games as far as movement/attack orders are concerned. Disclaimer: Of course, this all depends on the current structure used for the AI code, etc etc. This might be better in some ways and worse in others, or not applicable at all. Just a quick idea I came up with.

I don't think anyone has every gone into detail on this, did a quick search too. I'd like to see BIS do some extra research and give the weapons all the real life statistics... Rate of fire, muzzle velocity, that stuff. There are some great sites with tables of this data, so it would only take a couple minutes to look it up, and then set the numbers properly. Varying rates of fire would be neat too (for applicable weapons), might be a bit of extra work, but it would be pretty cool to see in game. That and semi-auto fire rate being limited to the weapon's cycle time (might be in OFP already, I don't remember). (Then again, mouse-wheeling might be a problem)

I haven't read through this in depth, but I think it might be a good idea, if there won't be any source code release... http://www.codeproject.com/cpp/gecko1.asp

This might be slightly off topic, but here goes: I would like to see a 'random damage' effect for soldiers. (wouldn't make much sense for most vehicle hits) For example, if a soldier is hit in the leg, he may limp, or he may be wounded to the point where he cannot stand (like in OFP right now). I'm sure you guys can think of ways this could be extended to other hits (arm, chest, etc). Special forces soldiers would have a much higher chance of 'just limping' when hit. In the end, soldiers wouldn't always die with 1 or 2 shots. Some may take a hit, and lose conciousness, while the guy next to him may be wounded quite a few times and keep going. (Medics can be used to save the unconcious soldiers as well! Carry to medevac) I would think that, with all the stories about special forces soldiers surviving in crazy situations, they'd get a good bonus in this area. Those guys are tough... Ammo, body armor, angle of impact, lots of things could be accounted for as well. This would also help distinguish between weapons, especially pistols; a .45 would knock the target down with one good chest shot, while a 9mm might not. All of this would make the medic's job more complicated. Be more difficult at least.

Oh well, it was worth a try. Thanks for the answer Suma. I'll guess you won't come back, but have you looked at the Half-Life partial source release, or any other game's partial release? Â Quake3,2,1, JK2, Serious Sam, a lot of other games have had partial source releases too (some have had full source releases since then). Â I just use Half-Life as an example because everyone (+/- 20 people) has seen it, and the Counter-Strike mod saved Valve... I'll admit, I don't see security risks in the way Valve or the other companies handled it, but I'm still a newbie programmer. Good luck with OFP2, still looking forward to it.

No one has anything to say? I'd appreciate it if a couple of you would post a opinion on this, you don't need to read the whole thing, I made a quick summary in the original post. Scripters: don't you realize that all those scripting requests would be unnecessary if code was released? Ralph "connectivity" Wiggum, no opinion? Suma, you've at least glanced at this post, could you give us a answer? Any thoughts? yes/maybe/no/hellno? w/short explanation? anything? please? I've let this thread sit for a couple weeks since I've posted last. I'll just let it die if no one shows up, but I'd at least like to see some interest in this. Still looking forward to OFP2, even if we can't mod it.

This is a great idea! SOF2 had a random mission generator. I forget if it was multiplayer maps or SP missions. It was pretty cool: it had a built in random map generator too. It made the geometry and placed a couple pre-made structures... I think this would be pretty easy to make for OFP2. Just use existing islands, run a couple algorithms to semi-randomly place units/patrols/waypoints/whatnot, and you'll have a random mission generator. Actually, we should be able to hack this together for OFP1. It would run outside the game, make a quick mission by placing waypoints, units, and stuff, then save it to a mission file and it should be ready to play... Could open/view the islands to control placement (don't drop a T80 in the river/on a cliff).

Thanks for the replies. I understand that the OFP2's architecture is probably very different from Half-Life's. Thats why I estimated several weeks to make the change to a partial source release format. Unless the BIS coders are extremely stupid, the 900 round magazine cheat wouldn't work, even with a full source release. With modern FPS games, the client never controls any important variables such as health or ammo. If this info is stored on the client, the client can change it, even without having source code. Servers never trust what the client tells them. Old games, like Doom and Quake1 had a problem because of this. I haven't heard of any games that stored these variables on the client for a long time. I think that the problem with a full source code release is mainly that it leaves the whole netcode and rendering code open to these crackers that make cheats. ------------------------------------------------------------ Again, crackers don't use the released code to make their cheats. For the most part, I believe that they edit the exe in assembly, connecting it to their cheat programs. I've done a little research on this, I won't post any links for you, but I suggest you do some research on your own. You'll be surprised at how easy it is to find this information. I'd advise you to stay on trustworthy sites, whitepaper type stuff. It seems to me that most 'cheat' sites are populated by script kiddies and hacker-wannabes. These people tend to try to damage your system using exploits and security holes on web browsers. You can usually tell what kind of site you've found from the description/snippet that yahoo/google will give you. You should also read the links on cheating I posted earlier, they do a good job of explaining cheating for the basic player. ------------------------------------------------------------ I encourage you to download the Half-Life source only SDK and take a look at it. You don't need Half-Life to look at the released source. http://www.valvesoftware.com/hlsdk.htm As always, any good, thought out, feedback will be appreciated. Support is appreciated too.

Before I start, I would like everyone to know that I am not a very good programmer.  I know basic C++ and Java.  I am primarily self taught and do not know most of the proper terms and names in programming. I have some experience modding FPS games. I've modded/edited Half-Life, Jedi Knight 2, Tribes2, OFP, and several RTS games. Currently, when I have free time I work on learning to use OpenGL. I'm working on making a simple 3d game (flight sim or RTS). I have it loading a heightfield off of a uncompressed 24 or 32bit TGA file, then break it into a quadtree.  Right now, I am working on getting the quadtree nodes to overlap at the edges to prevent gaps. Thats all off topic though, just to give you a idea of what programming experience I have (not much), so if I make any mistakes in this post, please tell me so I can correct them. Also, I don't want to see anyone attacking me on the grounds that I have not been a important member in the FPS modding communities.  I haven't had the time or skills to be able to join any MOD's or really publish my work.  I don't want to make a commitment I can't keep.  I just enjoy editing games on my own time, and I hope to be able to release a real MOD or join a team sometime in the future. ------------------------------------------------------------ I know that this topic has already been covered here, however, this was in only one thread.  It reached about 20 posts if I remember correctly, and this issue was not thoroughly(sp) discussed.  It was decided that a source release would add to cheating, and the discussion ended. I would like to start a good discussion about OFP2 source code release.  I believe that with the input/support from leading modders, moderators, and the community, BIS will consider releasing source code for OFP2. If you see problems with a code release, tell us.  Tell everyone about the good and bad effects that you think a source code release will have.  I want a good debate on this subject in the hopes that BIS will listen. I know that this is a _huge_ post, and that the majority of you won't read it.  I'm just trying to fully explain  this, for those who don't know much about this, are unsure, or feel like reading a small book... I apologize if this is difficult to follow for non-native English speakers,  I'm not a good writer. If you don't read it, here's a quick summary: OFP2 partial source code release will not make it easier to cheat. There are only a couple of downsides to a partial source release, and a lot of huge benefits. We'd be able to do pretty much anything in our MOD's, change AI, change flight models, make damage models, whatever. Whatever BIS doesn't put in the game, we'd be able to add. (only for gameplay, we wouldn't be able to tweak the engine or graphics) ------------------------------------------------------------ The release of source code for OFP2 modding is one of the best and most important things BIS can do for the OFP community.  It will allow us to make much better MOD's, and it will let us create/tweak/MOD thousands of features into our OFP2 MOD's that we otherwise couldn't have created. I have noticed that many of you believe that a OFP2 source release would be bad, your primary argument being that it would make it easier/possible(!) for crackers to create cheats and hacks for OFP2. This is incorrect, a source release would not make it easier to cheat, for several reasons. First of all, there are several types of source code releases for FPS games. With a "Total Code Release", all of the game's C++ (java, C, whatever) source code is released to the public.  Obviously, these releases would make it a little easier for crackers to make cheats for the game. http://www.gamedev.net/directory/links/category.asp?catid=24 However, a game developer does not need to release all of a game's source code in a code release.  For example, with a "Partial Code Release", the developers would release only some of a game's source code.  This is what Valve did with Half-Life, and is probably going to do with Half-Life2.  http://www.valvesoftware.com/hlsdk.htm Lots of games have partial source releases.  JK2, SOF, RtCW, Serious Sam, Quake3, UT2003, etc. http://www.3dgamers.com/news/class/source/ Cheaters can't use the released code for cheating in a partial code release, there is no net code, rendering code, or anything they can pervert for their purposes.  You could look at a partial source code release as a _highly_ advanced scripting system (easier than actually making a scripting system too) that lets us change any gameplay feature. I believe that BIS could easily do a partial code release for OFP2, like Valve did with Half-Life. For those of you who haven't played Half-Life, or don't know much about it, this is how Half-Life works... ------------------------------------------------------------ With Half-Life, the game's source code is broken up into three main areas. game.dll (name varies) client.dll engine (lots of files) The game.dll file contains code controlling the weapons, monsters, in game objects, player, and game rules (scoring/respawning/gravity/etc).  This is open-source. The client.dll file contains code controlling some client side effects, such as the HUD, VGUI menus, and particle effects.  There is no code to control the actual rendering of the game here.  This is also open-source. The engine contains the rendering, netcode, core engine code (object lists, bsp code, file loading, collision detection, major physics code, etc), main menu, and anything that isn't in the other two areas.  This code is completely closed, only Valve has this code. First I will explain how Half-Life MOD's work, then why you can't use the released code to cheat. Half-Life MOD's are stored in subdirectories off of the main Half-Life folder. (C:\whatever\Half-Life\myMOD) All MOD content goes in here, such as the new game.dll, models, and maps. The original Half-Life content is stored in the valve subdirectory. (C:\whatever\Half-Life\valve) When you run Half-Life, the engine will boot up, and load the main menu. When you load a MOD (from menu, or command line param), the engine will then load the main menu background and extra menu options from that MOD's folder.  The game.dll, client.dll, and all game content is loaded as you initialize a game (join/host). When you run a MOD, it will check it's subdirectory for any game files it needs (maps, models, etc). If it cannot find the file(s), then it will check the valve subdirectory for that file. Note: as far as the engine is concerned, the original Valve game is the same as any other MOD, it just gets picked by default if other MOD's aren't specified. Say you attempt to join a online game with "MOD-A" loaded.  If the online game is running MOD-A, everyone will be happy.  (checksums and stuff are run to help prevent cheating). If the server was running "MOD-B", the engine will load MOD-B and then attempt to join, if you don't have MOD-B, you'll be informed and cannot join the game. There are MOD's known as 'server-side' MOD's.  These MOD's do not require any special game files, and use the normal Valve models and maps.  When you join a server running one of these MOD's, it will play with different game rules than normal Half-Life, for example, the shotgun might shoot explosive shells, and the "MP5" could function as a semi-automatic sniper rifle.  Essentially, you are joining a game running a small enough MOD to download it on the spot.  If the MOD requires a client.dll, or special models, then you must download it and install it manually. The released code does not make it easier for people to cheat in Half-Life. For example, if you try to join a Half-Life server with a modified game.dll, you will get errors and be disconnected.  Same thing with the client.dll. I do not even know if having a game.dll on your PC is actually necessary to join a game, because the server uses it's own game.dll.  The server tells you how fast the weapon fires, how much health you have, and how much ammo you have remaining.  Even if you made weapon fire requests way faster than you are supposed to, the server won't let you fire any faster than it's game.dll allows.  It tells you if you have shot the weapon, hit the enemy, or taken damage. I think that the only purpose for having the game rules on your machine might be to do client-side prediction, and possibly to aid in interpreting the server communications (simplistic example:  what would 'rocket at location xyz' mean to you if your copy of the gamerules had no 'rocket' objects?), I believe it controls some precaching type stuff as well. Lets assume that somehow you got past all the mismatch errors, checksums, and all the other things that prevent you from playing with modified game.dll and client.dll files and somehow managed to play with a modified client or game.dll.  (extremely difficult imho, but for the sake of the argument...) Your "god mode" code wouldn't work.  Why?  The server controls everything.  If you try to jump or shoot when dead, the server won't let you, and you won't move.  So you code it to allow players to run super fast?  Your prediction would be off and it'll look like some major lag to you, you think the players zip across the rooms, they don't, they see everything normally.  You may see yourself run super fast, but you'll get that lag effect as the server tells you you're way back in a different room, and puts you back there.  The game wouldn't be affected for anyone but you. The client.dll?  All it does is control the HUD,  your in-game menus, and sometimes some fancy client side particle effects (stuff that you can turn off in the graphics menus anyway). Again, even if you got through the checksums and other anti-cheat measures, what would this do for you?  You might be able to have a different in-game menu, or HUD, but what would that do?  So your health bar would be in the upper right corner, or, you may make yourself a "choose spawn weapon" menu.  You still won't spawn with those weapons. You could possibly code it to show yourself as killing everything in sight, that still doesn't help you because the server doesn't think you can do that, you'd still function normally as far as anyone else is concerned.  The other players will laugh at you, because you'll be stumbling around shooting off into the air, and walking into walls. //(!) However, if you made your own server-side MOD and hosted a game, but tricked people into thinking it was standard Half-Life, your cheat attempts might work. You would basically be playing a MOD with unfair game rules, maybe with something like this in the player spawn code: if (player.name == "cheater") player.health = 100000; else player.health = 1; This type of cheat is very, very easy to defeat.  All the developers would need to do is make it obvious that the server is running a MOD (could have the MOD name next to the server name).  For example, if you see a server with it's MOD name set to be "Normal 0FP2", while it is obviously running a MOD (mod icon/colored server name/etc), you'd know something strange was going on and hopefully stay away from the server.  However, I have never encountered this with Half-Life or any other FPS game, I believe there are other mechanisms in place to prevent this. //(!) Remember, the MOD's themselves almost never release their game.dll and client.dll code.  While it is just modified Valve code, you can see how much has been added and changed with MOD's such as "Counter-Strike", "Natural Selection", "Day of Defeat", and "The Specialists" (hey, TS has working slow-motion in multiplayer games.  The timer code for Half-Life is part of the engine (closed source) as well, its not something simple like just tweaking the time compression, as in OFP scripting). So now you don't have the game.dll and client.dll code to use when you attempt to cheat at a MOD, like Counter-Strike, but people still manage to cheat, right? As far as the cheater is concerned, Counter-Strike, Day of Defeat, and all those other MOD's  are closed source games.  The only open source MOD I've ever seen is "Open Source Jail Break". ------------------------------------------------------------ Here is some stuff on how people really cheat. Note that none of this has anything to do with the released source code. http://www.counter-hack.net/content.php?page=typesofhacks http://www.counter-hack.net/content.php?page=howhackswork http://www.counter-hack.net/content.php?page=halflife http://www.3dactionplanet.com/features/editorials/speedcheat/ http://www20.tomshardware.com/game/20030517/index.html http://www20.tomshardware.com/game/20030517/cheating-01.html http://www20.tomshardware.com/game/20030517/cheating-03.html ------------------------------------------------------------ ------------------------------------------------------------ I believe that BIS should follow Valve's example with OFP2.  It will allow us control over nearly every aspect of the game in our MOD's.  We would be able to change the flight models, code more advanced AI, and improve the game in numerous ways.  How about a working OICW/SABR or OCSW?  Can't do that with scripting.  I've created a simple OICW airburst grenade for Half-Life, pretty simple too. http://www.geocities.com/random_number54321/ I have thought about this some, and a partial source code release might hurt the modding community a little too, though the benefits far outweigh the drawbacks. How?  It could drastically change the structure of the OFP modding community.  This may be good, or bad.  "Addons" might not work in the way they do for OFP1. More formal "MOD teams" would likely be needed (good and bad). ------------------------------------------------------------ My suggestion for OFP2: Remember, this is a suggestion, I know there would be a better way to do this.  Just think about this general idea. Break code into two modules game - contains weapon code, player code, game rules, all in-game-object-code, higher level user input.  Maybe even some base physics and collision detection/time compression code.  Also has non-essential client side code, such as the map, compass, watch, action menus, etc. engine - rendering, net code, file system, collision detection/handling, main game loop, direct user input, all that stuff.  Tracks all objects the player is aware of, stuff that could be used for cheating. Obviously, game code would be released to the community, while engine code is not. My idea on organization: c:\whatever\OFP2 -main directory, contains engine files, stuff like that c:\whatever\OFP2\bis -default directory, contains BIS code, models, maps, etc c:\whatever\OFP2\mymod -my mod directory, contains mymod code, models, maps, etc Basic scripting in addition to the code release would help some as well. For example, the current scripting system, or even a simpler scripting system, would allow for mappers to create basic stuff in their maps, such as spawning troop formations and moving them around on a large scale, area triggers to kill a player leaving combat zone, simple stuff that shouldn't need it's own MOD. (MOD's could introduce their own unit-states and scripting commands too) ------------------------------------------------------------ While it may be easier to have the weapons/vehicles hard-coded into the game code (Thats what I would want do.  Easier for programming modders), instead of included in separate text files, it would be possible to keep a addon system similar to OFP's through the code release if that was desired. Addon vehicles and weapons could probably work similarly to what is available now.  The addon could be created and distributed with it's own text file describing how it behaves (hp, speed, what OFP has now).  This would allow it to be dropped into non-MOD specific maps and used like addons are now. Again, MOD's could introduce their own unit attributes (something like "wheel durability", for example).  MOD specific addons could then use these attributes, and would probably be placed in the mod's subdirectory to avoid confusion with standard/generic OFP addons. The standard/generic OFP2 addons could be used in MOD's with new code too, simple "default standard wheel durability" fields in the MOD code would fill in new attributes based on the vehicle type (APC/truck/etc). Generic addons could go in a C:\whatever\OFP2\addon directory. This would allow mappers who don't want to learn C++ to easily make maps utilizing non-standard vehicles/weapons. ------------------------------------------------------------ Another point I know someone will bring up. I know that the code and comments won't be in English, but thats fine with me.  I can cope with that. It should be pretty easy to make a program to translate the code if it was needed anyway. Just a simple loop through all the code, replacing 'riffle' with 'rifle'. Repeat with different terms until satisfied. I also know that it might take the BIS coders a couple weeks to change the structure of their code to allow for a partial source release, however, this shouldn't hurt OFP2.  It is being release over a year from now, right?  BIS has plenty of time to make this change... (the sooner the better, of course, but they do have plenty of time...) ------------------------------------------------------------ With a decent partial source code release, we will be able to do almost anything in our MOD's. We could make functioning OICW's, we could allow passengers to fire their weapons from moving vehicles, and use BMP firing ports.  We could make realistic aircraft, functioning AV-8B Harriers, V-22 Ospreys, and more. Want a working aircraft carrier, that you can drive, spawn planes on, reload at, and sink? Realistic parachute physics if BIS doesn't add this, 'sqaure' chutes too... We could make those "Micro-Air-Vehicle" remote control airplanes, and let players stick them in their packs and use them at will, could even add battery/fuel functionality. We could make a decent Mechwarrior style MOD if we wanted, with animated walking Mechs, cool damage models, and more. We could add weather, animals (some people seem to want a "Deer Hunter MOD"), usable trained guard dogs, whatever we want. With some work, we could make highly advanced soldier and squad level AI that defeats the player through tactics, not reaction time/computer advantages. Without access to collision detection/handling code this might be hard, but we could tweak it to allow players to walk around in the back of moving vehicles if BIS doesn't code this for us. A whole lot more would be possible. ------------------------------------------------------------ Partial source code releases are fast becoming standard for FPS games. By the time OFP2 comes out, it will be abnormal for developers to not release some code.  Heck, Relic is releasing source code for their new Homeworld2 game _engine_ (RTS), this was a huge suprise for me... Look at Valve, their success is only due to Counter-Strike. Without Valve's code release, Valve would have crashed, and no one would know who they were. I suggest that you download and look at Half-Life's source only SDK. You'll see how capable it is, without making it easier for cheaters. http://www.valvesoftware.com/hlsdk.htm I'd like to see all the constructive criticism you guys can come up with. Especially people with programming experience:  If I made any mistakes explaining Half-Life or programming stuff, please correct me. Obviously, be careful if you use the quote function.