That old Pathing and AI thing

[ZaphodBeeblebrox]

In the begining there was an accretion disc. Basically all solar systems start out as a flat disc of material that clumps into a star and planets. The disk is fairly flat, hence most planets orbit in a similar plane about the central star. So do any asteroid fields.

Now for pseudo reality to intrude: No engineer (in their right mind) would build a station in an asteroid field. This then is the major problem with a lot of pathing in XR. To make the game visually more interesting, stations, jump beacons, gates and highways are placed in some very difficult to access (for AI) places.

Had all of hese things been built above or below the ecliptic then a lot of bumping and bouncing could have been avoided.

In a certain sector there are a lot of very large long thin 'roids. The best path could be above all of these rocks. However I found an abandoned ship and ordered it to fly to the nearest gate. So what did it do? It tried to fly through every area of rocks it could find. Bouncy bouncy bouncy.

So rule No 1 move up or down until there is a clear line of sight then off you go.

I did a test, I flew to an area of space with a clear line of sight to a gate. I then ordered the ship to my current position. I landed and told the captain to fly to he gate. So he promptly flew back among the rocks and off we went again with hitting every thing in sight.

I tried this several times and each time the same. There appears to be a fixed path designed to cause he most stupid of behaviours.

[fix some typos]

[pref]

Yes, they move on a precalculated path and prefer the sector plane.
I assume 3D navigation was assumed to be too demanding for the target audience even though it'd be much easier on the AI. Probably the same reason why visual improvements often take precedence over functional ones or why the ui got to be this limited.

[hisazul]

As someone else so eloquently phased it, everything in this game moves on rails. That's why you see ships doing stupid crap like docking backwards for 5+ hours while they are ****** 200 meters away from docking point and so forth.

The system itself is fundamentally flawed, frankly x3 pathfinding would have worked better since we have no collision damage.

[RAVEN.myst]

I suspect that these very convoluted invisible paths that ships are forced to take in the DLC areas (including the Teladi Outpost areas) are intended to make the areas feel "larger" by the artificial means of making the trips longer.

Incidentally, Zaphod, Mr Galactic President, you can avoid that infuriating bouncy-bump while going through 'roid fields - go to external view and zoom out as far as you can - your ship will then behave the way it did pre-4.0, which is by ignoring 'roids and flying straight through them. Yes, this is hardly realistic or immersive in any way, but at least it DOES help to keep blood pressure down

[ZaphodBeeblebrox]

I suspect that several paths are designed to trap the players ships. I have recently spent several hours capping near a large rock in FO. There is plenty of space to boost to various places around the station there but only the offensive Teladi do this.

I have a Taranis with me to keep the capped ships safe. It shreds the Teladi warships very effectively.

I also got a mission to take out a criminal in another zone, wihich led to the cap of a Condor.
I rode this back to Allbion, it was a very slow and painful experience. It did give me plenty of time to focus on my property and station building.

Now then, I can easily see that by moving the guidance points the journey would have been much quicker and easier. If only the player could place navigation and jump beacons and then instruct our captains which of these "way points" to use. We might end up with a lot faster movement of our ships.

[RAVEN.myst]

In FO, at least they (ES) provided the pretext of dangerous nebulae for some of the weird detours, but in the HoL DLC systems, I think this may happen in Cold Star here and there (iIrc), but not in Toride or HoL (again, iIrc.)

I've also wished for ways to encourage more sensible navigation - deployment of navigational aids (it WOULD make for a really nice application for the deployable nav-buoys, which are a good idea but underused/usable at present). Another thing would be for trips to be more intelligently handled by captains with high navigation skills - at the moment, whether 2 stars or 5, they still slavishly run the entire intangible rat-maze.

[pref]

Its not just about the path they take, any adjustments needed in the path take enormous amounts of time. And these adjustments are far from optimal, ships can do huge detours that cost minutes or 10s of mins easily.
Watched ships of mine chase fleeing enemies several times. Even though there are no obstacles around them, the chaser ship always flies to the current position of the target, never calculates the distance it covers by the time the chaser can catch up. And every time the discrepancy becomes too large, the chaser would stop entirely, readjust the direction and restart.
One such stop takes 20secs+.

