modemmaik

I wonder, weather the fz in the naming stands for franze, who created the F-18 E/F Super Hornet for ArmA.

An alternative signature process description is available at Bi Wiki. The download package needs the addon itself, signature and public keys. Do not include the private keys for download, but keep it for further addons in the future. Should not be a big problem. Anyways: Well done, hamis

Yeah, those panels from (A.T.R.F.) have the correct size and placement. @Marijus: I checked the maschinegun effect yesterday, and the gun had no effect on the T-72 ERA (aiming at the back of the tank) May be an effect can be seen on the included T-72, because the armor definition is BI original. Meanwhile I have released the latest binarized and signed version on the armed-assault.de forum, so I plan to release the unbin version plus reskins within this week here. Sorry for the delay, but some projects got higher prio. mike :edit: Ups.. I am total confused.. I have already uploaded the 343rdBadger reskin pack DL-link by zShare hosting 343rdBadgers Skins

You surprise me. I assumed that you identify an object in the surrounding / FOV and select a camo according to that information. Never would have imagined, that you access the texture of this object to be used as camo

I noticed this error using ECS + user addons (like RHS T-64, Törnis M60A3). No entry 'bin\config.bin/CfgModels.default' When the following section is added to the addons, the error does not pop up again any more (instruction from this Thread): so far, so good. But I may ask the question: Does this section also have negative consequences? Thanks, mike

Depends on linker's implementation... When he imlpemented a color reassign, the numbers of camos are unlimited, relsulting in a near-to-god-mode. When he implemented a selection one-out-of-n-textures, the camo effect is limmited to the numbers of available camos. But tricky to identify the closest object to determine the correct camo But at all: One of the best inventions I have seen so far, Linker Split :edit: Btw.: Is some kind of transition included...? I always wondered about the kind of best underware when changing to another camo... multi camo underwear??

Incompetent stated this in the ACE public forum: I realy hope that I misunderstand this... but it semms pretty clear

OK, Speed reduction after the climb-phase increases the hit-rate JavTest3 by zShare included: a new test mission (moving targets). Changes: - I have re-enabled the addon's script for event-handling - Changes Javelin ammo to "Javelin ®" - Changed TOW2B climb rate to 10 degrees, cruisealt 10 meters - Added TOW2A mag to the Stryker TOW2B - Added speed-reduction after the climb-phase: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">... if (alive _missile) then { _vel = velocity _missile; _vx = _vel select 0; _vz = _vel select 1; _vy = _vel select 2; _missile setVelocity [ _vx/20, _vz/20, _vy/20 ]; }; Open issues: - increasing the wait time to make it CPU-friedlier - cruisealt should be relative to target's ASL, else the missile would run into a hill, when the targets position is higher than the attackers have fun, mike

I had a simmilar effect on the early version of the T-72 ERA "style". Those effects belonged to misdefined sveto an zasleh sections in the model.cfg. May be a good job, if someone could check this

I think the mando-javelin is included in the Mando Missile ArmA Suite. The package also includes demo missions. @NoRailgunner: Mr.g-c also stated this in the ACE's public forum. So, the flight characteristics colnd be defined by _climbstart=9999 and reducing the _cruisealt. This may also improve the "illusion" of the 2B-impact to explode in mid-air and launching the penetrators. I think the hit ratio of the algrorithm may be improved by reducing the missile speed after the climb/cruise phase, giving the BI-routines a better chance to hit the target in the terminal phase by accellerating in the target's direction via the BI-routines. What do you think? BR, mike Ah, now I got you I try to implement an universal flightpath script, which can be adopted to any kind of lock-on missile existing in game (the lock on feature is needed for the terminal phase, where I give back the tracking control to the original codes implemented). I tried to include correct values taken from the pics frederf provided.

Placing some add vegetation, using the Authumn plants addon, should give it the most european style. You can see the effect on some of the BW-mod vids. I think they used the authum plants on schmalfelden, but it should also be useable on every other island (I have not tested this yet). BR, mike :edit: Ups.. sorry, but there is also a replacement available: Plants replacement

Well... launcher mode access is available using the fired Eventhandler But there should be an alternative. I noticed that ECS included a weapon jam function, which defines a special state of a particular weapon. In our case, there should be a solution to define another state, reflecting the weapon mode, which will be accessible by the guiding script to determine weather the mode is direct or top attack. :edit: When the range to target is less than _terminalstart, the algortihm does not try to correct the flightpath, so for a non-javelin missile, it will be direct mode anyway.

