robgraham

there any news on this one.. it's... frustrating as heck and really breaks missions when units get stuck and the group stops moving etc.

can we get some clarrification on this section @matt/newy/nine. We already know that the Super Carrier will work with out making the mess that the WW2 objects pack did (really think you should have stuck with high poly for those who brought low poly for those who didn't with that), believe that with the carrier it's you bolter all the time and the cats etc don't work. how is the Burke working? is it just a free addition to ALL users DCS etc but not releasing until the Super Carrier or ???. some of this stuff needs to be maybe communicated a little better on how it's going to be implimented, because lord knows none of us who run servers want another WW2 Asset pack issue were we put in a unit accidently on a mission and suddenly half our users can't join it because they don't own that module.

Fairly certain this ones been reported before, and the like but the Missile desync / not being destroyed on a client bug is still there, and at times with some missiles is rather frustrating as the client will see a missile hovering in the air, but either way.. yeah still a bug that has been around now for months that really needs to get addressed.. Steps to reproduce: 1. Start up a dedicated server. 2. Run a mission that has a lot of Air to Air and Surface to air missile use. 3. Connect with a client. 4. after a while or more start hitting f6 and watch as you see missiles that are at -3k altitude, or others that are at 20knots and not falling from the sky etc. (SA-15 missiles). Now this is a CLIENT issue, the server seems to destroy the missiles (at least as far as I can tell) and a disconect/reconnect will fix it for a short time.. until some one fires missiles again.

those who've watched said series the OP pointed out, and those of us who've spent time around non USN hornets at some point in our lives can atest to the issues the landing gear can cause heck just modifying some parts of the classics caused issues ;) (*cough light weight 'fake' launch bars), but you actually see them specifically talk about the very issues Mover and Trev are referring to in the canadian series, specifically after the high cross wind landing event at cold lake were it causes the jet to basically be out of action from memory for several days as they have to repair the linkages. Here in Aus the hornets from what I've seen tend to flare most times, but we don't use em on a boat ever so you don't have the habit issue but even with that I've noticed that when we have high cross winds etc it's basically just put em on the ground and be done with it.

yes he means you can have 10 missiles out simultaneously which even Matt comments on twice in the video, first when he says how many targets can be tracked and launched on at the start and then when he explains at the end that you can lock pri/sec, launch, launch, pri/sec, launch, launch, etc so long as you keep them all within the bar scans up to 10 missiles and 10 targets. It's just that you can only have a Primary and Secondary selected for actual targeting information at any time.

I'll believe Wags and Newy on the performance, the biggest performance hits in DCS aren't graphical, there Mission related due to the threading currently in the game, something which has been acknowledged more then once by even NG and others. If the codes optimised well enough the impact should be little. On the 'Hardware' talk i honestly am trying to not groan and bang head on the desk, but here's something that more then one person has pointed out about DCS which seems to be being ignored with the 'need a 2080ti or a titan rtx etc'.. DCS wouldn't leverage them fully anyway, even in VR with most settings turned up high DCS hits a threading CPU block before the CPU or the Graphics processor hits 100% on a 2070.. that's pushing 1440p + to 2 eyes and maintaining 30 - 45 fps on average in a MP mission (50 - 60+ on a non mp mission with less stuff). You can look at the graphs, commonly you'll top out at 95 - 97% which means the boost clock on most Nvidia cards never gets fully kicked into high, this is even more evident if you drop from VR and shift into single player on either 1080 of 1440p, GPU useage on a 2070 will drop to 50 - 70% even though your not getting maxed out frames but if you go and pull a thread report for the CPU you notice that DCS is hammering typically one core that hard it's bottlenecked. Again issues that the Dev's are aware of and working on based on what we've been told, but not something which can just magically go away. Until we see things moved to a better multithreaded engine performance will always bottleneck at the CPU unless you have like a 1060 or something and even at 1060 will drive DCS decently at 1080 and you can reach about 30fps in vr on it (trust me i've done it) so long as you sacrifice quality for frames. what's all that got to do with super carrier performance? Well so long as there not adding a massive chunk of extra code into the regions that currently bog down threads, in theory the impact as newy, matt, nine etc have reported would be next to nothing, until you start adding things like Aircraft etc into the mission which as again matt and others have reported are an impact because there in part were threads are bogging down currently. But until it's out and in peoples hands honestly none of us can say.. ED can't possibly check it against every config we all run.