When i tried to have a bunch of ships move in a coordinated way in a boarding script, i had to issue jumps just to avoid the ships turning towards the target themselves, because a single turn resulted in a min delay if one ship had to turn 60degrees more then the others - comparable to the whole attack time.
Even during scripting you can only define a desired spot of arrival, rest happens at engine level.

Maybe if player could use their own jump beacons (with the nav beacons as Zaphod mentioned) and player ships would only use these if a flag is set in manager UI then we could force them out of the sector plane on arrival at least. In many cases this would help the AI perhaps, and would also give a greater sense of political-military-like border (player can maintain a beacon in neutral zones only).
Think something like this would be possible to mod..

Though im not sure exactly how pathing would act in this case, it might still happen that the ship will move to the closest point of the sector plane first, and would start turning on the target only after that. In this case the beacons would just lead to more delays.

[RAVEN.myst]

Its not just about the path they take, any adjustments needed in the path take enormous amounts of time. And these adjustments are far from optimal, ships can do huge detours that cost minutes or 10s of mins easily.

Indeed. I've seen ships take, for example, a 90-degree left turn by turning RIGHT by 270 degrees! (And doing so badly, too.) Madness, sheer madness...

Watched ships of mine chase fleeing enemies several times. Even though there are no obstacles around them, the chaser ship always flies to the current position of the target, never calculates the distance it covers by the time the chaser can catch up. And every time the discrepancy becomes too large, the chaser would stop entirely, readjust the direction and restart.

I've seen this repeatedly also in the context of one ship ordered to move to another friendly ship - ships' autopilots can't even perform a proper chase (so let's not even consider an actual intercept course, lol!) What puzzles me, though, is that (despite what some people have INCORRECTLY claimed in blindly loyal defense of ES's coding of XR), this didn't happen in previous X titles - I'm currently re-playing the whole series, and am up to Reunion now, so my info is fresh, not compromised by faulty memory. Even in X:BtF, if a ship was autopiloted to follow another, it would CONSTANTLY keep adjusting its course toward the target's current position - so there's no great "processing overhead" challenge, as has been claimed by some - that's simply BS.

When i tried to have a bunch of ships move in a coordinated way in a boarding script, i had to issue jumps just to avoid the ships turning towards the target themselves, because a single turn resulted in a min delay if one ship had to turn 60degrees more then the others - comparable to the whole attack time.

Yes, I've seen some appalling choreographical snafus (No offence to Snafu_X3 ) when using more than 3 ships in formation (in vanilla) - sometimes, just FORMING UP was beyond them, rolf - two or more ships sometimes insist on wanting the same spot - you'd think they would try to spread out evenly, right? Even when they don't try to violate the Paulis exclusion principle, I'd often find three escorts all formed up within 120 degrees of each other, instead of keeping 120 degrees BETWEEN each other. And this is all before they even get moving - as you say, pref, getting them to move in unison, once they each start turning to adjust course... well, they just keep triggering each other's collision avoidance, and often get into infinite loops of changing course - under SETA it can be quite trippy to watch, but comes the time when one wants to actually get underway (and I've tested this to a maximum duration of over 1hr game-time, courtesy of SETA - and then gave up!) Always I had to resort to the expedient of separating myself from my fleet so I would be OoZ - which rather gets in the way of being a fleet commander...

[pref]

I think the original idea was to never get in a situation when player needs to specify any exact behaviour. Perhaps this is the main diff for me between the 2 games, that the point in XR is to own stuff, while in X3 player wanted to own stuff usually to have greater control over what happens in the sandbox.
The initial absence of seemingly simple commands like fly to pos, follow etc makes me think it was supposed to work in a fully automatized way that works in most cases (esp when player is not looking).
And if you dont look deeper, just assign ships to stations, or pick a few trade destinations it works out ok i guess. But it immediately fails when one faces a more complex situation. And more complex might just mean having a single enemy race. That alone is enough to put AI in a state where it fails constantly.

