Jump to content

'Persistant' Mission


Ditty

Recommended Posts

Is there an easy way to make a 'persistent' mission?

 

Say as simple as flying from airport A to B and shutting down. Come back later and reopen mission but now you're starting from airport B? How about syncing mission time with PC's local time?

 

Thanks either way!

Link to comment
Share on other sites

The only "persistence" you get officially is the mission branching depending on the score, have a look at the manual pg 105-. Depending on the score, <50 (failure), 50 (draw), >50 (success), you can define which mission is next.

 

A bit poor, but that may be a workaround depending on what you're trying to achieve.

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

The only "persistence" you get officially is the mission branching depending on the score, have a look at the manual pg 105-. Depending on the score, <50 (failure), 50 (draw), >50 (success), you can define which mission is next.

 

A bit poor, but that may be a workaround depending on what you're trying to achieve.

You can also copy all mission variables and even objects that were destroyed to an external file then have the new mission read that file. But again it’s a confusing difficult thing to do.

Link to comment
Share on other sites

You can also copy all mission variables and even objects that were destroyed to an external file then have the new mission read that file. But again it’s a confusing difficult thing to do.

 

Yes, I was thinking about something like that but with an external program, similar to how PWCG has brought dynamic/persistent campaign to another sim. I'm not sure it's possible to launch DCS on a specific mission and exit, but after all the data saving part is what Tacview does by grabbing data in real time (or alternatively the temporary track file could be decoded).

 

It's probably the only, not-too-invasive way, but it's indeed lot of work, requires the user to launch a specific mission, and to exit DCS properly. One also has to hope it remains compatible.

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

  • 2 weeks later...

There's a bunch of stuff you can do. And a lot more you cannot. Currently i've never worked on the "Player" only the MP client slot. You can generate code via trigger to block the slots and thus produce an effect of going from A to B. For some reason adjusting time and date is impossible though because you cannot do that in the mission, only rewrite the original mission from outside. There were some solutions for this I think, but I never tried them. DAWS was going wrong about the time we tried to get MOOSE and MIST working happily together. NO idea where in code that problem ever was, it wasn't very logical because they work together normally, just not when Chromium added his DAWS.

 

For persistence I use the grey area in between. Since DCS performs horribly with moving units, I don't do much more than patrol loops and not too many of those. Ships behave nicer. Then I collect what was destroyed during the mission and only spawn that in when it restarts. Thus the mission restart assumes "some time passed" but retains at least some count of what is going on.

 

 

There's a lot of people looking at TCP sockets right now and exporting the lot to other code. It's a lot of trouble if you ask me and it doesn't make large scale DCS any more stable. Simpler solutions work better and don't mess up. It doesn't stop folks chasing the dream though.

___________________________________________________________________________

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

Link to comment
Share on other sites

@About persistance

the main issue is to decide how to get out things from the mission scripting environment. With DAWS and a lot of other solutions you need to workaround the sanitization module in missionscripting.lua. While it's easy to automatize this step (SLmod did it in 2011...) it's also like an hack.

 

After many "feasibility studies" involving also current DCS performance I beliebe that the proper way should be this:

- use as less as possible spawning to simplify tracking and persistence of the units;

- track as much as possible with non-overheading event handler functions (nothing that works at any frame or similar);

- exporting everything at mission end (or host disconnection), not before.

- do most of the maths and processes ouside the mission environment (using hooks file).

 

But, you know, It's me that don't like exotic solutions like external software... others did that with success I believe :)

 

 

@About DAWS:

 

I believe Chromium took DAWS down for the time being due to compatibility issues. I had a bunch of issues with other scripts using tables while DAWS was enabled.

 

main reasons was to lack of time with constant updates and the need to implement compatibility with Normandy and WWII units, while ensuring compatibility with at least CTLD... cause about MOOSE there was that strange issue related with MIST. And salso ometimes bugs due to the fact that many people have issue with "RTFM" :D (some do not remove write protections, some load mist anyway, etc etc).

ChromiumDis.png

Author of DSMC, mod to enable scenario persistency and save updated miz file

Stable version & site: https://dsmcfordcs.wordpress.com/