Just a small wish list of features / additions even temp ones to make DCS Voice easier to use for server and clients. Add the ability to set the PORT for it in DCS itself not in the Autoexe.cfg file.. I understand that Chiz has said the aim is to combine the ports into a single datastream at some point in the future however at the current time it's not it's still 2 ports and that requires SERVERS whom run multiple SERVERS on 1 Machine to have different ports open, which in turns means to change the default by his own words you have to modify it on the server and the client for it to work. Most clients aren't going to want to/know how to etc go and make autoexec.cfg or mess around with it every time they want to change a server (given you need to RESTART DCS for that to work!), until the time that it's integrated can't ED add an extra box into the config area with something like DCS Voice PORT: 10309 (default) which is editable and what ever that is set to is the port that the CLIENT tries to connect to. That's a HELLA lot easier then rebooting and brings functionality a lot closer to SRS's.

Holton will give is a shot soon, sorry fires and really shitty weather here in Australia atm which is playing hell on me doing a lot (coupled with illness etc) will see if i can't test it tonight while i fly (if i get to) -Rob.

Newy, Looking at the logs atm since I did the changes that c0ff asked me to do it seems to have stabilizsed. Of course as I said on discord I've not had a chance to check files on the server as often as I'd like of late I've been a bit busy due to weather, illness and having to watch for fire alerts due to the first. (43c in spring isn't 'fun')

This is before I tried something I've been asked to do but is the log Newy Asked for. And newy before you go 'Mods on the server' Please note this: 1. This happens even if you have a clean server. 2. This was happening well before I readded LOTATC back into our server. I am trying the changes I was asked to in PM and will let you know how it goes. dcs_503error.zip

I've given them before but ok i'll wait for it to happen which might not be long it seems to be doing it on and off atm (i've just been restarting the server instances tongiht though because I've been testing another bug) though we've given you literally the ONLY lines that the dcs.log file spits out that are not the same as a normal log and we've all done so again and again Newy, the exact same set that we've all posted for the last several weeks across 8 pages. the lines haven't changed it's always this set the date/time just changes ERROR NET: HTTP request dcs:server:update failed with error 28: Timeout was reached ERROR NET: Server update temporarily failed. Will try again later. ERROR NET: Session check failed: 503 and again if it was a ROUTING issue we should see it on all server instances, at the same time as I an others have pointed out we are not seeing this, we can have multiple instances on the same machine, using the same network and out of those 1 server might be missing from the list and spitting out the above errors, or 3 out of 4 might be doing it. At which point the only method to fix it is to Restart that server instance, at that point it will instantly show up in the list again, even if said error happened like 1 second before in the logs. If every server instance did it all at the same time I would happily agree with you that it could be a 'network' issue, but that isn't the symptom. And this is really why DCS especailly in -server mode needs to basically make new log's each time it's started rather then just dcs.log if it spat out a new log each time we wouldn't run the risk of overwriting an error log for when you request it, a lot of us just want to get our servers back up and displaying correctly so we restart, not thinking about getting the log and renaming it.. and it doesn't always save a dcs.old log either.

There is an issue with EVENTS handling for Mark Points in Multiplayer vs Single Player which can break functionality if your relying on the scripting to you know.. work as documented. in single player when you place, interact or delete a markpoint you get a standard event structure back that includes the following data {[coalition]=2,[idx]=251658260,[time]=46802,[initiator]={[id_]=16826112,},[id]=25,[text]=,[groupID]=-1,[pos]={[y]=93.531725001358,[x]=-115491.59761345,[z]=-70963.214937865,},},} an important part of that is this line [initiator]={[id_]=16826112 as it is the unique Object ID of the event initaitor through which you can then find whom actually triggered the event. However when you run the EXACT same code on a server and interact with it as a CLIENT you get this event data triggering on the server instead: [coalition]=2,[idx]=251658241,[time]=46817,[id]=27,[text]=,[groupID]=-1,[pos]={[y]=61.399505979523,[x]=-122076.6142754,[z]=-81265.513559098,},},} The Server is the only one whom seems to send a Mark Point Event initatior and this is means when a client does so a very important box of data suddenly missing, said EVENT Initaitor, meaning that you can't find WHOM triggered the event despite the fact that the server has to know it's just not seeming to be passing the information as it does when it is locally triggered or in single player it also HAS to know this as it adds the mark point creator to the mark point's name. Could we please get this bug filed and looked at It's annoying as hell when functionality that works in Single Player scripting suddenly doesn't work at all in Multiplayer because things like this are not being passed.