I think X3 would probably look like stone age in pathing terms if we could peek into XR's code, but the end result is much worse for me too.

In X3 i just did not rely much on small ships, and was careful using seta. In my who knows how many 1000 hours on X3 i had really few funny/infuriating crashes or other unexpected inconveniences due to pathing compared to XR (even though there is no collision damage, which is a huge handicap for X3 as there you could loose ships on a miscalculation - wonder why its still off here..).

That system had its limitations, which were clear to me after a short while, and it was fully possible to manage without too much frustration.
XR seems much more advanced then the 'try a random direction if the obvious fails' logic of X3 pathing, but the way the game is designed hides any possible advantages imo.
Probably the same AI could function much better if the interface would be better, and the logic deciding on waypoints smarter and better parameterized in the UI.

Pity its not going that way, flee was a similar feature in 4.0 that didn't even get an on/off switch on the UI, with the decision completely trusted to a weird AI logic that doesnt consider ship role, attack/defence strength, just chances and employee skills.
No clue why ES avoids UI development whenever it seems even just remotely possible.
Are they afraid of getting too complex? Or they pay licenses per UI elements? It's so strange to me.
I remember one of the devs saying there are no FF settings because that was too confusing for players. Guess it's the same reason here as well with flee and general control over pathing.
But knowing how great impact games have on training ones brains and intelligence, this reasoning seems outright dangerous.
If everyone followed that logic in 20 years the most complex games would be about clicking the correct button out of 2 because of the feedback effect present here (drop level for more sales -> the average level of population drops as it always adjusts to the level of challenge encountered -> repeat until end of times).

Probably a better approach would be to work more on UI so with more options it is still less confusing then currently is (and i believe this is far from impossible).

[RAVEN.myst]

In my who knows how many 1000 hours on X3 i had really few funny/infuriating crashes or other unexpected inconveniences due to pathing compared to XR...
...
That system had its limitations, which were clear to me after a short while, and it was fully possible to manage without too much frustration.

Same here. I've long thought (and increasingly so, over the years) that the so-called "autopillock" has been way too maligned (even by luminary users who really ought to know better) - yes, it has its limitations, but just like you, I've had very few mishaps with it, and all of them avoidable, and it's simply because we take reasonable precautions. Factors that reduce X autopilot safety: speed, lots of small but deadly objects such as the asteroid fields in Seizewell and Rhonkar's Clouds and CBSW and such, and, most of all, SETA in combination with those factors (and also, autopilot getting spooked at last second by enemy presence/fire.) So, anyone trying to dock a fully upgraded Kestrel while turbo boosting in the middle of Seizewell at 10X SETA, and then throws up his/her hands in dismay upon turning into spacedust, is simply an idiot. It's analogous to running out onto a busy street in fast traffic, and then blaming the bus driver or the city's traffic light system or such.

No clue why ES avoids UI development whenever it seems even just remotely possible.

I've been asking myself questions like this lately. As mentioned elsewhere, I'm currently in a sequential replay of all X, and am up to Reunion, only to realise that it wasn't until X3TC that a decent mouse interface was introduced (as I played with joystick until it died some time ago, I was unaware of this my last time around) - a mouse control scheme that is modelled very much on that of Freelancer, which predated X2 by a few months! Also, features such as "autojump" and "autorefuel" and "autorearm missiles/ammo" were also only introduced in TC - quite surprising, really. And, if I'm not mistaken, members of the community were heavily involved in TC's development, so it seems to me that it took the intervention of outsiders to implement the most progressive UI advances ever to get into the X titles. Then along comes XR and, apparently, it must all inexplicably begin again from scratch. Most bizarre...

Are they afraid of getting too complex? ...
I remember one of the devs saying there are no FF settings because that was too confusing for players. Guess it's the same reason here as well with flee and general control over pathing.
But knowing how great impact games have on training ones brains and intelligence, this reasoning seems outright dangerous.
If everyone followed that logic in 20 years the most complex games would be about clicking the correct button out of 2 because of the feedback effect present here.

