sc_neo

@Blindspot Did you even read a couple of posts before that Poly is working on a new FM?

Great to hear the Gazelle is still going to receive more improvements and new FM at some point :) So i was not mistaken in recalling that you made a statement to that affect some time back, that the new FM your are developing for your current project would feed back into the Gazelle. And i said this before; that is the best case scenario you can hope for as a customer...that is; that foundational improvements to the core achitecture get back ported to a product released a long time ago! I can only encourage you to post a detailed blogpost about what technical/workflow improvements you guys came up with for your new "flight model 2.0". I am really curious about what goes into making a high fidelity FM for a helicopter, how to measure certain aspects and how to transfer that into efficient code.

@borchi_2b So i just fired up the mission editor and loaded a mission in all four Gazelle variants in dcs. And from the enduser perspective the cockpit and lighting options look (panel backlights, UV and overhead torch) to be exactly the same, might be overlooking the fine details of course :) From my imagination, there should be no real technical obstacle for the pilots on those variants to fly with nvgs. So, are the nvgs in the M and Mistral variants kindoff deeply hooked into the electronics of those variants, or is it just a matter of putting those on the pilots helmet and connecting them to some DC box? Now i would like to see NVGs added to these variants for the following reason; dcs players are and will use all 4 variants in all kinds of mission and fictional scenarios. Whose to say that a certain scenario does not include a story arch where an upgrade program was initiated to add nvgs. Additionally, flying a helo close to the ground in pitch black darkness is kinda more calling for nvgs than flying a jet during the same conditions. So, adding nvgs does not really fall into the same category like adding aim-120s or such. You can make this opt. in via a check box in the specials tab in the settings. But i am not going on the barricades if you decide differently either. Cheers

I am on 16gb memory as well and i often have to kill pretty much anything in the background to stop dcs filling my ram to the brim even in single player, especially on Caucasus. Now, i still have an amd 7870 2GB vram card, and plan to upgrade this fall. My question is; does anyone have any experience whether moving from such a low vram card to lets say a 8-10gb gpu might actually alleviate some stress on system memory? Is dcs offloading some stuff that usually belongs into the vram of the gpu into system memory if you have a low vram card?

@Havremonster Ha, you are right! But that is a can of worms that is probably not allowed to be talked about on this forum, it kinda falls under the general notion of militarism and is probably forbidden to be discussed under the provision to not discuss politics.

So, i have played around with PeterP's old "Proper neck" mod which essentially moved the eyepoint a bit forward and upward to simulate a proper neck, i.e. that our eyes are not placed at the same spot on the top of our spine where we actually turn and tilt our head. Back in 2011 it seems ED did not have any of this implemented for their own modules and the eyepoint was the same as the pivot point. If one takes a look at the server.lua we now see ED has implemented this for all the newer and reworked modules that i own, including the FC3 ones like Su-25T/27/33 and F-15C, Mig-29, L-39. The A-10C does not have this, but i assume this will change with the upcoming graphics and cockpit improvements. The server.lua contains a section that looks like this; " function default_fighter_player(t) local res = { CameraViewAngleLimits = {20.000000,140.000000}, CameraAngleRestriction = {false ,90.000000,0.500000}, EyePoint = {0.05 ,0.000000 ,0.000000}, limits_6DOF = {x = {-0.050000,0.4500000},y ={-0.300000,0.100000},z = {-0.220000,0.220000},roll = 90.000000}, Allow360rotation = false, CameraAngleLimits = {200,-80.000000,110.000000}, ShoulderSize = 0.2, -- move body when azimuth value more then 90 degrees } if t then for i,o in pairs(t) do res = o end end return res end " Thus all ED planes that rely on the "function default_fighter_player(t)" for those viewpoint values have the eyepoint moved 5cm foward from the pivot point. The second value should actually raisethe eyepoint in cm, but altering this value i did not see a difference in the eyepoint position in the cockpit, but when rotating the head, there is a slight displacement and your eyes seem to not rotate on a needle pin anymore but circumscribe a circle of whatever cm value you put in there. And yeah, the human neck probably does not work in perfect circles and such, but it can still be approximated better i reckon. Now one important aspect that i did not know anything about before looking into this, is that a collimated HUD is only centred in the HUD frame when looked at from a very specific position, and moving your head in any direction moves the HUD to the sides until you gradually loose more and more of it. We can see this in the Viggen happening when we actually move are viewpoint to the left or right, up or down. But when simply looking around i.e. turning our head from left to right for instance, there is no HUD displacement happening at all, which it should if our eyes were not placed extactly on the pivot point back in our neck. Unless i am missing something thats special about the Viggen's HUD, of course! So, i encourage Heatblur to take a look at this and add a "proper neck" where the eyes are roughly placed 5cm in front and 6-7cm above the pivot point. And do note, if you move the eyepoint 5cm forward, you need to adjust the actual pivot point position 5cm backwards to to have the same FOV and feeling like before, but i am not entirely sure how this needs to be worked around. I don't own the F-14, but i assume it's not implemented there either...so guys, go for it!:megalol:

