jimiC

How did you go on drivers? Would there be any other global Nvidia settings that could cause problems ?

Sorry my bad .dLG confirmed Did you change the a rgb values at all? I found it was really trial and error on those.

slight necro but i've come up with a tolerable solution in the meantime until its properly fixed. edt vrtooltip.lua in the dcsworld\scripts\ui folder change the text size at line 71 to 20 or so. better readability if you are going to use them or set it to like 1 if not. starting at line 49 change the "bkg" colour settings to (best i've found so far) ["a"] = .3, ["b"] = 1, ["g"] = 1, ["r"] = 1, makes the box darker shade but more transparent, can pretty much see through it.

sorry yes should have included that detail tried both direct and extended mode, no effect also tried windowed and fullscreen tickbox in the dcs settings tab.

actually in the meantime might i suggest you use some snapviews. They can be customised using numpad keys http://en.wiki.eagle.ru/wiki/Snap_views I've done this so i have close up camera views near each of my main panels

may have to wait for ed to create their own zoom function. shouldnt be that difficult, many other vr titles out there have magnified optics modelled for example

hey mate, just tested your mod works on the desktop with vr disabled. no effect however when vr enabled. I'm using the HTC vive with beta software let me know if you want a tester to pass versions to for a fix . happy to help as this is a critical mod for vive users imo

Possibly You could try using Libre vr injector in conjunction with the occulus software https://github.com/LibreVR/Revive Its definitely an important feature in dcs

removing report on issue.

very cool mate. this is something that may persuade me to get the ipad in the first place (tossing up between a generic 10inch lcd for this stuff or an ipad)

I'm having serious issues with the centering force adjustment via the controllers settings window. it works properly while open but when its closed, the stick goes completely rigid and is way too stiff to use when i have my hand over the sensors, and when i dont, its about where it should be with resistance, which to me sounds opposite to how the sensors should work. ideas?

wow dude if u can do this i will be very impressed. i have a lot Mission editor changes i want to see as well.

what weta said. this method allows you to make 4 outcomes each only able to occur individually using a single random % trigger only allows 2 outcomes, and the use of two % triggers means that both outcomes can occur at the same time.

I figured i would share this with the community. its a little trigger template that i often use to open up as the start of any mission i make and then 'save as' to create a new mission. The Mission editor isnt very good at random variables to generate multi-option ai decisions or activations. so i use this default flag trigger structure to create random outcome triggers that are linked to each other. -This template provides 4 outcome flags. Flags 1 and 2 are your 'coin toss' flags, with 50% random, and are set at mission start. - Flags 3 4 5 6 are your probability outcome flags, each one being determined as true based on the following.. Ouctome 1 = Flag 1 false and Flag 2 false : set Flag 3 true. Outcome 2 = Flag 1 true and Flag 2 false : Flag 4 set to true Outcome 3 = Flag 1 false and Flag 2 true : Flag 5 set to true. Outcome 4 = Flag 1 true and Flag 2 true : Flag 6 set to true. You then create various triggers in your mission that check if one of these flags is true. Example: Create a vehicle unit that goes one of 4 routes on the map. This requires you to create 4 of versions of the unit(lets hope in future patches they allow branched waypoints), and assign a route to each unit. you then activate one of those units with the above triggers, so if flag 3 is true, unit 1 activates and travels route 1, if flag 5 is true then unit 3 activates and travels down route 3. The above template ensures that only one version of the unit and one route is activated, whereas if you used the straight %random trigger rules, you could theoretically end up with all 4 units active. I realise this isnt rocket science but if it helps some people generate some more random missions then im happy. It also removes a few minutes of dull repetitive work to setup the triggers every time you make a mission too.. Obviously you can make multiple sets of these to allow for multi stage multi outcome situations. RandomWPtemplate.miz

if you want to play it seriously you should join a group who want the same. Our group has training together and is running an multiplayer dynamic campaign too.

This is a little project i've embarked upon with the assistance of AEF 161 squadron members over the past month. Basically we have got together to create what amounts to about the closest you can get to an MP dynamic campaign. We've done this by implementing a set of 'rules' and a phase of the campaign that centers around the forums each week in which the members of the squadron get together and plan the next mission. each mission is 90 minutes long with a 1 hour timelapse between missions that allows for rearming and breifing debriefing simulation. The actual time between missions in RL time is 2 weeks and then the next mission flies the following 90minute snippet of the campaign in game time. The goal is to create a flowing series of missions that develop over the course of the campaign based on the decisions made in the forums planning phase and also the effectiveness of the squadron in the actual missions. To this end, both the redfor (161sqn and its associated ground forces) and the blufor have a complete table of equipment and ORBAT which is finite. Casualties sustained or inflicted carry over to the following missions and are represented in the planning phase on the forums with debrief and INTSUMs from the squadron INT CELL. The gamemaster (me at the moment) is responsible for the BLUFOR ground and air assets. The GM decides on his blufor oporders independently and without telling the squadron, opens the template mission and moves the units to their positions and gives them orders. All movement has to be done over the course of the mission time and where they end is where they begin in subsequent missions. The squadron members discuss the plan for the next mission both the squadron flightplans but also orders for the entire ground force to be executed. When they conclude this process the GM takes these orders and enters them into the template as well, only after he has done the BLUFOR orders (this allows for better simulation of Fog of war and a more head 2 head feel to the opposing force) The campaign ruleset we are currently developing as we go along (this first campaign run is really a test of the idea and interest etc) is here http://www.aef-hq.com.au/aef3/forum/viewtopic.php?f=344&t=49905&p=395788#p395788 for anyone interested in how we're running it. So far we are 2 missions into the campaign, taking us from a 0600 start time to currently 1000 hours on the same day. Our redfor bde has moved some 30km and is prepping to invade georgia from Abkhazia. The blufor, currently a georgian infantry bde plus supporting assets has been engaged on the border on our previous 2 missions and suffered casualties to 2 of their 4 battalions. The overall goal set for the redfor is to seize the towns of poti and senaki within 4 days and to retain combat capability allowing them to conduct future operations from this point. As GM, i will also decide on a trigger point being reached at which time the US become involved in the campaign with a naval TF and Marine Exp. Bde arriving in theatre. We've had 6-8 pilots in both the missions run and everyone seems to enjoy it as something a bit different, bit more serious and more challenging than just playing the same missions over and over again (each mission is played ONCE and only once and theres no peeking before the allotted flight night :) ) I've posted this here to generate interest in this way of playing the sim, and just to give others an idea of what we're doing in the 161sqn. Feel free to take this idea away and come up with your own for your own squadrons!., or if you're around during the aussie evenings you can even hook up with ours :)