nope happening still had the same error spitting out on our second server just now until i restarted it newy. As I've said before it is something to do with when a server times out because you then get the Error 28 - 503 error. 503 is typically a Webserver/HTTP error code for SERVER ERROR. It's basically like it's going 'Hey I don't KNOW you, I'm not going to talk to you anymore'.. And it can't be as we've all pointed out a actual 'routing' issue because we can have servers on the exact same machine working fine, and others not.

That's why we are asking if the SCRIPT commands can be given, Tigger.Action.SceneryRemoveObjectsZone(zone) or something.. almost all of the other Triggers have a Script equivilent that is documented but some of the newer items don't. There should in theory be lua commands for them given that the mission is calling the commands and the triggers can be called after the fact, the issue though is that the triggers via ME are limited to what you put into the ME so if you have anything Dynamic it's pointless. Were as if we want to run say a script that allows you to have engineers go blow up tree's so they can set up a FARP or something, I can do everything but having the tree's blow up IN script.

the 'backroads' in DP02 are broken with a number that come close to connecting but don't actually 'connect' which in turn breaks on road AI pathing. I've attached an example image.

yeah you can use mist or moose to do what you want ickyline but you didn't ask that.. with moose for example you'd do something like this (note this isn't 100% it's just quick code) myZone = ZONE:New("Zone1") -- store our zone myPlayergroup = GROUP:FindByName("myPlayerGroup") -- store our player group Group1 = nil -- for our spawn isinzone = false -- so we don't' trigger multiple times below -- our function checker function checker() if myPlayergroup:IsAnyInZone(myZone) then if isinzone == false then Group1 = SPAWN:New("MyAIGroup"):Spawn() -- make our group save it in Group1 so we can kill it later isinzone = true -- we are in the zone so set this true and don't trigger again for now. end else if isinzone == true then if Group1 ~= nil then -- if our group isn't nil eg it did actually spawn Group1:Destroy() -- then destroy it. end isinzone = false -- we arne't in the zone no more so we can set this false end end end SCHEDULER:New(nil,checker,{},1,1) -- create a new scheduler for checker run it every second

