Jump to content

Mission design under valued by ED?


FubarBundy

Recommended Posts

Slightly OT, I agree also that the ME can do a bunch of things that satisfies most parties. For anyone wanting to get really complex it gets into the realms of scripting. There comes a point where adding more ME functionality is counterintuitive, it's made for people with a certain level, somewhere above casual gameplay and beneath a power user/coder level.

 

I work with a product that tried to do the same and made a reporting tool that tried to make MS SQL easier. It was pointless, by the time you knew what you were querying with it, you outgrew it and just learned SQL instead. ME and scripting can also be combined, for people of my level which is "hard core tinkerer", ie i use scripts, use snippets but tend to use them with the triggers and logic in the ME.

 

The only thing the ME needs is to stop corrupting the occasional misison and intelligently recognise when a script has changed and re-add it. And I've got ways around those too now.

 

In comparison, I can crash the entire game with one line of code that was previously fine. This, and some really silly group errors that started when we got multicrew that allow clients in the same group, amongst other things is what we are talkign about more recently in the post, anmd shoudl set a better comparison for discussion.

  • Like 1

___________________________________________________________________________

SIMPLE SCENERY SAVING * SIMPLE GROUP SAVING * SIMPLE STATIC SAVING *

Link to comment
Share on other sites

Besides I don't really know why you are looking on a wiki for official statement... it is a wiki article after-all.

Where else can I look for official statement & documentation on SSE?


Edited by Whisper

Whisper of old OFP & C6 forums, now Kalbuth.

Specs : i7 6700K / MSI 1070 / 32G RAM / SSD / Rift S / Virpil MongooseT50 / Virpil T50 CM2 Throttle / MFG Crosswind.

All but Viggen, Yak52 & F16

Link to comment
Share on other sites

Here's my $.02 on the subject:

 

Both sides have legitimate arguments. I've been in software development and performed work across the entire "Engineering V", so I can get behind what Sith is saying. If you're completely changing the code base, then applying fixes to a soon-to-be-obsolete code base is about as effective as rearranging deck chairs on the Titanic. However, if the Titanic is taking a long time to sink, and rearranging the chairs doesn't require much time or effort, then perhaps it is useful to give people a better view of the iceberg for the time being.

 

Now that I've stretched that analogy as far as it will go, here's what I mean by it. Everybody who has posted in this thread is recognized as a contributor in some form, and we have all put time into our projects to make DCS better for everybody. We're all enthusiasts who accept imperfection, but don't want to get mired in a never-ending debug cycle. I know that some of my projects I put on hold over two years ago, when I was waiting for 2.0 final to be released in December of 2014. I still haven't gone back to them because I don't know whether the effort is worth it. It's also why I've stuck with skins of late. However, if I knew that something was going to be stable (albeit not yet complete) for six months or a year, I would put some effort into updating those projects.

 

I get delays, and I understand and appreciate the why, but if we got some proactive communication that would go a long way. It could be as simple as a statement in this forum saying that certain netcode was worked on, and we may want to test certain group and individual triggers in the new build. It could be acknowledgement of bug reports (this has gotten a lot better of late).

 

We all want a better DCS. More bi-directional communication can only help.

Link to comment
Share on other sites

@Ignition,

 

I understand where you are coming from, but maybe the way you formulated it is a bit harsh. The mission editor is good. It has many functionalities that allow you to create nice missions, without having to code anything.

It also is a great platform to "try things out". I mean, it inductively does more than you think. There are indeed things we want to see improved, but still, it is what it is. Not going into details here, as other posts and threads are for this.

 

Let's call it that the ME has its limits. For those who want (to try) more, there are solutions. It is either:

- Use the core DCS API.

- Use frameworks like MIST or MOOSE.

- Use both.

 

Learning lua is not a bad thing to be honest. If you learn to code, you'll find a new world and it will open your horizons or just for plain amusement. I know not everyone will agree, but that is normal too :-)

 

It is very hard to create a mission editor "that can do all". And if such would exist, it would become so complex, that this fact would hold off people from the product too. Wouldn't you agree?

 

