reported Changes to scripts fail integrity check again.

[al531246]

I'm having files in Saved Games failing IC now. It's time for IC to be retired - less and less servers are running it and the devs can't figure it out. 

[Gripen-Whippin]

I just simply cannot FATHOM ,  how a group of people this intelligent, can create the most realistic and dynamic Aviation Combat Simulator in History, but can't fix a few lines of code to fix game-breaking issues. 

I think why so many people are frustrated here, is because MANY of the problems people are encountering have EXTREMELY easy solutions, that would require minimal effort, I'm talking literally seconds in some cases.  FOR EXAMPLE 

PERSISTENCE:    It's actually difficult to comprehend how in 2023, you need to edit the mission.scripting.lua       and literally put  4 "dashes" behind 2 lines of code , in order to be able to save a mission. How is this something that cannot be made into a setting? 

CONTROL MAPPING CONSISTENCY:   This one drives me nuts;   When trying to bind a new aircraft, you're sitting in the cockpit and you hover over a switch/handle/lever  etc...    and it comes up as let's say   " TDC Slew Left".   Okay, so now you go to the controls page and search  " TDC Slew"  ..... BUT WAIT,  NOPE, it's called something COMPLETELY DIFFERENT in the menu.

There's absolutely no reason for this; it can be fixed extremely easily and will help new players immensely when learning what things do. 

Clickable Cockpit Mode :  So for nearly every single aircraft, you have the ability to bind the control "Clickable-Cockpit Mode"  it's default as Alt+c  , then you hop into the Mig-21  , and it's nowhere to be found... It's called "Transpose Mode" or something dumb like that, and not bindable to the mouse.   

Like none of this stuff passes the sniff test.  

Don't get me wrong, I appreciate having new modules as much as everyone else, but like maybe instead of spending every waking minute making new planes, the devs could dedicate some time to fix major Quality of Life issues, and better optimizing the platform. Or even bring in some outside help, perhaps developers with experience in Graphical User Interface design and aesthetics. 

[Rudel_chw]

11 hours ago, Gripen-Whippin said:

MANY of the problems people are encountering have EXTREMELY easy solutions, that would require minimal effort, I'm talking literally seconds in some cases

 

How intelligent people can exagerate to this level, I will never understand it 

[Maverick87Shaka]

On 6/1/2023 at 6:43 AM, Gripen-Whippin said:

PERSISTENCE:    It's actually difficult to comprehend how in 2023, you need to edit the mission.scripting.lua       and literally put  4 "dashes" behind 2 lines of code , in order to be able to save a mission. How is this something that cannot be made into a setting?

Since these four dashes will expose servers or even worst your client to malicious code execution.
If you have de-sanitize mission environment, it's technically possible to look up your drive, and send all the files through socket connection over the internet.

[Se1ko]

On 12/20/2022 at 7:12 PM, c0ff said:

Just FYI, we are following this thread.

Indeed, we need be a better solution to "mods vs cheats problem", not like the current all-or-nothing one.

@c0ff

Hello, is there any further progress on this?

[[HOUNDS] CptTrips]

On 6/5/2023 at 3:50 AM, Maverick87Shaka said:

Since these four dashes will expose servers or even worst your client to malicious code execution.
If you have de-sanitize mission environment, it's technically possible to look up your drive, and send all the files through socket connection over the internet.

 

I'm new to DCS so there might be some gaps in  my understanding of how scripts work in the server\client mode in DCS.

When the server is de-sanitized, that only allows access to the servers file system correct?   That doesn't expose the file system of connecting clients, right?

When the server is de-sanitized, that can only allow access to the file system from scripts running on the server that the server admin himself would have put on, right?  Scripts never run on the connecting clients, right?

 

[Maverick87Shaka]

4 hours ago, [16AGR] CptTrips said:

 

I'm new to DCS so there might be some gaps in  my understanding of how scripts work in the server\client mode in DCS.

When the server is de-sanitized, that only allows access to the servers file system correct?   That doesn't expose the file system of connecting clients, right?

When the server is de-sanitized, that can only allow access to the file system from scripts running on the server that the server admin himself would have put on, right?  Scripts never run on the connecting clients, right?

 

Is correct, scripts will be executed on server side only, so when you de-sanitize a server potentially only the server filesystem is exposed.
I've mentioned in my previous post: "or even worst your client" because on DCS is pretty common use client to host a mission to be flown with a couple of friends.

