Senario :
When the autopilot is engaged, when an object, like a roid or station is in direct line between the ship position and the target destination point, the ship will crash into the obstacle. 98% guarenteed.

The ship proceeds directly toward the obstacle at full speed. At the last instant, the ap recognises that a collision is imminent and initiates a 90 degree course change.

At full speed, inertia carries the ship into collision. Game over.

Problems :
The avoidance is recognised far too late. The evasion is far too radical. Inertia is ignored in the avoidance taken.

Solution :
When the AP is engaged, it should recognise a collision will occur on the direct course. A course correction of say 25 degrees is applied before the ship even begins to move (may need more or less, but without knowing the existing coding, its hard to advise what will work best). This is then checked for collision, until a course that will not result in a collision is selected. Then the ship begins to move under AP control. After which, normal course checking for collision and destination should detect the needed change in course once the obstacle is cleared. The ship moves around the main obstacle in a sort of arc, rather than trying to avoid it at the last second.

Extra :
AI controlled ships should also use the same logic.

As far as I can tell, the speed used for autopilot avoidance of obstacles is hardcoded, not using the actual max speed of each individual ship.

The faster the ship, the more likely it will collide with something. Its as if the avoidance is being activated far too late because the speed of the ship is not what the avoidance coding expects it to be and so the ship is closer to an obstacle by the time avoidance happens, than the code thinks the ship should be. Result is collision, because the avoidance is triggered too late.

The autopilot makes no distinction for the size of a vessel and its ability to navigate an asteroid feild.

Anyone who has watched a Mammoth navigate from the north to south gates of CBSW knows how torturous the route is for a big ship.

I've sat in ore belt and told a mammoth to move 500 meters from a gate and watched it do a long round the sector route to get there, to avoid a lot of roids it didnt even need to go anywhere near. In most cases, the Mammoth is destroyed.

The procedure for moving a big ship should be different than for small ones.

The main problem is that the TL/M1/M2 proceeds at full speed the same as any other ship, and relies on the AP to avoid collisions. And it cant cope.

The procedure for moving a large ship should be :

Select a course free of obstacles, turn the ship while stopped, move the ship to a safe point, stop, find a new course, move the ship at an appropriate speed, stop, find, move, stop, find move etc.

TL/M1/M2 have no ability to turn and should not be turning at full speed in the middle of an asteroid field or near stations. All menouvering must be made while stopped.

As this code seems to exist to align with a gate, or a docking port, it should be possible to get the AP to use it always.

While partially fixed in 1.4, ships still hit stations and other ships while undocking from the external docking ports.

Several of the capital ships have been reported to always hit the station on departure. If IS, ship is destroyed.

Obviously, some aspect of the models is not being handled properly.

I'm not sure which ships are involved so would appreciate someone listing them here.

Part of the problem is ships going to full speed ahead, too soon. Or they rotate too close to the docking port and hit things because the model is longer than the the gap allowed for them to turn in.

All ships should back out of the docking arms to the start of the docking lights, and then the AP takes over and begins to turn the ship to travel. Speed is not applied to the ship until the direction of travel away from the station has been achieved, and confirmed as not being a collision course.

The player ship should reverse at full reverse speed, until the player manually changes the direction and speed. (this seems to happen in 1.4, but not 100% of the time). Joystick overrides are suspected of causing player collisions, but not enough investigation has occured to figure if this is the problem.

If a ship survives an actual collision, it continues to have full speed ahead and attempts to change course to avoid what its already hitting.

If the object it hit is a station connector within a complex, the ship is unable to veer away from the connector, and continues to "Head Butt" the connector until it dies.

Once a ship has collided, speed should be cut to zero, it should back away from the object (the same as backing away from docking), find a vector that it will not collide on, turn while stopped, and then slowly add speed on that vector.

Add voice for the Tractor Beam Forge. Everytime I select one its "...... ...... ...... alpha".

Symptom: Ship misses the object, turns 360, and is in same position than before. Endless loop. Ship just circles around the object until the command is turned off.

Proposed solution: Stop, turn on target, approach slowly. Or whatever suits the other autopilot modifications.

Speed is usually a factor here. The ap moves the ship at full speed, and so misses on the first pickup, and then tries to reallign itself on the target at full speed. Eventually it may or may not, slow down enough to align correctly. If it doesnt slow, it never moves far enough away to properly align at the speed the ship is moving.

If the ship misses the target on the first pass, it should stop, realign then move slower to pick up. Most pickups should be under 100, yet faster ships use top speed all the time.

