snYpir

Thanks, fixed now

Rgr, we know about the snow problem - see the ecp page for a fix. The INQ config and ECP-compatible JAM are now available from the ecp page: http://www.ofpec.com/editors/ecfg We will have a new release out this weekend. This new version totally revamps the mod with improved, well, everything ;) Keep those bug reports coming!

Will check it out. There is some tiny bugs in that config, please use this one instead. The ECP page will be updated with this later tonight. If you disable a feature then that feature won't initialise, minimising performance drain. The most processor intensive features are blood, fire and explosion effects. Bullet whiz may also cause a slight slowdown when people fire on slower systems. AT backblast, chopper dust and weather effects don't use much processing power. Hope this helps!

A new release version is approaching! The team has been working hard at putting the 'polish' on all our effects scripts. Here's some of the things to look forward to: [*]Reworked config.bin explosions [*]HALO accessable by all units by default [*]New island detection system, that actually allows you to add your own islands! This means that snow, for example, will work either across a whole island or only on snow-capped peaks. [*]Working lighthouses [*]Realistic explosive ordinance For the first time in OFP you'll be able to use grenades like they are used in real-life. Advanced scripting is used in conjunction with line-of-sight calculations, meaning that you can now hide from the previously devestating shockwave! No longer will shrapnel from grendes penetrate walls or objects. You'll no longer have to 'reload' different types of grenades (smoke will be accessable by another space-bar hit just like when you change weapon firing rates). In addition, grenade launcher rounds won't become live until after a period of flight (as per real life), and all grenades are fused (not exploding on impact). And to top it off - grenades provide a suppressive effect (that will be combined with ringing in the ears once Zay finishes the sound). The new release will be a huge enhancement over the current. Hopefully it will be out by the end of the week. Regards!

The version numbers increment differently for each component. This is because we have different people working on different components. The main version.txt file should be used as an overall guide to changes. We have a seperate folder for effect sounds so to speed up the process of updating the dev effect addons zip. Performance degradation? I doubt it... the hard drive will be accessed just as quickly regardless of path I assume...? We didn't know about it ;) Will check it out in due course.

Don't forget that ECP already has a dynamic range (much improved) config if you want it. The others will come. If you want to join our team, plz send me an email

Hi all. A few of us have got together at OFPEC and built the ECP (Enhanced Configuration Project): http://www.ofpec.com/editors/ecfg/index.php There have been a few problems with custom addons not working, and this is because of the way that the EventHandler class is handled by subclasses. If you define a new class with an eventhandler, say MyBoat, as follows: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">class MyBoat : Ship { class EventHandlers { fired="hint {bang!}"; } } And then you define a subclass, with some other eventhandler: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">class MyBoat2 : MyBoat { class EventHandlers { hit="hint {ouch!}"; } } The initial fired eventhandler will not be inherited by the subclass (it is replaced with the new definition). Now the ECP defines an eventhandlers superclass called ECP_EventHandlers. To get your addon to work with ECP events you will have to do this: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">class ECP_EventHandlers {}; class cfgVehicles { class MyBoat : Ship { class EventHandlers : ECP_EventHandlers { fired="hint {bang!}"; } } } Now my question is this: would addon makers mind supporting ECP in this fashion? The addon will work without or without the ECP being present, and all ECP effects would work on the addon in question (except for those that launch with the fired EH, in the case of our boat here for example). Thoughts? Note that this will work from version 1.04, the current version 1.03.

GMR explosions - TJ is working on explosion mods at the moment, and he has some completed very impressive mods. INQ weapons - yeah, we'd be open to including this. Can you perhaps send me the config? (call me lazy, but we are all very busy dudes). What advantages does it provide? morpj97@hn.ozemail.com.au. Weather - bear with us, it is early days yet. At the moment snow is seperate from random weather, however eventually it will be integrated (with the island detection script as well). Finally - if you make a change that you think is pretty sweet, plz email it to me. We are a free-flowing mod and fairly easy going, so if you wish to help out, please do!

As per the ECP page, we are fully open source. The 'how to build your own mod with the ECP as a backbone' tutorial is still to come. We welcome ideas, scripts, and even critics ;D We are all about trying to push the game to its maximum potential, so please email me if you have ideas. Suggestions as to how to implement ideas would also be very welcome

We will be adding new animations, all in good time

