Jump to content

mad rabbit

Member
  • Content Count

    161
  • Joined

  • Last visited

  • Medals

  • Medals

Posts posted by mad rabbit


  1. As I stated in my first post:

    "I know this sounds like an obvious question"

    But it isn't!

    I have the readme for each and every addon I have (a must when your making a CTI).  I also have the damn thing de-compiled so I can have a look at the config.cpp as sometimes the readmes are wrong or do not contain the necessary information e.g. icon/paa picture file paths, animation commands to disable certain aspects of an addon (BAS choppers CAS support).

    Now in regards to the DKM TOW, the magazine and weapon names are provided in the readme but you cannot add these the standard addWeapon/addMagazine way to the TOW Launcher.  Actually I have posted beacuse you cannot add magazines/TOWs at all.

    The Kegs AGS-17 readme does not even contain the magazine/weapon names in the readme.  I had to find this out via a debug hint (did the same for the DKM TOW Launcher by the way).  And again you cannot addWeapon/addMagazine additional mags/ammo the std. way..

    As I also stated in my previous/1st post, these are the only two addons I have ever come across where this is a problem.  Everything else (Fischkopps MK19, VITAPCs ZU23 M1) it is as simple as:

    1) get magazine names from readme.

    2)_obj addMagazine "magazineName"

    NOW,

    if you don't believe me then try and addMagazine(s) or addWeapon commands on these two addons and see for yourself that the magazine count does not increase/change regardless of current ammo amount (full, partial, empty). This has something to do with the way the addon was constructed as every other addon I've come across has one magazine string for every magazine when you check it's [magazines _obj] array.  However these two addons do not as I have stated in the DKM Forums with the link provided above.

    e.g.

    4xTOWs for DKM TOW Launcher yet

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">player globalChat Format ["TOWweaps = %1, TOWmags = %2, TOWammo = %3",weapons _StaticTOW, magazines _StaticTOW,_StaticTOW ammo "DKMM_TOWLauncher"]

    returns

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">TOWweaps = ["DKMM_TOWLauncher"], TOWmags = ["DKMM_TOWLauncher"], TOWammo = 4

    I hope this now clarifies the question and stops the "Try the search engine" or "Read the FAQ" responses.


  2. [Apologises for the double post (i.e. Addon:Discussion sub-forum) but I felt like this would be a more suitable sub-forum due to the nature of the question]

    Does anyone know how to addMagazine/s or addWeapons (if required also?!) to Kegetys AGS-17 and DKM's Static TOW?

    Now I know this seems like an obvious question, but I can't for the life of me figure out how to add extra magazines/rkts to these if they are pre-placed or CVed in game.  

    I am working on a CTI missions and have easily enough done this with heaps of other static defences e.g. FischKopp's Static MK.19 or VITAPC's ZU23 M1, but the standard commands (and a host of other combinations I've tried) don't seem to work.  

    I looked into the config.cpp for each of these 2 to try and decipher whats going on but I must admit addon production and their configs are a bit beyond me unless I am extracting the path to the picture for the in-game CTI menus or correct magazine names.

    I believe I am using the correct names for the mags:

    "KEGags17East" = vehicle and "KEGagsGrenade" = mag/weapon

    "DKMM_TOW" = vehicle and "DKMM_TOWLauncher" = mag/weapon

    but like I stated the standard commands don't work, try it for yourself.  I assume this has something to do with the way they were constructed.

    If someone has figured this out OR better yet the original (Kegetys or DKM) makers can help me with this that would be great!


  3. Does anyone know how to addMagazine/s or addWeapons (if required also?!) to Kegetys AGS-17 and DKM's Static TOW?

    Now I know this seems like an obvious question, but I can't for the life of me figure out how to add extra magazines/rkts to these if they are pre-placed or CVed in game.

    I am working on a CTI missions and have easily enough done this with heaps of other static defences e.g. FischKopp's Static MK.19 or VITAPC's ZU23 M1, but the standard commands (and a host of other combinations I've tried) don't seem to work.

    I looked into the config.cpp for each of these 2 to try and decipher whats going on but I must admit addon production and their configs are a bit beyond me unless I am extracting the path to the picture for the in-game CTI menus or correct magazine names.

    I believe I am using the correct names for the mags:

    "KEGags17East" = vehicle and "KEGagsGrenade" = mag/weapon

    "DKMM_TOW" = vehicle and "DKMM_TOWLauncher" = mag/weapon

    but like I stated the standard commands don't work, try it for yourself. I assume this has something to do with the way they were constructed.

    If someone has figured this out OR better yet the original (Kegetys or DKM) makers can help me with this that would be great!


  4. Hey CCCP great addon! I'm especially looking forward to the new Mi-26 it's looking great. I'm currently using the Beta you released a while back with the side-mounted PK.

    Anyway, I just have one question in regards to the Mi-2 urn.

    Why is the pilot always viewed as sitting above the rotors in the Mi-2 urn (East) but not any of the other Mi-2s? Is there a way to fix this?

    I have tested all the other Mi-2s (Civ, Res, West) and their all fine. I also have the latest verision available to date.

    If you want screenshots of this I can sned them to you, just PM me. Please help as I really want to use the Mi-2 in my upcoming map.

    Thanks.


  5. BUMP!

    A new version of this chopper has been released and it is still great.

    The textures are nice, the weapon interchange system novel and innovative and the foldable gears are fantastic.

    But please, please, please look into the turning capability of this excellent KA-50 release Hawk.

    I would use this version in a heart-beat if it wasn't for this.

    I know you can use the rudder to a much greater extent than any other chopper, but the rudder is only of use when the chopper is not moving with + or - velocity.

    In addition the AI engagement path is now terrible as they try to overcompensate and just fly around in a circle now instead of strafing runs. If you want a sample mission of this I can send you one. PM me.

    Otherwise this helo is fantastic. I don't usually say any negative comments about any addons as people work really hard on them and of course there free, but I really think this is a simple issue to fix and it currently 'hamstrings' a extremely versatile array of applications.


  6. DAMN THAT WAS QUICK bn880!

    Keep the great info coming please, I think this is important topic for problem solving and lag reduction, yes?

    @bn880

    So in regards to the createVehicle issue:

    I should create the vehicle and units (driver etc) local only to the server but with the moveIn command, can that be executed within the same script, or do I have to initiate another script which is local to the both client and server to ensure that the player sees the units move into the vehicle.

    A resource showing which particular 'commands' should be local to the server and which should not would be helpful I think, or does this just depend upon the application of the command?


  7. Hmmm....

    Just found these:

    gamelogics and local effects

    createVehicle in MP

    LI've provided these to show that I have researched this tpoic somewhat and for others to have a look at, but I would still like a better explaination.

    For example:

    -------------

    If I run a script (server only) that hints a msg, does that message appear on every client. In particular I'm using this in the CTI to hint error messages or max vehicle message but if every client is getting this then this would be a bad thing as the enemy would know when the other side has reached max vehicles in this example. Is this right?

    -------------

    I found this thread at OFPEC to be particularly helpful:

    Scripts in MP

    Terox mentions in this thread that you should never trust the client to store important data, and that you should get the client to send it to the server.

    Why is this?

    How do you do this?

    I can understand in some instances why you would want a script run only on the server for example for creating vehicles, but why would you want a script to run only on the player/client and not ther server.

    Doesn't go against the "don't trust clients to store data" thing?

    Wouldn't it just be easier then to not have any ?!(local server) or ?!(local player) things and just let the script run as is?

    Again further explaination would be grateful.


  8. I was wondering when is it necessary to have certain things only happening locally on the server and when is it necessary that every client has these things running.

    I have a very vague idea of what happens during MP OFP games but I would really like a better explaination or to be directed to a link that gives a good explaination.

    In particular I am making a CTI map and I have some trouble sometimes knowing when to make the script run locally or not.

    For example:

    -----------------

    I createVeh a scud (scriptA - local to server only) which is then entered into another looping script (scriptB - global script) which checks for the scuds phase. When the scud reaches a certain phase (i.e. >3) then a wait-time is started and upon completion a scud missle (still scriptB - global script) is created in mid air above the target with end of the scriptB starting scriptC which makes the nuke explosions (scriptC in an addon).

    ----------------

    I remember reading that if you createVeh something that it should only be done on the server (i.e. local localServerObject) otherwise it will create multiple copies of that vehicle depending upon the number of players as each client runs the script. Is this right?

    So if someone wouldn't mind explaining this whole 'local' concept thing to me and how it fits into OFP MP that would be most appreciated, as it would benefit me and the rest of the community as well I think.

    Thanks in advance


  9. This KA-50 version is great! I do agree with 'hide' though that this choper is really hard to turn but it makes sense if you think about what 'Acidcrash' said in terms of the rudder use.

    However a potential problem with this, that I am finding whilst trying to make my CAS script, is that the AI don't use the rudder.

    In other words, AI will normally engage from a chopper in strafing lines across the target. When the AI fly this KA-50 version, the circle around the target as if their trying to do strafing-lines but never quite achieve it.

    I think this can be fixed ex-addon by limiting the chopper speed but it would be nice to see this KA-50 AI friendly.

    Excellent work thoug Hawk this KA-50 is very nice. I especially like the range of weapons, compatibility with Ural Reammo and the fold-up gear. But please make this AI friendly (i.e. fix the turning circle problem) as I realy want to use the KA-50 version to it's full deadly agile capability.


  10. Sorry to say mate I don't have any direct links to this behaviour as it is based on my testing. If others can confirm or discredit this that would be great as I think it needs to be looked into a bit more.

    Most of the links I read up on in OFPEC and BIS Forum were in relation to the AI helos ability to engage infantry.

    From the reading I did 3 main things contribute to this:

    1) Infantry rating.

    2) Helo combat mode, behaviour mode and skill.

    3) Helo altitude.

    Now for the (1) I can't alter it and don't want to as I believe the more an enemy kills your troops off the higher priority he should become. In addition I want helos to engage tanks first which they do, and I already have a knowsAbotu threshold loop within this CAS script.

    For (2) is easy to set and I alter between 'RED' and 'COMBAT' for enagement and 'BLUE' and 'CARELESS' to disengage and return home.

    Now (3) again from my experience is effected by flyInHeight. I tried scripting the whole patrol route within the AO using flyInHeight and positional control (doMove) but found that the helo kept trying to make it's own flight path due to the 'RED' + 'COMBAT' setting. It also was less efficient at enaging tanks and did not fire TOWs from far away on most occassions.

    So as I said earlier instead of fighting the AI I let it run-a-muck i.e. got it to the area, set it to 'RED' and 'COMBAT' then let it chose it's own engagement flight path with a reveal infantry loop based on a knowsAbout threshold in the background. This seems to works best in my experience, the helo even used rockets against infantry in some cases.

    Another thing I found that effected helo inf engagement was:

    4) Helo weapon selection.

    An Mi-26 HALO with a PK is a behemmoth of a helo but is more likely to engage and kill inf due to the fact that it's only gun is the side-mounted PK. This is contrast to the Mi-24 Hind which will fire missles etc at tanks but pretty much ignore infantry, even with the reveal loop. Funnily enough the Mi-24 Hind chooses a flight path that crosses over the inf all the time. The Mi-28AA will engage inf a lot better than the Mi-24 due to a more rotatable cannon turrent and lack of AT missles.

    Funnily enough the helos that best engage inf are also the only ones which are fired upon by an MG inf !

    Again further tetsing by others would be great to confirm or descredit this, but this was my experience and it makes sense at least within the context of my map.


  11. Just been doing some more tetsing with the scripts I've got.

    It seems 'flyInHeight' interferes with the 'LAND' command issued to the helo, again at least in my experience.

    I've tested the non-flyInHeight script, where the paratroopes become pancakes (helo altitude too low for ejection) vs the pro-flyInHeight script, where the helo is at the right altitude for paratrooper deployment but the landing script snnipet that worked earlier now no-longer works.

    Will do some more tweaking/testing but this appears to be the case in terms of the helos landing flight path.


  12. I'm working on a CTI map so I've got scripts coming out of my ears!

    The whole needs to be dynamic which rules triggers out (mainly due to assoc setPos problems with triggers = another thread).

    I'm executing the command within a Paradrop script so the altitude needs to be low enough en route to avoid the radar system employed in the map but high enough during deployment at the DZ so the Paratroops don't die.

    Now your probably thinking, why don't I just use flyInHeight at lets say 60 en route then 100 deploying then 60 during retrun to base.

    The reason is:

    I've been doing a lot of investigation, within the context/scope of my map, into the helo pilot and gunner AI as I've got the whole system wired in the map with a nice GUI, different options etc. This system also applies to the CAS scripts I have.

    I've gone with the philosophy of working with the inherent AI (e.g. using 'doMove', 'doStop' etc) rather than trying to fight it (e.g. 'disableAI', flyInHeight). Now for the CAS scripts I've tweaked it so it all works great, or at least to my statisfaction.

    The reason being is I stopped using some of the CAS scripts out there which adjust the helo altitude via flyInHeight and in my belief/experience interfere with the helo 'engagement' path. With the script I got I basically get it to go there, reveal the targets above a certain knowsAbout lvl and let it run-a-muck on 'RED' and 'COMBAT', whilst making sure the helo stays relatively within the AO.

    This also pertain to the MG on the Paradrop helos as the gunner will not engage properly during an extraction script if you've messed with the helos altitude i.e. used flyInHeight. Therefore, again in my experience, during an extraction the helos gunner on a mounted MG provides better cover fire if the helo is allowed to decend on its own terms.

    This is why I'm trying to avoid using flyInHeight if possible and I was also curious to the application of the doMove command as the aircraft obeys the first 2 parameters within the array you send it i.e. x and y, but ignores the z.

    To quote bn880:

    "...be happy flyInHeight works at all..."

    Disclaimer: This is based on my testing within my map, others may have had different experiences as I have read (feel like I've read the whole forum by now!), but again I say go with what works best, looks good and realistic but fair.


  13. Thanks for the reply bn880 smile_o.gif CoC guys!

    I've looked at this command before and to the best of my knowledge this will only alter the z-axis speed of the aircraft and not make it increase or decrease it's altitude to the desired height.

    Therefore if this statement is correct, this command wouldn't work as it would make the aircraft get to the desired altitude faster or slower, as determined by the z variable in the setVelocity array, but setVelocity would still not address the problem of telling the aircraft to climb/decend to that altitude. right?!


  14. Is there a way to alter the altititude of an aircraft mid-flight temporarily, without the altitude setting being permenant?

    I am mainly working with helo and have tried using:

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

    _helo doMove [x,y,z+120]

    however this does not seem to work.

    I do not want to use 'flyInHeight' because that locks the helo into using that altititude for the rest of the game, and setPos is way too unrealistic.


  15. I've found the best combination to be:

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

    _Helo setBehaviour "CARELESS"

    _Helo doMove getPos _heliH

    Prior to this the helo is in RED and COMBAT. BLUE and CARELESS together definitely makes the helo disengage (at least for my CAS scripts).  And like bn880 stated, you should put a move order after to get the helo on it's way back to base.


  16. Thats sounds like a really good idea Vektorboson, thanks. I could get the gunner of the helo in group B to join group A leader then join group B pilot again. Hopefully this will transfer the targets like you said. The only thing off the top of my head that I think could stuff it up would be unit rank. i.e. gunner rank lower than pilots upon rejoin = erases target list 'retrieved' from group A leader ?!

    This is messy in terms of solutions (flash joining!) and like you said needs to be tested. I'll post the results when I have a go at it. Thanks for the repsonse!

    Here's a question that might yield a more elegant solution:

    How is the target list accessed by the player radio menu [2 (Targets) then 0 (more)] populated?


  17. Thankyou for the quick reply.  

    Unfortunately I already thought of that but it won't work because you have to define what the enemy unit is i.e. this is always changing because in a CTI this can be a host of objects/units from either west/res (if leader of group A & B were East).

    I need to be able to transfer the current list of enemy objects that the leader from group A knowsAbout above a certain lvl (usually listed with corresponding knowledge in relation to knowsAbout lvl in radio menu) to the helo group B.  

    Now if this target list, comprising of all targets including buidlings, was retrievable in the form of an array I could to a forEach command to reveal the units in that array from group A leader to group B helo.

    I don't want to run a script for every CVed unit in the CTI to check whether group leader from group A knowsAbout lvl reaches x = exec of script to reveal to group B helo.  

    I don't want to use triggers because of the bugginess involved with moving them and they are not specific enough to the group leader from A in IMHO.

    I also don't want to use nearest object and an array of enemy inf units as that would be unfair if these enemy units have properly hidden from the group leader from A.

    Hope that clarifies the problem.


  18. Is there a way to tranfer the list of targets (and corresponding "knowsAbout" lvls if also possible) that the leader of group A can see, to the leader/unit in group B?

    I'm working on a CTI map and I need to do this without using triggers (or "nearestObject" as this would be unfair). This is so that helo support units can see the same enemy units as the group leader that called the support, with the same knowsAbout level.

    I noticed that in the default radio menu that a whole list of targets that can be seen by the player is present. I assume that this list also corresponds to the "knowsAbout" level that the player has for these targets as some appear in this menu as 'Man' or 'Unknown'....I might be wrong about the last one...also houses appear in there as well. So if this list/array can be accessed that would solve a lot of my problems.

    Thanks in advance.

    P.S. BAS please contact me as I have been trying to reach you guys for some time now!


  19. Thankyou for that MrZig, very helpful. I had the DKMM Mi28 unPBOed the whole time and never thought to check if the readme was correct. Just took what it said in there as gospel.

    However, I have checked the config.cpp for the BAS AH-60L DAP and the:

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

    BAS_CAScalled = true

    in the the init.sqs should work!? Any feedback on this would be most appreciated. (again BAS contact me pls!)

×