Agree with the general sentiment here, there should definetely more missions covering the weapons and systems of this lovely bird. And as stated above, it's not about quantity, but coverage, that statement rings very true with me.

Ah ok. Have been using the pages for quite some time as simple kneeboard pages like for all other modules. Was not even aware there were issues when you released this. Anyway, thanks again, they look awesome and are pretty handy.

Ehm, what is the difference between the lua based mod/OvGME version and simply dropping the pgns into C:\Users\....\Saved Games\DCS\Kneeboard\AJS37? Both seem to work just fine, but i'd like to know whether i miss out on some cool functionality that might come with the lua mod version :). BTW: i really dig the 60/70s yellowish paper typewriter style you have managed to pull off!

Hey mate, so for how long have you be waiting for Hollywood to get in touch with you? Is this a one man show and not a fulltime job, so give him some time. Now, what steps have you taken to verify the installation is setup correctly? Windows 7 or Windows 10?

Actually, i believe i have read during my investigation into the DefaultReceiveWindow config stuff, that programs can be coded to dynamically set that buffer window, increase from default. But i am not sure whether this was for some specific buffer for TCP, or really for that general DefaultReceiveWindow.

Coop version pretty please!

Great to hear...looking forward to the full package!

Glad it worked out for you in the end :) And, yeah i felt pretty annoyed when i got it working and the issue was so simple to fix. So documention is key, i am sure Hollywood will update the manual und troubleshooting section to account for the DefaultReceiveWindow issue.

FIXING UDP PACKET PROBLEMS: So i guess this goes mostly for folks on windows 7 but might be worth investigating for anyone who has difficulty on getting the correct module/aircraft show up on the PTT page which might be related to UDP packet size and windows receive buffer: So first, as Hollywood mentions in the intro to Vaicom 2.5, the data transmission between Vaicom/VA and DCS runs via UDP and it doesn't hurt to read the first three short paragraphs to better understand why there can be issues here on wikipedia. https://en.wikipedia.org/wiki/User_Datagram_Protocol The important thing here is, that unlike TCP, UDP connections don't set up a proper connection between sender and receiver (no handshake), instead the sender seems to simply propagate datagrams on a specific port and the receiver must listen for it on that same port. I better paste the pertaining wikipedia paragraph highliting the important stuff: "UDP uses a simple connectionless communication model with a minimum of protocol mechanisms. UDP provides checksums for data integrity, and port numbers for addressing different functions at the source and destination of the datagram. It has no handshaking dialogues, and thus exposes the user's program to any unreliability of the underlying network; there is no guarantee of delivery, ordering, or duplicate protection. If error-correction facilities are needed at the network interface level, an application may use Transmission Control Protocol (TCP) or Stream Control Transmission Protocol (SCTP) which are designed for this purpose." Now, i had the problem that the actual voice commands worked fine but only on some missions did the PTT page display the correct module. I spent something like 40 hours over a couple of days trying to find out why that was happening. Neither the trouble shooting information on the Vaicom homepage nor the manual did address in detail what specific requirements Vaicom presuposses in relation to ones windows network settings so you are kind of left in the dark fumbling around. In the end i found out that there is a general "DefaultReceiveWindow" that afaik sets the windows wide buffersize for all incoming network packets unless overridden dynamically by the communicating programs or whatnot. Not entirely sure, but increasing this buffer's size resolved the connection issues on my end. So, windows 7 being older than windows 10 could be the explanation here. If i recall it correctly from my research into this, windows 10 has a DefaultReceiveWindow size of 64Kb, while windows 7 apparently has only 8Kb unless specifically increased dynamically by the communicating programs or increased by the enduser. That is what you need to check and change if need be. This size difference kinda makes sense since back in 2009 when windows 7 launched big ass broadband connections were not the norm for most endusers. Today many folks have 50-500mbit internet connections and windows 10 accounts for that probably from the get go. After i figured out what the problem likely was, i tested increasing size like 10Kb,12Kb, 24Kb etc., and the sweetspot according to my tests was between 10 and 12Kb. Below, the connection on the Caucasus and some missions was not working ok. Hollywood later stated that the datagram size was about 8Kb. Either it's more than 8Kb and the datagrams coming over UDP from DCS simply do not fit into the DefaultReceiveWindow, or the transmission speed and collection by Vaicom are not in sync. No idea. Anyway, now this is how you check and alter the DefaultReceiveWindow on windows 7. Again, windows 10 users probably would never run into this issue since windows 10 has a more than sufficient DefaultReceiveWindow by default. So go read the short description on where and how to check in the windows 7 registry at: http://www.miersengineering.com/2015/03/480/ " Windows 7 has a default maximum upload (and download) rate. To increase the upload/download rate the following can be done: 1) Regedit: [HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \Afd \Parameters] DefaultReceiveWindow = 1024000 DefaultSendWindow = 1024000 If these keys are not present, the default is 8KB for both which was the amount of data 2) If the DefaultSendWindow / DefaultReceiveWindow value is not in there, you will need to add it. Right-click on the right column and choose “New > DWORD Value (32-bit)” and name it DefaultSendWindow (DefaultReceiveWindow). Make sure that you enter it exactly like that, with the first letter of each word capitalized." For me, i did not have this key at all, only the DefaultSendWindow. So i did as advised and added this as per the description above. I set it to its maximum value of 16777216 decimal or 1000000 hexadecimal (16mb). But i am not entirely sure whether this high value i actually applied, there was some conflicting information on various microsoft blogs and other websites. But the default window will be bigger than the default 8KB, and afaik for all network traffic on your system. I have not researched whether this should be an issue or something, so keep that in mind. @Home Fries and Ghost Dad Recon Let me know whether you don't have the registry key and if adding this with a high enough value fixes your issues...i am curious i must admit :) @Hollywood You mentioned that you are going to deprecate win 7 and 8 support in the future. Any specific reason for this? Something that you intend to implement that is not supported by pre windows 10 versions? Because i gotta say, for us privacy minded users it sucks if more and more programs require windows 10, unless there is a really compelling reason for you to do this. From what i know about Vaicom, i don't see any fundamental issue that makes it harder or more failure prone on windows 7 instead of windows 10. Both perfectly support Net. 4.5.2 and we probably now know how to make sure the datagram UDP stuff needs to be checked and configured on windows 7 if stuff is not working properly. Anyway, hope this helps some of you...cheers.

