Mission design under valued by ED?

I remember back when you guys folded your tents. The Firehouse lasted awhile after but then I was running into the same problems you were with missions breaking constantly and not having the expertise to fix them without tearing them apart and redoing them.

I've been gone about two years... tried coming back in around November of last year but couldn't even get my server to run after trying every trick in the book. I got one flight in and bailed- memories of the frustration were overwhelming.

A few friends of mine in town started playing it in single player so that gave me the bug to go back at it again. Always loved the multiplayer aspect but it was so much more fun to run missions together.

I'd like to give it an honest try again, knowing full well that any effort I put into making missions is a letter of code from being a waste of time.

ENO, my friend. How are you! All okay?

I completely share your thoughts. Those who are (bug) fans of the game could get a bit more of attention, wouldn't you think? But unfortunately it is not done...

Anyway, don't loose your spirit man. Life had so much more to offer than this simulation. I advise you join back in and let the good times come.

FC

Hi all,

This is, in some part, a reaction to FlightControl's decision to stop work on the wonderful Moose project and, in some part, a rant that's been a long time coming.

 

I have been running a server, (CoffinDodger) for some time now but it is presently down. Initially this was due to a hardware failure but it has stayed down because of the time it takes to find workarounds and fixes for long known bugs and problems within the scripting engine.

 

I have posted along these lines before but will state it again... DCS, no matter how fantastic the flight models and no matter how beautiful the aircraft models etc.. would be pretty much meaningless without the scenarios created by the mission making community.

 

I am no programmer but, thanks the the likes of FlightControl, Grimes, Ciribob et al and the frameworks and scripts they have created, even I have been able to produce some pretty decent missions which, (connection issues aside), have proved to be quite popular at times.

 

In truth, FlightControl's decision to leave the Moose project involves personal reasons but there is also a deep frustration with the way ED interacts with the mission building community.

 

This is not surprising as the interaction is little to none!. There are mission editor bugs which have been around for months, (if not years) and these cause all mission builders to tear their hair out regularly trying to find workarounds and fixes for things that just don't work as they should in the first place.

 

We all understand that any piece of software as big in scope as DCS will always have bugs and problems but it is the lack of communication, feedback and assistance from ED which is the problem.

 

I find this bizarre as I see mission design as fully 50% of DCS and, from where I'm standing, this 50% of DCS seems to be woefully under supported and under valued by ED.

 

Every week we get a newsletter telling us about the latest bundle offer or modules in development etc.. (not knocking that because its a good thing), but could ED not also put up news regarding features and plans for the scripting engine?.

Could ED staff and or 3rd party developers not post their own tips and pointers regarding how to get the most out of the mission editor or even have somebody respond to queries and maybe even give out little snippets of code in response to feature requests?

 

Please understand, I am not knocking DCS or ED but I am puzzled as to why the mission builders and server hosts get so little support and attention. I strongly believe this should change because DCS has the potential to be something truly amazing.

 

People like FlightCcontrol are an asset of untold value and should be recognised as such, not driven away by frustration.

 

Anyway, rant over. Hope somebody from ED reads this and understands what I'm getting at.

One year later..., not much has improved unfortunately. Try using lua to destroy a client (that is a unit started by a player) using Unit:destroy() in multi player... Not working. The multiple clients group bug is only partially resolved... Burning units still can't be destroyed, so they keep on blocking airbases and there is nothing than can be done about it... These kind of problems keep hiding in the system.. Although reported, it seems ED does not care fixing them. Communication is zero when it comes to lua scripting. I've even reached out a helping hand, but no avail.

I really hope that 2017 will bring some light to the team of ED. If there is anything that can be done from the community side to improve on things, we are happy to cooperate. Send multiple posts in this regards... Moderators know them.

I hope that some of the team members are looking into how the community can help or bring a structured message on which priorities can be set and communicated. Things just keep on to be broken for years in a release version. Cone on. We all paid lots of money, even funded the project when it started buying 50$ modules.

I understand the frustrations.