FC

 

Maybe the way I said it was harsh yeah. I started doing mission on the ME but the amount of work to do what I wanted was really big and the missions ended to be really "basic" with random things but predictable. The way to have respawn or random paths is almost inexistant and those are basic features on a mission.

 

Then I went to MIST which opened a lot of doors to me and let me do what I wanted and then I went to MOOSE (thanks for that) and its really amazing, I can do exactly what I want and in a easier way and gave me even more tools. I can do big missions very fast with a lot of variables.

 

I know its hard to do a ME with all this features I know but I'm sure if it had more tools with a easy UI were more people could do mission, this game would be a LOT better.

 

I also know ED its focused on 2.5 and thats amazing too but the mission editor needs much more work. A lot of people rely on others to make missions so they can fly, what if everyone could do missions without the need to learn a programing language to play a game.

 

At least I hope as ENO said that ED support their community and giving the scripting guys the help they need to update their work because its what makes this game unique and excelent as it is.

 

Just imagine if we didn't have any of these tools, amazing detailed aircraft with barebones mission to play with.

Link to comment
Share on other sites

My biggest gripe is the lack of documentation. There's just not enough information available and you know it's bad when google doesn't help.

 

My second biggest gripe is that lua really doesn't do a whole lot - i mean yeah you can respawn some units and setup patrols but it's really really limited in what it can do. In fact you can do almost anything you need to in game with triggers, there isn't a whole lot that lua has a purpose for unless you are building mods where the support is better.

 

Third is the general unstableness of mission design in general - one day it will work, the next day it wont.

Developer of Kaukasus Insurgency - a customizable Dynamic PvE Campaign with cloud hosting and stats tracking. (Alpha)

 

http://kaukasusinsurgency.com/

Link to comment
Share on other sites

My biggest gripe is the lack of documentation. There's just not enough information available and you know it's bad when google doesn't help.

 

My second biggest gripe is that lua really doesn't do a whole lot - i mean yeah you can respawn some units and setup patrols but it's really really limited in what it can do. In fact you can do almost anything you need to in game with triggers, there isn't a whole lot that lua has a purpose for unless you are building mods where the support is better.

 

Third is the general unstableness of mission design in general - one day it will work, the next day it wont.

 

Well I think is the other way. I think with lua (MIST and MOOSE) you can do a lot of things that you can't do with the mission editor alone.

 

You can't have random units/groups and paths or respawn with limits for the 2 sides and a LOT of other things.(Yes you can do it but it will be very very limited.) You can't even do a ground group to patrol an area.

 

But if you want to make a simple and fast mission the mission editor is the best choice but it will not have replayability.

Link to comment
Share on other sites

My biggest gripe is the lack of documentation. There's just not enough information available and you know it's bad when google doesn't help.

 

My second biggest gripe is that lua really doesn't do a whole lot - i mean yeah you can respawn some units and setup patrols but it's really really limited in what it can do. In fact you can do almost anything you need to in game with triggers, there isn't a whole lot that lua has a purpose for unless you are building mods where the support is better.

 

1. Can't speak for the ED documentation, suffice to say the PDF is somewhat out of date, just look at the UI style used in it compared to what we have now. Some of us have tried to create useful documentation. This whole forum section has plenty of threads of people helping each other out with assorted issues. Again, I feel I must link to the hoggit wiki where we've tried to get a little more in-depth in terms of documentation.

 

2. Really the only thing that triggers can do that lua can't is stuff associated directly with player aircraft and the specific aircraft they are flying. For example can't set failures, add cargo mass, know what cockpit instruments are reading, etc. My whole attitude of triggers vs scripting is that they both have a lot of overlap, but as soon as you start to create certain types of missions or logic then the complexity and workload required to do it with triggers becomes stupid high. Case in point is all of the wonderful scripts that automate anything. Doing that with triggers would be a nightmare, plus it wouldn't be easily "transportable" for you to use with other missions or allow you to add it to existing missions.

The right man in the wrong place makes all the difference in the world.

