Realistic Javelin mod

[walmis 0]

This addon is made out of mando's javelin mission, I've modified some scripts from that mission and converted to an addon so now it works for every mission.

The javelin now works more realistically and has two fire modes - top attack and direct attack. Also i've made a realistic launch sound.

Required addons: mando's missiles 2.3 and extended eventhandlers.

Download v0.2

Version 0.2 changes:

Fixed scoring.

Fixed incompatibilities with existing mando missile missions.

Smokeless javelin.

Signed.

[-MCF- Frantz 0]

Armaholic news and mirror :

- Realistic Javelin Mod

[buliwyf 4]

Sounds nice.. what about Keys?

[mandoble 1]

Is this some "enviromental" addon that is always active as long as you have the addon in your addon folder or does it need to be initialized by the mission designer?

[Alex72 1]

Nice!

In what ammobox is the javelin?

[walmis 0]

Is this some "enviromental" addon that is always active as long as you have the addon in your addon folder or does it need to be initialized by the mission designer?

Yes, it's "enviromental", no need to edit existing missions.

@Alex[Dev]72

sorry dont know the ammo box, try using addweapon, addmagazine commands

[mandoble 1]

Yes, it's "enviromental", no need to edit existing missions.

Well walmis, I unpboed it and it just have what mando javelin already has (same scripts), so it is 100% uncompatible with mando missile as it does what mando missile already does:

mando_haveiajavelin.sqf

mando_missilesmoke2a.sqf

mando_javelin_mode.sqf

mando_replacemissile.sqf

What you just added is this to the config:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">

class AllVehicles

{

wJav_Incoming="_this execVM ""\wJav\mando_replacemissile.sqf"";";

};

Which means that all the vehicles will have "\wJav\mando_replacemissile.sqf" executed when a missile is incoming instead of any replacement a mission author has already included in his mission (not only for "M_Javelin_AT", "M_Stinger_AA" and "M_Strela_AA", but for any other missile type).

So, making mando javelin environmental ensures it is already incompatible with mando missile missions.

Even more, this addon also initializes mando missile automatically this way:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">

[true] execVM "\mando_missiles\mando_missileinit.sqf";

which will overwrite anyother mando missile initialization present in the mission (the real one intended by the mission author, as this script has several parameters which are up to the mission designer to set up).

[jerryhopper 286]

we've been rickrolled?  

( for the noobs : http://en.wikipedia.org/wiki/Rickrolling)

[metsapeikko 0]

So this is client-side addon, and is multiplayer compatible?

Also, little demonstration video would be quite awesome.

[mandoble 1]

This is just my old Mando Javelin demo pboed into an addon without permission and with a config which will always conflict with existing and future missions using mando missiles.

[andersson 285]

Thats too bad. I like the idea though. Would be nice to have all default missiles changed to mandobles with an addon so I dont need to implement it in every mission.

@Mandoble. Its been asked in your thread before, but it would be nice with addons like this that replaces default missiles without the need of editing missions. Is it possible to change this addon so it doesnt interfere with mandoble missions but still work as intended? Is it possible to make one addon for all default arma-weaponsystems?

[mandoble 1]

Yes, it is possible to do that. But there are some things that, if using mando missile, should be always set or configured at will be the mission designer, not just imposed by an addon:

- mando missile initialization.

- mando missile replacement.

Both of them affects directly to the playability of a mission (which includes also difficulty level related to avoid missiles and the characteristics of the missiles: range, accuracy, etc). All this was designed with the mission designer freedom in mind. The real problem arises when an addon "locks" all these characteristics and the mission designer gets limited to what this addon sets.

[walmis 0]

Ok, i've improved the existing version. Now the mission reinitializes with it's variables, so the values are not imposed by the addon.

Also the replacement works fine, since this addon replaces only the javelin, every other missile is up to the mission's author.

Tried most of the demo missions, everything works fine.

[mandoble 1]

Walmis, 90% of the MMA 2.3 demo missions doesnt use missile replacement. But, for example, Mando Bombs air support missions use it.

To startwith you should move this addon to "beta" and make sure nobody uses it extept for testing purposes until conflicting points are removed. The very first step is to never initialize mando missile by your own, or initialize it after few seconds and only if it has not been yet initialized by the mission itself:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">

// your init.sqf

if ( isnil ("mando_jav_checker") ) then {

Sleep 5;

// If nobody has initialized it yet

if (isnil "mando_missile_init") then

{

/* Note that placing true there forces the init to use MMA addon instead of MMA script suite, which might be what the mission author wants to use */

[true] execVM "\mando_missiles\mando_missileinit.sqf";

};

mando_jav_checker = true;

// mando_haveiajavelin.sqf is already inside mma 2.35 and 2.4, so probably you will not need it for any future version.

[] execVM "\wJav\mando_haveiajavelin.sqf";

};

This about initialization, about replacement you should not force any automatically, much less for all and every vehicle. Actually you have this inside the config so probably you should move that into a script which checks for some condition triggered by a global indicating that the mission author wants to use your missile replacement instead of its own one.

For example:

<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 AllVehicles

{

wJav_Incoming="_this execVM ""\wJav\wjav_replacemissile.sqf"";";

};

};

