b101_uk

just a guess One would imagine you would extract the relevant modules from “modules.pbo†in A2/A2OA, then recreate part of the directory structure as in modules.pbo but in the TKoH Hsim folder (so it replicates the file structure of the TKoH modules.pbo) (much like with FM update xml). no doubt there is a .bin file for the TKoH modules (in the TKoH modules.pbo) that will need copying to the Hsim\..\.. folder then you will want to extract the same .bin file from the A2 modules.pbo to another folder location so you open it and can copy the relevant sections of info from that .bin (A2/A2OA) to the TKoH .bin in the Hsim folder. Or some permutation of the above, if you just copy modules.pbo/modules_e.pbo from A2/A2OA into a new addons/mod folder you could end up with either lots of duplicates OR e.g. older A2/A2OA modules overriding newer TKoH modules simply because the older modules are seen as having a higher version number maybe like with some of the version number errors you get if you copy A2/A2OA .pbo en-mass into TKoH.

Something along those lines as implied in the txt in the “BIS_fnc_wpTransport†link.

Use the TKOH scripted waypoint type “transport†and put a “transport†type waypoint on top of each unit http://community.bistudio.com/wiki/BIS_fnc_wpTransport Or use unitName moveInCargo vehicle; or unitName moveInCargo [vehicle, CargoIndex]; in the on activation bit of the waypoint for all the units you want in at that point http://community.bistudio.com/wiki/moveInCargo In all cases there will be NO getting in sequence they will just immediately be in the cargo space

it may be because the lower point of the collective is <8 (default >8 <17.3) in Nightsta1ker mod & Patch2_XML_RC1, which has a strange effect on the collective behaviour as if >8 <17.3 is the pre-programed positive range elsewhere and if its <8 it becomes strange, hence why with the collective fully down the torque reading is higher then as you move it up slowly the torque drops (as if winding off pitch) until it reaches the approximate ~8 reading (collective) which is the lowest torque thus least pitch before rising again, the net effect is a shortening of the range of effective collective movement for the >8 <17.3 or <18 zone making the joystick collective more sensitive to each input. also the range of forward/rearward cyclic is wrong and leads to torque damage and an unnatural amount of lift from the front/rear of the disk at zero collective, both (Nightsta1ker mod & Patch2_XML_RC1) have +20 and -20 range which is just wrong as it represents 40deg, the total degrees of movement is in real life 24deg to 27.8deg total, of which it is made up of forward 17º to 18.5º, aft 7º to 9.3º and also NOT all the forward amount of 17º to 18.5º is available to use its available for the cyclic to trim into during forward flight, a more realistic value and keeping in mind joysticks that something in the range of ~ >9.3º to <14º should be used hence keeping symmetry so when you start the game things don’t race forward/backward when you rise the collective given we don’t have indexed trim-wheels or other indexed trim methods to set take-off trim, instead we have to imply trim when the game starts to be near enough that required for a hover (trade-off between game vs. real life) If you think logically if you are trying to force +20 and -20 range into a blade that only has e.g. 18deg – 4deg = 14deg total or 17.3deg – 8deg = 9.3deg total you are going to come unstuck mathematically before you account for any foreshortening/crossover of that range by collective input vs. cyclic inputs etc. This is why I didn’t change the values in my power update/example and commented the info in and put a note about keeping symmetry assuming people wouldn’t jump for the larger values of symmetry forward/backward like is more appropriate for left/right cyclic. But then what do I know.

thanks for the info, updated Eliteness etc and looked at the rtd_center in o2. seam to be at 1:1 size also.

Something I noticed yesterday which isn’t PIP related (I don’t think) but has a FPS drop, is “free look†(Kpad *) to mouse-look, it seems all the little green icons have their cost in FPS of <10fps. I then found if you like to mouse-look when flying rather than use Kpad 1 – 9 or use of the joystick POV and the green icons or the FPS drop you don’t need, if you go into options > game options you will see a setting for “free-look interaction†which is defaulted to “disabled†meaning every time you have to turn ON free-look AND you get the green icons and FPS drop, if you set it to “default OFF†then “free-look†is by default ON with green icons OFF when you get into a helicopter and if press the free-look button it toggles the green icons on/off. :)

I can tell you the “z="-2.2"†is minus suspension length and minus wheel radius i.e. “-2.2†– “0.2†– “0.1†= “-2.5†then plus a small value for the “sag†of the suspension so would be in the range of ~ “-2.4†to “-2.5â€. it also seam that when no one is in the heli ridged ground contacts are used that I suspect are in the memory lod, when people/player are in the heli the suspension values are used and the ridged ground contacts ignored. as for the discrepancy between the xml and what is reported in O2 if you have somehow imported the heavy heli into O2 then it may have been at a scale other than 1:1 i.e something like ~3.1:1 (~0.3 +-0.02). Out of interest, how did you decrypt the .p3d to get it into O2 to look at? :confused: As I would like to take a look at the exact placing of the rtd_center in the medium heli.