Current Projects:  Grayflag ServerScripting Wiki

Useful Links: Mission Scripting Tools MIST-(GitHub) MIST-(Thread)

 SLMOD, Wiki wishlist, Mission Editing Wiki!, Mission Building Forum

Link to comment
Share on other sites

  • ED Team

To expand on number one, much of the documentation is woefully behind, and its been reported, so its known and they know it needs to be done, we (Testers and such) just have to keep on it.

 

As Grimes said though, this forum is chuck full of knowledgeable people, and I dont see many question if any go un-answered, Grimes being very active here and very smart with all this coding mumbo jumbo is a big part of it.

 

So while ED fights their way to 2.5, we just have to hold on a little longer and hope more focus will come around after that, until then, the coding guess are one of the strongest parts of this community, and always very helpful.

 

1. Can't speak for the ED documentation, suffice to say the PDF is somewhat out of date, just look at the UI style used in it compared to what we have now. Some of us have tried to create useful documentation. This whole forum section has plenty of threads of people helping each other out with assorted issues. Again, I feel I must link to the hoggit wiki where we've tried to get a little more in-depth in terms of documentation.

 

2. Really the only thing that triggers can do that lua can't is stuff associated directly with player aircraft and the specific aircraft they are flying. For example can't set failures, add cargo mass, know what cockpit instruments are reading, etc. My whole attitude of triggers vs scripting is that they both have a lot of overlap, but as soon as you start to create certain types of missions or logic then the complexity and workload required to do it with triggers becomes stupid high. Case in point is all of the wonderful scripts that automate anything. Doing that with triggers would be a nightmare, plus it wouldn't be easily "transportable" for you to use with other missions or allow you to add it to existing missions.

64Sig.png
Forum RulesMy YouTube • My Discord - NineLine#0440• **How to Report a Bug**

1146563203_makefg(6).png.82dab0a01be3a361522f3fff75916ba4.png  80141746_makefg(1).png.6fa028f2fe35222644e87c786da1fabb.png  28661714_makefg(2).png.b3816386a8f83b0cceab6cb43ae2477e.png  389390805_makefg(3).png.bca83a238dd2aaf235ea3ce2873b55bc.png  216757889_makefg(4).png.35cb826069cdae5c1a164a94deaff377.png  1359338181_makefg(5).png.e6135dea01fa097e5d841ee5fb3c2dc5.png

Link to comment
Share on other sites

So much hope being stacked on the skip up to the version of DCS that it seems almost scary.

 

Let's all hope we can do a full reset and get back on an even keel. :)

To expand on number one, much of the documentation is woefully behind, and its been reported, so its known and they know it needs to be done, we (Testers and such) just have to keep on it.

 

As Grimes said though, this forum is chuck full of knowledgeable people, and I dont see many question if any go un-answered, Grimes being very active here and very smart with all this coding mumbo jumbo is a big part of it.

 

So while ED fights their way to 2.5, we just have to hold on a little longer and hope more focus will come around after that, until then, the coding guess are one of the strongest parts of this community, and always very helpful.

___________________________________________________________________________

SIMPLE SCENERY SAVING * SIMPLE GROUP SAVING * SIMPLE STATIC SAVING *

Link to comment
Share on other sites

With regards to the titel: Mission design under valued by ED?

 

I understand the importance of the 2.5 release and not doing all kind of script engine alterations while in this process.

 

I like the open structure of the script engine and I think .lua is not that difficult if you have any knowlege of programming language principles. So it's doable and rewarding to make missions for DCS. But all kind of minor and bigger script functions broke since 2015? Many got repaired, although it was never 100% clear when or if they where repaired (even if you think I exaggerate, you understand what I mean) That made me loose motivation to make anything with .lua.

 

Furthermore I noticed something I don't particularly like in the file structure of new map(s). The static objects or vehicles are not usable anymore. So no more freedom in making stories as envisioned with those nice new items in NTTR.

 

But as I understand 2.5 will tell if ED likes there misssion designer community. Then new objects will be usable and script functions can be used as if it where 2014.

 

 

 

 

 

 

