Posted by: AbuDhabi
« on: January 14, 2014, 11:42:59 AM »What exactly happened with the Belasco Commune?
Posted by: Steve Walmsley
« on: January 09, 2014, 02:17:25 PM »Wow, you waited for the wrong time to reply on this one, Steve's actually made this exact change in the next patch :p.
Thank you steve, and thank you belasco commune for playing tag with those silly Russian Oscar class destroyer commanders.
Actually I made the change for ships/missiles intercepting moving fleets. There is still no intercept movement for planets for the reasons I mentioned above.
And you're right it was the Belasco Commune that persuaded me to finally sort this out
Steve
Posted by: MarcAFK
« on: January 09, 2014, 06:57:23 AM »Wow, you waited for the wrong time to reply on this one, Steve's actually made this exact change in the next patch :p.
Thank you steve, and thank you belasco commune for playing tag with those silly Russian Oscar class destroyer commanders.
Thank you steve, and thank you belasco commune for playing tag with those silly Russian Oscar class destroyer commanders.
Posted by: AbuDhabi
« on: January 09, 2014, 06:00:26 AM »It's also partly because a lot of the potential intercepts are far from simple. If your destination is a moon orbiting a planet that is orbiting a star that orbits another star which in turn orbits a third star (while taking lagrange points into account), then working out an intercept course is tricky. I found this when I had to do exactly that calculation in Newtonian Aurora (because constantly changing course is expensive in fuel) and also allow for acceleration and deceleration of a ship that is constantly losing mass (and therefore changing acceleration rate). As noted above, it isn't often an issue so it seemed like a look of effort to solve a minor issue.
Steve
That makes sense. Thanks.
Posted by: Steve Walmsley
« on: October 21, 2013, 03:41:07 PM »For the vast majority of the game, it doesn't matter. Your ships move so much faster than the planets that you're not really losing much by direct chase. For the portion where it does matter (extremely slow, conventionally-engined commercial vessels in the early game), you can work around it by placing waypoints. That's what you have to do when trying to intercept enemy task groups, and I haven't heard anyone complain about having to manually work out those intercepts. In fact, that's a major part of games like this.
While it would be nice if the game predicted planetary positions and moved toward those, in most cases, it just doesn't matter. So I wouldn't call it "terrible," so much as "inconvenient." If you have an alternative implementation ready to go, why not submit to the Pulsar 4x group? The base functionality of Aurora is unlikely to be changed, especially in marginal cases like this.
It's also partly because a lot of the potential intercepts are far from simple. If your destination is a moon orbiting a planet that is orbiting a star that orbits another star which in turn orbits a third star (while taking lagrange points into account), then working out an intercept course is tricky. I found this when I had to do exactly that calculation in Newtonian Aurora (because constantly changing course is expensive in fuel) and also allow for acceleration and deceleration of a ship that is constantly losing mass (and therefore changing acceleration rate). As noted above, it isn't often an issue so it seemed like a look of effort to solve a minor issue.
Steve
Posted by: Bgreman
« on: October 21, 2013, 09:48:05 AM »Are you saying it is not terrible that pathfinding does not do any prediction for where the target they're headed for is going to be considering their speed?
For the vast majority of the game, it doesn't matter. Your ships move so much faster than the planets that you're not really losing much by direct chase. For the portion where it does matter (extremely slow, conventionally-engined commercial vessels in the early game), you can work around it by placing waypoints. That's what you have to do when trying to intercept enemy task groups, and I haven't heard anyone complain about having to manually work out those intercepts. In fact, that's a major part of games like this.
While it would be nice if the game predicted planetary positions and moved toward those, in most cases, it just doesn't matter. So I wouldn't call it "terrible," so much as "inconvenient." If you have an alternative implementation ready to go, why not submit to the Pulsar 4x group? The base functionality of Aurora is unlikely to be changed, especially in marginal cases like this.
Posted by: Nathan_
« on: October 20, 2013, 10:52:40 PM »The single biggest reason for the chase the planets implementation is its simplicity, no need to create extra hassle when not needed.
Posted by: AbuDhabi
« on: October 20, 2013, 03:56:42 PM »This is extremely helpful.
Are you saying it is not terrible that pathfinding does not do any prediction for where the target they're headed for is going to be considering their speed?
Posted by: Bgreman
« on: October 14, 2013, 03:59:06 PM »Posted by: sloanjh
« on: October 12, 2013, 10:30:51 AM »So the database gets loaded into memory? That would be faster, yes.
The DB is loaded into memory objects at the start of a movement cycle, so that it is NOT accessing disk during each interval. There should be a post from Steve in Mechanics that's 4-6 years old talking about this optimization when it was done.
John
Posted by: AbuDhabi
« on: October 12, 2013, 06:43:38 AM »So the database gets loaded into memory? That would be faster, yes.
Posted by: Mel Vixen
« on: October 12, 2013, 03:18:21 AM »yes memory and most likely relative stationary so issuing an GetAddress(x) is faster then on the fly calcs.
Posted by: TheDeadlyShoe
« on: October 11, 2013, 08:11:03 PM »Quote
it is unlikely that accessing disk-bound data would be faster.I would think it's in memory.
Posted by: AbuDhabi
« on: October 11, 2013, 03:38:36 PM »The reason that the X/Y coordinates are stored is so that you can have one function that sets where a TG is moving (or a mineral packet / missile /etc is being sent). That function just looks up the X/Y position of whatever target object (lots of tables in the game have an X/Y coord, and many also have a "last x" / "last Y" so that you can draw the movement trails as well).
This can be done with on-the-fly calculations as well. Simply calculate positions for t1 and t2, and draw those. The last time increment is a known value.
As for the question about what happens if a planet / body moves when a ship is trying to go there, it depends on what order things happen during the production cycle. If planets move first, there is no problem, as the X/Y for the body will be updated before the ship tries to figure out how to get there. I would assume body motion comes first for this reason, but it's possible it may not. Just watch a slow conventional engine freighter trying to catch up with a planet and you will see that they aren't doing any kind of predictive motion interpolation. They just head directly for the body.
That's terrible.
As for why to store X/Y for each object rather than calculate it on the fly each time, that should be obvious. Performing a calculation is almost always going to be slower than a simple DB lookup. When you compound this with potentially thousands of calcs/lookups every increment, it can get slow pretty quick.
No.
Performing a cheap calculation (as is the case here) will almost always be faster than a "simple DB lookup". Trigonometry stopped being calculationally expensive more than a decade ago. Even with solid-state drives, it is unlikely that accessing disk-bound data would be faster.
Posted by: Bgreman
« on: October 11, 2013, 01:21:03 PM »It should be noted that it is not necessarily every five days. Orbital motion calculations are performed every production cycle (whatever you have that set to) and the body positions updated then.
The reason that the X/Y coordinates are stored is so that you can have one function that sets where a TG is moving (or a mineral packet / missile /etc is being sent). That function just looks up the X/Y position of whatever target object (lots of tables in the game have an X/Y coord, and many also have a "last x" / "last Y" so that you can draw the movement trails as well).
As for the question about what happens if a planet / body moves when a ship is trying to go there, it depends on what order things happen during the production cycle. If planets move first, there is no problem, as the X/Y for the body will be updated before the ship tries to figure out how to get there. I would assume body motion comes first for this reason, but it's possible it may not. Just watch a slow conventional engine freighter trying to catch up with a planet and you will see that they aren't doing any kind of predictive motion interpolation. They just head directly for the body.
As for why to store X/Y for each object rather than calculate it on the fly each time, that should be obvious. Performing a calculation is almost always going to be slower than a simple DB lookup. When you compound this with potentially thousands of calcs/lookups every increment, it can get slow pretty quick.
The reason that the X/Y coordinates are stored is so that you can have one function that sets where a TG is moving (or a mineral packet / missile /etc is being sent). That function just looks up the X/Y position of whatever target object (lots of tables in the game have an X/Y coord, and many also have a "last x" / "last Y" so that you can draw the movement trails as well).
As for the question about what happens if a planet / body moves when a ship is trying to go there, it depends on what order things happen during the production cycle. If planets move first, there is no problem, as the X/Y for the body will be updated before the ship tries to figure out how to get there. I would assume body motion comes first for this reason, but it's possible it may not. Just watch a slow conventional engine freighter trying to catch up with a planet and you will see that they aren't doing any kind of predictive motion interpolation. They just head directly for the body.
As for why to store X/Y for each object rather than calculate it on the fly each time, that should be obvious. Performing a calculation is almost always going to be slower than a simple DB lookup. When you compound this with potentially thousands of calcs/lookups every increment, it can get slow pretty quick.