I too looked and did not see it in any .bin's But a memory point called "rtd_center" in a modal may be picked up on automatically by the game engine hence there is no need to add "rtd_center="rtd_center";" to a .bin unless it has some other name in your modal e.g. if yours is called "my_heli_CoG" then you may have to add in the .bin file "rtd_center="my_heli_CoG"; so just add a point called rtd_center to your modal & put rtd_center="rtd_center"; in the .bin to make sure Purely conjecture on my part based on all the modals I have made for other non BIS games where “part names/points/etc†are pick up automatically by the game engine and appropriately used. ;)

The cheapest in terms of cost to FPS vs. look that I have tried is FXAA, the one by “some dude†(inject FXAA), it has txt files so you can tweak settings in them so you can change the quasi AA and sharpness filters, worked well with the TKoH CP with the A2 maps and as far as I could tell the FPS cost was between >0 <1 fps! i.e. less than the standard deviation you would expect if it was running or not over subsequent start-ups of the game. Have not tried SMAA, but I suppose I should. ;)

go into the options > controls, then select all controls from the drop-down list and check your left/right/up/down for the POV hat are set correctly. if they set correctly are but it is still backwards for you, then remap them backwards so it’s right for you, i.e. map rights to lefts and up’s to downs etc.

Remove the hsim folder. Start the game, go into the mission editor, place a “player†then place 3 AI grouped to the player, place an empty light helicopter with 100% fuel and then set the weather to no wind and a sunny day, then save the mission so it can be reopened in the editor after a restart of the game Start the mission, get in the helicopter and order the 3 other AI to get in, and start it up, when ready for take-off set auto-hover to ON, increase collective while looking at the torque gauge to keep the needle on 90% then look at the climb rate in FT/min for amount the first few mins of flight and make a mental note, then exit the game. Reintroduce hsim folder, and repeat the mission with the torque gauge needle on the same 90% point, you should see a significant difference in climb rate and altitude reached in a similar time with the CU3 given the other constants of zero wind, same fuel weight, same passenger weight, same helicopter weight, etc. As for your joystick it may need calibrating as the centre point may have drifted coupled with having 0 dead-zone would show this up, in the controller options it’s possible to see what the joystick is reading when centred by clicking the “show†button, if its anything other than “0†for a specific axis when centred you need to recalibrate (same place you set the dead-zones in game)

a config.bin for the Medium heli, it just drop the hsim folder in the TKoH root like with FM xml files, etc, it has a readme in the zip. will show up under "Emergency services > Medium (Red Air Ambulance)" http://www.mediafire.com/file/k60y5pbqbwy5k28/Medium_heil_With_Red_Air_Ambulance_V1.03.zip

yes, a big screen in the dash, works for sling loading etc.

Unfortunately, the textures repeat the left side on the right side, so you cannot put txt/logo on them unless the letters/logo look the same both forward and backwards.

if anyone wants to try my medium heli here it is, it’s using quasi engine setup temporarily which is basically one engine one engine of twice the correct power and the second engine has a token 1hp/1nm until the torque gauge needles get fixed etc. 90% on the right half of the torque gauge (labelled as engine) is the mast torque at take-off power as the needles are mixed up! There is ~10% deficiency in lift (hover) at MTOW for the given power/torque/weight and rotor RPM, as if it weighs 450kg to 550kg than it should or that TKoH is reporting via the debug console, hence my question a few posts back. ;) :rolleyes: The .xml is heavily commented with info etc. http://webspace.ssesurf.co.uk/~m.todd/Medium_heli_test_1.zip

you have to add the "\HSim\Air_US_H\Helicopters_Light\" part i.e. drop the "HSim" folder in the .zip file into your main Take On Helicopters root folder thus making "C:\..\..\..\Take On Helicopters\HSim\Air_US_H\Helicopters_Light\"

They don’t like to carry guns either, but you can give them a phone! ;)

i have quite a nice flying medium helicopter with all the correct engine, rotor, RPM, torque, blade chord, radius etc etc, but i am just waiting for the multi-engine torque vs. damage vs. gauge handling is functioning properly/logically. AS, have you applied any form of “handicapping†specifically relating to the medium heli to curtail excess performance outside of the xml file e.g. coded in the .exe or e.g. a hidden weight factor, or have invoked drivetrain loss as I need 8% to 10% more lift while retaining the currant loads and it’s not collective pitch but its acting/performing like its 450kg to heavy (i.e. 5850kg vs. 5398kg) in a hover by my maths but once moving its about right :confused:

