kenoxite

Yes, I edited the first post a few minutes ago. I also stumbled upon that feature when messing around my control panel. Also, it seems the linking has been fixed. Example: https://encrypted.google.com/search?q=ofp+materials

There seems to be some inconsistencies regarding how the forums behaves depending on if you are logged in or not. I'm talking about things like the "latest post" link directing you to the first page of the thread instead of the latest post if you're not logged. There might be other instances, but that's the one I've noticed so far. I've updated the first post with all this.

I think I know what happened to your images. You wrote them in lowercase and the parser they have used to migrate was surely case sensitive. I say this because all my imgur ones were ported okay, and the same applies to the rest of other imgur ones that I've seen elswhere around here. If you used the "insert image" button in the old forums toolbar then the tags would surely be uppercase, and hence properly parsed. I agree on enhancing the contrast. Anyway, it seems some things have been fixed already, such as the avatars. I will update the main post reflecting that.

Just added that to the 1st post.

@BohemiaBeck: good to hear. I see you've at least dealt with the banning reason thing. About the broken links, this seems to be the move from flashpoint1985.com to bistudio.com all over again. Google still spits out some flashpoint1985 results even nowadays. I've updated the first post with some of the mentioned issues. It seems that menu is now located at the red pinpoint icon at the top left of a thread.

I think this is the root of the problem: The whole OFP subforums section seems to have been badly ported or glitched when doing so. Instead of being a hub of subforums it's actually a forum itself. You can even post there, such as here.

Something is very wrong here. The OFP section is actually a forum instead a hub of subforums, as it should be.

That was some weird phrasing on my part. I mean that you can assign the function to a global variable (and hence load it into memory for the rest of the mission). If you named the sqf file inForest.sqf then you should just write on the init.sqs (or elsewhere, but just once): inForestCheck = loadFile "inForest.sqf"; Now every time you call the inForestCheck global variable the function will be processed. Such as: [getpos vehicle player] call inForestCheck Say you want to know if a location set by a player using onMapSingleClick is in a forest, you would use something like: player onMapSingleClick { if([_pos] call inForestCheck)then{ hint "The position is inside a forest!" } else { hint "The position is not in a forest" } };

lol ruebe This is... OFP! Also, go back to your fancy weather systems with your cheaty engine commands. Here in OFP we have to do it the hard way, or no way at all.

Thanks for the heads up, Akvadakar. And also for the fixed textures, Sanctuary. Replace ww4ext_strykers.pbo in WW4_EXT_VEH with the one found here: https://www.mediafire.com/download/ghb9hp92vh7rs35/ww4ext_stryker_quickfix.zip As the name for the slat.pac has changed to slat.paa ww4ext_matdef.pbo needs also to be updated with the one provided in the zip file, or the slat will look flat and dull with materials enabled. I've also removed a couple faces inside the strykers that were using an inexistent texture, and changed another inexistent one (white_mat_10.pac) with a vanilla BIS one (white.pac).

IIRC in DAC you have to manually place markers or triggers over the forest areas for it to be able to detect them. If you want a more general solution you can use this function: comment{/* IN FOREST Returns if the location is inside a forest. Result in forest corners, borders and between forest tiles is unreliable. Uses measurements of vanilla forests done by Rellikki. Parameters: - Required: * _p: position - Optional: * _v: check for vanilla forests only. If false, glades will also be detected. Default is true * _r: radius. Default is 20 * _s: step. Default is 5 by kenoxite */}; private ["_p","_f","_ss","_z","_nO","_r","_x","_y","_i","_d","_v","_s"]; _p=_this select 0; _v=if(count _this > 1)then{_this select 1}else{true}; _r=if(count _this > 2)then{_this select 2}else{20}; _s=if(count _this > 3)then{_this select 3}else{5}; _x=_p select 0; _y=_p select 1; _f=false; _i=_s; while {_i<_r && !_f} do { _d=0; while {_d<360 && !_f} do { _nO=nearestObject [_x+_i *sin(_d),_y+_i *cos(_d)]; _z=getPos _nO select 2; _ss="emptydetector" camcreate [_x,_y,0]; if((_nO distance _ss)<=40)then{if(_v)then{if((_z >= 18.0418 && _z <= 23.1900) || (_z >= 25.8946 && _z <= 28.5844) || (_z >= 23.4063 && _z <= 24.344) || (_z >= 11.6016 && _z <= 12.7339))then{_f=true}}else{if(_z>12)then{_f=true}}}; camdestroy _ss; _d=_d+30; }; _i=_i+_s; }; _f As stated, it uses Relliki's tree measurements, which should cover the default ones. Also, as it uses nearestObject, it might not return a forest block when the automatic check is done just between two forest blocks. It also has problems with diagonal forest edges. So, it's not 100% reliable, but it might be good enough in most cases. You can copy the body of the function to a, say, inForest.sqf file, load it into memory as inForestCheck and use it as: [getpos vehicle player] call inForestCheck. There's also more arguments you can pass. Just check the comments in the function.