the ship slides sideways as it's turning in X3. What happens is the ship turns to face the target, slips sideways and misses it.
It needs to approach from further away so the slide has finished and it can fly straight at the target.

It would be far better if the transporter device was used to beam the containers aboard, than the auto-pilot trying to get the line-up right.

IMO, the "realistic" solution would be to expire the message on any boards that have it the moment one copy is accepted anywhere.

However, I assume that the XI script simply adds the message to BBS when invasion is 'active' and you dock at valid stations. Thus it may not 'know' which BBS actually have a copy. Maybe a solution would be to add the message on dock and expire it already on undock? It would reappear if one redocks anywhere, as long as the mission remains 'active'.

Any ship docked at a station removed by the God-Engine is destroyed along with the station. This includes NPC and Player Ships. Since the player gets no warning of this event, ships are lost without warning and beyond the control of the player. This happens to UT's as well as station traders.

This event should first undock all ships, remove station, ship orders are reactivated so Player and NPC ships move again with a purpose. (NPC ships optional, Player Ships essential).

The range of the tractor beam is 2km. But high yeild ore roids cannot be towed from that close, given only large long ships can mount a tractor beam. The Ore Mine on high yeild roids spins constantly and the tow is lost continuously after only seconds attached.

The normal range for towing is 3.5 to 4km. The tractor beam range should realistically be 4km.

When a new station is added to a complex, NONE of the prices set for intermediate or product trading should be changed.

The jumps value is reset too and should not be.

The name of the station that the player changed it to is lost as well. If you need to identify a particular station and you have 10 with the same name (eg. Crystal Fab Alpha), its not enough to tell them apart. In the case of a Mine, where the player name includes the yeild, the yeild information is lost completely once joined to a complex, where if the name remained on the individual station, this information is retained. Each station in a complex, should retain its name from before joining to a complex.

OOS Lasertower performance is pitiful. I have seen 50 LT's take 20 minutes OOS to kill 2 ships out of 6, with 2 casualties. Jump in and IS, the same LT's take 20 seconds to destroy the other 4 ships without casualties themselves.
I have modded the LT's to take 1gb sheilds, and yet, OOS, you still lose LT's at the same rate as 25mj shields.
This appears to be hardcoding issue in the way LT's fight OOS, where the specs of the gun are ignored, so any scripting/modding changes are ignored.
Any hardcoding of OOS LT combat, must access the spec files for sheilds and gun values.

General review of the station announcements would be grately received by all. Removal of the old X2 announcements and replacement with new ones please. Alternately, a turn off station announcements switch in the player options.

The player ship is an Octopus spawned in Kingdoms End. When you push the throttle forward using X key a small bar of light slides forward along the centre axis of the ship and stops just in front of the nose of the ship. Decreasing the throttle moves it back towards the ship. It is always there at full throttle. After a while you stop noticing it though - it is not too intrusive.

Don't know if this is general - when going into a trade station barter menu, if there are M or Larger goods (the Octopus is an M5 that can only carry S type goods) the quantity column shows M or XL e.g. instead of 0. I think this is just for goods bigger than S type, as the S tyep show a qty of 0.

I've just started plot mission 5 where I am escorting the mammoths and the mission just never seems to end!
I killed all the Khaak from three turrets, then mopped the remainder up in my Nova. One of the mammoths did die (ran into an asteroid I think, not sure though).  I followed the convoy to Paranid prime and now they just keep flying round.

3rd time lucky - reloaded again from the same save (luckyly I did a save just before starting the mission!) and on killing all the Khaak I got the confirmation.
Two things were different. Firstly one of the mammoths didn't splat itself on an asteroid shortly after I ported out.
Secondly there were 5 khaak in each group I killed from the turrets. THe other games there were only 4...

IS Mobile Mining is way to dangerous still. Part of this is the auto-pilot and its problems, but most of it is the fact the ship is moving while picking up the ore chunks, and vulnerable to collision. Picking up can only be done safely while the player is OOS. The whole process of a moving ship inside the post-1.3 asteroid field trying to pick things up at high speed with an AP that cannot avoid collisions is basically rediculous.

I suggest that the pickup process be changed as follows. Require a transporter device. On activation of "collect rocks in sector" command, ship moves to a safe point within transporter range of collectable rocks. Ship stops. Ore Collector and transporter combination beams rocks into the cargo bay without opening the cargo bay doors. Ship is moved to another safeplace near collectable rocks, stops, collects, moves and repeat.

No messing about with the auto-pilot, no having to ensure 2 roids are not too close together and unable to avoid an impact.

