Trains Chase along the Same Track - I GIVE UP

[JG4_Deciman]

28 minutes ago, Regingrave said:

It is still quite messy down there.

The problem here is Bodenplatte map alone will take around an hour to load in debug mode because in this mode game runs without any optimization, not to mention this complex logic you have there. There should be a bare minimum of objects on map: no blocks or bridges, smallest map possible (not in this case since there are no railway junctions on Lapino, but in all other cases it's better to use Lapino) and no entities or MCU's other than ones that cause the bug.

 

 

 

You can safely delete all bridges, buildings, airfields, ...

Only thing needed is my (very intensive, I know) logic in the main group 'Test'

Inside that group you can also safely delete all subtitles (only used for debugging)

And you can also delete all vehicles (except the trains)

They are used as 'spotters' only, to mark trains on the map.

 

But in any case the complex logic is a main part (even if it is used in the smallest version to handle 1 train only)

because if there is a bug with that 1 train it will rise with every additional train.

 

Deci

40 minutes ago, Regingrave said:

It is still quite messy down there.

 

 

 

Additional remarks:

 

Before implementing the 'Checkpoint' trains were driving directly from 'Guetersloh' to 'Bielefeld'

and that was working as intended.

But in the full size mission (more tracks, switches, ...) a train showed the same strange behaviour when reaching a switch.

And all other switches using the same logic were acting without any problems...

 

I can only guess....

Track related (map)

Deactivating already inactive waypoints

Having too many timers... inside the mission (but I guess that is not the problem, because full size mission showed the problem only in a few places and uses much more resources)

 

Deci

[Gambit21]

1 hour ago, JG4_Deciman said:

 

 

You can safely delete all bridges, buildings, airfields, ...

Only thing needed is my (very intensive, I know) logic in the main group 'Test'

Inside that group you can also safely delete all subtitles (only used for debugging)

And you can also delete all vehicles (except the trains)

They are used as 'spotters' only, to mark trains on the map.

 

When you post a demo/test mission for the purposes of demonstrating a bug...

 

Do your best to reduce the mission to the simplest form possible which still illustrates the bug in question.

 

This means isolating the necessary logic, and deleting everything else.

 

Just a friendly FYI

[JG4_Deciman]

17 hours ago, Gambit21 said:

 

When you post a demo/test mission for the purposes of demonstrating a bug...

 

Do your best to reduce the mission to the simplest form possible which still illustrates the bug in question.

 

This means isolating the necessary logic, and deleting everything else.

 

Just a friendly FYI

Thanks @Gambit21

I never was aware of the fact that debugging mode would take an hour to load the (empty!) map.

And because I'm pretty sure that the problem is either located in the map itself (tracks) or train movement (waypoints, tracks, ...)

and only happens under rare (and unknown) circumstances I thought, the best way to isolate them is using the full logic.

To make it more easy I've reduced it to to the part where the error ocured (even with reduced logic), still using the full logic (and environment) because it may be due to server overload (even if the dServer window didn't show any)

 

Cutting it down to the absolute basics would mean:

Take the waypoints at the current position

Take the activators / deactivators

Spawn a train and let it run

But I think, for doing that the complex logic itself (excluded the waypoint positions and delay times) is not needed.

And I also think  if trains not following simple connected waypoints (even with delay activating them)

that problem would have been reported a long time ago...

 

Currently I'm working on a 'scripted' version using 1 train and the problem track.

Replacing all 'external' logic by loops (as I know where the train has to start and where to go with all points between)

Reducing the 'internal' logic to a minimum.

 

But my guess is (and remains)

either the trains react false on the tracks (map presets) only for specific tracks/positions/distances/...

or the problem is because of deactivating inactive wapoints.

 

The 'master' logic (debugged by subtitles) triggers the wanted (and only these) actions.

 

Maybe the devs can tell me exactly what they need to find the bug.

If they do I'll do my best to modify the mission according to their needs.

And I also know that modifying such a complex logic will be very hard for anybody.

It's also hard for me (and I coded it), because when removing any part of it I'll have to be sure

where is is needed and what has to be connected as a 'bypass' (including the time used by the original logic as a delay timer)

to have it run wit a 'bypass' as it would with the complete logic.

 

Deci

@Regingrave

@-DED-Rapidus

@Gambit21

 

Ok, gave it a try....

 