[[HOUNDS] CptTrips]

12 minutes ago, Maverick87Shaka said:

Is correct, scripts will be executed on server side only, so when you de-sanitize a server potentially only the server filesystem is exposed.
I've mentioned in my previous post: "or even worst your client" because on DCS is pretty common use client to host a mission to be flown with a couple of friends.

OK. 

So only the server is at any risk, and only from the servers own scripts. (Regardless if it is a standalone or in-game server. )

So no servers file system is at any risk from anything a connected client could do.  And the server admin is in control of what scripts he puts on his own server and runs.

 

 

[Se1ko]

Back to the matter of IC and export viewports breaking pure scripts....

When multi-threading was released in a recent patch it initially broke cockpit display exports. MFDs were a mess everywhere.

To my surprise (after being told off like a naughty schoolboy by someone representing ED saying that very few people use cockpit exports so it isnt worth the effort) the display extraction problem was fixed in a matter of days. I was amazed (pleasantly).

The squeaky wheel gets the grease, so cockpit extraction must be a bigger deal and perhaps a lot more people use it than I was was admonished for.

I am also heartened that @c0ff did say they are looking at IC.

I was wondering this:

If ED aren't able to readily change the IC easily for whatever reason, can they modify the script for the aircraft to allow for export of particular instruments?

Case in point; currently in the F-16 it is possible to export the left and right MFDs only which does not break scripts (as far as I am aware). 

Many sim pit creators also break out instruments such as the DED, RWR, and HSI as well, which is where you run into the "Pure Scripts" issue.

Considering that ED must spend a spend a small fortune and a lot of effort on developing 3D models of pilots to satisfy those that use VR headsets (of which I dont use myself but dont begrudge those that do, each to their own), why not add the few lines of extra code to the cockpit scripts of each aircraft that allow users to extract the most needed instrument displays, as mentioned above?

Over time, ED could review each aircraft and its displays and add the extraction code to the cockpit scripts for instruments that would be the most needed to extract by sim pit owners, or even those with an extra screen that would appreciate being able to break out that screen or display if they so wanted (not all of us have the eye sight of a hawk).

Surely it can't be that expensive or time consuming to do, especially when stacked against something like the rendering of a 3D pilot.

Add lines of code to cockpit scripts for the few extra instruments (in the case of the F-16) such as DED, RWR and HSI (throw in the CM panel counters too for good measure) **on top** of the existing capability to export MFDs that you have as standard (which was fine back when DCS was first released, but time, technology and price point of equipment such as monitors has change a lot since then). 

Its easy low hanging fruit that could be introduced across the whole lineup of EDs aircraft over time. Hell, it can be a selling point (just like your expensive 3D pilot). 

That way you can keep your IC and at the same time make a lot of users (more than just a small handful) very happy.