I think you should change the tail rotor to about +-3 <Controls A1UL="0" A1LL="0" B1UL="0" B1LL="0" thetaLL="15" thetaUL="-27" useExtendedCollectiveRange="true"/> i.e. replicating take-off/ground efect hover trim, as it is you have to much thrust to the left, also the rotor is on the left so works backwards so the thetaUL (upper level) is a higher negative number while the thetaLL (lower level) is a smaller positive number – opposite to e.g. the medium heli with its tail rotor on the right. As centre trim (side thrust balancing torque) would logically be at ~50% to ~60% of the torque load or i.e. sat on the top of ~5ft to 10ft ground effect at ~ 2913lb (~1322kg) TOW, or think of it as maybe how you would leave your trim if you had just got out of your helicopter 5 mins ago and were about to take off agene, it can be just as easy to power/lift into trim as to power/lift out of trim IF you know how you left it trimmed – i.e. to kick a little right in before it goes neutral then adding more power you have to add some left to counter torque. (may also help keyboard uses) also you have done something to the blades i suspect giving them a "range" that is outside what the game will allow as the moving the cyclic back and forth with collective fully down sat on the ground the torque gauge goes straight to 110% ultimately damaging things while little in the way of anything hapaning to justify the torque gauge reading and damage.

If you do not use the config.bin file that was with the xml then the effective power at rotor is too high giving ~450hp vs. ~375hp. So you may want to look into making sure the config.bin and xml are paired up correctly, or not being overridden by something in the Hsim folder if you have put the config.bin/xml elsewhere, as they may be overiden by what is in your \hsim\\\ folder

You need to edit the “config.bin†file for the helicopter you skin belongs So you need CfgConvert.exe (from BIS tools) to go from config.bin (binorized) to config.bin (txt form – AKA: config.cpp) (drag and drop config.bin onto CfgConvert.exe or a shortcut made to it to convert to a txt format config.bin/config.cpp, or onto cpp2bin.bat or a shortcut to it too re-binorized config.bin or to change and binorize config.cpp (txt) to config.bin. You will want to put you skin and the new modified config.bin (that has been binorized) in a new folder structure that mimics the .pbo folder structure. e.g. (using the light helicopter) C:\...\...\...\take on helicopters\HSim\Air_US_H\Helicopters_Light\data\skins†The “\take on helicopters\†is the root folder for take on helicopters that your game resides. You will need to add the subfolders “\HSim\Air_US_H\Helicopters_Light\data\skins†The modified config.bin would go in the “\Helicopters_Light†folder like it is in the .pbo The skin (if it’s the primary one) would go in the “\data†folder like it is in the .pbo. If it a secondary one it would go in the “\skins†folder like it is in the .pbo. From the above you can go to a single .pbo of a unique name provided you can call the path to the original modal file, other textures and sounds without actually putting them in your .pbo, but realy if its just for your own use you are as well forgoing putting it in a .pbo and just using “C:\...\...\...\take on helicopters\HSim\Air_US_H\Helicopters_Light\data\skins†etc

So are you going to change the torque gauge logic and damage logic handling of the combined maxTorque in the config.bin/cpp to a maximum per engine, so the engines attain an appropriate load relative to their torque gauge needle while not reducing the damage threshold of the rotors combined maxBrakeTorque relative to its own gauge needle and actual load, i.e. if maxTorque in the config.bin/cpp is set lower than the rotor maxBrakeTorque in the .xml file. if the maxTorque in the config.bin/cpp was to be changed to a maximum per engine, then permutations of multiplying or dividing maxTorque in the config.bin by the number of engines operating/giving actual load then dividing or multiplying by the maxBrakeTorque (rotor) in the .xml file etc etc etc would yield a relationship factor for engine/s vs. mast torque gauge needles outside of the currant automatic multi engine gauge relationship. Especially since the medium helicopters real world counterpart has 1800hp (900hp x 2, or 900 to 1140HP x 1 OEI) with a mast rating of only 1370hp (~0.761 with both engines working, ~1.522 to ~1.201with just one engine)

for outside of sling loading waypoints etc, have you not got to use bis_fnc_PIP

in the heli "initalization" box set for the light heli e.g. (0 sets off, 1 sets on, numbers >0.01 <0.99 do nothing) this animate ["addDoors", 0]; this animate ["AddBenches", 0]; this animate ["AddBackseats", 0]; this animate ["AddFLIR", 0]; this animate ["AddFLIR2", 0]; this animate ["AddScreen1", 0]; this animate ["AddHoldingFrame", 0]; this animate ["AddTread_Short", 0]; this animate ["AddTread", 0]; this animate ["AddGunHolder", 0]; this animate ["AddMusicUnit", 0]; this animate ["AddMirror", 0]; Medium doors, note R3 is the right 3rd door from frunt, L3 is the left 3d door from the frunt, 0 = shut, 1 = open. this animatedoor ["DoorR3_Open", 0]; this animatedoor ["DoorL3_Open", 0]; if you want to run the doors open/shut from e.g. a trigger you would use the heli "object" name in place of "this" in the trigger.