Hi @ all Well, Mandoble alredy released his Javelin, and I count it is full function, as all your addons So, I count this as some kind of test implementation: Javtest 3 by zShare I have integrated support for Extended_EventHandlers by this code: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">class Extended_IncomingMissile_EventHandlers { class landVehicle { class JAV_exclusion_landVehicle { exclude[]={}; IncomingMissile = "if ((_this select 0)==(_this select 0)) then {[_this] execVM ""javshot.sqf""}"; }; }; }; OK, that's the working part I implemented a definition part for the missiles, by the factors - _climbstart: distance to target for climb - _climbfact: Angle to start climb - _cruisealt: Altitude for cruise phase - _terminalstart: distance to target for teminal phase <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">if (_ammo == "hx3_BGM71F") then { _climbstart = 200; _climbfact = 30; _cruisealt = 30; _terminalstart = 80; }; if (_ammo == "M_Javelin_ATx") then { _missile = nearestobject [_attacker,_ammo]; _rangeToTarget = (getPos _missile) distance _unit; _climbstart = 9999; _climbfact = 30; _cruisealt = 160; // missile tries to gain _cruisealt before reaching terminalstart _terminalstart = _rangeToTarget -700; if (_terminalstart < 0) then { _terminalstart = 2 * _rangeToTarget / 3; }; }; Result: Well the missiles fly well... but you will not even hit a house with them I think that I have mixed somthing up in the algortihm, that is why I moved the JavShot.sqf to the mission for better debug capability: The algo has 2 parts: -Wait till distance reaches climb start -climb phase till terminal distance is reached Debug-output: actual climbstart distance actual terminal start distance plus #flightpath corrections <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">//player globalchat format["%1",[_climbstart,_ammo]]; if (_climbstart > 1) then { _missile = nearestobject [_attacker,_ammo]; _rangeToTarget = (getPos _missile) distance _unit; _vel = velocity _missile; _misslepos = getPos _missile; _targetpos = getPos _unit; while { _rangeToTarget > _climbstart && (alive _missile)} do { sleep 0.10; _rangeToTarget = (getPos _missile) distance _unit; _misslepos = getPos _missile; _targetpos = getPos _unit; }; player globalchat format["climb %1",[_rangeToTarget,_climbstart]]; // climb phase while { _rangeToTarget > _terminalstart && (alive _missile)} do { _vel = velocity _missile; _vx = _vel select 0; _vz = _vel select 1; _vy = _vel select 2; _vs = sqrt ((_vx * _vx) + (_vz * _vz) + (_vy * _vy)); _dir = ((_targetpos select 0)-(_misslepos select 0)) atan2 ((_targetpos select 1)-(_misslepos select 1)); _vxc = 1.00 * _vs * sin _dir; _vzc = 1.00 * _vs * cos _dir; // trajection for direct hit: _climb = ((_targetpos select 2)-(_misslepos select 2)) atan2 _rangeToTarget; _count = _count + 1; _climb = ((_cruisealt - (_misslepos select 2)) / _cruisealt) * _climbfact; _vyc = _vs * sin _climb; _vxc = _vxc * cos _climb; _vzc = _vzc * cos _climb; _missile setVectorDirAndUp [[ _vxc, _vzc, _vyc ],[ 0.0, 0.0, _vyc ]]; sleep 0.04; _misslepos = getPos _missile; _targetpos = getPos _unit; _rangeToTarget = _misslepos distance _unit; }; player globalchat format["term %1",[_rangeToTarget,_count]]; }; On the other side, even having a wait for only 40 msecs, the correction for the TOW2Bs flightpath is only called 3-4 times during the climb phase... I am not sure, weather this is enough to reach a defined altitude... but, tomorrow is another day... BR, mike

Hey Q Thanks for the info I just noticed that william1's Flares countermeasures implementation includes xeh support. I hope that I find useful codes within. At least the xeh codes for IncomingMissile should be locateable. BR, mike

So I think the G36 are the BIs ones. New vid including the PzH2000 seems to be online.

Ok, here we go New test version of the TOW2B can be accessed by zShare link Accidentially, I have left some stuff from mapfact in the mission, so Mapfact Misc package is needed to execute the included mission (nothing bad, because good stuff is included in the package) Big credits to Mandobe I analyzed Mando's missile suite and found that the incommingMissile eventhander gives us the target, ammo and the attacker. So this can be used to calculate the distance to target plus identification of the matching ammunition, but we have to set the eventhandler for every possible target Example code eventhandler: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_unit = _this select 0; _x = _unit addEventHandler ["IncomingMissile",{_this execVM "\javtest\javshot.sqf"}]; Which has to be initialized for the possible targets (mission.sqf): <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> class Item1 { position[]={2584.170410,13.881000,2961.166748}; azimut=180.000000; id=2; side="EMPTY"; vehicle="T72"; skill=0.600000; init="res=[this]execVM""\javtest\initEventHandler.sqf"""; }; So whenever a missile is launched at a target, the handler calls \javtest\javshot.sqf: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">//Definitions passed to script _unit = _this select 0; _ammo = _this select 1; _attacker = _this select 2; _target = objNull; _targetpos = objNull; _misslepos = objNull; _missile = nearestobject [_attacker,_ammo]; //player globalchat format["%1",[_missile,_mtarget]]; if (_ammo == "hx3_BGM71F") then { _rangeToTarget = (getPos _missile) distance _unit; _vel = velocity _missile; // normal fly phase while { _rangeToTarget > 150 && (alive _missile)} do { sleep 0.10; _rangeToTarget = (getPos _missile) distance _unit; _vel = velocity _missile; }; // climb phase while { _rangeToTarget > 80 && (alive _missile)} do {... sleep 0.10; _rangeToTarget = (getPos _missile) distance _unit; }; // Terminal phase... }; Result: Well I think not bad Usually 3 of 4 hits. The missile climbs and hits the target, The same code sould be easily adopted to match the javelin data. I hope that using extended eventhandlers capabilities, the eventhandler function for all possible targets could be included into the addon (may be including other possible targets, as Messiah mentioned?), but at the moment I lack knowledge, how to implement this into the xeh functions. I hope that something like this can be implemented into the addon to replace the missions init's: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">class Extended_Init_EventHandlers { class landvehicle { "incommingMissile = _this select 0 execVM ""\javtest\javshot.sqf";"; }; }; I will start to analyze the xeh examples soon, but if anybody can implement this, he/she's very welcome Best Regards, mike