Unfortunately, I think you're bang on the money here - I call it (far from originally, of course) appealing to the lowest common denominator. And it's much like the decaying standards of language use in today's equivalent of "journalism" - it mis-educates the audience.
It's a troubling trend in games development that games, for many many years now, have been getting consistently easier and shorter - appealing to that lowest common denominator of the "instant gratification generation" (or, as I often call it, the ADD generation.) I've seen it in all manner of games, all genres (I was a gaming journalist for almost 2 decades, got to see the trend first-hand - before the falling standards left me "overqualified") - as games have become an accepted mainstream entertainment medium, no longer the province of "nerds", "geeks" and other intellectually overendowed pariahs (indeed, those words have become "cool", these days - which part I'm ok with, it's time humanity evolved toward greater cerebral bias), the audience base has broadened. However, just because it's no longer "uncool" to play games doesn't mean that everyone has the cranial capacity, or simply the tenacity and determination, to overcome the challenges of games such as we had ~20 years ago. No matter what sort of game I play, be it a space "sim", a strategy game, a fantasy MMORPG... everywhere I turn, I see players wanting quick fixes that BYPASS in-game challenges - cheats and win-buttons. It seems that being level 65 or whatever is more important than GETTING there, to most - never mind that they then haven't learned the skills they will need at the top of the pile (not to mention that they don't "deserve" to be there, in the first place). Not long ago I read some other commentator (perhaps on this very forum) suggesting that the future of gaming may devolve even lower than you suggest, pref, to the point where it's a two-step-zero-decision cycle of "click -> get reward" ad nauseam - rather puts me in mind of slot machines, come to think of it...

Besides, publishers WANT to push out as much product as possible, so it simply wouldn't do for a game to capture its audience for a long time during which those players don't buy freshly ground out consumer gaming crud, right? So the games HAVE to be made easy - so that they can be completed more quickly, and so that players get bored of them more quickly. To think that replayability used to be a marketing PLUS...

/end_pompous_rant

[ZaphodBeeblebrox]

Back on topic. They need to produce code that allows ships to fly in formation.

If you grouped ships in previous games you had the option to pick a formation.

If you imagine a cube similar to a Rubix, then we could populate something like that, placing each ship in one of the smaller cubes.

The turning speed is then that of the slowest ship. As is maximum forward velocity, and also when boosted.

When moving from Point A to point B. The fleet needs to orientate as one then rise above the eclipic and move in formation.

In the past I have animated wire frame models of spaceships. Simlilar to those in the original Elite. It is not difficult to do if you have done GCSE maths and know a coding language. The tricky bit is getting them to move together, especially if they rotate with a forward velocity. This is due to the outer edge having to travel faster than the inner.

[RAVEN.myst]

The fleet needs to orientate as one then rise above the eclipic and move in formation.

Now wouldn't that be something to see? The order is given and, in stately fashion, the group of ships rises out of the asteroid clutter into clear space, individual ships adjusting their facing as they do so, and sliding into their relative positions once they have cleared the rocks; then, as one, the blinding lights of their boost engines flare up, and they speed off in unison...

Simlilar to those in the original Elite.