well with the new bonus packs frieght beamer mods you don't need to dock with them now just beam your stuff in bit of a pain thou i know if your jumping your TL all over the universe and you can't take you TS's with you.

That only solves a relatively minor problem. When placing large numbers of factories, the inability to gather up freighters in your TL means that you need to outfit every freighter with jumpdrives and energy cells simply to get them safely to where they're needed. No more flying a TL to a shipyard, purchasing the TS's, loading them up and transporting them to their factories. It's now a LOT more tedious to do, not to mention expensive. You can buy a TS for as little as 100K, but then you have to give them a 100K jumpdrive! And then, you have to get the jumpdrives on them, which means, since you can't carry more than one at a time, you need a TL to carry a load of fighters that can carry the jumpdrives. Then you need to somehow transfer all those jumpdrives from the fighters to the transports simply to get the transport to jump to where they're needed. Whew!! Yeah, that sounds like fun.

And yet another problem. I capture ships for a 'living'. That means lots of TS & TP smugglers. In X2, any captured freighter could be loaded on the TL/M1 and shipped to market. Now, unless a shipyard is nearby, it means equipping the new capture with a jumpdrive, Nav software and energy cells and jumping it to a shipyard. But then, unlike X2 where you could beam the jumpdrive off the ship before it jumped, in X3, you have to fly to the shipyard and manually transfer the jumpdrive off the TS/TP before you sell it, or lose 50K for each jumpdrive you use. That also sounds like fun, doesn't it?

The lack of TS/TP docking capability on both TL's and M1's has dramatically reduced gameplay and increased tedium in a number of areas. It's not simply about transferring wares between two ships. Indeed, I need to transfer upgrade modules between two ships much more often than wares. So the remote transfer function is of limited use to me.

For whatever reason the decision to not allow TS/TP's to dock with a TL/M1 was made, playing the game as a TRADER is now significantly more complicated, as Nanook has outlined. The ability to move large numbers of unoutfitted ships to the few places they can be outfitted (especially jumpdrives) is essential given the inability to buy things like jumpdrives at more than 1 a ship. Anyone who is based in the east sectors, has significant trouble, not to mention fluing time, getting a newly bought ship to CBSW to buy a jumpdrive. It basically isnt fair on the trader (or the capper for that matter) to have taken away the ability to transport freighters accross the universe in a single jump using a TL or M1. The M1 has become purely a strike-carrier, and the trader player does not need this. Traders need a ship mover-carrier instead, and this has been taken away from us. The freighters are too big to dock argument is very thin. The docktl script shows it can be done, but that script has its own limitations.

Please please please please please put this functionality back and let us dock TS and TP ships at a TL or M1. Alternatively, add a M1 and TL variant to each race that is a ship-mover, not a strike craft.

So there are two possible solutions: either let something to carry freighters, or make remote bulk transfer of upgrades possible. I would rather see the mass hauling of upgrades. However, I fear that adding docking possibility is easier to implement.

It seems to be that 1.4 introduced random spawnings of small groups of M4/M5, with no particular hit this target order or go here order. These spawned ships are later de-spawned but players are capping them before the despawn happens. Some ships that are capped, disappear as soon as they leave the sector. They just vanish, without any log entry as to why.

From my observations, this particular disappearing ship phenomenon is restricted to the pirate M5's and occasional M4's that spawn near the edges of sectors, in groups of three, and the civilian ships that spawn in regulated space. These spawns were introduced in the latest patch. They cannot be saved, no matter what you try. Believe me, I've tried everything I could think of. These disappearances occur some amount of time after you leave the sector where the ship is located, or send it to another sector. They disappear out of stations, out of TL's, as they pass through gates, and just out in space. If it's their time to go, they go. And you never get a message that they've been destroyed. It appears to be a 'despawn' flag or some such thing that doesn't get reset when the player captures the ship.

It doesn't seem to affect any of the other spawns, such as pirates at Teladi shipyards and pirate bases. I've never had any TS/TP/M3 disappear in that manner (other ways, yes). So far, out of some 500+ captures in the two games I've started since 1.4, I've had maybe 20 go missing due to this bug. So I don't thnk it's a major problem, unless you really want to keep one of these ships (for me, it was a Pirate Harrier Raider that I really, really, REALLY wanted, but it just wasn't to be )

In the claim code, it would seem there should be a check to see if the player has claimed the ship, and if so, the despawn is aborted, by removing whatever flag exists to make that happen. Should be a minor if-else check in the claim code to disable the despawn flag.