This line in cfgInGameUI: colorText[] = {0.8,0.8,0.8,1}; might be it. But is Faguss you should contact for this kind of stuff. At this point all this must be second nature to him.

OFP units do take the "spray & pray" motto to the letter. It seems that little can be done with the animations then. But if the bullets are shot you could at least take control of them and move them forward, so pray happens but the spray would focus on the direction of your choosing.

IIRC there's no "run and shoot" animations in vanilla OFP. There is in the WW4 and WW4bis mods, though. You can force AI units to shoot towards any direction you want by placing some invisible object in the desired direction and elevation (such as an invisible helo landing marker) and making them target it. With that said, they will revert to the "looking up" stance if they fire at that target or you delete it. This solution requires a lot of micro anyway, and might interfere with normal AI behaviour if not careful. EDIT: In any case, here's a snippet for something similar: _tgt = "HeliHEmpty" createVehicle [_x,_y,200]; ~0.1 _unit reveal _tgt; _mode = _flare; _unit selectWeapon _muzzle; ~0.1 _unit doTarget _tgt; ~1 _unit fire [_muzzle, _mode, _flare]; deleteVehicle _tgt; _unit doTarget objNull; This would be better to be run only on the leader, and then loop through all the units of the group. You should also make sure to only make them fire if they are using their primary weapon, and use the proper muzzle, mode and ammo of the weapon used. You might also replace the custom target with an enemy unit but, for that, you should first keep an array with all the alive enemy units, then check for the closest ones, then check for the ones in front of the leader. Quite a hassle.

I'm not familiar with that mod but, if I understand this right, you want the zombies (or any other placeholder units) to move to a given marker when they spawn. Is that correct? If so, to issue move orders you would use something like: (group zombie1) move getMarkerPos "myMarker" where zombie1 is the name of the zombie leader and "myMarker" is the name of the marker you want the group to move to. If you want to move them to the position of the player you could use: (group zombie1) move (getPos vehicle player) If you want this mission to be multiplayer, you should name the player units first (say, p1, p2, etc) and then use: (group zombie1) move (getPos vehicle p1) or whatever player you want them to move towards You would place that line in the script you use to spawn the units. Anyway, FML might have specific scripts or parameters you can use to specify a custom init line when a unit or group spawns (to set initial orders to spawned units, which is what we're dealing with here). In that case, it'd be better to use that method. As for attacking, make sure the zombies are set to an enemy side. West if players are East or East if players are West. If the zombies are of side Resistance, then you must first set their allegiance in the mission properties (the screen where you set the time of the mission, etc, at the bottom). You would probably want to set Resistance to be friendly to Nobody in this case (just note that Resistance allegiance also affects allegiance of armed civilians).