Lave. Diso. Leesti. Bare-bones Cobra Mk.III. Nostalgic sigh... (incidentally, you may or may not be aware of it, but there's an open-source remake of that one out there, so faithful that they even accurately reverse-engineered the universe-generation algorithm - good fun when you fancy a retrospective change of pace...)

The tricky bit is getting them to move together, especially if they rotate with a forward velocity. This is due to the outer edge having to travel faster than the inner.

As with wheeling while marching in formation, the trick here would be for the inner side to "shorten stride" by an appropriate ratio (and half that in the centre) - I'm guessing nothing too scary for a decent programmer with an understanding of math (if dozens of jarheads marching in lockstep can pull it off, after all... )

[pref]

And, if I'm not mistaken, members of the community were heavily involved in TC's development, so it seems to me that it took the intervention of outsiders to implement the most progressive UI advances ever to get into the X titles. Then along comes XR and, apparently, it must all inexplicably begin again from scratch. Most bizarre...

Yes, it was the bonus pack that made TC into what it is - and i think without it the game would have a much lower value (im not even sure if would have fallen in love with it without the community-made features).
Nice example of how those last careful touches/adjustments can have a huge impact on a game.

I call it (far from originally, of course) appealing to the lowest common denominator. And it's much like the decaying standards of language use in today's equivalent of "journalism" - it mis-educates the audience.
It's a troubling trend in games development that games, for many many years now, have been getting consistently easier and shorter - appealing to that lowest common denominator of the "instant gratification generation" (or, as I often call it, the ADD generation.)

Just imagine how much further profit this brings, such audience means so much higher success rate from marketing pov.
Funny, how these small seemingly independent acts of carelessness, greed and manipulation add up to possibly become a near perfect self strengthening process in the long run
Reality can be so.. symbolic? sometimes.

Back on topic. They need to produce code that allows ships to fly in formation.

In the past I have animated wire frame models of spaceships. Simlilar to those in the original Elite. It is not difficult to do if you have done GCSE maths and know a coding language. The tricky bit is getting them to move together, especially if they rotate with a forward velocity. This is due to the outer edge having to travel faster than the inner.

I think w.evans' MICT improves on in-formation flight (among numerous other things), you could give it a try perhaps if you dont use it already.

As far as i know currently no scripting commands support adjusting the full path of an object. You can only pick the desired destination, and use some params affecting how the 'rail' will be shaped on which the object moves. And any frequent geometric calculations on scripting level would most likely result in a really low fps. Smells like an engine level change.

Maybe if you detail the required changes over in devnet there is a higher chance to be heard. Pretty sure im not readig this wish for the first time.

[UniTrader]

Regarding adjusting path scripting-wise: i think you can define waypoints by using move_to, interrupting it immediately and calling it again with abortpath="false" - but not tested yet.. also move_to will add additional waypoints if it thinks they are needed, which limits this to guaranteed valid paths

Also one reminder to the pathing: the paths are calculated when movement begins, there are no pre-defined paths i am aware of - i think an earlier post from me was misunderstod



Also the spline flight control model is not the only one used, its just the most used one. also its the only one where parking works correctly. But it does not support formation flight as follower - in this case its the steering fcm i think. (I have only looked into single capship movement (spline fcm) in detail so far, and much of that is also assumption based on observed behavior, not knowledge - so please dont take my word for granted)

[pref]

You could define waypoints, but im not sure how that would work out performance wise. I'd expect a heavy load doing such calcs from aiscripts..
Maybe from LUA it would run better?

I tried quite a few move_to combinations (all on capships though), but it wasn't easy moving them in a coordinated fashion. I saw a few different options, like avoid, spline or run without any steering.
The main problem was that they spent a lot of time adjusting path, while each needed a different amount to come up with the next direction so i ended up making them wait for eachother, and used jumps instead of turns to ensure they will start the next move_to at the same time.

I got the rail idea because they seem to approach objects on the same spline, and alsso because they keep to sector plane usually (even if you turn on the 3rd axis movement).

[UniTrader]

i think we should continue this in the Scripting forum but here some approaches for more coordinated capship formation behavior:

1. Captains - if all Ships have the same top speed put the least skilled Captain in the leader Ship (eg 4★ Captain in Leader Ship, 5★ in escorts) - because Skill also includes a multiplier to top Speed (0.5 for 0★, 1.0 for 5★)

2. For better formation coordination
Leader signals himself with what he plans to do (Jumping, boosting, Gate Passage etc.) in advance - first time for preperation where he passes all parameters needed by followers(Coordinates, Gate etc.) and an Empty Group where all followers may add themselves while they prepare, too. a second time he sends another Signal that he now starts this Action and Followers should do the same (the given group has to be empty first of course, otherwise the Action will be delayed until it is )
already started on movement scripts which include this, but i have no follow or escort script yet which actually make use of this functionality though...

3. also i think its best to use the default FCM (spline for capship leader, i think steering for followers) except in a few rare cases (eg Spline FCM needs a few seconds before actual movement starts because it has to calculate the path first, Steering FCM can move immediately but is probably more ressouce-intensive and definietly more erratic when avoiding Objects)