Stonehouse

Running Win10 and 660TI graphics card with latest drivers (355.98 ) and generally I am not seeing the mirror finishes particularly on the default F86 skin which looks much as it does under 1.2.16 but generally as well. Closest I get to what I see in other peoples screenshots is probably the all metal skin P51 in the instant action free flight mission. Is there a particular setting in the game options or outside in the Nvidia settings that enables the higher reflectivity or might prevent it? Perhaps one of the config related lua files? Or is it just that the old card lacks the ability to give the effect? Thanks, Stonehouse

FYI Using the dev version of MIST v3.8.53 and Flakv3_3 everything works fine under DCS 1.5 beta.

Yeah I can remember Win3.11 coming out too.......doesn't time fly by

OK had success thanks to the info on the other post. This thread is worth subscribing to http://forums.eagle.ru/showthread.php?t=114030

Hmmm think I see where you are heading although it would probably mean I would need to reinstall the beta and modules again to "pick up" the fact that Mig21 had a key if it does work like that. Not sure I want to do it yet as I had trouble getting the Mig21 activated at the beginning and had to get some assistance from Cobra at the time.

No in the main DCS module manager it appears as "No Key" but it is activated. I also just for the hell of it ran the copy of the Mig21 module I just downloaded hoping to fix the beta against my main install and it went in fine and didn't ask to be activated - so assume there is no key related issues in my main install. I just cannot run the installer against the beta because it says it requires 1.2.16.43180 - which is what is there according to the beta splash screen. <edit> ok I just saw another person post that they are going through the same exercise but that when updating their beta via module manager they had some sort of issue with A10C so they downloaded the module from the store and tried to manually install it and got the version error message I got. So there must be something subtly different beyond version number between a beta install and a normal one that the modules check for. If that is so then the kickstarter Mig21 owners might need help to install it under the beta.

Hoping for a solution or some assistance. I've just got the latest 1.2.16 beta of DCS world installed and wanted to get it all the modules up and running ready for 1.5. However I've run into a problem with the Mig21 in that my module manager lists this as "No key". I understand this to be because I got the Mig21 through the original kickstarter and not via Eagle Dynamics. Therefore I cannot use module manager to update the beta install. I have downloaded the latest exe from the ED store however when I try to run it against the beta install I get a version mismatch error. Any workarounds or solutions please? Thanks, Stonehouse PS Confusingly the versions of the two installs match 1.2.6.43180 which is also what the installer for the new d/l of Mig21 is asking for

OK that method works fine for everything barring the Mig21 for me. Module manager lists mine as no key presumably because I was part of the original kickstarter and didn't purchase through ED. Is there a solution to allow you to test the Mig21 under the beta? I did redownload the module but when you point it at the beta install it complains of a version mismatch. Thanks, Stonehouse <edit> problem solved thanks to Skatezilla http://forums.eagle.ru/showthread.php?t=114030

Misplaced my local copy so had to find this one. Giving it a bump since there seems to be a lot of new 190 pilots these days.

Is there any planned downtime scheduled in the server operating hours? Asking because I am (and the group I fly with) in the GMT + 10 timezone which may correspond with what an EU server considers off peak and therefore available for updates and fiddling about and not available to players. We have been very slow on the DCS side of things pending DCS 1.5 but I believe that the arrival of the P40 will get us back on board as it's been a squadron favourite since IL2 days. Especially as we're an vRAAF group. Previous posters question about access to the public/non members also applies to us, is there any hoops to jump through to gain access if the CO and the rest of us decide we would like give your server a try (considering it may not work out due to lag and our poor Australian internet connections)? Thanks Stonehouse

I thought there was a particular speed that gave neutral rudder trim. I seem to recall that the 109 had a bendable trim tab that was preset on the ground to give neutral at speed xyz. In IL2 it was about 50% throttle if my memory isn't playing tricks but does it say anything like that in a real 109 manual?

Attaching the mission to a post here (pretty sure you can) is definitely the best way if you're stuck. It may take me a little while to go through it as it has to fit in around other things but I will look at it for you.

Sorry guys, forgot about this, it's been lying about for a week or so and during a short work break today I did a quick tidy up of the files and uploaded them to git. It's a spin off from my recent work on GCICAP to also move to local vars and tables for the Flak manager to improve performance (seems to be better for me anyway). Those people who use it please give the new version a go and see how you fare. No changes as far as how you use it or what it looks like in mission just hopefully less performance impacts https://github.com/457Stonehouse/Flak-Manager/releases/latest Thanks, Stonehouse

