kenoxite

Hi Circassian, Actually creating a description.ext file is pretty simple. There's no need to send any example. 1. Open the directory of your mission (in <main dir of OFP/CWA>\Users\<yourNick>\missions\<nameOfYourMission> (for example, assuming you use your same nick and your mission is named "CoCUA_test", on Everon, the path would look something like: ...\Users\Circassian\missions\CoCUA_test.Eden\ 2. Right click there and create a new text document 3. Change its whole name to "description.ext" (no quotes). Make sure it ends in .ext and not .txt 4. Open that file with Notepad or any other text editor 5. Copy and paste this line there: #include <CoC_FED\FED.hpp> 6. Save the file 7. Reload your mission if you had it opened, or just launch your mission normally otherwise If you are ever told to change something in a file you don't know about (like init.sqs or stringtable.csv) it'll be also there. And if it's not there then you'll have to create it yourself by following the instructions from above, then edit them accordingly. You also need to do the following in the game editor, although you've probably done this already (the options I mention are from memory, so they might be named differently): - Add the "CoC_Obelisk" game logic (the one found in CoC_UA, in Game Logics). That's the correct one. Ignore the rest. - Add the "Enable FED" logic, also found in the same place - If you are using a unit with a backpack radio you'll have to place the "Enable portable radios" logic to link them to CoC UA. If you're using the WW4 radio you'll also have to add the "Connect radio to CoC UA" logic, found in WW4 logics. - If not you can just put a CoC_radio object (found in Empty -> CoC UA) close to the player unit and grab it yourself once CoC UA has been initialized Hope that helps.

No problem. That was my impression, but I wanted to expand on it as I felt it had an ambiguous intention. Why would be important how would I feel? If you're curious I myself wouldn't feel anything in particular. Maybe a bit proud and curious about what they're going to do with it, as my stuff would fall into the Attribution-NonCommercial 3.0 Unported license (although I actually paraphrase it instead). Particularly if it's something that I created years ago and probably forgot about. Funny thing is that absolutely all the people I've contacted when asking for permission to either use, update, fix or expand something have felt the same way. In some cases I even got told that the permission wasn't needed (although appreciated), as long as I credited them. So "the community" (the OFP community in this thread originally, the BIS community now as pointed by you) consists of a wide spectrum of views on the matter. But I agree that there's a section, and a very vocal one, that regards ownership, attribution and "copyright" of their creations very highly, usually backed up by moderators, which makes it a de facto official stand on the matter. Nothing wrong with that. I was only commenting on the general feeling which I, as a recent contributor, have. Mainly, why I keep asking myself these questions before any new submission: did I forgot to keep track of someone crucial? Will I get another infraction? Will I be suspended? The point is, there's no way to know, but all those possibilities exist. You can either get an infraction for the most apparently innocuous thing or just get a friendly warning and no infraction for editing something by someone else without asking for permission, while others get suspended for the same reason. If we take that inconsistency and mix it with the perceived official stand on attribution, etc, not forgetting the small and not too prone to feedback community of this game... Well, those things don't add up positively if you plan to attract new contributors to this rickety scene. And yes, I also have played OFP since 2001. Yay me, yay you. If there's anything to be proud about that, that's it. That probably only means that we are both too old :) If for some reason you feel like anything related to all this should be discussed further I invite you to PM me instead, so we don't divert the focus of this thread even further.

Well, you make it a big deal of it, that's for sure. Not sure about the rest of the community, although it seems they're in tone with your views. I'm not surprised about a modding community being wary about attribution and ownership, it happens almost anywhere. But here it feels more drastically enforced. And I'm not sure if that's a good thing, considering the already small community, the even smaller active contributors, and the age of this great game. And, for what it's worth, and because your remark could be considered as an accusation of some sorts or a warning, everything I've released has been properly attributed when needed to, and permissions asked and granted when expanding, fixing or modifying the work of someone else. Not because "I should", but because that's common sense and a gesture of appreciation. And if I ever end up forgetting someone (or have already) that's not because I'm a bad person, that's because I simply forgot to keep track of their names. My impression is that that's the reason for this kind of situations in most cases. But I think this goes beyond the scope of this thread, which seemed to focus on the boundaries and use of copyrighted material from outside this community and not on its use and attributions from other members. Anyway, I thought I'd expand my point of view on the matter, as I was directly pointed at.