@Ghost Dad Recon do you have the same missing module/aircraft thing happening in the PTT page like Home Fries showed in post 2483? Gonna sit down in 30 mins and type this thing up :)

@Quigon Yeah i know and thats a pity. User made campaigns and those coming with modules are usually easy to edit to exchange a wingman for another client then playing one mission after the other in multiplayer. But as i said, saving ain't possible on the seperate payware campaigns.

Seems like you guys have a similar problem like i had. Will write a post on how to check and fix this tonight, in case you are on win 7. Fairly easy and not a biggy, but finding out about what the problem was was very painful indeed.

Any news on this front? I'd really love to play the Red Knight campaign! Would be a great gesture if FC3 owners and standalone guys where treated equally.

So i reckon the best way to play this campaign is buying the current version in the ED store. But, the OP makes me believe that it initially was planned to be multiplayer/coop playable. Now, is the payed version only SP, or does it support coop? Since payed campaign are DRM protected i know of no way of changing the wingman from ai to client cause you can't save it.

@Ghost Dad Recon @Home Fries Just checking in to make sure you guys are not suffering from the same packet size issue i ran into recently. Are you seeing the correct module/aircraft displayed on the PTT page no matter which map oder mission you are firing up?

The Persian Gulf map becomes evermore enticing :)

I likely upgrade to Virpil stuff from my current TM setup at some point in the future. And i am happy to see that many of the gripes i had with the initial offerings have been addressed. I won't be on the hunt for a new setup for some time to come, but i reckon by the time i do intend to upgrade, pretty much all i want will be available from Virpil. And i do understand everyone who is annoyed that the initial production runs were missing some important features that became available so soon afterwards. Virpils move from contract production to having their own factory made things possible that they themselves might not have anticipated. At the same time, if the things missing from the early versions are so important, you guys must have known that sooner or later either Virpil or VKB would have offered something more suited. For instance, the T-50 was missing the thumb 4/5 push head the Warthog replica has...that was a deal breaker for me so i did not order that one, assuming that this was gonna get fixed in the future,... a lot of folks on the forums were asking for it. But, why don't you sell your current Virpil throttle, it aint old and should still fetch a reasonably good price? I reckon most people don't expect to get the upgraded version at no cost...so take a loss on your current setup and order the new version from Virpil. Though shipping will probably add to that quite a bit.

-Adding a couple of clickable knobs and switches -correcting the turn direction on a couple of dials -english cockpit . . . . -the main campaign is still a no show. Maybe it's in the works for a baltic map and thats why it takes so long :)

As per the manual, VAICOM PRO uses IP ports 33333, 33334, 33491 and 33492 and 44111, all on UDP protocol. Are these ports handling specific parts of the back and forth between Vaicom and Dcs? For instance, which port handles the module and frequency info displayed in the TTP tab? I am trying to find out whether my issue maybe coming from one specific port not being properly setup, although i have no idea what should be wrong with my ports. By the way, increasing/decreasing MTU size from 1500 up to 16000 and down to 576 did not help either. Its a pitty that there is no way for the enduser to diagnose what the problem might be with Vaicoms network protocols. I am stumbling in the dark and have pretty much exhausted all "alter the system environment" gunpowder at this point.