Ok thanks as always Grimes. Some of that will take a bit of digesting and possibly generate some more questions but I am glad that generally I seem to be heading in the right direction. On the tableA[side] and tableA thing I get the impression from your response re: sideCoa1 and sideCoa2 that again it is only pointers? so if you make changes to the table referred to by sideCoa1 say it will also be reflected in table referred to by tableA? or am I getting off the track? I suppose just for completeness sake - if instead of tables I had two variables but still declared as a global and a local to the script so I believe the scope is the same - does that change anything about your comment of not needing to return the variables from the function? If so, is the return statement in some ways just a commentary or descriptive thing to make it easier to see what the function is meant to do? or is it actually required in certain circumstances? You may have already covered this in your reply but it hasn't sunk in yet so if so apologies and just tell me that's the case. Cheers, Stonehouse

Trying to get something straight in my head around returning tables from a function. If I have a script that is like: Ok few questions and clarifications sought on the statements below: tableA is a global declared table so is freely available throughout the script and also outside in the DCS mission because essentially DCS calls the script and tableA is global. I understand the return passes back a pointer to the portion of tableA for index side and not the actual table data itself. anything incorrect? If the table is global why is a return needed? Wouldn't the changes to the table done in the function be reflected immediately outside? Is there any reason why you would return a pointer to only a portion of the table rather than the whole? eg return tableA rather than return tableA[side] What are the ups and downs and implications of the two tableB is a local declared table so is only freely available within the script. I understand because it is declared in the outer do-end block that it is freely available within function xyz. I believe that any updates to the table within function xyz are reflected outside the function in the script. Do I need to return tableB in order to see the changes? In the sort of logic example above what does the return of the table/s acheive or why is it needed? Thanks, Stonehouse

@Shadow, I don't think it is immediate but perhaps I am wrong. Which version are you using? the Jan 2015 one or the Sept 2015 one? Yes to overwhelming at times, although the script should only assign one bunch of interceptors to each group you should recall that each player is a group so potentially you may find up to 4 planes on each player depending on your script setup and DCS internal logic for aircraft in a CAP role with free to engage ROE also plays a part particularly with modern aircraft with search radar as this will override things if the CAP/GCI aircraft has already killed it's target and is waiting about for the script to give it a new target or RTB it. If it's gets too much you should tone it down using the script settings (also helps your server performance) as the script is definitely built to kill intruders and does so pretty well. @Silk, so perhaps a invalid waypoint description? Ok definitely a possibility and thanks for the info I will try to see if I can get the waypoint data out during script execution and check it/cut and paste it into a stand alone mission to see what happens. Strange it only happens sometimes. It definitely stuffs things up though as I can see things working fine and then a CAP flight will just head over the border for no reason (I can see they haven't been given an intercept and there are no intruders) and trigger a war or a flight will just RTB even though the script hasn't told them to and they have only been airborne for 15 mins on full tanks and trigger a new flight once they despawn. The only culprits really thinking logically can be the flight plan created at the time the group spawns and it's interaction with DCS or a obscure bug in DCS itself. Doesn't seem to matter what type of aircraft or whether it's red or blue. Saw your PM by the way and sounds good. Will reply with the info you wanted when I get two secs coinciding with me remembering to do so, lol life is a bit hectic at present.

No Ai improvements, just what DCS provides. General comment on the CAP - currently the script generates 20 waypoints randomly around the cap zone. Been seeing similar behaviour as you describe while testing and doing some checking the base DCS behaviour seems to be that on getting to the end of the waypoints the aircraft will land at I *think* the nearest friendly or failing that neutral base. In the script environment this will cause them to despawn and so the script generates a new CAP flight. I have a feeling that perhaps DCS has a glitch in this default logic and sometimes instead of heading to a base they just carry on at the same heading, alt and speed as they were at their last waypoint. Ideally I would like the script to work such that a CAP flight needs just a few random waypoints with an action on the last to switch back to waypoint 1. I don't think that will happen this time around sorry. As the waypoint generation is based on random (-zone radius, +zone radius) it is probably better to have bigger and fewer zones so there is more chance that travelling through the assigned points will take longer. GCIs will launch from any one of the sides bases which have been designated with a zone over it of the same name as the base. <edit> even stranger....I am finding sometimes that if say 4 cap groups spawn that one or two will decide to head for base almost immediately again. Don't think it is getting to the end of the waypoints so fast and I know via debug that the script is not resetting their task and flight plan to RTB. So I am reluctantly thinking that either something is wrong with the spawn flight plan occasionally or DCS is doing something odd itself. Headache material Yes to the CAS flights, one day I hope to see it do something like the intercept task generation for GCICAP.

