Login
User Name:

Password:



Register
Forgot your password?
Vote for Us!
Bug in disarm( )
Nov 12, 2017, 6:54 pm
By GatewaySysop
Bug in will_fall( )
Oct 23, 2017, 1:35 am
By GatewaySysop
Bug in do_zap( ), do_brandish( )
Oct 18, 2017, 1:52 pm
By GatewaySysop
Bug in get_exp_worth( )
Oct 10, 2017, 1:26 am
By GatewaySysop
Bug in do_drag( )
Oct 8, 2017, 12:40 am
By GatewaySysop
LOP Heroes Edition
Author: Vladaar
Submitted by: Vladaar
Heroes sound extras
Author: Vladaar
Submitted by: Vladaar
6Dragons 4.3
Author: Vladaar
Submitted by: Vladaar
Memwatch
Author: Johan Lindh
Submitted by: Vladaar
Beastmaster 6D sound files
Author: Vladaar
Submitted by: Vladaar
Users Online
CommonCrawl

Members: 0
Guests: 11
Stats
Files
Topics
Posts
Members
Newest Member
476
3,704
19,231
608
LAntorcha
Today's Birthdays
There are no member birthdays today.
Related Links
» SmaugMuds.org » Codebases » SWR FUSS » Incorrect vector calculations...
Forum Rules | Mark all | Recent Posts

Incorrect vector calculations in the space code
< Newer Topic :: Older Topic >

Pages:<< prev 1, 2, 3, 4 next >>
Post is unread #41 Oct 19, 2009, 8:48 am
Go to the top of the page
Go to the bottom of the page

Keirath
Magician
GroupMembers
Posts144
JoinedJan 24, 2008

What is the best way to do this after converting to vectors? (This is in hotboot.c)

   fprintf( fp, "VX %d\n", ( int )ship->vx );
   fprintf( fp, "VY %d\n", ( int )ship->vy );
   fprintf( fp, "VZ %d\n", ( int )ship->vz );



       
Post is unread #42 Oct 19, 2009, 9:07 am   Last edited Oct 19, 2009, 9:12 am by Kayle
Go to the top of the page
Go to the bottom of the page

Kayle
Off the Edge of the Map
GroupAdministrators
Posts1,195
JoinedMar 21, 2006

Without having any idea what the V in that stands for, I'd guess something like:
Thing = name of whatever V translates to in your new vector changes.
 fprintf( fp, "Thing %lf %lf %lf\n", ship->Thing->x, ship->Thing->y, ship->Thing->z );


And then read it in with something like:
            if( !str_cmp( word, "Thing" ) )
            {
               char *line;
               double x1, x2, x3;
               line = fread_line( fp );
               x1 = x2 = x3 = 0;
               sscanf( line, "%lf %lf %lf", &x1, &x2, &x3 );
               ship->Thing->x = x1;
               ship->Thing->y = x2;
               ship->Thing->z = x3;
               fMatch = true;
               break;
            }


[Edit:] Just looked at the actual code by Caius, and it looks like he uses floats. So those would just be %f and
double x1, x2, x3
would be
float x1, x2, x3;
       
Post is unread #43 Oct 19, 2009, 9:13 am
Go to the top of the page
Go to the bottom of the page

Keirath
Magician
GroupMembers
Posts144
JoinedJan 24, 2008

That is what I had thought, but I wanted to be sure. Thanks, I appreciate it.
       
Post is unread #44 Oct 19, 2009, 9:43 am
Go to the top of the page
Go to the bottom of the page

Caius
Magician
GroupMembers
Posts132
JoinedJan 29, 2006

Kayle said:

Just looked at the actual code by Caius, and it looks like he uses floats. So those would just be %f and
double x1, x2, x3
would be
float x1, x2, x3;

I used floats in the examples at the start of this thread. In the actual code I use doubles consistently, though.
       
Post is unread #45 Oct 19, 2009, 9:57 am
Go to the top of the page
Go to the bottom of the page

Kayle
Off the Edge of the Map
GroupAdministrators
Posts1,195
JoinedMar 21, 2006

Mmhmm. I was referring to the ones at the start of the thread. I haven't downloaded anything lately as the right click function of my mouse doesn't want to work most of the time. =/
       
Post is unread #46 Oct 19, 2009, 10:11 am   Last edited Oct 19, 2009, 10:11 am by Caius
Go to the top of the page
Go to the bottom of the page

Caius
Magician
GroupMembers
Posts132
JoinedJan 29, 2006

Kayle said:

Mmhmm. I was referring to the ones at the start of the thread. I haven't downloaded anything lately as the right click function of my mouse doesn't want to work most of the time. =/

That sucks.

Anyway, I recommend not using the Vector3 structures directly in the actual space code, for the most part. There are many pitfalls you can do, like accidently using the heading instead of the position for getting the distance. Here are some examples of what you should do instead:

// Get distance from ship to ship
double ship_distance_to_ship( const SHIP_DATA *ship, const SHIP_DATA *target )
{
  return vector_distance( &ship->pos, &target->pos );
}