Openbeta: https://github.com/Chromium18/DSMC

 

The thing is, helicopters are different from planes. An airplane by it's nature wants to fly, and if not interfered with too strongly by unusual events or by a deliberately incompetent pilot, it will fly. A helicopter does not want to fly. It is maintained in the air by a variety of forces in opposition to each other, and if there is any disturbance in this delicate balance the helicopter stops flying; immediately and disastrously.

Link to comment
Share on other sites

Quick one, reason for Spawning, because a lot of people don't really consider this.

 

 

It's down to DCS scaling. DCS really really starts to struggle with lots of units, even worse if they start to move and more so for each connected client.

 

 

Whilst I saw back when we chatted last year and before about this that you weren't supporting Spawning, the alternative is to place every unit out in the mission beforehand. This is a very difficult limitation, especially accessing them for dynamic routing (easier to spawn and send it somewhere relevant)

 

 

For long missions, where many units are in play, Spawning holds the trump card with scalability. Long missions, read - campaigns, are where persistence also comes in. So we are in a competing situation where the demands are very high for the DCS server and spawning would be an obvious choice in limiting the amount of units in play at one time.

 

 

Thus from a design perspective, Spawning and dynamic tracking across restarts, to me at least seem to go hand in hand.

 

 

I'm completely with you regarding "events", they can be the death of a mission and I try to asynchronously track units as much as possible. But there are limitations. I woudl love proper event processing direct from the written log, outside the frame too.

 

@About persistance

the main issue is to decide how to get out things from the mission scripting environment. With DAWS and a lot of other solutions you need to workaround the sanitization module in missionscripting.lua. While it's easy to automatize this step (SLmod did it in 2011...) it's also like an hack.

 

After many "feasibility studies" involving also current DCS performance I beliebe that the proper way should be this:

- use as less as possible spawning to simplify tracking and persistence of the units;

- track as much as possible with non-overheading event handler functions (nothing that works at any frame or similar);

- exporting everything at mission end (or host disconnection), not before.

- do most of the maths and processes ouside the mission environment (using hooks file).

 

But, you know, It's me that don't like exotic solutions like external software... others did that with success I believe :)

 

 

@About DAWS:

 

 

 

main reasons was to lack of time with constant updates and the need to implement compatibility with Normandy and WWII units, while ensuring compatibility with at least CTLD... cause about MOOSE there was that strange issue related with MIST. And salso ometimes bugs due to the fact that many people have issue with "RTFM" :D (some do not remove write protections, some load mist anyway, etc etc).

___________________________________________________________________________

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

Link to comment
Share on other sites

I know why spawning is important, but I prefer ai off / ai on could help a lot keeping low impact on performances. Anyway I prefer a low-units approach but with full fixed orbats (<1000).

 

Don't read it as a "no I don't want" spawning, I only would like to do not track them. I.e., I prefer a dismount script that associate "n" infantry to a vehicle that could freely move embarking and disembarking them as required (See MBot dismount script) only when enemies are nearby, and within certain limits.

 

About events handlers I prefer to use them instead of ricursive checks but I strongly try to reduce calculation overhead at any event... i.e., I might only populate a table or record the very first hit in a group instead of every unit hit to reduce a lot calculations when using area weapons over multiple targets (like the "rockets on infantry" nightmare).

 

Most of those choices depends on the objective you need to achieve: for my current one it's better my approach. Instead, if I would like to run intensive server with a lot of AI life going on, I might prefer a spawn/despawn approach to keed mess as light as possibile.

ChromiumDis.png

Author of DSMC, mod to enable scenario persistency and save updated miz file

Stable version & site: https://dsmcfordcs.wordpress.com/

Openbeta: https://github.com/Chromium18/DSMC

 

The thing is, helicopters are different from planes. An airplane by it's nature wants to fly, and if not interfered with too strongly by unusual events or by a deliberately incompetent pilot, it will fly. A helicopter does not want to fly. It is maintained in the air by a variety of forces in opposition to each other, and if there is any disturbance in this delicate balance the helicopter stops flying; immediately and disastrously.

Link to comment
Share on other sites

  • Recently Browsing   0 members

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