:)

Link to comment
Share on other sites

1. Can't speak for the ED documentation, suffice to say the PDF is somewhat out of date, just look at the UI style used in it compared to what we have now. Some of us have tried to create useful documentation. This whole forum section has plenty of threads of people helping each other out with assorted issues. Again, I feel I must link to the hoggit wiki where we've tried to get a little more in-depth in terms of documentation.

 

2. Really the only thing that triggers can do that lua can't is stuff associated directly with player aircraft and the specific aircraft they are flying. For example can't set failures, add cargo mass, know what cockpit instruments are reading, etc. My whole attitude of triggers vs scripting is that they both have a lot of overlap, but as soon as you start to create certain types of missions or logic then the complexity and workload required to do it with triggers becomes stupid high. Case in point is all of the wonderful scripts that automate anything. Doing that with triggers would be a nightmare, plus it wouldn't be easily "transportable" for you to use with other missions or allow you to add it to existing missions.

 

I'm really greatful for the hoggit wiki - it is my main go to place when I need to learn about what kind of calls I need to use and what to pass into them, and it's similar to how the Arma wiki is setup so finding stuff is relatively easy. However there's stuff that's not well explained that I can't find anywhere (how to setup IPC between DCS and an external program, how to connect to luasocket, interop, etc, the various lua environments (mission editor, simulation, external, etc))

 

For number 2, that's partially my point - cockpit arguments can only be done in triggers, and there's no way to poll a unit for their active radio and frequency. You also can't script dialog. As far as I can tell from searching, there's no way to create triggers in lua. I don't see methods for getting a units health, setting damage to a unit, moveToPosition command, setting weather, adjusting in game time, controlling mission flow logic, missing events (landed, hit, takeoff, flares, chaff).

 

Some other frustrations: can't log boolean variables using env (but this is a limitation of lua it seems). Flags are terrible imo. Considering the majority of trigger functionality is based on an indexed variable with no name, it becomes unwieldy to understand what some trigger logic is doing when all you see is (flagActive(51) && flag(100)==2) - that doesn't explain anything to the coder. It's the equivalent of obfuscating all variables in code to A, B, C, etc... If we could give meaningful names to them that would help greatly.

 

I also tried declaring and using a global variable instead of a flag, but I couldn't get it to work; it's not explained how far reaching the global scope is (is it accessible to each trigger do script? each units action do script? when is it initialized?). There's no explanation on when different parts of the simulation and scripting are initialized.

 

Perhaps I'm being too rough on DCS, because I have an existing base to compare it with (Arma) which has a more complete suite of mission editing capabilities. But it also means that there's little incentive for me to work with LUA in dcs if there's no support for some of the things I would like to do above.

Developer of Kaukasus Insurgency - a customizable Dynamic PvE Campaign with cloud hosting and stats tracking. (Alpha)

 

http://kaukasusinsurgency.com/

Link to comment
Share on other sites

The wiki is very much focused only on the scripting engine and mission editor. I frankly don't know all that much about the other lua environments to the point that I can write documentation on it. Besides having to use luasocket is more the purview of "game modification" as I believe the only way to do it purely within the scripting engine is to modify a few files. It can be done on the server side because that is what slmod uses to interact between the server and mission environments. It is a wiki though and if anyone has that know-how then they are free to add to it.

 

No argument from here that there needs to be more triggers and scripting functions. Even when you think you've added enough, there will still be something new to add.

The right man in the wrong place makes all the difference in the world.

Current Projects:  Grayflag ServerScripting Wiki

Useful Links: Mission Scripting Tools MIST-(GitHub) MIST-(Thread)

 SLMOD, Wiki wishlist, Mission Editing Wiki!, Mission Building Forum

Link to comment
Share on other sites

Flags are terrible imo. Considering the majority of trigger functionality is based on an indexed variable with no name, it becomes unwieldy to understand what some trigger logic is doing when all you see is (flagActive(51) && flag(100)==2) - that doesn't explain anything to the coder. It's the equivalent of obfuscating all variables in code to A, B, C, etc... If we could give meaningful names to them that would help greatly.

 