Haven't given up on the moose framework though... Slowly and steady this thing is reaching it's final goal. I hope fubarbundy will be back soon.

Fc

The question is, what is blocking for who. How do we define when the simulator is not running. Where do we see a communication from ED about these things?

Multiplayer is a valued environment for many. People have invested a lot of time creating scripts and features that failed to work because of errors deep in the system. Fixing some critical bugs would do a lot of good to the simulator. I an sure I speak for many here. I would be really interested to see if ED knows which bugs are the issue.

Does the sim launch and run? Can you fly all your modules? I see most issues you discuss are coding issues, am I wrong? They may hurt some custom missions, but you can still enjoy the game otherwise...

The other caveat is whether an issue breaks a large amount of missions, specifically with built-in and DLC content because it is a commonly used feature. For example the recent bugs with part of group in zone and group is dead being broken for triggers had a trickle down effect causing related functions to be also broken for scripting. Bugs like that will generally be fixed fairly quickly, while lesser used functions might not be. That and crashes. If something crashes it also has a higher priority to get fixed.

Does the sim launch and run? Can you fly all your modules? I see most issues you discuss are coding issues, am I wrong? They may hurt some custom missions, but you can still enjoy the game otherwise...

 

As I said, the goal is 2.5. I have said this over and over.

Imagine you had a job, and you had to drive to it. Ang you can't turn off your windshield wipers, the windows roll down when you start the car and the turn signal can only indicate left. The air conditioning is set to warmest one week, and then coldest the next. When you call the car company, some dude in customer relations tell you that since you can still start the car and you can still drive it, he won't hear any complaints and you should be happy with it. Would you?

Let me try to make it concrete ... Another attempt.

1. AIRBASEPOLICE

We have a class called AIRBASEPOLICE.

The code of this class can be found here. As you can see, a lot of work has been put into it.

https://github.com/FlightControl-Master/MOOSE/blob/master/Moose%20Development/Moose/Functional/AirbasePolice.lua

The AIRBASEPOLICE class provides the main methods to monitor CLIENT behaviour at airbases. CLIENTS should not be allowed to:

* Don't taxi faster than 40 km/h.

* Don't take-off on taxiways.

* Avoid to hit other planes on the airbase.

* Obey ground control orders.

The reason why is class is made, so that mission designers can embed this code without having to deal with a complex server logic. They just incorporate this class into their mission, and all airbases, both at caucasus and nevada are monitored...

Clients who are not obeying the rules are kicked.

Now, this class works perfectly in single player.

In multi player, it does not work.

The statement at line 185 is the one that fails: Client:GetGroup():Destroy()

2. CLEANUP class

There is a CLEANUP class. This class should ensure that any airplane or object that is destroyed within the permiters of an airbase, get "removed" from the airbase... Burning units are burning and burning ... And they block airbases. The AI just stops. No airplane is moving anymore and the fun is away in your mission. It is easy to sabotage ANY multiplayer server by flying around, and crashing at any airbase. There is simply no method to remove burning units today...

However, there used to be... Till DCS version 1.2.6, burning units could be removed. I wrote this class at that time, which is about 2,5 years ago by now. Since then, it has been consistently impossible to remove burning units from the simulator.

You can find the CLEANUP class here:

https://github.com/FlightControl-Master/MOOSE/blob/master/Moose%20Development/Moose/Functional/CleanUp.lua

3. TASKING ...

In our little framework, there is a complete TASKING mechanism created, which allows to orchestrate missions for human players. Unfortunately, as for many other scripts created in DCS, these kind of implementations require that in multi player, the Group function is working for remote clients. I am not going to repeat anymore what has been written over and over at other places on this subject.

Right now, this problem has only been half resolved. Only one Client can be present in one Group in multiplayer to make the Group object work as expected. If you add more clients (max 4), the Group object will fail...

eg. Group:getName() will fail for groups with more than 1 client!

You can find the TASKING framework here:

https://github.com/FlightControl-Master/MOOSE/tree/master/Moose%20Development/Moose/Tasking

And an accompanying video here:

I am not even mentioning lua predicates, JTAC laser code problems, events not being fired where they should, events fired double, ...

I understand that DCS 2.5 is a target for the ED team. That being said, and as others will confirm, wouldn't it be a normal thing to have the product as currently released in its current form, is working as expected? The problem is not just about missions that fail, or some cockpit features not working, or some graphics looking ugly...

This is about guys making compelling missions, so that even more players join the DCS MP servers. So, is that now such a difficult subject to discuss and get done?

I tried to make it as concrete as possible, exposing the source code. Please have a look into these issues. I can provide with test missions to validate or prove the problems.

Sven

[Additional to the bug I posted with the 'Group get' applying to only Mi8 and UH-1 which causes and immediate and instant CTD, and overlaps with this...]

So I was in a PM flow with BIGNEWY yesterday about what I call the "tasking overflow CTD" and how to report it. The issue with reporting the symptom is that the reproducibility will involve scripts and my ask of BIGNEWY was if that then made reporting it devalued.

Whilst he said he would be more than happy to report it, we were both agreed that reproducing only with a script does make it harder for ED to understand the relevance and impact. So I said what if I can do it with two seperate scripts that are unrelated to each other? Again, same.

There are missions provided by users, who are posting in their own seperate subforms for said scripts, issues that all provide the same memory access violation type when the same thing happens. Far be it from me to say it's the same issue, but common sense says, same error, same steps to reproduce, same root cause.

GCICAP CTD's (reproducible) https://forums.eagle.ru/showthread.php?t=120325&page=92

AutoGFT (reproducible but no mission to hand) https://forums.eagle.ru/showthread.php?t=179522&page=6

I've also had it with manually looping units, not tried that mission for ages, you get to a point when you sigh...welll because....DCS and move on.

You need to be 'in the know' and watching the minidumps to know what's going on for 1.55 right now, but I can tell you without fear of contradiction that it's massively vulnerable to CTD when it comes to running scripts that task units, usually many groups at a time.

It's worth pointing out that it does not reproduce easily on 2.04 that I found. Which to me says it's worth looking at

I said I wouldn't post a bug on this version.

As far as I am concerned, the last release was hasty being some pressure towards end of year and some slack needs to be cut, if it really was confined to that release. But, come some dust settles on this, I'll be posting these dumps if the bug persists and raising Helpdesk cases for them because the impact on the game is being misunderstood.

The impact, in short, is that people cannot use community scripting to further expand their MP gameplay experience, because the servers won't run anything that crashes. The server owners are responsible for the entire Multiplayer community and provide the ONLY multiplayer content. Damaging MultiPlayer extension IS a massive hit to DCS's viability, the issue is that server admins and mission makers are massively under-represented in the DCS community as a whole, yet just a few people provide content for the public that keeps players interested and coming back.

If I had stayed offline since A-10C I'd have not played DCS 6 months after A-10C release. Additionally I've bought modules only because of their online use, like the warbirds and only because my friends were playing them. My group has done the same, we propel our own excitement and sales together, under the hood, MP sells and retains customers, holding a higher number of second sells than the single player market due to greater exposure and cross experience. I've seen this effect through more than 100 players coming past my door over the years in various virtual squadrons over the years. And we relied on less than 5 people to make our content. ANd every new MP player said his eyes were opened after they started to go online.

That's all anecdotal as I only have my own statistics to back it up. But I have touched, met and created many communities over the years and across the world.

TLDR; it's really important to nail scripting issues as they are core to an iceberg community lead by content developers.

[Poetically, this is my 2,000th post on these forums]

The question is, what is blocking for who. How do we define when the simulator is not running.

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.

When I report most of the scripting stuff I could set every single bug to block, but that doesn't necessarily mean that 1. QA or whoever else doesn't think it is a block and changes it. or 2. The bug becomes the top priority of whoever it was assigned to. Funnily enough most of the scripting bugs I report are block or just 1 step down from block. My personal rule for that is by looking at the bug in context. If something is supposed to do something and doesn't then it is an important bug to fix. If a bunch of other stuff relies on that something in order to work, then I set it to block.