To change the vehicles, infantry units and weapons used in MFCTI you need to edit the Stats.sqs file inside the Main folder (you have to dpbo the mission first). All the affected global variables you must edit end in "Names", but they are actually "Classes". Infantry units are defined in <side>SoldierNames (westSoldierNames, etc). Vehicles in <side>LightNames, <side>MiscNames, <side>HeavyNames and <side>AirNames (westLightNames, etc). For upgraded units (once the commander pays for it) you need to also edit the <side>UpgradedSoldierNames, etc. The names are similar to the variables from above. Weapons in <side>PrimaryWeapons (westPrimaryWeapons, etc), <side>Sidearms (westSidearms, etc), and all the ammo related global variables. Depending on what you change you might want to edit the stringtable.csv file so the mission uses proper names. As noted before, you will also need to edit most of the files in the Loadouts folder. You will also want to edit the mission.sqm so the playable units, civilian vehicles, etc already present in the mission are of the class you want. EDIT: To change the flags used by each side you must edit the entries around line 45 in the SetTownSideServer.sqs file, inside the Main folder. Anyway, it looks like MFCTI wasn't built with this kind of flexibility in mind. Changing one thing in stats.sqs requires further changes in the same file (related global variables) and others that use the global variables defined there (such as the buy scripts). A single edit can easily spread through several scripts that you should revise to avoid unwanted consequences. The only way to avoid all this would be to create a rewrite of that part of the mission, to make changing unit types more flexible and focused. But that's another whole deal and, if you want to reach that point, you might as well create a whole CTI mission yourself from the ground up.

There's too much lack of death on those NPCs :P Great job with the textures!

Good stuff, =SappeR=. Keep it up!

Patch v1.0.3.1 released! More info and download links in the first post. Changelog: v.1.0.3.1 Logics and scripts FIX: Fixed small syntax error in healTimer.sqs FIX: Fixed CAS and transport support scripts ignoring the passed custom vehicle and crew CHANGE: Fire support scripts can now emulate artillery, mortar and MLRS. Check the updated Extra Features Manual for more info. Infantry FIX: Fixed model path for middle east guerrilla with IED Vehicles FIX: Desert variant of M60 was using woodland model Weapons FIX: Fixed texture paths for some missile models CHANGE: Reduced recoil effects for 7.62 sniper rifles Other FIX: Tank layout/direction icon edited by OFP Aspect Ratio Fix was placed over the tank's unit info area. Now it's placed below it. FIX: Added null and alive checks before applying tracers to units in bn_tracer_red.pbo. This should stop the annoying (but harmless) script errors displayed sometimes when dynamically spawning vehicles. It includes the previously released scripts patch. Patch installer script: http://pastebin.com/DGHjyUYf

I actually don't think you can do anything about it. I also looked into this for my own reasons, and it seems it's hardcoded in the "soldier" simulation. Any unit that uses that simulation will inherit the blood particles on hit, among other features.

You might have noticed a script error pops up sometimes. You can fix this by using this vesion of the scripts pbo: (included in latest patch) The error itself is harmless anyway.

I you mean that old bug then yes, I haven't seen it happening for a few versions now.

Cool stuff, mate!