double ship_distance_to_planet( const SHIP_DATA *ship, const PLANET_DATA *planet )
{
  return vector_distance( &ship->pos, &planet->pos );
}

It may seem a little odd at first, since they only call vector_distance anyway, but there are a few reasons for doing it this way. The first one is as I stated above; you avoid using heading instead of position by mistake (very easy to do). The second reason is that in some larger functions you might have pointers to both planets and ships, and it's easy to get the distance to a planet when you really want a ship or a missile when you're using vector_distance() directly. By using functions like the above, the compiler will stop you from doing these errors. The third reason is that this makes the code more readable, its intention is clearer. Finally, the Vector3 structure is kind of a low-level implementation detail, and by hiding them behind an interface like this your code is more robust in the face of future changes.
       
Post is unread #47 Oct 19, 2009, 10:25 am
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

Something to keep in mind, by the way, if efficiency becomes an issue, is that when comparing distances you don't necessarily need to take the square root. For two positive numbers x and y, x < y is equivalent to sqrt(x) < sqrt(y). Therefore, if you are running in a tight inner loop and efficiency really matters (note: this is unlikely to be the case) you can avoid the sqrt if you are just comparing distances (e.g., sorting the list of ships by their distance to some point).



As for the function names, in C++ you can do argument type overloading to have something like:

double ship_distance(const SHIP_DATA* ship1, const SHIP_DATA* ship2);
double ship_distance(const SHIP_DATA* ship, const PLANET_DATA* planet);


And if you use object orientation, you can further simplify this so that you have just:

ship->distanceTo(planet);
// or...
ship->distanceTo(ship);


If you wanted to get fancy, you would define these things as implementing some kind of interface that knows about position and velocity, so that with a single function, you can compute the distance between any such objects.
       
Post is unread #48 Oct 19, 2009, 11:21 pm
Go to the top of the page
Go to the bottom of the page

Kayle
Off the Edge of the Map
GroupAdministrators
Posts1,195
JoinedMar 21, 2006

I <3 Encapsulation.
       
Post is unread #49 Oct 20, 2009, 7:48 am
Go to the top of the page
Go to the bottom of the page

Caius
Magician
GroupMembers
Posts132
JoinedJan 29, 2006


Kayle said:

I <3 Encapsulation.

mee 2 lol
       
Post is unread #50 Oct 21, 2009, 5:39 pm
Go to the top of the page
Go to the bottom of the page

Rojan QDel
Fledgling
GroupMembers
Posts25
JoinedDec 30, 2006

On the note of converting it all in a matter of hours, I just removed all the old distance fields and sorted through the compile errors :)
       
Post is unread #51 Oct 22, 2009, 12:35 pm   Last edited Oct 22, 2009, 12:35 pm by dbna2
Go to the top of the page
Go to the bottom of the page

dbna2
Sorcerer
GroupMembers
Posts600
JoinedDec 2, 2008

which are those... I don't use SWR codebase, just trying to import the space system to a normal smaug.


Also does SWR2.0 that was posted here have the space system already changed?
       
Post is unread #52 Oct 22, 2009, 12:57 pm
Go to the top of the page
Go to the bottom of the page

Caius
Magician
GroupMembers
Posts132
JoinedJan 29, 2006

dbna2 said:

Also does SWR2.0 that was posted here have the space system already changed?

Yes. And I just updated that download with the latest revision, so if you just downloaded it, you might want to redownload. I'm still working on it, though, and cleaning up the design of the space code is of high priority. For instance, removing duplicate code, and decomposing those 750+ lines functions into manageable chunks. So if you wait a few days, I'll rebundle it again with new changes.
       
Post is unread #53 Oct 22, 2009, 6:19 pm
Go to the top of the page
Go to the bottom of the page

dbna2
Sorcerer
GroupMembers
Posts600
JoinedDec 2, 2008

just post on here when you do so kay?
       
Post is unread #54 Oct 29, 2009, 1:28 pm
Go to the top of the page
Go to the bottom of the page

Darrik
Fledgling
GroupMembers
Posts20
JoinedJan 29, 2008

I'm going to come down on the side of arguing against this change... the way the space code displays your position is in x, y, z coordinates. Presumably, this is why the coders do the distance calculations this way: It's impossible for a regular player to calculate how far away they are from an object in a true vector, but it's easy for said player to calculate that they are 1000 away on the x-axis, 1000 away on the y-axis, and 1000 away from the z-axis.

I did change the distance calculations on my code, but that's only because I offer a second display format that uses spherical coordinates so that players know how far away they are from another object with the more accurate calculation. Base SWR does not provide such a display.

In summary, although the calculations are wrong, the way it's done provides ease of use for the player.

DV
       
Post is unread #55 Oct 29, 2009, 1:46 pm
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

How exactly do spherical coordinates simplify a player's mental calculation of distance? If anything, it seems like that would be far more difficult, as you have to reason about the angles in 3d space in addition to axis positions. It would be much easier if the spherical coordinates were centered around the ship itself, but at that point you might as well just use normal cartesian coordinates and display the distance.