For example if Unit.getByName() always returned nil, then that bug is a block because it impacts a ton of scripts in general, but also every single unit object function.

If getPosition() was broken that would also be a block, but if it were something like getLife0() I'd probably label it as a major bug. Yeah it sucks that it is broken, but it isn't "literally every single mission with scripting would likely be broken" sucks.

It could also be summed up by a famous expression from the US history

I shall not today attempt further to define the kinds of material I understand to be embraced within that shorthand description ["hard-core pornography"], and perhaps I could never succeed in intelligibly doing so. But I know it when I see it

In this instance replace hard-core pornography with "blocking bug" :lol:

@Pikey. I was about to post this whole thing and hit preview and saw your post. Since I am short on time I will be brief in a response.

Stuff like that deserves its own thread/post in the bug reporting sections. Compile what is known about it and put that in a thread somewhere. I personally don't read every scripts forum thread on a regular basis, even the ones that utilize mist. But I do check the 3 bug sections and also check AI and mission editing sub-sections everyday. So when you guys are running into persistent issues, especially crashes, there has to be a crossover point from "the maker of the script is doing something wrong" and "there is actually a bug in the game that needs addressing".

In terms of complexity of scripts in bug reports; if I can reproduce a bug with a relatively simple script then I would. Taking Flight Control's example of using moose for destroying clients, I'd just make an F10 trigger attempt to destroy a specific unit on command. Two triggers, one line of code, don't even need to plug in a joystick or operate an aircraft to do it. It is simple for the dev to look at and understand what is going on. Its just down to if there is a literal and easy implementation of a given feature.

As far as I am concerned, the last release was hasty being some pressure towards end of year and some slack needs to be cut, if it really was confined to that release. But, come some dust settles on this, I'll be posting these dumps if the bug persists and raising Helpdesk cases for them because the impact on the game is being misunderstood.

Yes but it is still worth testing. Perhaps it isn't reproducible in 2.0.4 because 2.0.4 hasn't been patched since November 25th. Crashes are always worth investigating. I'd rather have something reproducible like that on one version so you can easily test it on others. Send me what you know and I'll have a crack at it.

?

@Grimes

As a normal mission editor myself, using both MIST and MOOSE I noticed time to time the DCS engine has literally to many annoying bugs and problems that you have to do workarounds, for example the cleanup to avoid usage of memory etc. Or Tasking. The limitation is there but because ED isn't fixing it.

Pointing that the 2.5 is the main objective to be released, great. But the way ED has been dealing with it has been poorly. Why release 2 different versions (1.5.5 and 2.0). Before explaining and going off topic, I understand engine difference but then focus would be moving everything to 2.0.

Back to topic -> I don't either see active community response regarding bugs and issues with ED. Its often quiet or few small responses. Why? Why not engage with your community base and build it up better? I understand flightcontrol and others frustration as a mission editor..

Thanks BIGNEWY, that is an answer that makes a lot of sense.

I understand the hard and difficult job the dev team is doing.

It is just, our patience has been tested and is tested...

When will things get back to normal as it used to be?

That day when 2.5 is released will be a good day ans a big milestone achieved for the product. I am not trying to be the annoying guy, although some may feel I am.

I do agree with Grimes that not every bug can be urgent. And somebody needs to decide upon that. One cannot do good for all, especially with a team under pressure.

I guess then we'll just need to wait until something new comes?

But I really hope that these issues reported will be addressed at a point in time. Pks your feedback.

OK, @Grimes, @BIGNEWY,

For the purposes of being exact, please use this mission on this post.

https://forums.eagle.ru/showpost.php?p=3010556&postcount=919