Topic says it but Newy, Chiz, Nine, Grimes, whoever is it possible to find out if there is an scripting API command for SCENERY REMOVE OBJECTS ZONE ? The command can clearly run AFTER mission start (you can set a timer and it'll remove objects in the zone when the timer kicks in) but looking at Hogget etc I can't find any scripting API command to access it from within a script. only the actions menu in the Triggers there seems to be a number of trigger singletons that are now either not documented or missing...

Something I notice over and over again with these types of posts we can give money for ED to employ people and throw devs at x. The issue people forget is that isn't how things always work, 124 or so people currently work at Eagle Dynamics, most of whom are either Coders, Artists or the like all touching parts of a code base then on-top of that all the 3rd party dev's. If you know programming you know full well that some times it doesn't help to throw 50 people at a problem that 1 person is working on, all it does is literally cause more issues then it solves. Or for you non programmers out there, throwing 50 mechanics at removing a battery doesn't necessarly make it any faster then just having left 1 guy there to do the job with out them all getting in the way. So no I don't really want a subscription model, I don't based on all the discussions I've been part of believe it would have the impact people believe it would. Better communication etc is what would help and hopefully we start to see that happen, it seems to have since certain parties have become more involved recently.

For a long while now this has been happening, it seemed to solve itself out for a while and be good only to return again in the last few updates, and looking at the other 'bug' report here about the F10 map I wonder if the issues aren't related but I've made a NEW thread because that was for te Occulus while this is for WMR/SteamVR. Quite often if you've been in game for a while especially on MULTIPLAYER, hitting F10 will basically lock up your VR headset as DCS stops talking correctly with SteamVR, this results in one of 3 things happening. 1. A blue screen and then a black screen on your headset and when you lift it you can see on the SteamVR message box 'An issue has occured please restart your headset' 2. the image pausing and never actually picking back up if you look on the screen your HMD's movements will still MOVE DCS but again steamvr will be reporting an issue. 3. Stuttering / suddenly extremely low performance like what is reported by those with the rift. Now the interesting thing here is that WMR tells us that it's NOT an issue with the headset so it's not FIRMWARE related, it's an issue with DCS, specifically it's output to the hooks that are waiting for information from it aka OpenVR, basically during certain moments DCS is hanging long enough or sending garbled data that openVR reports a timeout that it couldn't recover from, this results in this case with SteamVR wanting a reset because the HMD couldn't do a refresh correctly or steamvr didn't respond correctly or something (despite it working perfectly fine and you can tell it is because the WMR cliff house etc is working correctly and SteamVR CAN NOT reboot a WMR headset unlike a vive). The issue though of course is by 'Resetting' steamvr you KILL DCS, it doesn't allow for a VR headset to disconnect and reconnect. I know I'm not the only WMR user to have this issue or the only VR person either, over 3/4th of my Sqn/group fly in VR in a mix of things from the HP Gen 1 WMR headset - the Reverb - Vive - OR products and EVERY one of them has reported issues when hitting F10 at some point or another, to the point that if we've been in game for longer then 20 minutes we at times don't want to press the damned button. The only extra things I can add is that it appears to be SteamVr version independent as far as I can tell, I'm running latest OpenBeta, but if Rift users are reporting issues then it's NOT SteamVR as rift users don't have to use SteamVr I thought? Anyway just reporting. And yes @Nineline, @Newy I'll 'try' and find logs for you when this happens next time I didn't think last night to save them out in part because when this happens tend to be in a middle of a @#$@ gaming session and all I want to do is restart and get back into the game. But lets be clear it's not a 'resource' issue, my system is more then powerful enough to handle VR and then some. -Rob.

Holton, i got this working with OzRunways (Australian made EFB), I had to do some adjustments to the AHRS packetsend, seems your packets don't seem to match 100% with what was expected. I've dropped the code changes I had to do below. other then setting broadcast to true (though might not be required), if you want to add it to the code base as another option or something, I was lucky I've made the connector for the LM fs to this EFB so I knew what it wanted. if AHRS_UDP == 1 then if AHRSt == 1 then AHRSt = 0 my_send_AHRS_GPS = socket.protect(function() -- had to change this line because some specific look for XGPS as the packet header OZRunways is one of them. local json = string.format("XGPS ,%.5f,%.5f,%.1f,%.2f,%.1f", Long,Lat,Alt,TC,Speed_ms) socket.try(AHRS:sendto(json, host_AHRS, port_AHRS)) end) -- my_send my_send_AHRS_GPS() end AHRSt = AHRSt + ANEt my_send_AHRS_ATT = socket.protect(function() -- As above, XATT because it's what is expected but also had to pad the full ATT packet out and give it the extra data it wanted, -- in the case of Oz Runways this is Heading, VX, VY, VZ but we send it pitch, bank as well because it's already there.. --I just can't find what the values i'm missing are but then when i worked on the connector for another sim - ozrwys we ignored these as well anyway. local json = string.format("XATT ,%.1f,%.1f,%.1f,0.0000,0.0,%.1f,%.1f,%.1f,0.00,1.00,0.00", Heading,Pitch,Bank,VX,VY,VZ) socket.try(AHRS:sendto(json, host_AHRS, port_AHRS)) end) -- my_send my_send_AHRS_ATT() end and images of it working, did have to restart ozrunways after the sim started to get it to talk but that's just a quirk of OzRunways some times.

2019-10-20 04:26:41.991 ERROR NET: HTTP request dcs:server:update failed with error 28: Timeout was reached 2019-10-20 04:26:41.998 ERROR NET: Server update temporarily failed. Will try again later.

we noticed weirdness on ours last night Newy some of it seems to be Desync between Clients - Server, newer clients connecting seemed to get sync'd properly and see things correctly but those who had been on for a time had a LOT of weirdness happening Tanks in the Skies, etc.

Hey man there's no need to personal attack if your gonna start on about toxicity ;) , I was stating what was said in multiple places ok? Even here on the forums I then go on to defend the fact that ED is damned if they do and damned if they don't and there is nothing wrong with 1 radar guy, I never said that there was, I was answering a person who asked how we knew that there was 1 radar guy. Do I honestly think that they'd be better off having some one else learn along side him if only for redundency yes, but hey that's life maybe they don't have any one else who can learn vector math? This type of response is why nine and newy end up locking threads. As for what I think on radar programming, actually by and large it is a lot of vector math and ray calls.. literally that's what radar programming is in simulation or in real life, your shooting a ray from the emitter out (in sim a raycast, in reality a radio wave), you watch what that ray hits and then depending on what it does and in DCS the level of simulation you do a number of things. 1. either just do a simple RCS return (not what I think DCS's programmers have done) 2. do a bounce based on the object surface and it's current vectors (more what i think they are doing) Is it complex math? yeah but it's math in the end a lot of this variable1[] = ray.shoot(emitter,emitter.vectorx,emitter.vectory,emitter.vectorz); if variable1[] !- nil { code to start iterating the returned contacts }; etc. etc. ettc as for the newsletter but again take it as you want i'm not going to start a fight with you. I was stating an opinion, your welcome to disagree and refute it but do it with out the hostility, I've not attacked any one so really... who's being toxic?

How do we know? Because Nine, Wags, Nick, Newy have all confirmed that the Hornet team was moved over to the Viper, it was even in the newsletter. That's how we know, we also know because some one said *eyes nine* that they only have one radar programmer at the moment. So yeah we know that it's 1 guy. On the 'you know what your were buying Early Access' and ED doesn't owe you anything comments that get thrown around, actually ED should be giving a time frame for EA to finished release and if I am not mistaken if they are doing EA on Steam they have to give at least a rough idea of how long they believe something is going to be in 'Early Access' these days after valve got burned by a number of games etc being in EA for well ever. It's why the changes to things like Release Dates etc have all been made (and that was also one of the reasons given for the move of the Hornet team and the rush on the Viper, they needed to get it out due to having missed the original steam projection at least according to what reps have said both here and on Hoggit). A lot of the anger that has built up since the Viper wouldn't be here IF there was a proper roadmap and a proper release schedule, but there is neither. After a really indepth discussion with Nick Grey on hoggit we got the start of a roadmap in the last newsletter but it's not a true one because it's just well dot points with these are what we plan to release next but it's still better then nothing. And while yes EA is what the Hornet is in lets be clear about something when you buy into that your buying in expecting that the product you have brought will be completed as early as possible and with all resources needed assigned to it until that point is reached. That is what it seems the majority of the community expected based on the sentiment here on the forums and else were. When the Viper etc was hinted at and then announced people specifically asked rather pointedly if it being done would take resources away, they also asked about other modules like the YAK etc taking away from the Hornet, again and again the official response was 'No they are all their own teams'. Then we got told that the Hornets dev team had been moved to the Viper to help get it to release, now we know from hoggit and Nick that this was due to them needing to get it out because of the Steam Release date being set and that they wanted it out also before the Autumn Sale (why i don't know because it's not on sale...) shortly before all this though we'd been told TWS and the like was 'Almost done and would be out soon, the wall eye was almost done' and that as soon as the viper released that the team would be back working on the hornet including TWS. We know what happened we can recount it easily enough Viper released people asked if the Dev's were back, Wags said 'not yet' and the news letter said that they would return in the coming weeks. Ok, and then we get told TWS is coming for the viper first and you end up here and the slinging match of evreything happens all over again, Nine and Newy get frustrated because they are trying to actually do what they have said and open up and be more transperant and fair etc on the forums and yet at the same time there damned if they do and there damned if they don't because no matter what they do there is gonna be a chunk of people who aren't happy no matter what happens if the Viper gets features that the Hornet is meant to have BEFORE the Hornet due to the Hornet having been in E.A longer. It's why multiple EA releases can bite them in the rear, it's why it has. Because even if they are doing everything they can to be 'fair' there is always going to be the feeling now amongst some of the user base that the Hornet's new features are being sacrificed for the Viper to get it's first because it's the new shinny bird that they want to get $$ for. It won't matter if that's not true etc, that's just how we as humans work and it doesn't help that there isn't any clear timelines even in 'general' x months worth because it allows for the speculation. For all we know (and actually I suspect this) Both projects will go faster now because the last several years have been spent laying the API work needed, that's part of why the Radar guy spending this time to do what he's done for the Viper does make sense.. He was moved, he kept programming and completed the API.. because he was on the Viper at the time he simply finished the implementation of how it looks front end there. Makes sense from a programming point of view, makes sense from a company point of view too. But knowing that and even being able to explain it etc won't instantly fix the hurt feelings people have or the mistrust caused by the handling of the past few weeks. Only time and honesty etc will and that as I said means ED is gonna have to grow a thick skin and wear it for a while until they can build back up some trust. But throwing 'wells you knew what you were buying into' around won't solve that either because people brought into EA with expectations and ED has as I've said clearly not recently meet those expectations.

we ain't getting the AGR for a while saddly that's from the owners mouth.