(P.S- the new F-15E has 7 MFD type displays. Do you think that hard-core simmers aren't eventually going to want to break out some simpit extraction for those?)

 

Edited June 17, 2023 by Se1ko
Spelling

[rurounijones]

@Se1ko The work to enable exports of all the other instruments has already been done by the HELIOS team. See my post earlier in this thread (posted 6 months ago) about what ED can do to use that work to get exports to function again for everyone and also fix custom countermeasure programs as well.

It is not difficult work and I do not believe it to be time-consuming. However ED, for whatever reason, does not care to do it nor provide updates on this topic despite multiple people asking @c0ff @BIGNEWY @NineLine for an update multiple times.

Welcome to "How ED reacts to community suggestions, especially low-hanging fruit QoL ones" crash course 101. Leave your optimism on this topic by the door.

Edited June 24, 2023 by rurounijones

[Se1ko]

15 hours ago, rurounijones said:

@Se1ko The work to enable exports of all the other instruments has already been done by the HELIOS team. See my post earlier in this thread (posted 6 months ago) about what ED can do to use that work to exports to function again for everyone and also fix custom countermeasure programs as well.

It is not difficult work and I do not believe it to be time-consuming. However ED, for whatever reason, does not care to do it nor provide updates on this topic despite multiple people asking @c0ff @BIGNEWY @NineLine for an update multiple times.

Welcome to "How ED reacts to community suggestions, especially low-hanging fruit QoL ones" crash course 101. Leave your optimism on this topic by the 

As I've said earlier, the squeaky wheel gets the grease.

In the real world of synthetic training devices for pilot training, where there's a lot more at stake, it is hard to get momentum going with OEMs to implement fixes or changes. You have to keep at them and eventually they look at it (this is from personal experience).

ED is no different. 

There are people making noise about the effect of pure scripts on their DCS experience and its not an insignificant amount. 

I am optimistic things will happen if going forward people offer reasonable solutions to perhaps guide ED's thinking.

[BIGNEWY]

Once we have a solution tested we will let you all know and it will be in a patch. 

I know it can seem slow and we are not meeting your expected timeline, but you will need to be patient. 

thank you

[Se1ko]

16 minutes ago, BIGNEWY said:

Once we have a solution tested we will let you all know and it will be in a patch. 

I know it can seem slow and we are not meeting your expected timeline, but you will need to be patient. 

thank you

Hi @BIGNEWY,

Thanks for the response, sometimes it can feel like you're talking in an empty room.

Without wanting to pressure about a timeline of when things are going to happen, could you perhaps let us know if there is indeed work going on concerning the issue of pure scripts and IC and what that might look like?

[NineLine]

Closing this as it is marked reported. When we have more news on this we will share, if not watch the changelogs for updates. Thanks. 

[NineLine]

On 12/24/2022 at 12:24 AM, rurounijones said:

Helios for instrument exports

Helios literally has a list of patches that they apply to ED files to enable cockpit instrument exports that are currently missing.

https://github.com/HeliosVirtualCockpit/Helios/tree/1.6.5600.0/Patching/Patches/DCS/002_008_00000_33006_00000/Viewports/Mods/aircraft

ED can look at those, validate that they are safe, and then upstream them into DCS itself so that Helios no longer needs to do any patching. Most of them are literaly one-liners. ED can then invite the Helios devs to the Beta Test team so that they can validate changes work with Helios and contribute fixes before new versions go to open beta.

Helios has also been downloaded thousands of times. With a minimal amount of work, ED has now catered to those users. These patches will also fix IC for people who just want to export displays by manually by providing the screens that they can reference in their moitor lua setups.

 

 

I have a question from the devs on this:
"Some changes in those patches are NO GO for example : in Ka-50 they just rename already possible export of named viewport "ABRIS" to "KA_50_ABRIS" ( why not use already unique name ? )

for example i can expose functionality to setup viewport directly to indicator though export API ,
similar functionality ( POPUP ) we already have in internal tools :
https://gyazo.com/174b5846188bcb1ae12e460a60812732"

Let me know and I will respond back to the dev that questioned this. Thanks. 

[MadKreator]

18 hours ago, NineLine said:

I have a question from the devs on this:
"Some changes in those patches are NO GO for example : in Ka-50 they just rename already possible export of named viewport "ABRIS" to "KA_50_ABRIS" ( why not use already unique name ? )

for example i can expose functionality to setup viewport directly to indicator though export API ,
similar functionality ( POPUP ) we already have in internal tools :
https://gyazo.com/174b5846188bcb1ae12e460a60812732"

Let me know and I will respond back to the dev that questioned this. Thanks. 

@NineLine

#1 reason : The “patches” helios applies places the export script “ try_find_assigned_viewport_…”custom name” “ in each of the appropriate aircraft “viewport” files. Doing this along with the custom names allow helios to place viewports ( mfd’s, ehsi, cdu, ded, rwr’s etc etc) in different locations in different sizes for each aircraft using a SINGLE monitor file. F_16_ left mfd, a10c_left mfd, av8b_ left mfd, can all be exported in different sizes in different locations on a single screen when flying the appropriate aircraft, without switching monitor types each time.
- in the ka-50 example, it allows the arbis for the ka_50, ka_50_2, and ka_50_3 to be placed  in different places depending on the profile layout a person chooses to create for each aircraft / variant.

Using the standard method of exporting confines the viewports, say left_mfcd and right_mfcd to be in the same location and same size across ALL aircraft, unless you create a new monitor setup  and switch monitor types for each aircraft.

Helios also configures files like this to be able to export some things which may not be exportable natively.. the DED in the f-16 and CDU in the a-10. <— I could be wrong on if some of these are available or not.

I work closely with the Helios Dev quite often and without clogging up too much of this thread, we can DM, if you want, and I can send you the very specific files and examples of “patches”, monitor setups and all that. Helios isn’t maliciously pulling info from DCS core files, it simply “allows  them, using the tools built into dcs, to export items in different places for each different aircraft. BUT because it needs to  have the custom names inserted and called from the appropriate cockpit viewport file, it fails IC.

Also if you are willing, maybe through discord, I can help get you in touch with the Helios Dev ( maybe you already know who he is) If you would like some more detailed code/script level explanation and examples from the man himself.

Helios, the program is just for creating a graphical interface for cockpit functions. The software itself causes no issues. When it comes to the exported displays, all helios is doing is creating the monitor setup file for you within the format that DCS expects. However the custom names and “patches”  are necessary to facilitate the “#1 reason” above. 

 I think the bottom line is, if each “viewport” for each aircraft already had a specific/ alternate name (av8b_left_mfd, f5e_rwr etc) that could be called , instead of a generic “ left_mfcd, right_mfcd” blanket covering all aircraft, then there wouldn’t be a reason for helios to “patch” anything and create the custom naming using “try_find_assigned_viewport_“custom name”. This  would, in turn, negate the IC failures from modified scripts…
OR if this sort of API was exposed and available on the user end and not an internal SDK, then that could completely change the game, being able to drag and drop exports
 

 

Edited April 26 by MadKreator

[MadKreator]

@NineLine Helios dev is going to reply  soon. Please await his more educated response

[NineLine]

On 4/26/2024 at 10:52 AM, MadKreator said:

@NineLine Helios dev is going to reply  soon. Please await his more educated response

Thanks!

 

[MadKreator]

1 hour ago, NineLine said:

Thanks!

 

No prob! He will be more tactful than I in his words and he speaks the language only a software developer could love  If it would be better for him to DM you, I will relay it to him. 

Edited April 30 by MadKreator

[BluFinBima]

@NineLine and un-named ED Dev.  Many thanks to both of you for taking the time to follow up on this.  I’m one of the Helios developers and Helios is a free suite of programs which makes use of changes to module Lua files to allow users to create 2D virtual cockpits which enhances their sim experience.
  

In response to the suggestion of making the internal “Pop-up” available in the exports API, I think this is likely to be a viable alternative to the current mechanism.  The API would probably need the following capabilities if it is to replace the viewports which are currently in use:

1. Allow pop-ups for all viewports which can be created today - not just those which have a viewport name defined in the module Lua.

2. Allow multiple pop-ups

3. Get & Set the position and size of the pop-up.

4. Open & Close a named pop-up.  It would be nice (but not essential) to have the ability to Close all pop-ups with a single API call.

5. expose the list of available pop-ups and their default sizes

6. Have unique pop-ups for each cockpit (eg AH-64D would have one for Pilot Left MPD and another one for CP/G Left MPD)

7. Work with all modules, not just the ED developed ones

8. The brightness & contrast of the pop-up should change with the brightness & contrast of the in-game device.

9. It would also be very helpful to have the Export API expose the name of the active cockpit for multi-cockpit modules (maybe this exists today, but I have not found a way to determine this).  This is needed to change pop-ups when the cockpit position changes.

On 4/25/2024 at 12:46 PM, NineLine said:

I have a question from the devs on this:
"Some changes in those patches are NO GO for example : in Ka-50 they just rename already possible export of named viewport "ABRIS" to "KA_50_ABRIS" ( why not use already unique name ? )

 

This is a reasonable question in the case of "ABRIS", and of course we could just use "ABRIS" in this specific case.  I didn't write this patch but there have been instances where modules in early access do not initially have a viewport name defined so in this particular case, possibly the Helios patch name came before the official viewport name.  Regardless, there are quite a few viewports which cannot be exported without Lua being changed to insert a “dofile” for “ViewportHandling.lua” and a name for the viewport.  Multi-cockpit is another case where it is beneficial to have both a general viewport name and a specific viewport name.  As for the names themselves, it is beneficial for readability of the monitor setup Lua if the name of the viewport contains the module which the viewport refers to.
Finally, there have been some viewports which are not rendered well, and the values for stroke / fuzziness have been changed to improve the readability of that viewport.  Hopefully a pop-up will not suffer from the same sort of problem.  The FA-18C RWR is one example of this.

Once again, many thanks for being open to addressing the very common concern from users about not having pure scripts while in MP.  I'm obviously very happy to provide any other information you think might be useful.

Regards, BlueFin

 

[NineLine]

On 4/30/2024 at 2:19 AM, BluFinBima said:

@NineLine and un-named ED Dev.  Many thanks to both of you for taking the time to follow up on this.  I’m one of the Helios developers and Helios is a free suite of programs which makes use of changes to module Lua files to allow users to create 2D virtual cockpits which enhances their sim experience.
  

In response to the suggestion of making the internal “Pop-up” available in the exports API, I think this is likely to be a viable alternative to the current mechanism.  The API would probably need the following capabilities if it is to replace the viewports which are currently in use:

1. Allow pop-ups for all viewports which can be created today - not just those which have a viewport name defined in the module Lua.

2. Allow multiple pop-ups

3. Get & Set the position and size of the pop-up.

4. Open & Close a named pop-up.  It would be nice (but not essential) to have the ability to Close all pop-ups with a single API call.

5. expose the list of available pop-ups and their default sizes

6. Have unique pop-ups for each cockpit (eg AH-64D would have one for Pilot Left MPD and another one for CP/G Left MPD)

7. Work with all modules, not just the ED developed ones

8. The brightness & contrast of the pop-up should change with the brightness & contrast of the in-game device.

9. It would also be very helpful to have the Export API expose the name of the active cockpit for multi-cockpit modules (maybe this exists today, but I have not found a way to determine this).  This is needed to change pop-ups when the cockpit position changes.

This is a reasonable question in the case of "ABRIS", and of course we could just use "ABRIS" in this specific case.  I didn't write this patch but there have been instances where modules in early access do not initially have a viewport name defined so in this particular case, possibly the Helios patch name came before the official viewport name.  Regardless, there are quite a few viewports which cannot be exported without Lua being changed to insert a “dofile” for “ViewportHandling.lua” and a name for the viewport.  Multi-cockpit is another case where it is beneficial to have both a general viewport name and a specific viewport name.  As for the names themselves, it is beneficial for readability of the monitor setup Lua if the name of the viewport contains the module which the viewport refers to.
Finally, there have been some viewports which are not rendered well, and the values for stroke / fuzziness have been changed to improve the readability of that viewport.  Hopefully a pop-up will not suffer from the same sort of problem.  The FA-18C RWR is one example of this.

Once again, many thanks for being open to addressing the very common concern from users about not having pure scripts while in MP.  I'm obviously very happy to provide any other information you think might be useful.

Regards, BlueFin

 

 

Thank you I have passed this along!

[MadKreator]

Thank you @NineLine You're the man!

[rurounijones]

@NineLine @BluFinBimaI am not raelly following the nuances of the "Pop up API" details so forgive me if I am stating the obvious or something that is alrady understood; but i would just like to make sure that this conversation does not only benefit Helios users but also people who are just using MonitorSetup.lua with the Helios patches to add viewports to separate monitors can still do so easily: e.g.

Displaying Mirage 2000 RWR on separate monitor:

Mirage_RWR =
{
     x = 1110;
     y = 1360;
     width = 800;
     height = 800;
}

Which is what the current Helios patches help with by exposing viewports missed by ED and third-party developers (For example adding the missing M-2000 VTB export) so they can be added to MonitorSetup.lua which is a "good enough" solution that should not be ignored in favour of some "perfect" API.

Edited May 6 by rurounijones

[BluFinBima]

@rurounijonesMy comments relating to pop-ups being exposed in the Export API are based on ED's comment about the changes being made by DCS users to export viewports

Quote

 Some changes in those patches are NO GO

This appears to be a "red line" for ED, so if people want to pass the integrity check, then it appears that something new is needed.  ED seems to be offering a route forward.

Helios's role in this is simply to make the viewport changes more convenient.  If Helios did not exist, the Lua changes would simply be made manually.

If pop-ups were to be implemented the way I described above, then I would expect everyone to be able to use the same API.  The only constituency I think might have additional requirements are VR users.  I know that there is some who want transparent viewports/pop-ups when in VR.

I hope this clarifies my update.

[MadKreator]

On 4/25/2024 at 1:46 PM, NineLine said:

for example i can expose functionality to setup viewport directly to indicator though export API ,
similar functionality ( POPUP ) we already have in internal tools :

@bluefin I suppose I didn’t read this with the right mindset either. I was taking it as him sayin that THEY can just do it on their end. I wasn’t realizing that he was ( hopefully) implying that he CAN expose the same functionality to all of us…. Falls right in line with our conversation yesterday.. now I’m the guilty one If the tool is already there on their end then that seems like the most logical route to take, IF that was in fact an offer for a solution

Edited May 10 by MadKreator