The resulting crash around the 15/20 minute mark. You can get x10 speed so its max 5-10 minutes effort. My own feeling is that tasking many units at the same time causes this issue. Possibly an RTB, who knows. It's one of scaling and thus its a horrible one to report. The key difference with this mission is that he had 18 planes up at the time.

Now I can reproduce using another script that moves ground units. We aren't talking about the CPU burst, or the delay, lets leave that aside, just the CTD. Again, solved that one by tasking less groups at a time. If it's worth repeating the symptom in different ways and different scripts, let me know, I've already done loads of scaling testing and i'm not afraid of hard work if I know it has ED's attention, but for us outside of the internal logging system, its like pouring in water to try to fill the sea and it's very difficult to motivate myself to do these more obscure tests when you don't even know if it's worthwhile.

Things are difficult at the moment with the different builds, some bugs are waiting for new code to be implemented or merged into public builds.

 

Some of us testers spend a lot of time trying to get around to everyone's favourite bug to make sure it is reported to ED, sadly not enough of the testers are doing this in my opinion which leaves a handful of us trying to get around to more than our fair share.

 

All I would ask is if you report a bug, especially with scripting it is done in its simplest form, it is easier then to reproduce and get the bug report in, we then have to test it over several versions to see if it is a bug or just something that has not been merged into public.

 

As Grimes mentions it is always worth testing, so if you have a bug or you think something is not right post it, we will get around to it eventually.

@BIGNEWY and @GRIMES, I promise you, I will keep in the background silently observing the progress. There is challenge enough with the MOOSE framework to continue its development and manage its user base.

But I do have this hope, that one day, the AIRBASEPOLICE and the CLEANUP classes will function, and that TASKING will work for clients more than 4 units... So that this functionality can be fully released to the people who are awaiting it, and that my friends, is not just me. It is a larger group of people.

That being said, if I find other self declared urgent bugs, I will report them discretely..., in the trust that people DO care, and will solve them.

Sven

@BIGNEWY and @GRIMES, I promise you, I will keep in the background silently observing the progress. There is challenge enough with the MOOSE framework to continue its development and manage its user base.

 

But I do have this hope, that one day, the AIRBASEPOLICE and the CLEANUP classes will function, and that TASKING will work for clients more than 4 units... So that this functionality can be fully released to the people who are awaiting it, and that my friends, is not just me. It is a larger group of people.

 

That being said, if I find other self declared urgent bugs, I will report them discretely..., in the trust that people DO care, and will solve them.

 

Sven

Top Man - have some rep

+1

'T'

Well, there's still something that itches me greatly about the whole topic, and the "ED is working toward 2.5" isn't going to appease me for that, at all.

The whole stance of ED toward SSE is that it's an added layer they "offered" like the icing on the cake.

When I read the official wiki SSE page, I'm baffled. Page 1 :

Note: The engine was initially developed for debug purposes. It was not tested properly, not tweaked, not reworked or extended due the requests of the community, so now it may contain bugs and disadvantages.

 

The document is actual for DCS: World 1.2.0.

So the only official statement about SSE is up to date with ... version 1.2.0

SSE is presented as the debug tool it originally was and only an additionnal layer, and prone to bugs.

If any other component of the simulation was treated in the same way, .... well, I can't even imagine it.

Very clearly, the SSE is not considered a core part of the engine, like 3D, modelling, physics, but is considered a additionnal tool. Nothing in 2.5 annoucements shows that this status will change. This is imho a huge, huge mistake. That means that when considering a change, SSE is not taken into account and people in ED departments are constantly struggling with consequences of choices to fix bugs appearing.

I'm speechless when I see basic stuff like the ability to embark troops into cargo broken, (whole ME commands for it actually disappearing!), just to name this. That's half the utility of 2 modules (Huey & Mi8 ) ED is actually selling ... gone! (unless you rely on community script like CTLD, thks Ciribob!). What would be the outcry of ED suddenly removed the 3D model of the A10C wheels? This stuff should have been corrected presto! Yeah, it's being looked into (thank BigNewy for the update) but... look at the dates : https://forums.eagle.ru/showthread.php?t=176514