That sounds fine, I guess. Anyway, I couldn't care less about all this copyright stuff, but in this community all this seems to be a very big deal, and hence my previous post.

SS2 is on a kind of a limbo, but still has a proprietary. An insurance company for that. The story behind the rights on SS2 is a weird one: More info here: http://www.g4tv.com/thefeed/blog/post/713030/the-lost-history-of-system-shock/

Hey all, I'm having this weird issue where I can't assign targets to my gunner. There's no "square" around the selected target nor the "diamond" when the gunner's turret is aligned with it. So, the gunner just doesn't shoot at anything, not even through the command menu (target x ->fire). The only way for a tank unit in the player's group to engage is to disembark from the vehicle. Then in automatically starts shooting anything that moves. That or switch to the gunner position and shoot myself, which defeats the purpose of commanding. Not being a regular tank player this has passed unnoticed by me for a good while. Now I'm not sure if it's default WGL behavior (which would be weird but, well... it's WGL) or maybe I changed something in the config that I can't recall. Anyway, is there any way to fix this?

Thanks guys. I totally forgot about that alternative way to order fire (the ctrl key). Too bad they decided to remove that feature for SP. For MP I'd understand, but they have already vehicles tagged for pvp with extra functions disabled (like the radar). I know they aimed for realism, that's why I like it, but removing the obvious way to command the AI for tanks in SP... meh. Commanding AIs is frustrating enough in vanilla OFP. There's no need to make it even harder. But, well, problem circumvented. Thanks again.

It does work, but very, very slowly. Their server seems to be under heavy stress for some reason.

Sounds great. Good luck with all this!

He means when you place a space or tab before the semicolon while editing a SQS file. For Notepad++ not to think that a semicolon inside, say, an if conditional block was a comment I had to check the "Force line comments at the beginning of line". For the rest of file types (such as SQF) that's not an issue. There you can place comments wherever you like.

Nice one. Yep, that comment behaviour could be better. The workaround I'm using so far is placing the semicolon at the start of the line, and then TAB my way to where I want to place the comment, to keep it aligned. But I think that's a minor annoyance. What are you using then? OFP script editor?

No problem. Apart from what I mentioned, make sure to add the "Enable FED" logic if you haven't already.

Have you added this line to the description.ext of your mission? #include <CoC_FED\FED.hpp> Also, you only need to place the logic obelisk.

kSuppression is updated to v1.2 This version introduces the concept of suppression levels, the ability to suppress nearby units after a kill or a hit and some changes to wait.sqs which should allow the use of rapid fire for suppression. It also fixes the MP bugs mentioned earlier. Compared to 1.1 it performs a bit worse, but it's the price to pay for allowing rapid fire. Now it will wait for two seconds after the first shot before pausing the checks. Then one second of pause and start again. In two seconds you (or any other unit) has time to fire two bursts or make a quite generous sweep with an MG. This also means that for many units almost every shot will be checked, and hence the hit on performance. Also, the new check in suppression.sqs to retrieve and update the suppression level of the unit contributes to all this. If you feel like the performance hit is too high let me know. The suppression levels make suppressing a bit harder now. A single bullet close enough won't necessarily suppress a unit immediately. Now every time a bullet comes close to a unit its suppression level gets higher (MGs and sniper rifles raise this level faster). Only when this level reaches a given limit the unit is considered suppressed, and in most cases will only raise to "moderate" suppression, not "full". This limit is automatically tied to the skill of the unit (80% used), so poorly skilled units will be easier to suppress and for longer periods, but suppressing an "ace" will require a lot of effort. For instance, a unit with a skill of 1 (such as a player) will need a suppression level of 8 and will be suppressed for 2 seconds tops. Apart from that, I've moved some stuff around and removed some. For instance, the fu directory isn't needed anymore (the one in the root, not the one inside kSupp). The init.sqs isn't needed either, unless you have one for your own purposes. The stuff from the init has been moved to kSupp\start.sqs, and kSuppression is now started by a logic in the map editor (which is deleted as soon as ksupp starts). If you want to upgrade to this version this means two things: - You'll have to copy, merge or recreate the new kSuppStarter logic. - You really need to delete all the stuff from your init.sqs related to kSuppression (or some weird things might happen) On the bright side, now including kSuppression in a mission should be way easier. The only thing you'd need to edit is the _wCl var in kSupp_settings.sqf, and only if you use some addon or mod with custom MGs or sniper rifles. Also, the ball particles shown in debug mode will now display three different colors: yellowish for moderately suppressed units (reduced fire rate), red for fully suppressed (lie down and stopped) and green for fully suppressed but skilled enough to be able to move and shoot (at a reduced rate). It's probable that I'm forgetting something else to mention. Make sure you read the changelog in the first post for more info. This will probably be the last version of kSuppression. Any further versions would focus on polishing some aspects and fixing any remaining bugs, and not on including new features.

I just noticed there's an error in suppression.sqs, where the units are stopped and not reenabled again. I'm afraid that was due to some careless copy/pasting when I was moving the stopped block around. You can fix it by finding this line: ?((random 1) > (_sk/1.2)): _u stop true and moving it below this: ?(stopped _u): _st = true So it would look like this: ; Chance to stop unit _st = false ?(stopped _u): _st = true ?((random 1) > (_sk/1.2)): _u stop true Alternativelly, you can just copy this corrected version of suppression.sqs and paste it over your own: ; SUPPRESSION ; PREFERENCES _sett = [2] call loadfile "kSupp_settings.sqf" ; Percentage of the skill of the unit to use to calculate if unit manages to not be affected by suppression ; Set to 0 to make all units being able to be suppressed, no matter the skill _skP = _sett select 0 ; Duration of the suppression effect on the unit (in seconds) _d = _sett select 1 ; Duration of the suppression effect on the unit when suppressed by MGs _mgD = _sett select 2 ; Duration of the suppression effect on the unit when suppressed by a sniper rifle (in seconds) _snD = _sett select 3 ; Show particle above unit when suppressed. For debugging _debug = kSupp select 8 ; -- _sU = _this select 0 _u = _this select 1 _mg = _this select 2 _sn = _this select 3 ?(_mg): _d = _mgD ?(_sn): _d = _snD _null=format["%1",_nullstring]; ?(_u in (kSupp select 0)): exit ; Chance of avoid being suppressed altogether if unit skill is high enough and lucky _sk = skill _u _p = (_sk*(_skP /100)) ?(_p > 0): if ((random 1) <= (_sk/_p)) then { exit } kSupp set [ 0, (kSupp select 0) + [_u] ] ?(_debug): player sidechat format ["%1 SUPPRESSING: %2, skill: %3",name _sU,_u, skill _u] ; Chance of detecting suppressor if not known yet ?((random 1) <= (_sk/1.2)): _u reveal _sU ; Lower skill _u setSkill (_sk - 0.5) ; Force laying down _anim = "Lying" ?((primaryWeapon _u) != ""): _u selectWeapon (primaryWeapon _u) ?(SP): _u playmove _anim ?(!SP): [[_u,_anim],"fNplayAnim","NO_NQ"] call fNSendAll ; Chance to stop unit _st = false ?(stopped _u): _st = true ?((random 1) > (_sk/1.2)): _u stop true ; Keep suppressed for duration _pos = getPos _u _c = 0 _t = 1 #loop _u setUnitPos "DOWN" ; Show particle effect ?(_debug): drop ["cl_fire", "", "Billboard", 6, _t, [0,0,2], [0,0,0], 0, 1.275, 1, 0, [0.4],[[1, 0.7, 0, 1]],[0],0,0,"","",_u] _c = _c + _t ~_t ?(_c < _d and alive _u): goto "loop" ; Unit unsupressed _u setSkill _sk ?(!_st): _u stop false _u setUnitPos "AUTO" kSupp set [ 0, (kSupp select 0) - [_u] ] ?(_debug): player sidechat format ["%1 #NOT# SUPPRESSING: %2, skill: %3, alive? %4",name _sU,_u, skill _u, alive _u] ; Set behaviour of unit to combat if it wasn't yet ?(behaviour _u != "COMBAT" or behaviour _u != "STEALTH"): _u setBehaviour "COMBAT" exit I'm going to update kSuppression pretty soon. That version fixes this, and also adds a couple new features that I'm testing right now. Namely, the addition of suppression levels and the ability of a killed unit to raise the suppression levels of its close allies. The former changes the suppression dynamics quite a lot. All units now will have a built-in suppression level that raises each time a bullet passes close (mgs and sniper rifle bullets raise it more). When it's beyond half total suppression the unit will be in a "moderate" suppression level, where only its fire rate will be affected. Those with suppression level at max will be in "total" suppression, where the effects you already know will be working (unit lies down, etc). I was hesitant until now to use that because of the potential performance impact. It turns out that it does indeed affect performance but not to the degree I imagined, so so far this will go into v1.2.

I've updated kSuppression to version 1.1. Check the "NOTES ABOUT VERSION 1.1" and the "CHANGELOG" section in the first post for more info about what's new and other stuff you should be aware of. This version contains a couple relatively minor bugs in MP. This should be fixed in the next version. As I have the impression that his will script pack will be used mainly for SP I've decided to not delay the release any longer. As always, if you find any bug or weird behaviour, or you have any suggestion, please, go ahead and let me know.

Yes, I thought about that. TBH I did that on purpose to speed up the extraction petition process, as I found myself requesting extraction under heavy fire more often than not. And also to even out the powerful tool that is to be able to trace flight paths. So you had it for insertions but not for extractions (on the other hand, choppers fly higher on extractions to compensate a bit). That was actually a design choice. Anyway, I was planning to rewrite the flight path scripts so they use CoC NS to synch instead of damage values of game logics. That would allow even more freedom when storing data (no 63 units hard limit), so I'll definitely think about this for a next version. I remove binoculars from AIs so they don't waste precious time sightseeing while in a firefight. I guess I forgot to exclude players from that to happen in the respawn gear array (they are in the prepfriendly script). I'll look into that. And when I thought I already squashed that bug... Well, that's unfortunate indeed. That bugs is starting to become unfixable. The problem is, I can't locate it. I know (or think so) WHEN it does happen, which is when the player is driving a vehicle. But I don't know WHY it does happen, as there's no script associated with that with any kind of infinite loop (which is more likely the cause). BTW, the script that lowers the volume of some vehicles isn't the culprit. That was my primary suspect. The only solution, and I'm aware that isn't a solution, is to try to not drive vehicles yourself. Or cross your fingers when doing so. I'm truly sorry about that. That's my civPopulate thingy, which does those dynamic civilian migration things. I was aware of it but thought nobody would care. I see I was wrong :D Luckily there's an easy solution for this. There's in fact two: a) Deactivate civpopulate in the preferences, so the default civ system is automatically used instead OR b) In CCE\CAP\InitialEnemies.sqs change ?(!CCE_civPopulate): [] exec "CCE\Misc\SpawnCivilians.sqs" to [] exec "CCE\Misc\SpawnCivilians.sqs" That way you'll have both civPopulate and the default civ scripts running together. Haven't tested this yet, though, but it should work. Glad to be of service :) And kudos to Drongo69, as this is his mission. I just beefed it up, polished it a bit and added some bells and whistles. Thanks a lot for trying out the mission and reporting back. It's really appreciated.