WW4 Extended updated to v1.0.3! More information and download links in the first post. Changelog: v.1.0.3 Logics and scripts CHANGE: WW4 EXT Logics/FX renamed to WW4 EXT/Time & Weather. Moved the Random time and Random weather logics there. CHANGE: WW4 EXT Logics/Other renamed to WW4 EXT/Player features. CHANGE: WW4 EXT Logics/Unit scripts renamed to WW4 EXT/Unit scripts. CHANGE: WW4 EXT Logics/Support renamed to WW4 EXT/Support. Infantry CHANGE: New models for digital flora motorized rifle, VDV and GRU spetsnaz. Model and textures look closer to the 6B23 gear. DF texture reduced to more realistic sizes. CHANGE: DF GRU now equipped with AN-94 rifles, helmets and balaclavas (they are now more Direct Action focused, leaving recon tasks to GRU partizan or VDV recon). Vehicles FIX: AH-1Z pilot and gunner “get in†positions are now usable FIX: Fixed all the problems related to the commander and gunner hatches for the T72s and T90s (inverted rotation points, incorrect Fire Geo positions, etc). FIX: Skoda Rapid yellow now uses correct model Weapons NEW: New AN-94 GP SD rifle variant CHANGE: You can now autotarget with Vikhr missiles CHANGE: US designated marksman rifle in 1st person model now uses a higher poly version (the same as in A2) Other FIX: Kodiak island: Replaced the buildings that had windows with the windowless ones provided in vanilla WW4. This is done so there’s no alpha sorting problems with WW4 units (units being invisible when behind a window). This means that now this version of Kodiak requires WW4. CHANGE: Revised and reduced section count of several models This version should be compatible with OFP v1.96. If you are using the installer it should automatically replace ww4ext_inf_cfg.pbo with the compatible one. If you are installing all this manually then you'll need to get the v1.96 compatibility patch, rename the file from ww4ext_inf_cfg.pbo.OFP to ww4ext_inf_cfg.pbo and place it in the addons folder inside WW4_EXT. As I suspected, the incompatibility was caused by the inability of the OFP v1.96 engine to preprocess one of the pbos, in this case the infantry one. The patch includes an already preprocessed version of the conflicting file. Kudos to Faguss, who was the main motor behind this fix by providing a little tool that allows to preprocess config.cpps automatically. Also, to krzy, who was the one dealing with all this compatibility issue since the beginning. This version is not a patch, but a complete new version of the main files. This time around an installer is also provided. The installer is able to install vanilla WW4 and all the WW4 Extended modules (main, Cold War and Arctic). This installer will allow you to install the following components: WW4 v2.5.1: WW4 2.5 with patch 1 already applied. WW4 Extended core v1.0.3: Main component of Extended (EXT) that focuses on infantry units, scripts, logics and objects. WW4 Extended Vehicles v1.0.3: All the main EXT vehicles. WW4 Extended: Cold War v1.0.2: Infantry and vehicle units from the 80’s Cold War era for all sides. WW4 Extended: Arctic v1.2: Infantry and vehicle units for arctic and winter islands from the 80’s Cold War era for all sides. It also includes Kegetys' Winter Nogojev and its dependencies. The installation process should be self-explanatory. With that said, here are some highlights of what you'll encounter: You'll be able to choose to install a Low Contrast version of OFP Materials If WW4 was selected to be installed you'll be able to: Apply a custom version of Faguss' OFP Aspect Ratio Fix to the WW4 config. Install the version of the config with radio enabled. Install a performance friendly version of the cloudlets (dust particles generated by explosions, etc). The provided version is the one used by the WGL mod. [*] In the programs folder you will find the following shortcuts: Launch EXT or vanilla WW4. If you have CWA installed through Steam, versions to launch those mods from within Steam will also be added. Shortcuts for all the available documentation, located in the Documentation subfolder. Shortcut to quickly uninstall all the EXT components (including vanilla WW4, if it was installed via this installer). Launching the installer after an installation has completed will allow you to Repair the current installation (by overwritting the selected components) or Uninstall it. If you want to Modify the installation by removing some of the already installed components it's better for you to uninstall first and reinstall again from scratch. The installer was created via Inno Setup with Inno Script Studio. You can find the installer script here. Check it out if you want to create your own version. Use it as a guide for your own installer or just copy the parts you're interested in and change the needed parameters.

My keyboard... it skips keys sometimes. I like to think I type so fast that the electrical signals can't catch up. Regarding the new installer, I've used Inno Setup with Inno Script Studio Wizard to help with the scripting (you don't need to download it separately, there's already a download version of Inno Setup that bundles it). While the Inno Script Studio Wizard helps, you still have to do a lot of work if you want something other than the most basic installer. To help with that here's the installer script I made for this project. Use it as a guide, copy/paste or modify it at will for your own projects (anybody's). Just be aware that the scripting language used by Inno Setup is Pascal... I also have ready an installer for WW4 EXT which is way more involved that that and are planning on releasing one just for vanilla WW4. Those will be released in the following days. --- EDIT: I've updated the zip and exe so the low contrast version also uses the new vegetation material definitions. The exe now places all the program folder shortcuts in an OFP Materials subfolder, just to keep things more organized, and adds a shortcut to play with this addon enabled and another shortcut for the readme. The installer script in pastebin has also been updated with this latest version.