So my main problem isn't the actual bugs, lack of proper reporting channel, etc.... It's more to do with how ED regards ME and SSE. They are heavily toward pretty and 3D, but if editing topics are not integrated into the core of the development, I don't see anything actually getting better. I'm sorry, but I read "ED is working heavily toward 2.5" only has "ED is enhancing graphics and physics", and that doesn't make me comfortable.

There's a big parallel that can be drawn (and has been early on in this thread) between SSE and Bohemia Interactive take on their own scripting engine in Operation Flashpoint (now ArmA series) back in 2001. It was initially the exact same stance BI had toward their scripting engine : it was originally a debug tool & they kindly gave access to it to the players. It was neat but kinda horrible in the same time, with half the scripts being explained in Czech, for example. The situation changed after a few years and BI heavily invested in making the scripting engine and mission editing a core aspect of the game. DayZ has shown how a winning move that was.

I'm not saying ED should go the exact same route, but getting out of the idea that it's a simple tool they kindly give us access to would be a start.

EDIT : Imho ED has 2 choices : Either built themselves the content (and I'm not talking about modules, because modules without a proper way to use them isn't going to cut it), by the mean of proper dynamic campaign, working multiplayer scenarios (along with larger theater, proper dedicated server support ... ).

Or give the ability to the community to do all that. And the SSE is the perfect tool for that. Or would be, if it was more viable.

Agree 100%. DCS World has a very under developed mission editor. If it not were for MIST and MOOSE the missions in DCS would be very basic.

The "problem" with MIST and MOOSE is that you're programing a mission with scripts and if you're not into it you will not be able to make complex missions.

Don't get me wrong MIST and MOOSE are very simple and there a lot of documentation very well explained but sometimes for we the non programers can sometimes be difficult.

ED should support their community and even implement this functions and framework into the game and DCS would be 100% more impressive than already is.

My qualm with its "lack of development" is that mission scripting and unique content creation is happening in spite of developers instead of because of them.

I hope I'm not the only one who wishes that there was a stronger relationship with some of the really strong scripting guys so they could better anticipate and troubleshoot their work... the same work those of us who have ideas but no scripting experience depend on to create missions to keep everyone who has no creative ambition busy.

I said this a long time ago and I'll say it again: The ideal world (through my lenses) would allow script creators a certain level of access to patch information so they don't need to go on witch hunts when a patch breaks something. This would help keep them engaged with improving their scripts and supporting those who use them instead of scratching their heads in frustration.

Again- opinion only- but these scripting guys are literally the furnace that keeps the platform warm over time. Stoke the fire and it expands the reach of the platform to a broader spectrum in the community. Burn it out and the community becomes a cold, desolate place where only the hardcore hunker down and ride it out.

I have been through alpha's / early access before when devs would not invest resources in fixing technical problems in old builds when the upcoming build already fixed it. VERY frustrating... I wish there was some middle ground but know that wishing doesn't create solutions.

Well, there's still something that itches me greatly about the whole topic, and the "ED is working toward 2.5" isn't going to appease me for that, at all.

The whole stance of ED toward SSE is that it's an added layer they "offered" like the icing on the cake.

When I read the official wiki SSE page, I'm baffled. Page 1 :

 

So the only official statement about SSE is up to date with ... version 1.2.0

Ok, first off you are probably looking at the drafts wiki article. In the early days of the scripting engine those articles were used by the developer that did most of the scripting engine to keep testers like Speed and myself up to date on the functionality. The last major patch in terms of scripting additions was for 1.2.6 and you can find its wiki article here. There have been a few new functions added here and there since, but 1.2.6 was the end of a "big push" of adding scripting functions.

It is worth noting that the ED wiki was online but off limits to user side modification for the longest time, and I think it was taken offline completely for a little while too. It only recently came back online in the last year or 2. During that time it was locked down I decided to re-organized all of that data onto the hoggit wiki. It is not the 'official' wiki, but it contains more info than the ED one.

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

@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