Bascially, if your addon doesn't use any eventhandlers, the following effects will be automatically enabled: [*] Blood [*] Explosion effects [*] Burning vehicles [*] Bullet whizzes [*] Anti-tank weapon backblast And a bunch of other stuff... That link above has the full listing, and more are added all the time. If your addon defines it's own EH, then none of the above will be availble unless you do: class EventHandlers : ECP_EventHandlers { etc. You would put in 'class ECP_EventHanders {};' just before the 'class CfgVehicles' line in your config.cpp. Ie it doesn't go inside any other class. And then you'd put 'class EventHandlers : ECP_EventHandlers' actually in your vehicle class definition.

Jesus, you go away for a few weeks and the ECP thread gets a couple of thousand replies. Well done to RED for getting it out there. This is a very 'developmental' sort of thing, and with every release there are big changes happening. We are seperating Dynamic Range and ECP in future releases, all of which will be available from the ECP page at OFPEC: http://www.ofpec.com/editors/ecfg/ But yes, we understand people don't want to download huge files every time so we'll be catering for both as you suggested esti_the_big. 1.04 will be released by the end of the week, and can be thought of as the first 'stable release'. Such is the nature of OFP editing eh? regards

Got lag? In your init.sqs file enter the following: blood_object_maximum = 200 (or smaller) blood_particle_spawn_chance = 0.5 (or smaller) blood_particle_number = 25 (or smaller) See the readme.txt file for more info Since the OFPEC ISP went down we found ourselves with nothing to do, so a few of us got together and made a Blood Addon for OFP 1.90 and greater. WARNING!!! This addon seriously ups the 'gore factor' in OFP. It is not recommended for use by children under the age of 15. The authors take no responsibility for this addon; it is meant to be used by adults. The authors ask mission makers to include a warning similar to this in missions that utilise this addon. Nagual kindly posted a screenshot below Let me describe what happens: [*] Unit gets hit [*] Blood particles spray from the exit wound, opposite to the direction of where the unit was hit from [*] Blood textures are spawned on the ground where the particles land Also, I haven't had time to play with the various settings I have put in there to create the most realistic looking blood spray patterns. No scripting is required, all you need is one trigger to implement the blood effects. I think you'll find the effect is worth it - the screenshots don't really do it justice. Features: [*] Blood spray when unit hit [*] Bleeding [*] Damage from bloodloss (requires blood_bleeding_bloodloss_disable = false to enable) [*] Multiplayer compatible Updates: 1.4 [*] FINAL! [*] Reduced the slight lag each time a blood spray is initiated [*] Added new variables for blood z velocity, removed blood_particle_vertshift [*] Added a new variable (blood_particle_spreadfactor) which determines the probability distribution of blood in the spray [*] Added a new variable (blood_particle_color) which sets the colour of the blood spray 1.3 [*] Big code changes to make blood splatter more realistic (more blood closer to the casualty, blood splats now happen exactly when the particles hit the ground). Still not as efficient as I want it, so wait out for 1.4... [*] Added 'blood_bleeding_life' - sets how long 'bleeding' objects remain before disappearing. [*] Many defaults changed to make the blood splatter and bleeding less processor-intensive and more realistic. [*] A list of objects for bleeding can now be specified (and the actual object chosen is randomly chosen). [*] You can now specify damage from bloodloss (must set blood_bleeding_bloodloss_disable = false) to enable. [*] Different decrypted config.bin file now utilised as required (see Advanced Installation below). [*] Parameters to blood_init.sqs in config.cpp now work as expected (use the new config.cpp as per Advanced Installation). [*] Multiplayer works (blood splatter, bleeding and damage from bloodloss). No in-mission changes required, and the seperate 'server' game logic unit is not required. [*] Blood objects updated by Asmodeus. 1.2 [*] Added support for blood to be defined in a decrypted config.bin file (see Advanced Installation in the readme). This allows blood to be enabled for ALL units in ALL missions and campaigns. [*] Dripping blood now has a minor random position, and comes up through the ground rather than simply appearing. [*] Default maximum number of blood particles reduced to 400 to reduce lag. 1.1 [*] Units now bleed constantly after being hit. The amount they bleed depends on their damage. At the moment the 'bleeding' is simply a blob of blood on the ground. This is in early development - I really need some realistic looking blood for this (anyone want to volunteer?). [*] Moved all initialisation into blood_init.sqs - You'll need to update the 'On Activation' field of the blood trigger (copy the line from the readme below) Download: [*]Readme [*]OFPEC_Blood.zip [*]Blank decrypted config.bin files (1.90 and 1.91 - use at own risk) The blank config files are not needed if you want to implement blood on a mission-by-mission basis. I am still willing to add new blood objects. If you are a Oxygen guru and would like to help out with this project, please put together either blood puddles or chunks and send them to me. Authors: [*] concept by Igor Drukov [*] scripting / PBO compilation by snYpir [*] default blood objects by Asmodeus Known bugs: [*] Blood from an explosion sprays away from the unit that threw the grenade, not away from the explosion (can't be fixed) [*] Utilising the decrypted config.bin modification method does not work in multiplayer (will be fixed when the Enhanced OFP Configuration Project is released)

OFPEC is always happy to host addons (addons submission) During submission, authors can select there addon as being 'AAE compliant' (using the AAE installer and also using an OFP tag). At the Addons Depot, AAE compliant addons are marked with the following image: Remember: addons can be downloaded by the public as soon as they are submitted, but they are not 'released' until staff review them. We are still happy to host non-AAE compliant addons, of course.

But the init eh is not fired at all on client in MP, no?

In the addons depot we now recognise AAE compliant addons with an image: See here for an example. But the image is fairly lacking in quality because Tigershark made it (sorry dude, it's the truth). Two questions: a) Can someone plz email me (morpj97@hn.ozemail.com.au) that 90 x 30 AAE image discussed above, and b) Where do i download this BETA installer? appreciated.

In the addons depot we now recognise AAE compliant addons with an image: See here for an example. But the image is fairly lacking in quality because Tigershark made it (sorry dude, it's the truth). Two questions: a) Can someone plz email me (morpj97@hn.ozemail.com.au) that 90 x 30 AAE image discussed above, and b) Where do i download this BETA installer? appreciated.

Back to the original problem... ;) We want to run a script for every unit in a mission right at the start, regardless of their class, without a trigger. This counts out the fuel eh because it is dependant on simulation. Anyway, we have concluded that it is near impossible to do this. If anyone has any ideas, plz share ;D

Myself and a few others are working on a little project, but we have MP problems. We want to execute a script automatically for every unit in the mission, without doing anything to the mission. Obviously, in order to do this, for every mission, you need to run a script for every unit in a given mission right at the start via the config.bin file. We have been doing this via an 'init' eventhandler defined in the 'AllVehicles' class (calling a seperate script). This looks as follows: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">class AllVehicles : All {   icon="unknown_move";   class EventHandlers   {      init="_this exec {somescript.sqs}";   }; }; The problem is that in MP the init eventhandler doesn't fire on clients. The fuel eventhandler workaround doesn't suffice either, because i need this to work on 'Man' class objects as well that don't have fuel. I assume that this is some sort of anti-cheat mechanism. It is really screwing me over, though. I know that it is common knowledge that the init eventhandler doesn't work on clients in MP. Anyone know of a work-around? I need a script to run for every unit, every mission, automatically. I am all out of ideas Edit: Well, perhaps I should have searched first. Looks like what we want to do in MP is impossible. This is a bit of a tragedy

If OFPEC can help out with anything - webspace for forum boards - let me know ;)

Hard-coded config.bin changes cannot be un-done or modified. The settings file will only be for the various scripts used in the mod - this is all of the effect and MP scripting.

actually, I take that back. you can call a script in a mod directory outside a pbo. u learn something new every day, eh...

Every effect and script can be turned on and off by mission designers through publicvariables. Because we don't have a way to read straight text files (everything has to be in a pbo) it is a little harder for the average dude to adjust settings for the mod as a whole. At this stage we expect to have a single 'settings' addon that can be easily modified de-pbo'ed, modified, and re-pbo'ed by anyone who wants to change settings. Settings set by mission makers take precedence, followed by those in the settings addon and finally the defaults set by the mod itself.

;D We have implemented alot of effects, however they are still in beta testing and some authors still haven't been approached for permission to release their work as part of our mod. Everything goochy that has ever been seen in an effect script will be implemented. The most popular MP scripts will also be implemented. We need to know, however, what scripts the 'community' wants to have automatically run. Remember that these scripts run 'outside' the mission, and can use no in-mission triggers, markers etc. Any ideas?

Cheers Zay. Good idea about the blood trickle out the front - didn't think of that ;) You're right about the annoying pink mist that BIS use - I don't know where it is defined. I imagine it is in the simulation definition for 'soldier', which unfortunately we can't see. Myself and a few others are working on an effects mod, and that's where blood 1.5 will appear. Between now and then, I probaly won't do much more work on this (all outta time) ;)