DrongosToolkitVoices.pbo with corrected volumes: http://www.mediafire.com/download.php?kiro3zbgvgkv6cz As for the click problems, I'm afraid that had nothing to do with CAS or other onmapclick scripts interfering with it. I had problems with that just from the start of the mission. The only solution I found was to switch to the camera of another squad and switch back. That sometimes helped. Anyway, it was a weird issue.

Direct link: http://web.archive.org/web/20090502024907/http://www.downloads.thechainofcommand.net/zips/CE2Editing122.zip More info: http://web.archive.org/web/20090502024907/http://www.downloads.thechainofcommand.net/ce2_v1_22.htm Both are from archived versions using the Wayback Machine. Use that site to browse the rest of the CoC site. All the files and pages should be available there. CoC homepage (archived): http://web.archive.org/web/20090518092134/http://www.website.thechainofcommand.net/

Yes, it actually works pretty well. Units spend way less ammo for the same suppression effect. You have made me realize that the extra settings I've included for this script pack should be expanded. So, I've added more predefined configs in the "_extra_settings" dir. It now includes: WW4 WGL Laser Weapons pack Russian Weapons Pack (ORCS) LSR+RFWP (those two above combined) JAM OEF+WGL Lost Brothers Tonal PLA VTE SEB UKF OFrP FFAA+Finul DOWNLOAD extra settings: http://www.mediafire.com/download.php?v5ovaejot5vn48e I've also noticed there's a couple errors in the pack. They're quite minor and shouldn't affect any functionality, so I'll wait a bit before releasing a new version.