@(A.T.R.F.): I have sent you a PM, including an example normal / bumpmap to generate the "illusion" of a rivet, including correct shading etc. kikill addressed the same issue. This way, you will get a better ingame result with less polys This is not O2-related, but texture related and included in those _nohq textures. BR, mike :edit This wiki-link describes, bumpmap / normalmap.

Sounds good to me Just a little hint: Usually I do not include mounting screws and other little things in the model. A bumpmap provides the propper illusion (check the BI's M1A1 front side turret plate attachment in the m1abrams_1_nohq.paa or the wheels included in the m1abrams_3_nohq.paa). This reduces the polycount.

Woooh That's a beauty. Those ERA looks very good. I do not know your plans for the chassis, but the KMDB T-72AG might show you a modern ERA chassis protection. Keep up your good work

OK Folks, this will be the release version New Features: - T-72A "reskin enabled" included - Flag section included The basic addon includes the model plus the basic definitions (armor, hamis sounds, random numbers, SLA-flag) for a T-72 and a T-72 ERA-style. Those can be used for mission based skins (see example mission included). The reskin addon includes the skins plus definitions for the mission editors containers (I have splitt the skins into different containers to make the mission makers live easier plus having a single designation for the T-72 and the ERA-style in-game.) I plan to release a signed and binarized version within the next days in the addon's complete section (actually the latest signed / binarized version is available @ armed-assault.de forum post nr. 75). Infos to include new skins / modified configs: The reskin-addon can be used to create your own addon: 1) Unpack the addon 2) Define a new addon name (e.g. 343rdBadger_skins) 3) Rename the t72_era_custom_retex directory to the new name 4) Rename all texts "t72_era_custom_retex" to you new name in the config.cpp, textures.sqf and readme.txt 5) Modify skins / config etc. as you need. 6) pbo the directory again and test it This way, you should be able to create a addon without interference with existing variants of this addon. zShare DL-Link T-72 ERA style 1.10 Final unbinarized zShare DL-Link Retex Package Final unbin p.s.: Actually I create a "343rdBadger" version and a Marijus version. I will release those version within the next days... :edit: Ups... download links corrected... pointed to source zShare...

Hi Snoops, this was just a quick and drity test implementation only for the climb implementation given on frederf's pics. I used a time-based implementation, simply because it is easier and I wanted to check, how many corrections are needed for the climb and if the lock remains for the missile I have not located any script that checks the distance to target for a lock-on missile But I will check the MAPfact addon's, maybe they included some code to handle this :edit: I noticed that mandoble integrated targeting etc. into his 2.3 version of mando missiles. I will check, how he integrated this. btw.: Mando also integrated his Javelin version :edit2: I have acutally discovered that mando uses his own target-lock algorthm So I integrated Mr.Peanut's binocular designator algorithm into the script: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">Function binoLOS Mr.Peanut April 2007 Binotarget v1.01 Adopted to tow-launcher by modEmMaik ... _targetpos = objNull; ... // if ( not (isNull _mtarget)) then if (_ammo == "hx3_BGM71F") then { _ds = 0.50; _max = 3000; _offset = 1; _dvec = _unit weaponDirection "FastTowLauncher"; _mpos = getPos _unit; _height = -((_unit modelToWOrld [0,0,0]) select 2); _wpos = []; _gl_north = "LOGIC" createVehicleLocal _mpos; _gl_north setPos _mpos; _gl_north setDir 0; _breakflag = TRUE; for [{_i = _ds},{_i <= _max && _breakflag},{_i = _i + _ds}] do { _mpos = [_i * (_dvec select 0), _i * (_dvec select 1), _i * (_dvec select 2) + _offset]; _wpos = _gl_north modelToWorld _mpos; if (((_wpos select 2)) <= _height) then {_breakflag = FALSE;}; }; deleteVehicle _gl_north; if _breakflag then { } else { _targetpos=_wpos; }; player globalchat format["%1",[_breakflag,_targetpos]]; if (not _breakflag) then { // guide the missile to the target ... Works pretty good, when you point to the ground in front of the target, but when you target a tank direct, the missile gets guided to a point on the ground behind the tank, as if the tank would not exist for the targeting So I consider to integrate a laser into the launcher to be the better alternative. This way, correct guidance should be implementable, but I wonder how the AI might handle it, when multiple attackers laser the same target :edit2: While analyzing Mandobes Missle Suite, the included replacement config used the incommingMissile Eventhandler. This provides attacker and target, but needs to be initialized for every possible target. Yesterday, I have set up a test suite, that includes distance to target calculation and tracking.

I have implemented a test version for a TOW2B Stryker: TOW2B test version link Credits to WGL / ACE Team: I used WGL-Defintion for TOW2A+B definition. Credits to Frederf for his blueprint implementation. Included a simple mission including unmanned target MBT's ranging from 300 to 600 meters. The script includes a simple climb implementation (200ms after launch for a 600ms period), followed by a altitude hold direction. Targeting is performed by BI-targeting routine. I tried to implement an algorithm that does not speed up the missile during climb / terminal: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> sleep 0.20; _count = 12; // climb phase while { _count > 1 } do { _count = _count -1; _launchDir = vectorDir _missile; _vx = _launchDir select 0; _vz = _launchDir select 1; _vy = _launchDir select 2; _vs = sqrt ((_vx * _vx) + (_vz * _vz) + (_vy * _vy)); _vdirect = _vx atan2 _vz; _vxc = _vs * sin _vdirect; _vzc = _vs * cos _vdirect; _vyc = _vs * -0.8660; _vxc = _vxc * 0.5; _vzc = _vzc * 0.5; //_missile setVectorUp [ _vzc, -_vxc, _vyc]; //_missile setVectorDir [ _vxc, _vzc, _vyc]; _missile setVectorUp [ _vxc, _vzc, _vyc]; sleep 0.05; }; // Terminal phase _launchDir = vectorDir _missile; _vx = _launchDir select 0; _vz = _launchDir select 1; _vy = _launchDir select 2; _vs = sqrt (_vx * _vx + _vz * _vz + _vy * _vy); _vdirect = _vx atan2 _vz; _vxc = _vs * sin _vdirect; _vzc = _vs * cos _vdirect; _vyc = 0.000001; // _vyc = _vs * 0.5; // _vxc = _vxc * 0.8660; // _vzc = _vzc * 0.8660; _missile setVectorUp [ _vxc, _vzc, _vyc]; It proves quite nice when attacking static targets, but hit ratio is close to 1:10 at moving targets. I have not included a full readme, because I count this as a test only. You find the "Stryker TOW2B" in the armour container. This addon requires xeh, ECS users have to install Themis compat package BR, mike

Hey Hamis Nice 1 I already fell in love with the T-72 engine sound I will check the other sounds pretty soon mike

Thx Marijus, thx 343rdBadger I finished the new concept today and tests are on the run. I fyou want to check, you find the download links in post #69 in this forum. Actually I have not included Maijus new amunition values, but this can be integrated within a couple of minutes. When all tests have passed, I will post a link to the unbinarized pbo in this thead and release the basic T-72 / T-72 ERA "style" binarized plus keys in the "Mods Complete" forum. have fun, mike

Actually, we are discussing about integration the TOW-2B into a Bradley / Stryker-TOW. Thus this kind of ATGM includes "fly-over", like the Javelin, we considered a "easy"-style implementation: Correction starting after 20ms for every 5 ms for about 1 second period to an angle to ground at 60 degrees. After that period, the TOW should be able to correct it's direction and apply to target direction. This should enable a more-or-less flightpath like a javelin. Open question: Will the ATGM still keep the lock on target, when we manipulate the flight direction?