Jump to content

C6_Hellfrog

Members
  • Posts

    387
  • Joined

  • Last visited

Personal Information

  • Location
    france
  1. Fantastic work ! Excellent for shoppers and no MFDs old planes... And for pedagogy to help new pilots... I tried that many years ago with DCS-BlackShark whitout success... (After years out of DCS, waiting to comme back after pc upgrade next year and on reflexion about re building very old pit ... therefore reading forum... and found your thread.) I would be very pleased to see an example of your lua edited script. specifically for vertical strings ! Hey, at least one people is interested in your work !
  2. I stopped using DCS since 2 years because fed up with continuous update and mods maintenance and lack of time. But looking at 2.5 release to go again. I have 3 screens 1920x1080 with crossfire 2 rx280 I had best results with 1.5 than 2.0. So if you say 2.5 performs equivalent to 1.5 it means 2.5 is a progress relative to 2.0. (Even if crossfire optimization is not good, relative to AMD drivers mainly) Are you sure about that asset ?
  3. editing key bindings won't work for now on SA342L because of new dll, different from one used by default.lua in SA342M in previous versions for direct input it should work
  4. for the sa342L in 154 have a look at DCS World OpenBeta\Mods\aircraft\SA342\entry.lua
  5. won't work on 154 SA342 L because of different dll. confirmed by dev team.
  6. has anyone already done missing bindings for SA342 L variant (weapons ...) ?
  7. realistic settings on flight model from 1.53 update cyclic inputs are VERY sensitive, as for rudder I have a warthog basis with extension DIY is 35 cm height, and usually cyclic moves are in a circle less than 10 cm diameter in maximum, very often 1 - 3 cm is enough... and rudders inputs with a mfg crosswind is often a few mm press, at some times I go to a 1/3 or pass a 1/2 of length of the possible move, but rarely, except in very abrupt manoeuvers you have no interest to try before you get familiar with the flying another commonly encountered error is often people are making over corrections in inputs and don't wait some 1/4 to 1/2 to 1 sec of delay before response to the inputs... you have to be very gentle with that subtil "demoiselle"
  8. the thing which has the most impact is if you turn off the gyro stab... then the gazelle becomes much more difficult to control...
  9. campaign bug has already been advised... a new update to correct that is WIP, but builder need only some time (people working on that are volonteer, they have their own life and job, and simply cannot have all the needed free time to correct everything immediatly), and then, when files are sent to DCS, it depends on when a next update is released to public. be patient way to go while wiating is to launh mission one after one from in the folder campaign they are (navigate to DCS World...\Mods\aircraft\SA342\Missions\FR (or EN) \Campaigns to find them in DCS mission choice window) EDIt : Nicolas was faster than me... (go work on miz and not wasting time on forums ! lOl ! )
  10. I can propose you a very much more complicated way to achieve that, with a very different structure of programming teached by ivanwfr many years ago on those forums once you understand the architecture, it is very powerfull general rules : you define global vars for each btn status you map the btns using these vars and a function call in the main{} statements of your main tmc file that wil use MapKey() and your vars to map btns on the stick (same for throttle) then in the main{} of your main tmc you can either use functions call or direct vars editing to have your vars updated to do what you want for your that specific tmc mapping will do using functions you gain a great freedom in programming using those definitions you can map what you want but it will destruct directX mapping in DCS, unless you use a layer reserved for DX definitions for detailed infos search past years forum for ivanwfr posts, credits to him some example in main tmc use include and path to a js_declare.tmc (same for throttle) include "js_declare.tmc" in the js_declare.tmc you will have something like that (definitions are in predicate part to be globals, empty function is needed for to read the definitions on initialize via that function call from main tmc) int H2D_DI=0; int H2D_DO=0; int H2D_MI=0; int H2D_MO=0; int H2D_UI=0; int H2D_UO=0; int js_declare(){ } and so on to declare vars used for btns mapping... in main tmc use include and a path to a js_map.tmc include "js_map.tmc" in which you have a function that will execute int js_map(){ MapKeyIOUMD(&Joystick, H2D, H2D_UI, H2D_UO, H2D_MI, H2D_MO, H2D_DI, H2D_DO); } call that function in the main tmc in the main section as an initialization runtime int main(){ js_declare(); } then directly in main tmc and main section, or via a include of a more specified tmc update your btns declarations vars to define the action you want them to do maybe a macro, maybe a pulse+USB statement or anything you want... as a function call... from there you can define a function call that returns the 1st btn status, or easier a function that updates and stores that status in a flag by example to do that define that flag in the main tmc file and in the predicate to have it act as global var : flag_Btn1_Pressed_ForTime = 0; int main(){ btn1_ioumd = func_flagBtn1() ; btn2_uiomd = func_Btn2(); } then below main section of main tmc, or in your specific tmc file declared with include add your functions something like int func_flagBtn1(){ return TEMPO(0, EXEC("func_flagBtn1True();"), 800); } where 800 will be the delay in msec you want 1st buton to stay pressed you can replace 0 by any input you want your btn press to produce at the same time then you will have int func_flagBtn1True(){ flag_Btn1_Pressed_ForTime = 1; } then you can proceed the same way with btn2 define a func call with the tempo statement for the second delay I you don't want consecutives delays ( because that way you 'll have btn 1 for 800 msc then btn 2 for ... msec as explained below) but at the same time delay use two flags and another function in the event handler as proposed previously that will check the both flags status if they are true at the same time and then from that condition, you can return to what you want... another function call, a macro, and so on... don't forget to reset your flag to 0 at some conditions... so basically : btn press is relative to a func call to update global vars = flags how to have the flags updated after a maintained delay of press : use TEMPO statement in the above funcs to avoid defercall and sleep problems how to check your flags : either call a fucntion that tests the flags in the event handler or either (the better) use that test from one function call depending on your mappings logic and what you want to do with it... cannot have it in mind for you... one point to keep in mind : if using sleep instead of defercall, you'll down any user key input down to 1-2 msec... always do the simplest way: basically for you the shame is btn1 press : tempo : flag1=1 btn1 release : flag1 = 0 btn2 press: tempo : if flag1==1 then flag2 =2 btn2 release: flag2 = 0 no need to test flag1 and flag2 continuously, only check flag 1 when you are in conditions flag2 becomes true except you have to take care of the orders of your presses : if you press btn2 before btn1, may lead to some malfunction... but you can have reflexion about different ways to do your checks and logical programming a bit long answer but hope it can help
  11. can't we have an invisible unit ( a simple soldier by exemple) with transparent textures = you cannot see him unless in editor, that can be targeted, and placed wherever we want = on a structure we can't lase designate without it? someone could probably create that ?
  12. another idea came to me with that. Do you think we can use it to compensate lack of buildings detection in LOS function ? knowing target.point and unit.point, we could check all the line between the both, and calculate if a building is present, if its height is too much to maintain the LOS and will break it... a thing the LOS function cannot do. or it wil not be precise enough or it will consume too muche processor time / FPS impact ? because I think someone else should already have had the idea I suppose... but to use it we have to edit the IA scripts ... to avoid that bad snipper ability they have...
  13. same question for fog and clouds ? because we can change fog density. for night / day have to work on time of mission start...
  14. tried, think it is no. but no way to achieve that ? can't load / run a lib that could make that working ?
×
×
  • Create New...