Good to hear that :) Also, let me know if you find any bug or broken functionality.

Hi all, I've updated the WW4 mission to 7.2.3. This version should have fixed most, if not all, the bugs present in 7.2.2 (which were plenty on the MP side). It has been tested locally with a listen server and 2 clients and a dedicated server and one client, also locally. I'd have wanted to test it also with a listen in real MP with another human being, but RL stuff keeps making that impossible. The mission comes now in the default version (same as 7.2.2 but with bug fixes) and a new one with rucksacks integrated. Please, if you get to play this and find a bug or any kind of weird behaviour don't hesitate to post here and let me know. Have fun! CHANGELOG beta 7.2.3 - CoC Network Services (CoC NS, using the one included in CoC UA) is now used extensively for server-client sync. - Most strings moved to stringtable.csv, so they can now be easily edited and localized - Fixed "lose" debriefing not showing up - Fly altitude of CAS units lowered, to make sure it's compatible with most addons (previously some units didn't engage due to high altitude) - Added custom init files to infantry and vehicles, which can be used to init whatever you want to those units whithout having to edit the core scripts - Modified option to "skip nights" feature, so it can also now skip day missions - DSAI reduced during nighttime - Most Faguss Red Tracers dependencies removed from the core files, as dedicated servers can't run that addon. The original tracers by BN880 are suggested instead. - Mission success, failure and abort messages properly displayed now on clients when using a dedicated server - Added option to make enemy infantry and vehicle kills grant only Command Points, without advancing the Operation Progress. - Buy Artillery Ammo is now handled by the server - Aand all the rest of the broken stuff in 7.2.2 should be fixed

Hi all, I've been trying to find the first release of Lost Brothers but so far I haven't been lucky. The reason I'm looking for that is that I seem to lack something that defines the "LoBo_125Gun" weapon, which is used by the syrian T-72s (and others, I guess) and therefore I can't use those units. I've found and installed addon packs 2 and 3 (consecutively) and the syrian/jordanian pack after that. According to the readme that's all that is needed (actually pack 2 wasn't mentioned, but I installed it anyway after the first error). So, my guess is that there's still something missing from my install, maybe something from the first release. That's why I ask here. Any help on this would be appreciated. Also, sorry if this isn't the right place for this. -- EDIT: I found the 1st addon pack. It turns out I skipped that entry in the dozens available at ofpr.info/gamepark.cz. Unfortunately that didn't solve my issue. I guess I'll start a new thread somewhere else, as I'd really love to be able to use all the units. -- EDIT2: Nevermind all this. I screwed up and overwrote the LoBoammo.pbo file with an older version. Everything works as intended. Sorry about all this. As an addendum, maybe this will help others: While the lostbrothers.com site is down, you can still access it through the wayback machine: http://web.archive.org/web/20110202201822/http://thelostbrothers.com/ And if you ever look for the Lebanon 1.3 and Sinai 1.5 maps, here's the correct link: ftp://ftp.ofpr.info/ofpd/mods/Lebanon1_3Sinai1_5.rar

Thanks for the sshots. I've been orbiting east riflemen like a crazy moon for a while now and I haven't found that glitch. Maybe I haven't managed to find the "sweet spot", but my bet is that it's something related to your WW4 install. Now, you have to decide if the glitch is annoying enough to create a clean install of WW4 and try again or not. Also, just in case you didn't, test that again with only the rucksack addon and WW4 running. Maybe someone else can bring some light on this kind of glitch.

No, the original addon isn't required. What unit class is the one that is giving you problems? Basic WW4 east rifleman (motorized infantry rifleman)? Does the problem show in the demo mission from the zip file in the first post or are you using a custom script? In any case, all the needed textures are packed in the pbo, so if you can see and use the backpack in some units it should show and work the same for all the rest. Have in mind that the class of the unit shouldn't affect how the backpack is displayed at all (be it a rifleman, autorifleman, etc), as the backpack itself is always the same. Try to re-download the file and replace the one you installed with that. Maybe it got corrupted somehow.