Ok another small update. I believe that I have sorted out the CAP spamming issue and have reintroduced separate CAP and GCI template aircraft and hope that I have task generation and the RTB code working properly. Going to do some more testing as well as try to implement some of the global to local vars changes to try to help performance that I have been working on as well. Potentially will add in the airfield capture logic if I feel it is solid enough - basically I have a wip version of the script that will detect a change in ownership of an airfield. At present it becomes operational for the new side immediately whereas I had hoped to somehow build in a delay or some other sort of thing to make it not quite so magical. Maybe a few other things too depending on how it is looking. Getting tired so going to knock off for the night with this update.

Small update, after a lot of pain I seem to have fixed the issue around CAPs continuing to air start after the first set of CAPs have spawned ie the startairborne issue. It looks like you'll end up with the ability to specify startairborne individually for each side. Unfortunately this means that there are some more global vars added so don't know what it means long term for performance. I guess it is only in the spawn CAP routine which is only called every now and then. Now to find the cause for the spamming issue. I am going to try add back separate CAP and GCI template aircraft as part of this set of fixes as just like Rob from a few posts back I didn't like going to less functionality.

Hi Hijack, Just be aware that there is a bug with CAPs at present in the new version and that the startairborne setting seems to be a blanket thing for CAPs rather than just the first set. Trying to figure out what the cause is but still a wip.

the seed of that's sort of already there. If you go back up the thread someone pointed out that global vars can be modified by in mission events. So for instance I have introduced a very simple logistics system a few versions back that limits airframes for each side individually. So it would not be too hard to have say a ship arrive in port trigger an increase in this value and of course if the ship didn't make it you might just run out of planes...... That was a big part of the work I was doing on GCICAP before this last issue interrupted things. That and switching a lot of the global vars back to local ones for performance reasons and suffering all sorts of scope related bugs. You would also need a ground war version of GCICAP to handle tanks etc I guess possibly similar to the old IL2 DCG.

yeah definitely. It's just been like that since the beginning.

A big capzone means that the flight needs to be further away to be off station where as a little cap zone means that they only need to move away a bit before they are regarded as off station. It's because it's a dynamic distance based on 1.2 * radius. So 50000m radius zone (50km) means more than 10kms outside their zone and they are off station whereas a 10000 m radius zone it's only 2 kms. I guess that is ok but perhaps it needs to be included in the designers decision making because if a cap flight is off station a new one is launched to replace them. I doubt there is a hard rule and it would be situational based on the mission.

Sorry Grimes example below. Trying to track down the CAP spamming issues in GCICAP. I believe #actualCAPtable will either be 0 or greater than 1 and it contains the CAP flight information with one entry per CAP group. numstatusCAPgrps is the factions max number of CAP groups chosen by the mission designer and configured in the script as part of setting it up. CAPside is the faction being dealt with at that particular time ie red or blue So if z was < 0 would the loop iterate? sounds like yes and from what you said the Group.getByName would return a nil group name if the entries in actualCAPtable ran from 1 to whatever? I guess this is actually a table related question not a loop one. Thanks, Stonehouse

Can't find this in any reference docs so far so asking here. I have a do loop that is something like for j = z, #table do and z is a calculated value. If the value of z is < zero what happens? Inside the loop the table elements for j are being retrieved as well - so I assume if the for statement somehow works then the table elements for say j = -1 will be nil on retrieval? I believe that the table itself is either empty or has indexes greater than 0 when being built. It also looks to me like the calc of z is trying to prevent z ending up zero as it's #table - max chosen for table + 1. However as #table is built up by things spawning until it hits max chosen I think z could be less than 0 early on in the mission. eg max chosen = 4 so until the 4th group spawns z would be less than 0 and when the 4th group spawns it would be 1. Thanks, Stonehouse