And inside wjav_replacemissile.sqf first lines:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">

if (isNil "mando_jav_checker") exitWith {};

if (!mando_jav_checker) exitWith {};

Also remove "mando_" there as it is not any of my globals, use jav_checker if "jav" is your tag.

And finally, if you want to have a "safe" version now, proceed as indicated BUT with a modification in the init:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">

// your init.sqf

if ( isnil ("mando_jav_checker") ) then {

Sleep 5;

// If nobody has initialized it yet

if (isnil "mando_missile_init") then

{

mando_jav_checker = true;

/* Note that placing true there forces the init to use MMA addon instead of MMA script suite, which might be what the mission author wants to use */

[true] execVM "\mando_missiles\mando_missileinit.sqf";

// mando_haveiajavelin.sqf is already inside mma 2.35 and 2.4, so probably you will not need it for any future version.

[] execVM "\wJav\mando_haveiajavelin.sqf";

};

};

So it will work if mando missile is not in use for that mission, which would prevent any conflict which this addon in its current stage.

[walmis 0]

That init.sqf from config.cpp is executed not on mission startup, but on game startup.

[mandoble 1]

In this case you cannot initialize mando missile there, if you do any mission using its own initialization will work using yours instead of the mission author one.

[walmis 0]

I think i've solved the problem. Going to upload a new version shortly.

[mandoble 1]

Which of the problems do you think is solved?

- Mando missile initialization overriding correct mission one?

- Mando missile replacement overriding correct mission one?

- Using and renaming other's people work without asking for permission?

[walmis 0]

Which of the problems do you think is solved?

- Mando missile initialization overriding correct mission one? yes

- Mando missile replacement overriding correct mission one? yes

- Using and renaming other's people work without asking for permission? I didn't rename anything, all your files used have proper headers indicating it's your work. I see you're not happy with this, maybe i should keep this mod to myself then?

[mandoble 1]

- So far that it is mando javelin pboed and renamed as wjav.pbo.

But if the other two points are really solved, I might not care about the third one. Now, before posting more incompatible environmental versions, might you explain how the two mandatory points are solved?

[walmis 0]

i've modified the initialization script, stripped it down to the minimum, and now when it's called, mando_missile_init remains false, so the mission can override existing values. As for the missile replacement, if mando_missile_init == true, then it will never replace anything.

[mandoble 1]

What is what you consider the minimum for the initialization script?

Note that if you use mando_missile_init == true to do not proceed with replacement, it simply will not work with missions using mando missiles. This will make your addon "safe" but limited.

IMO your best choice would be to not create this as "environmental" addon, but something that needs to be initialized on purpose in the mission (for example, adding a simple special gamelogic in the mission). This would give you much more flexibility.

[Thunderbird 0]

Quote[/b] ]IMO your best choice would be to not create this as "environmental" addon, but something that needs to be initialized on purpose in the mission (for example, adding a simple special gamelogic in the mission). This would give you much more flexibility.

IMO it would be better to avoid to include 'gamelogics' just to make the 'Already done' missions [including the Javelin] compatible with the Addon in question.

If you find a way to properly avoid the implementation of the gamelogics then it's fine I bet.

Regards,

TB