Here is a flag scheme. Use this convention and a flag is directly tied to a Coalition/Group/Unit/State, or a Zone.

WC's Flags.txt

Visit the Hollo Pointe DCS World server -- an open server with a variety of COOP & H2H missions including Combined Arms. All released missions are available for free download, modification and public hosting, from my Wrecking Crew Projects site.

Link to comment
Share on other sites

My biggest gripe is the lack of documentation. There's just not enough information available and you know it's bad when google doesn't help.

 

My second biggest gripe is that lua really doesn't do a whole lot - i mean yeah you can respawn some units and setup patrols but it's really really limited in what it can do. In fact you can do almost anything you need to in game with triggers, there isn't a whole lot that lua has a purpose for unless you are building mods where the support is better.

 

Third is the general unstableness of mission design in general - one day it will work, the next day it wont.

 

Hi there, you wrote that lua doesn't do a lot... Can you elaborate a bit more on this? I mean, why do you say such. Am afraid you're missing out on the good stuff...

 

FC

[TABLE][sIGPIC][/sIGPIC]|

[/TABLE]

Link to comment
Share on other sites

Flags are terrible imo. Considering the majority of trigger functionality is based on an indexed variable with no name, it becomes unwieldy to understand what some trigger logic is doing when all you see is (flagActive(51) && flag(100)==2) - that doesn't explain anything to the coder. It's the equivalent of obfuscating all variables in code to A, B, C, etc... If we could give meaningful names to them that would help greatly.

 

 

 

On this one I completely agree. If you're looking for an alternative method, have a look here:

 

This will simply your mission building a lot.

[TABLE][sIGPIC][/sIGPIC]|

[/TABLE]

Link to comment
Share on other sites

  • 4 weeks later...
Well obviously you have decided that those 3 issue that happen to have direct examples associated with code you have written should have a severity of block. Likewise I could probably find some guy to complain about missile flight models who thinks the missile-FM behavior is a block. Would probably be able to find a damage model guy, 3d model/texture rivet counter, etc. Even within mission editing there are the triggers and scripting, both may have bugs, and to the people who use the different systems there are different bugs that effect each. Point I am trying to make is that there are all these bugs and to each person certain bugs are more important than others.

 

Grimes,

 

I understand the viewpoint and reasoning.

 

However, please don't misunderstand my post. Reading behind the lines, the post I wrote earlier was coming from many voices in the community and was trying to support them with this communication. The post was not only for the code i wrote myself and to support my own ambitions. It was meant to help users.

 

Sven

[TABLE][sIGPIC][/sIGPIC]|

[/TABLE]

Link to comment
Share on other sites

Hi there, you wrote that lua doesn't do a lot... Can you elaborate a bit more on this? I mean, why do you say such. Am afraid you're missing out on the good stuff...

 

FC

 

It's probably somewhat subjective but I can easily come with a few limitations that shouldn't be hard to remove to make the life much easier, and enhance the missions.

 

- No persistence between missions or when repeating a mission is a very annoying limitation which could be easily removed, off the top of my head being able to load/store files in a fixed directory would already bring a lot of possibilities.

 

- The LUA PREDICATE condition field, which is broken, is also a bit sad and requires convoluted and awkward work-arounds.

 