I've been taking the small mission (including all, so not the scripted one I've started working on which seems to be not nesessary to continue working on it)

I've been simply moving the entire group for the 'Checkpoint' to a position more north on the track

(all external connections don't need do be moved/fixed/adjusted)

I've adjusted the waypoint containing  groups (located in 'POSITION_ME') to have all waypoints on track

I've selected all waypoints inside that group and set them on ground

Saved the mission and started it.

 

Train left the switch, reached first waypoint (where it turned around before)

got ordered to move to next waypoint (as before)

and CONTINUED ON TRACK!!!

 

Deci

[-DED-Rapidus]

@JG4_Deciman, In the next version, there will be a small update on the issue of train traffic.

[JG4_Deciman]

1 minute ago, -DED-Rapidus said:

@JG4_Deciman, In the next version, there will be a small update on the issue of train traffic.

 

Thanks

 

If you need more information I can provide more input.

Positions of the waypoints (from, where spins around and to)

where I noticed that first time (and checkpoint)

 

And waypoint position where trains behaved as they should (moved checkpoint)

 

Deci

[JG4_Deciman]

Unfortunately the fix didn't solve the problem...

Updated both installations (game and server instance)

Opened  the updated server

Loaded the original mission

Saved it (new name)

 

Started dServer (new saved mission) and game client

and saw the same strange things happen...

 

Train enters the 'Checkpoint' and depending on 'from where' it uses either the full logic and did what it should

or it turned 180° after reaching the first waypoint.

 

Made some further tests.

Took the same base mission for all tests and activated my debugging subtitles.

All that was changed in the 3 testing versions was:

 

Moved the entire group containing the 'Checkpoint' to a different position on the same track.

 

Checkpoint at 1035-7-2

Trains entering from Gütersloh reach the first waypoint

trigger the next waypoint

turn around instantly

drive a while and stop.

The second waypoint is never reached.

Trains entering from Bielefeld proceed on track as they should, triggering all waypoints and proceed on track

 

Checkpoint at 1035-7-6

Same things happen but completely the other way round.

From Bielefeld  -> strange behavior

From Gütersloh -> behave as they should

 

Checkpoint at 0935-6-7

same as at 1035-7-6

 

So as both missions use completely the same logic

and the only thing changed is the positon of the waypoints (and all other MCU's what should make no difference)

I can say:

The logic is working as it should (up to the point where I could test it)

The strange behaviour is (waypoint?) position related

None of the positions where the 'strange running' train finally stops is the position of any waypoint inside the mission

 

So now it's up to you

 

@Regingrave

@-DED-Rapidus

@Gambit21

 

to tell me what you need (mission) to be able to locate that bug.

Using the entire mission is too much, that's what I know now.

But I finally found different locations giving me different results for the same logic used...

 

Deci

 

PS:

Bridges not tested up to now,

Concentrating myself on this bug

 

 

Edited August 18, 2020 by JG4_Deciman

[-DED-Rapidus]

@JG4_Deciman, we need simple examples where there will only be a train and waypoints, without buildings and decorations.

[JG4_Deciman]

ok, deleting everything except the logic is not the problem.

but the logic still is massive (even if only 1 train)

I could try to create a 'scripted' version

means every logic inside that is working (and I guess all are)

and not relevant in that case could be replaced by a 'loop' trigger (using the delay for the 'normal' logic feeding that trigger)

 

My problem (and I guess yours, too) is

- there is a lot of logic constantly running and using resources

- waypoints are activated (but not triggered)

- waypoints are deactivated (triggered or not)

 

And I can only say, the only active AND triggered waypoint

is never reached under conditions I cannot define.

I know the (completely) same logic (switches) in most cases worked as intended

and in 1 known case not (and they are all the same by 100%)

 

Same to the 'checkpoint'.

Sometimes it works, sometimes not

Same logic, different position (just moved) result exactly opposite one.

 

Maybe I'll have to create a very simple (scripted) one

using all waypoints for 1 train

letting them be activated/deactivated with the same delay my 'normal' logic would need

and see what happaens

 

Deci

 

 

 

 

 

[JG4_Deciman]

@Gambit21

@-DED-Rapidus

@Regingrave

 

Here are 2 reduced versions.

No buildings, no bridges

Reduced the mission to 2 subtrains for the same train (starting position)

Removed the 'spawner logic'

Removed the 'area logic'

And bypassed everything needed on mission start.

 

All commands are serverinputs

 

To spawn trains :

Spawn BIE (train from Bielefeld)

Spawn GUE (train from Guetersloh)

Only 1 train possible at the same time (spawner is disabled/enabled automaticaly)

 

Subtitles:

Checkpoint ON/OFF

 

Difference between the 2 missions:

Simply moved the entire group containing the 'Checkpoint' to a different position on the same track

 

Behaviour of the trains:

Checkpoint at 1035-7-6

- Train from Guetersloh behaves as it should

- Train from Bielefeld turns at first waypoint

 

Checkpoint at 1035-7-2

- Train from Guetersloh turns at first waypoint

- Train from Bielefeld behaves as it should

 

Additional notes:

Before implementing the 'Checkpoint' trains behaved as they should in both directions

Same waypoints were used

So the track between the switch in 1034-6-6 and the station in 0936-7-9 seems to be the problem.

Same strange things were noticed before on a different track

Trains passing the switch at 0736-6-9 heading to the switch at 0638-8-3 behaved normal

Trains in opposite direction turned when reaching the first waypoint of the switch at 0736-6-9

 

Deci

 

 

 

 

TrainDebugging.zip

[JG4_Deciman]

Ok, simple question (as I can see at least 1 user downloaded the mission pack)

Did it help or do I have to extract all waypoints from my mission

let them be directly triggered (with the delay used by the logic)

and see what happens...

 

And I really think after all testing I've made the problem is not located inside my complex logic.

Otherwise the problem would be present always and not related to the location of the group

(or to be more detailed, the location of the waypoints making troubles)

and not happen (or happen not) with exactly the same logic used and only moved the waypoints to a slightly different position...

 

Deci

 

PS: I could also try the same logic on a different map (lapino)

but I don't think it would make any sense

as the problems must be related to the map AND the positions of the waypoints

Edited September 2, 2020 by JG4_Deciman

[JG4_Deciman]

AddOn...

 

The trains pass bridges after the latest update without any problems.

Thank you guys, and I'm sure you'll handle the other bug, too

 

Deci

[-DED-Rapidus]

On 9/4/2020 at 5:47 PM, JG4_Deciman said:

The trains pass bridges after the latest update without any problems.

Thank you guys, and I'm sure you'll handle the other bug, too

Thank you for the extended reports, if there is still something uncorrected - write.

P.S. and it is desirable to write here: https://forum.il2sturmovik.com/forum/89-technical-issues-and-bug-reports/

[JG4_Deciman]

Ok guys

 

I finally made it

And it took me 'only' a year...

A 'Train Chaser' was wanted

And a very complex logic was needed to create the 'chaser', which was only the final step...

 

Here is a very small part containing all the 'basics' used

 

10 trains (each having 5 subtrains -> spawning places and carriages can be different)

Entire logic used is COMPLETELY random (spawning, movement, ...)

Tracks are the connection between 2 points (Checkpoint, Switch, Station, DeadEnd)

Every track can be used by 1 train at the same time only

Trains will use random tracks when passing a switch (depending on the target tracks being busy or not)

Trains will randomly spawn (depending on the target track/spawning position being busy or not)

Trains will wait at signals (switches/station) until target track is free (or despawn after a while)

Trains will despawn at a switch if BOTH target tracks are busy

 

Spawning/Despawning points:

DeadEnd at 1032-7

Station at 0231-4 (moved from 0331 to a closer position)

- only connection is toward north.

- any train spawning or entering with heading south will despawn

 

Switches

0127 (no further target possible, so despawning always when reaching)

0432 (no further target possible, so despawning always when reaching)

 

Checkpoint (0131-3)

Trains can enter from both directions

In case a train cannot proceed on track it will wait

In case a train cannot enter because of a waiting train the waiting train will become a 'Ghost'

(means despawn and save train and orientation)

In case a train will become 'Ghost' all existing ghosts are deleted

In case a 'ghost' is present after a train passed the checkpoint it is respawned

 

 

Deci

 

PS:

If you don't understand the basics on mission creating don't even try to understand what I did here.

The logic used inside is VERY complex and VERY demanding if you try to understand it...

and I've made it as understandable as I could when coding it!

 

I'll be able to answer questions for details, but I'm not willing to teach the basics before answering questions

 

Noticed bugs:

Trains passing the switch 0131-6 entering from south (checkpoint at 0131-3)

and heading towards DeadEnd (0132-7) can despawn instantly after passing the switch.

Reason still unknown...

 

 

Edit:

The mission inside is multiplayer/dogfight

and created to run under dServer AND hosted by player.

In case you want more/different planes edit the airfield

and make sure any added plane is 'AXIS  SIDE'

TrainChaser.zip

Edited September 24, 2020 by JG4_Deciman

[JG4_Deciman]

Ok, tested my own logic under 'hardcore' conditions

And it was working

 

Moved copied the entire logic to a second position

and got really strange results.

Train enters the checkpoint from N and waits (as expected)

Second train approached from S

Train at checkpoint became ghost (despawned and was remembered)

Train from S continued moving, passed the checkpoint and left direction N (all as expected)

Ghost respawned at checkpoint, direction S (as expected)

Then turned arround 180 degrees, followed the train that has left the checkpoint before,

missed the first bow on the track and derailed because it moved straight ahead (leaving the track)....

In fact it should have left the checkpoint direction S

 

I really think that problem is MAP related, because I noticed other strange things before (and still notice them)

but they do not happen always, and the logic used is the same for every instance.

99% of the instances work as they should and only very few start making problems.

 

Currently I'm (once again) debugging and trying to isolate these problems...

 

Deci

 

[Gambit21]

I’m designing randomized  train logic for Normandy.

 

I’ve found that it’s best in all cases to keep logic as simple as possible so long as it seems just as complex or random to the player.

 

I’m also designing German radar intercept /night fighter patrols and I can get very complex and algorythmic if I want to with regards to the chances of a night fighter showing up after you’ve been pinged by ‘radar’ However I can build a much simpler (but still sophisticated) version that eliminates an entire layer of proximity logic (leaving a layer intact) that will work just as well and look exactly the same from the more limited player perspective. So which one would I rather debug later?

 

In other words, what is technically more “accurate” or fancy from an all-knowing mission builder or “God’s-eye” perspective might not always be the most practical solution from a pure functionality/player,  or bug squashing standpoint. So I build as complex as I need to, not always as complex as I can.

 

Trains especially are something to watch out for as they’ve been buggy for a while.

 

The more you get “cute” with logic, the more likely it is to break for unknown reasons. I’m seeing sporadic failures of relatively simple “force complete” RTB logic for instance lately. It’s not easy to reproduce but at least it’s not a birds nest that I have to untangle.

 

Good luck.

 

 

Edited October 1, 2020 by Gambit21

[Sketch]

110% this. A good Mission Designer is just an Illusionist. If the player believes and is immersed, then you've done your job. The path to least resistance to get to that point is always ideal. In the end, does the player give a crap about how deep your logic goes? Nope, they only care about being immersed in the game. Sometimes I've built stuff and later was like - what was the point of this extra work? The player doesn't care about this!

 

Examples include:
- Having AI take off miles and miles away that the player doesn't see. Why deal with that logic? Just have the planes spawn in the air.

- Having AI land miles and miles away that the player never sees. Again, just have the planes delete when out of sight.

- Setting up logic to make the AI fight with attackArea MCUs, when you can just use low priority for waypoints

[Gambit21]

6 hours ago, Sketch said:

110% this. A good Mission Designer is just an Illusionist. If the player believes and is immersed, then you've done your job. The path to least resistance to get to that point is always ideal. In the end, does the player give a crap about how deep your logic goes? Nope, they only care about being immersed in the game. Sometimes I've built stuff and later was like - what was the point of this extra work? The player doesn't care about this!

 

Exactly.

With the radar/night fighter dispatch logic I got the initial logic built fairly quickly. Radar Ping (player flies above 550 meters or so)  Radar Yes - to 3k check yes/no, 5k check yes/no, 10k, 20k, 50K - and worked like a charm. Basically the farther away from you that the patrolling German night fighter happens to be when Radar over the continent pings you and tells him "attack", there's a slightly higher chance contact is lost and he breaks off. More than enough - move on.

Then I started scheming (when I should be sleeping) about another set of proximity checks/dice rolls after the night fighter was already determined to be inbound. Then I had a "what am I doing?" moment.

The only thing that really matters is the final output probability. "I got attacked/I didn't get attacked" and all of the additional, fancy backflips I was thinking to use to get there were totally superfluous and would of course be utterly lost on the player. The initial distance/proximity logic adds some plausible uncertainty and is plenty to get this job done.

 

 

6 hours ago, Sketch said:

 

Examples include:
- Having AI take off miles and miles away that the player doesn't see. Why deal with that logic? Just have the planes spawn in the air.

- Having AI land miles and miles away that the player never sees. Again, just have the planes delete when out of sight.

- Setting up logic to make the AI fight with attackArea MCUs, when you can just use low priority for waypoints

 

Yep, plus these things use CPU overhead that is much better tasked to things that the player is directly experiencing.

Time dilation is an insidious problem and it's often difficult to tell just how or with what group you stepped over the line.

So basically now I'm fighting it tenaciously from the first group/building block on the map upward.

 

 

 

 

 

 

 

[JG4_Deciman]

Maybe I've located and eleminated the bug hidden very deep inside my logic...

 

But according to the things mentioned before...

 

I want to have multiple trains for every region

I want trains to spawn AND move completely randomly

I want them to spawn ONLY when players are inside that area (or inside a range when they could see a spawning train at the outer limits of the area)

I want them to run completely random on the possible tracks

I want them NOT to collide on track

I want to have the option of multiple areas containing (some, not all) used tracks being overlayed

 

So what do I need:

A logic for every train

- containing all possible used waypoints

- activators / deactivators for anything related to 'moving to' or 'reaching a' waypoint

- checking the options for every place, where several tracks meet

- randomizing the options according to the given situation

 

So result:

- every track (connection between two points) can be used by ONE train only at the same time

- ANY train using a track must block it for ALL other trains

- every connection of the tracks must know, if ANY train is blocking the outside track

- every connection of the tracks must know, if ANY train is present at the inside positions

- the logic of the connections must handle the presence and outgoing possibilities on these informations

- the logic result must be sent to ALL trains that could be there (so even if they are not there)

- the train logic must react ONLY to the train present in the right position

 

And solution:

Having the same logic for every train and every position

So a train reaching a waypoint will activate some triggers, ... and deactivate other triggers, ... only for HIS part of the logic.

Next he will trigger the master part of the logic

The master part (getting all reports from any train that had reported)

will react on the input

and send the result to ALL trains

and the trains (or the train logic) will receive every input (even if it is at a completely different position)

but as the train logic has activated it's internal settings before only trains that SHOULD react will react.

 

The base is:

ALL train logic is disabled on mission start

On the initial spawn and move (random) the train will activate everything for reaching the first waypoint (inside the target group) and move (internal logic of the target group is used)

And whenever reaching a waypoint inside the target group the train will modify its own internal settings (reacting on inputs, activating/deactivating waypoints, ...) inside the target group

Whenever a train leaves the target group (new target group do drive to, despawn) ALL input/output triggers for that train are disabled.

The only input triggers that remain active allways are the ones telling the logic,

that a train was ordered to go there (entrance waypoint)

or to spawn there (and spawning is activated/disables somewhere else, because it's not related to moving active trains but uses moving logic to start movement)

 

Deci

 

 

 

 

 

 

AddOn...

 

Pro:

If it works as intended moving trains could be implemented to any mission as 'eye candy' or 'objective'

Prepared the option to block tracks (b e. track will pass a bridge that has been destroyed)

Prepared to set the max number of trains (any nation, red, blue) used and active at the same time (area related)

 

Con:

Massive use of waypoints/triggers, but no way to reduce in a significant way

 

Deci

 

 

[Gambit21]

IMHO and with much respect you're making this way, WAY more complicated than it needs to be.

 

When a player flies over for the fist time he sees one of two things...a train on the track in a given place/no train on the track.

If he sees a train on that track the first time, all you need to do is make sure that next time the train, if it's there, will be in a different spot.

 

With a few trains, (or even 1) a few random outputs, (4x, 8X, 16X whatever) and a handful "spawn at me" MCU's I can create an endlessly variable train environment on a track/line that will never be the same for the player regardless of how many times he boots the mission and flies over that area. Previously I achieved the same results by placing the actual trains in varioius points on the track and used random logic and timers to activate them.

 

I can think of a few different ways to keep trains from colliding with one another just off the top of my head.

The first is simply being smart with where you generate them to begin with, the second is using proximity logic between Train 1, and Train 2 with stop/resume plugged in.

The third is modifying that logic further by adding 2 sets of waypoints for the following train to modify it's speed first before stopping, and depending on what happens it will speed up again without stopping at all. Personally I wouldn't bother with that waypoint switcher option. I've used it to get subs to submerge when an enemy is close (see groups sharing) but it's a bit much for trains.

 

I prefer to be smart with how/where I generate the trains to begin with thus negating the need for complicated trickery.

I don't want train to to collide with train 1, well then guess what I'm not going to have train 1 stop in front of train 2.

 

If I'm worried about train 1 getting killed and train 2 crashing into it (I'm not) but if I was I'd employ the proximity logic mentioned above.

If you enjoy doing this then by all means keep at it.  I'm just saying there are easier ways to achieve functionally the same results...again from the player viewpoint.

 

It take me minute to pars my own logic sometimes a year or 3 down the road and remember what I was doing... I sure wouldn't want to crack the hood on this thing you're attempting.

KISS

 

Edited October 2, 2020 by Gambit21

[JG4_Deciman]

5 minutes ago, Gambit21 said:

IMHO and with much respect you're making this way, WAY more complicated than it needs to be.

 

 

 

 

 

Well, I did that in the way you wrote a long time before (RoF)

where I had 3 tracks and one connection of them

So I had 3 trains simply driving from A to B

and a simple logic (because only 1 train was possible).

And as a player i really hated it.

All you had to do was wait at the connection of the tracks and kill the train.

 

Now I have much more options after a train has spawned (where to go)

and if it can spawn (spawning location OR track to target free or used)

 

And as a player the things I hate most are

- targets that spawn at pos XXX when the  mission ran fox YYY minutes (including movement what can be calculated)

- targets that would be moving in reality (trains, tanks, vehicles) act as local targets (or being able to calculate where they are at a given time)

- logic that reproduces human behaviour and behaves 'perfectly'

 

So back to RoF

Taking a balloon, acting as an observer

Whenever an enemy came into outer range -> fireing a red flare

Whenever an enemy came into inner range -> going down to ground level

Whenever no enemy inside inner/outer range -> going up to normal level

 

No Problem, very simple to be implemented and done.... But realistic?

No!

So implemented more....

Enemy inside range (any) located but NOT seen

NO Enemy inside range (any) located but seen (due to flee shit on the glasses)

So I've got balloons crying for help and going down when no help was needed

and I've got balloons not crying for help or going down when enemy was in range

and I've got balloons going up again even if enemy was in range

 

So the more you want it to be random or realistic (or immersive) the more you have to implement

 

Deci

 

 

 

 

 

 

[Gambit21]

9 minutes ago, JG4_Deciman said:

 

So the more you want it to be random or realistic (or immersive) the more you have to implement

 

No, not really - or at least not to the extent that you think.  I can easily use the logic I mentioned and your “wait at the connection” doesn’t happen.

 

That said I wish luck.

 

 

 

Edited October 2, 2020 by Gambit21

[JG4_Deciman]

41 minutes ago, Gambit21 said:

It take me minute to pars my own logic sometimes a year or 3 down the road and remember what I was doing... I sure wouldn't want to crack the hood on this thing you're attempting.

 

As I'm happy about any kind of input/help/ideas there is no problem.

But it's hard (and I mean really hard) to get human created functions

(simple connection of triggers) to behave human like...

So the way is (as you showed up) to

create what you want

see how it is possible to realize

see how it's running (and what resources it is using)

eleminate bugs until it is running as expected

and then reduce it to the minimum.

 

And if the gap between 'wanted' and 'possible' is too big find a way that is possible and you can deal with...

Currently I'm at step 2-4 (checking how its running, eleminate bugs and reduce if possible)

 

But I know what I want.

I want it completely run independent (except track usage)

And I know that i've reached a point far beyond everyone who tried that before...

And I also know that everything I want IS possible.

The only thing I do not know is what has to be removed afterwards to make it runable without having a dia show instead of a mission.

 

But according to my first tests i know, that reducing the number of waypoints, ... used (so reducing the track system)

and implementing a connection of overlapping tracks would reduce that (was created, tested and works as expected)

 

The final step would be if the mission (or better template) could be imported without having to change hundreds of connections.

But there is no way (not even for me) to edit 120 connections by hand, when adding a new track connection.

But since 6 months (or maybe more) I use a selfmade tool to edit all these connections

what limits the mission construction itself to a very specific naming and grouping direction for anything used.

But it's working

 

Deci