Frankly, I think that they did distance calculation this way because they didn't know what they were doing, OR, they wanted to simplify the math in the name of efficiency and thought that the difference wouldn't matter.
After all, this incorrect distance calculation can lead to extremely unintuitive results, such as those I discussed in post #24.

I also disagree that it's so terribly hard to get an approximate idea of distance in your head. Certainly not "impossible". It's unlikely that people need distances accurate to the unit, and (most of the time) a more or less accurate distance would suffice. I think you underestimate the ability of people to develop a feel for distance after playing the game for a while.

Besides, if the only problem is displaying distance to players, just display a distance next to positions that they care about. Or add a MUD command that lets them type in two positions and returns the distance. This would accelerate the natural process of developing an intuition for what distances between positions are.
       
Post is unread #56 Oct 29, 2009, 5:20 pm   Last edited Oct 29, 2009, 5:20 pm by Caius
Go to the top of the page
Go to the bottom of the page

Caius
Magician
GroupMembers
Posts132
JoinedJan 29, 2006

Darrik said:

I'm going to come down on the side of arguing against this change... the way the space code displays your position is in x, y, z coordinates. Presumably, this is why the coders do the distance calculations this way: It's impossible for a regular player to calculate how far away they are from an object in a true vector, but it's easy for said player to calculate that they are 1000 away on the x-axis, 1000 away on the y-axis, and 1000 away from the z-axis.

I did change the distance calculations on my code, but that's only because I offer a second display format that uses spherical coordinates so that players know how far away they are from another object with the more accurate calculation. Base SWR does not provide such a display.

In summary, although the calculations are wrong, the way it's done provides ease of use for the player.

DV

Could just add it to the radar output:
ch_printf( ch, "%s %.0f %.0f %.0f (Distance: %.0f)\r\n", ship_name, x, y, z, dist );

Sometimes I feel that the SWR team jumped through hoops to make the space system difficult to use for the players. Having the distance in the radar output seems obvious to me. Similarly, a player shouldn't need to worry about trajectories, or even enter coordinates most of the time. Consider this:
course x y z

Why such a dirty solution? This is much friendlier:
course <planet/star/ship name>
       
Post is unread #57 Nov 1, 2009, 7:29 am
Go to the top of the page
Go to the bottom of the page

Quixadhal
Conjurer
GroupMembers
Posts398
JoinedMar 8, 2005

Darrik said:

I'm going to come down on the side of arguing against this change... the way the space code displays your position is in x, y, z coordinates.


Presentation layer should not determine how things work in the Application layer. You can easily choose to display the data in any format you want, but don't make the space-time continuum work like some kind of swiss-cheese simulation because you don't like the way the UI works.

The changes to the code don't change the way it's presented, they correct the math distance formulas, which are just flat-out wrong. If you don't like the floating point values, convert them to integers on display, and to floats on input.

This reminds me of the elaborate lengths that early astronomers went to, in order to describe the strange orbital behavior of Mars, because they were unwilling to accept that Earth wasn't the center of creation. Do you think the planet orbits us with weird loops like that? The scientific community did for hundreds of years, but that didn't make it right.

Having the distance formulas wrong puts the players in the same position as those early astronomers. They know it doesn't work quite right according to logic, but when they try to figure it out, they have to make up elaborate rules to make their observations fit.
       
Post is unread #58 Nov 1, 2009, 7:51 am
Go to the top of the page
Go to the bottom of the page

Kayle
Off the Edge of the Map
GroupAdministrators
Posts1,195
JoinedMar 21, 2006

But unless players read this thread, there's no way for them to know the underlying math is wrong.
       
Post is unread #59 Nov 1, 2009, 8:16 am
Go to the top of the page
Go to the bottom of the page

Kayle
Off the Edge of the Map
GroupAdministrators
Posts1,195
JoinedMar 21, 2006

Also, Any word on that updated SWR2.0 code you were working on Caius? I wanted to take a look at it, but I remember you saying you were gonna roll out another update so I was waiting till after that update to have a look.
       
Post is unread #60 Nov 1, 2009, 9:05 am
Go to the top of the page
Go to the bottom of the page

Quixadhal
Conjurer
GroupMembers
Posts398
JoinedMar 8, 2005

Kayle said:

But unless players read this thread, there's no way for them to know the underlying math is wrong.


I don't think that's quite right. They have no way of knowing HOW it's wrong. Others have noted that their players recognized that things didn't work quite right and have tried to adapt their playstyle to fit the incorrect physics model.

That's why I linked the Ptolemy orbital model. He developed a complicated model to account for his observations, because he couldn't believe the assumption of an Earth centric universe was wrong.

Now, if everyone is happy with things being broken, fine. I suppose all it means is that players who figure out the loopholes in the physics have an advantage over those who try to use real-world tactics.
       
Pages:<< prev 1, 2, 3, 4 next >>