my understanding is that once the laser is in standby mode it is warmed up and ready to use. It then fires when you designate a target, this in effect shoots the laser onto the point and returns a range, at the same time as locking a target if the targetting system Ids one (you get the TA on ur tv camera) Having it on standby mode afaik may eventually burn it out, but we're talking 30mins ++ if at all. Excessive targetting will burn it out, if its anything like the LRF on a main battle tank (i have more experience in these so i know how they work there) specifically for the KA50 16 cycles of 10 seconds with intervals of 5 seconds in each series. which means that when you designate a target you are using one of those cycles, and the laser will return the range for a total of 10seconds before it should be cooled for 5sec Once you've used it 16times you should probably turn it off for 30mins. at least thats my understanding

you're totally right. I dont expect to have it all. I would quite happily trade the ability to land my KA50 on a train for a better and more functional mission editor.

Nothin special just my first attempt at a video capture . Me and a squaddie on an MP map http://www.youtube.com/watch?v=QXq_Ato33zE

unfortunately the ground ai, beyond limited pathing (how to follow a road) and targetting range based on skill, is non existant. no tactical behaviour is coded in. And you wil have to 'fly mission' to view what you have placed.

Several of the AP modes are dampeners. They deliberately 'sponge' the input to help avoid over corrections from the human reaction to overreact. I think maybe you are confusing what control surfaces affect what. Rudder doesnt cause sideslipping. It creates yaw around an axis. The fact the rudder sits at the very end of the tail results in a long moment arm (the tail length) between that surface and the COG. You may be thinking that the sideslip is the result of this reference a crosswind force, but keep in mind that what you are doing is that you are yawing the nose of the chopper into the crosswind such that your bearing is not the same as your flown track. If one was to view this from the ground you would certainly see the chopper crabbing or sideslipping relative to its nose heading but that is the effect of the wind vector versus the chopper heading to create your intended tracking. And this concept is more relevent to fixed wing aircraft anyway. In this chopper, to correct for xwind you really only need to adjust the cyclic so it is angled forward and slightly into the wind direction. My opinion is that this flight model is extremely accurate and all those real life manouevres are entirely possible in this sim once you have learnt how to fly it. Allowing people to mod the flight model would be counterproductive as it woudl result in a less accurate sim.

thats kinda the point. this isnt just a flight sim, this is a sim for a ground attack aircraft. the ground vehicle ai is INTEGRAL to this. therefore the sim i will name is a ground combat vehicle sim: Steel beasts pro. It has all of that and more. Im sure the editor willl always get upgrades but again thats kinda the point, its almost incidental. Its not about what I want to see( well ok yes it is, but its no from a selfish perspective) its about what will make this sim infinitely more playable and replayable and hence make the online/MP community thrive and remain active. All just one persons opinion naturally. but there it is.

Well... to be honest im a little dissapointed. The listed improvements to the ME are pretty limited and havent removed the labour intensive nature of making half decent missions. Theres been no attempt to improve ground ai behaviour (lets face it there is no ai behaviour unless the mission author goes to the extravagent lengths to manually 'script' it with thousands of triggers, even then many vital trigger logics are missing still ) Things like branching waypoints, waypoint actions, trigger rules such as group % alive, % dead, side % alive/dead, group sees enemy etc are all still missing and these are just the bare essentials to make the ME acceptable. One can only hope the editor gets its own patch at some point, and soon, because it is the crux of sim content and replayability. And i won't even speak of the possibility of dynamic campaigns given the aenemic results of this patch.

i just made one. its pretty easy.

So, I was thinking this area of the sim could be one of the areas where some really high power mods could be developed. Ive started sniffing around the LUA files looking for the ones that relevent to this area. From my limited knowledge these seem to be some of the ones that one would have to play with. menuitem.lua menu.lua theme.lua wingmancommandplane.lua what i would like to acheive eventually, is customized radio menu commands for missions that, when used, combined with say a designated point on the map via the LWS and tshkval lock, allow the player to ID targets and pass them to ai units for fire missions or strikes (allowing the player to interact with the ai units in for instance the AFAC role.) All that really needs to happen is for the menu command activation to set a flag to true, which is in turn set up in the editor to activate a group, and which takes the currently targgetted/designated point from the LWS beam and uses that coordinate to create a target for the ai with relevent details on target type. so, if anyone has ideas, or has already done some work on this, let me know.