- Not being able to access the cockpit would currently be another major drawback to Lua scripting for me. Any tutorial mission would benefit from it, and simplify the logic. Check if a set of switches are in the correct position and if not, highlight them for instance. Or monitor the gauges / controls. Instead huge lists of repetitive conditions and actions are necessary, which render the missions prone to bugs and almost impossible to maintain (not mentioning it's not possible to copy a set of triggers to another existing mission).

 

So Lua, while being a bit of a weirdo language, could still allow a lot of creativity and simplifications, but the interface to the aircraft is very limited. And trying to mix what is accessible from Lua, and what is accessible from the ME is not user-friendly (or dev-friendly) to say the least.

System specs: Win7 x64 | CPU: i7-4770K | RAM: 16 GB | GPU: GTX 980 Ti 6 GB | Thrustmaster HOTAS | MFG rudder pedals | SATA3 SSD | TrackIR

Link to comment
Share on other sites

It's probably somewhat subjective but I can easily come with a few limitations that shouldn't be hard to remove to make the life much easier, and enhance the missions.

 

- No persistence between missions or when repeating a mission is a very annoying limitation which could be easily removed, off the top of my head being able to load/store files in a fixed directory would already bring a lot of possibilities.

 

- The LUA PREDICATE condition field, which is broken, is also a bit sad and requires convoluted and awkward work-arounds.

 

- Not being able to access the cockpit would currently be another major drawback to Lua scripting for me. Any tutorial mission would benefit from it, and simplify the logic. Check if a set of switches are in the correct position and if not, highlight them for instance. Or monitor the gauges / controls. Instead huge lists of repetitive conditions and actions are necessary, which render the missions prone to bugs and almost impossible to maintain (not mentioning it's not possible to copy a set of triggers to another existing mission).

 

So Lua, while being a bit of a weirdo language, could still allow a lot of creativity and simplifications, but the interface to the aircraft is very limited. And trying to mix what is accessible from Lua, and what is accessible from the ME is not user-friendly (or dev-friendly) to say the least.

 

With lua you can do a lot in DCS. It opens up a new world for you in mission design.

There are a couple of lua frameworks that you can use and these will accelerate your lua development. Example are MIST, MOOSE, .... On top there are many scripts available made by skilled flight simulator enthousiasts that you can use.

 

I really advise you check on some of these frameworks. I leave it up to you which one you prefer.

 

To close this post, LUA is a fantastic scripting language and it opens up the power of DCS. Don't underestimate what is available out there by the community if you are open for something new.

 

Fc

[TABLE][sIGPIC][/sIGPIC]|

[/TABLE]

Link to comment
Share on other sites

I know those frameworks, thanks all the same :)

 

I'm just pointing out a few simple improvements, in answer to a previously asked question. AFAIK, those frameworks don't address those problems because they're current limitations in DCS.

System specs: Win7 x64 | CPU: i7-4770K | RAM: 16 GB | GPU: GTX 980 Ti 6 GB | Thrustmaster HOTAS | MFG rudder pedals | SATA3 SSD | TrackIR

Link to comment
Share on other sites

It's probably somewhat subjective but I can easily come with a few limitations that shouldn't be hard to remove to make the life much easier, and enhance the missions.

 

- No persistence between missions or when repeating a mission is a very annoying limitation which could be easily removed, off the top of my head being able to load/store files in a fixed directory would already bring a lot of possibilities.

 

- The LUA PREDICATE condition field, which is broken, is also a bit sad and requires convoluted and awkward work-arounds.

 

- Not being able to access the cockpit would currently be another major drawback to Lua scripting for me. Any tutorial mission would benefit from it, and simplify the logic. Check if a set of switches are in the correct position and if not, highlight them for instance. Or monitor the gauges / controls. Instead huge lists of repetitive conditions and actions are necessary, which render the missions prone to bugs and almost impossible to maintain (not mentioning it's not possible to copy a set of triggers to another existing mission).

 

So Lua, while being a bit of a weirdo language, could still allow a lot of creativity and simplifications, but the interface to the aircraft is very limited. And trying to mix what is accessible from Lua, and what is accessible from the ME is not user-friendly (or dev-friendly) to say the least.

 

Besides LUA Predicate, the issues you have with LUA have absolutely nothing to do with LUA. What you describe sounds like you are talking about the DCS API which is separate from LUA.

Link to comment
Share on other sites

I know those frameworks, thanks all the same :)

 

I'm just pointing out a few simple improvements, in answer to a previously asked question. AFAIK, those frameworks don't address those problems because they're current limitations in DCS.

 

Hello Redglyph,

 

Yes and no.

 

If you know those frameworks, then i think you know what they provide and do, good for you!

 

But I get your view on DCS. Yes, it has limitations, many.

However, DCS is still a fantastic simulator, isn't it?

 

The DCS is however not limited, just, there are things that people would like to see added, no?

- Which task an AI is doing at the moment?

- Control unit machinery (like open close cargo bays).

- Control lighting on units.

- Shut down and Start engines.

- Be able to move AI ground units separately from the group.

- Better control of airport safety regulations

- ....... Shall i continue?

 

And lua predicates, if you think that is a problem;

who still needs that? Some lines of code hidden deeply in your mission file?

 

There are other ways of dealing with lua code in missions: Frameworks:

1 mission lua file contains all.

No triggers in your miz files

No lua predicates in your miz files

No waypoint lua code in your miz files

No configuration of options etc on waypoints, but dynamically set.

Copy/paste code

Upgrade, release

...

 

Not saying that goal is achieved today 100%, but getting there... Every release of the framework is a step closer to that goal.

 

So, I understand what you're saying, and you're probably a good lua coder too, but had to read behind the lines to get that context.

 

Just an additional question, you find LUA an awkward language. What is not an awkward language according to you?

May I remind you that LUA is the de-facto standard in the gaming industry for scripting?

 

FC

[TABLE][sIGPIC][/sIGPIC]|

[/TABLE]

Link to comment
Share on other sites

Whilst not being an elegant solution, DAWS savestate has been saving mission states for quite a long time now. The next iteration will bring it into the UI of DCS for simplicity. Yes , its a mod, but then without it, you can't save a mission. I don;t know that it's simple, as you say, the code runs into thousands of lines, so I think the developer would like to defend the view that it's simple, as he has worked on it for many months, but then i'm sure you used the word in a throwaway sense.

 

For accessing cockpit this gets into a different design kettle of fish, access to affect clients from the server side is not allowed, the reasons seem obvious to me, the thought of allowing talented coders access to my controls in Multiplayer are quite scary. This applies to adjusting a helicopters weight in MP too at one level. Nevertheless access to positions and indicators is possible and is done in all the tutorials for start up that you see, so unsure what the limitation you need resolved is.

 

LUA Predicate is often spoken of. I'm not finding a need for it, you can trigger LUA in other ways, it's just a defunct box until resolved, if at all. If you need to run Lua there are conditions and so on that cover the use case, but I haven't thought of one that doesn't match.

 

As for being an unfriendly interface, I'm sure everyone understand that if you want complexity, you get compelxity. Anything complex isn't achieved that easily, though I find the current scripting efforts in the community have 90% resovled that by simply adding their scripts and a couple of lines to a file, which is terribly easy. I can definitely agree that DCS is complex all over, but I have to admit not being able to see all your points in the same light as yourself, as is pretty common inbetween individuals.

It's probably somewhat subjective but I can easily come with a few limitations that shouldn't be hard to remove to make the life much easier, and enhance the missions.

 

- No persistence between missions or when repeating a mission is a very annoying limitation which could be easily removed, off the top of my head being able to load/store files in a fixed directory would already bring a lot of possibilities.

 

- The LUA PREDICATE condition field, which is broken, is also a bit sad and requires convoluted and awkward work-arounds.

 

- Not being able to access the cockpit would currently be another major drawback to Lua scripting for me. Any tutorial mission would benefit from it, and simplify the logic. Check if a set of switches are in the correct position and if not, highlight them for instance. Or monitor the gauges / controls. Instead huge lists of repetitive conditions and actions are necessary, which render the missions prone to bugs and almost impossible to maintain (not mentioning it's not possible to copy a set of triggers to another existing mission).

 

So Lua, while being a bit of a weirdo language, could still allow a lot of creativity and simplifications, but the interface to the aircraft is very limited. And trying to mix what is accessible from Lua, and what is accessible from the ME is not user-friendly (or dev-friendly) to say the least.

___________________________________________________________________________

SIMPLE SCENERY SAVING * SIMPLE GROUP SAVING * SIMPLE STATIC SAVING *

Link to comment
Share on other sites

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...