eighthfleet-development Mailing List for Eighth Fleet

Status: Alpha

Brought to you by: nclow, tkhamilton

eighthfleet-development — Mailing list for discussion of the development of Eight Fleet

You can subscribe to this list here.

2006	_Jan	_Feb	_Mar	_Apr	_May	_Jun	_Jul	_Aug	_Sep	_Oct	_Nov (28)	_Dec (1)
2007	_Jan	_Feb	_Mar	_Apr	_May	_Jun	_Jul (11)	_Aug (1)	_Sep	_Oct	_Nov	_Dec

Flat | Threaded

1 2 > >> (Page 1 of 2)

[Eighthfleet-development] Updates and thoughts.

From: TIMOTHY K H. <tkh...@ve...> - 2007-08-06 02:34:13

Pushed another revision this evening, mostly minor stuff, including correct gravity calculations.

Now, before moving on to more game features there are unfortunately a number of additions to the core game code that have to be done first.  I've been putting these off because, frankly, they're going to be painful.

-Mouse selection is a big one.  My previous attempt at this caused the game to completely break, but it has to be done.  We can't go on using keys to cycle through targets forever.

-Navigation AI.  Again, painful, but it has to be done.  Ships must be able to go between point a and point b on their own without any manual steering.

-A ship builder.  Pretty obvious what this should be, maybe not so obvious how to go about it.  I'm pretty sure mouse-selection is going to need to be done first for this to not be a really tedious process.

Anyway, that's what's to be done next, I think.  After that, more can be done to make it start acting like a game.

-Tim

Re: [Eighthfleet-development] Updates on 7-28

From: Nathan C. <n_...@ho...> - 2007-07-31 22:30:34

G is the gravitational constant, one of those mysterious constants you =
find profuse in nature, like Pi.

G =3D 6.67 * 10^-11
Its base units are m^3 / kg * s^2, so you shouldn't have to do any =
conversion if you plug in basic SI units.

Solving gravity on all objects for a system of N objects is (N-1)! time =
if you apply symmetry. It can get expensive very quickly. I think a good =
simplification for real simulators is to treat collections of objects at =
a distance as having just 1 center of mass. So if an asteroid field is =
very far away, you don't need to calculate the effect of all their =
individual gravitation on the ship, only a single gravitation with a =
single value from the asteroid field's center of mass. This lends itself =
rather nicely to treating discrete systems like an asteroid field, solar =
system, etc as logical objects for the purposes of gravitation. You =
could opt to only do extensive gravitational calculations on one of =
these objects only if their center was close enough to the ship to be of =
interest.
  ----- Original Message -----=20
  From: TIMOTHY K HAMILTON=20
  To: Nathan Clow ; eighthfleet-development=20
  Sent: Tuesday, July 31, 2007 6:18 PM
  Subject: Re: [Eighthfleet-development] Updates on 7-28


  That would be it, except... what is G, exactly?

  I'm curious what would happen if I stuck this in the asteroid field =
scenario.

  -Tim

  Nathan Clow <n_...@ho...> wrote:
    F =3D G (m1) (m2) / r^2

Re: [Eighthfleet-development] Updates on 7-28

From: TIMOTHY K H. <tkh...@ve...> - 2007-07-31 22:18:41

That would be it, except... what is G, exactly?
   
  I'm curious what would happen if I stuck this in the asteroid field scenario.
   
  -Tim

Nathan Clow <n_...@ho...> wrote:
            

  F = G (m1) (m2) / r^2

Re: [Eighthfleet-development] Updates on 7-28

From: Nathan C. <n_...@ho...> - 2007-07-31 22:15:32

    Note: look for the section labeled ***HACK***.   This is where I =
simply slapped a number into the code in order to see if it was working =
correctly.  Instead of this really bogus number, it needs to be the =
correct amount of force that would be applied by gravity.  Someone with =
some knowledge of physics please figure out what this would be?  =
Currently, the only data for the gravity well is mass(in kilograms), and =
position.

The force due to gravity is a function of the masses of both attractors, =
and the distance between them.

F =3D G (m1) (m2) / r^2

where F is the force due to gravity, G is the gravitational constant, m1 =
is one body's mass, m2 is the other body's, and r is the distance =
between the bodies. F is exterted on each body in a direction straight =
towards the other body. =20

Was this what you were looking for?


-------------------------------------------------------------------------=
-----


  =
-------------------------------------------------------------------------=

  This SF.net email is sponsored by: Splunk Inc.
  Still grepping through log files to find problems?  Stop.
  Now Search log events and configuration files using AJAX and a =
browser.
  Download your FREE copy of Splunk now >>  http://get.splunk.com/


-------------------------------------------------------------------------=
-----


  _______________________________________________
  Eighthfleet-development mailing list
  Eig...@li...
  https://lists.sourceforge.net/lists/listinfo/eighthfleet-development

[Eighthfleet-development] Updates on 7-28

From: TIMOTHY K H. <tkh...@ve...> - 2007-07-29 00:12:00

I've made a number of small fixes and additions today, here's a summary:

-Missiles are fixed.  They are now correctly oriented upon creation no matter what facing they were fired from.  I had to dig into the ODE documentation and really figure out what crazy matrix functions to play with.  See launcher.cpp for the changes to fireMissile()

-Missile have a shockwave effect in addition to an explosion.  It is currently a graphical effect only, and has no affect on entities within the game, but I hope to extend this soon.

-Added gravity wells, sortof... There is now a second scenario file (scenario2) which is of the "near-orbit" type.  Data has been entered for a planetary body roughly equivalent to our moon.  In the tick() function of game.cpp there is a now a small loop that applies a force to all entities in the direction of a gravity well. 
    Note: look for the section labeled ***HACK***.   This is where I simply slapped a number into the code in order to see if it was working correctly.  Instead of this really bogus number, it needs to be the correct amount of force that would be applied by gravity.  Someone with some knowledge of physics please figure out what this would be?  Currently, the only data for the gravity well is mass(in kilograms), and position.

-Added some extra functions to util and entity to make things easier in the future.

Note on units: ODE uses the SE units of meter/kilogram/second.  Currently, distances in all the code is treated as kilometers, not meters, so there is technically some heavy fudging going on.  I'm not sure that I care yet, but there it is.

I am now going to start updating the guidance code in ship.cpp, making it match all of the new functions.  Who knows if it will really work at this point, because we have moved from variable to static time steps, but it will be interesting to see what happens.

-Tim

Re: [Eighthfleet-development] wohoo! it builds and runs now *g*

From: Nathan C. <n_...@ho...> - 2007-07-27 23:52:05

I think the nice thing about 8th fleet right now, from a development 
standpoint, is that the basic framework is in place (sans networking), so 
anyone can dive right into the fun stuff of planning out actual game 
mechanics: weapons, combat, objectives, a HUD, etc. The design is not 
perfect, but hopefully it will show some promise of the extensibility we 
tried to build into it.

The existing AI bits will probably have to be rebuilt. When I left those 
they were only half done. The basic kinematics will probably still be 
functional with some minor tweaks but their application in the algorithm 
needs to be rethought. I think there are some old emails archived that 
explain some of the difficulties with the approach I used, and I think I 
remember enough that I should be able to answer any questions cogently.

By the way, I see you're a PSU tutor. Is your involvement with 8f an 
academic project?



----- Original Message ----- 
From: "Larry Leach" <le...@gm...>
To: "eighthfleet-development" 
<eig...@li...>
Sent: Friday, July 27, 2007 2:49 PM
Subject: [Eighthfleet-development] wohoo! it builds and runs now *g*


> So, wednesday night I was up off and on most of the night poking at the
> game.  (if I'd read my e-mail i would have seen your
> list-o-dependencies).  I was able to get the libs installed, but had a
> problem because of my distro.
>
> Ubuntu is tracking a version of ODE that is one version too old to use
> with eightfleet.  I ended up removing that package and installing the
> latest ODE bits manually.  There was a final problem.  The ODE .so file
> was in the wrong place for the program to use.  Copying it into the
> right place worked.  Yesterday at OSCON Tim and I were poking and
> managed to get it to work!
>
> The big news is that you now have users *vbg*
>
> I've shown the game to a friend of mine, and we'll be wanting to play
> around with it.  Brace for the onslaught of change and feature requests
> from us!
>
> Also, I'm willing to hack at code, so let me know where hands are needed
> most.  I'm wanting network play (PvP or players vs AI), I see the ship
> and scenario editors need to be done, and there are some problems with
> AI and missile guidance.  Let me know the most productive place to work
> on eighthfleet!
>
> Larry Leach
> PSU CS tutor
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> Eighthfleet-development mailing list
> Eig...@li...
> https://lists.sourceforge.net/lists/listinfo/eighthfleet-development
>

Re: [Eighthfleet-development] wohoo! it builds and runs now *g*

From: TIMOTHY K H. <tkh...@ve...> - 2007-07-27 21:55:07

My thoughts on most useful work right now:
   
  Since adding network support is going to require that certain things be set in stone (so that any communication routines don't get borken when we change some detail of a ship), I'd like to put that off just a little longer.
   
  In order of importance right now, I'd say: 
   
  1. Ship guidance, which, by extension means missile guidance as well.
  2. Ship editor
  3. Scenario editor
   
  I'm working on missiles right now, trying to solve the facing bug, after which I'll go back to the old guidance code and clean that up.  The latter half of the ship file that has our old (and really broken) AI code has not been updated to match the current function names.  Once that is done, I'll start actually fixing it, hopefully.
   
  So, new pokings should probably start with the ship editor, since I haven't actually written any defenitions for other scenarios yet.  Just mail the list as things come up, and I'll do my best to explain them, and add it to the documentation I'm working on.  If you're really lucky, I might even finish the documentation before you ask a question.
   
  -Tim

[Eighthfleet-development] wohoo! it builds and runs now *g*

From: Larry L. <le...@gm...> - 2007-07-27 18:50:01

So, wednesday night I was up off and on most of the night poking at the
game.  (if I'd read my e-mail i would have seen your
list-o-dependencies).  I was able to get the libs installed, but had a
problem because of my distro.

Ubuntu is tracking a version of ODE that is one version too old to use
with eightfleet.  I ended up removing that package and installing the
latest ODE bits manually.  There was a final problem.  The ODE .so file
was in the wrong place for the program to use.  Copying it into the
right place worked.  Yesterday at OSCON Tim and I were poking and
managed to get it to work!

The big news is that you now have users *vbg*

I've shown the game to a friend of mine, and we'll be wanting to play
around with it.  Brace for the onslaught of change and feature requests
from us!

Also, I'm willing to hack at code, so let me know where hands are needed
most.  I'm wanting network play (PvP or players vs AI), I see the ship
and scenario editors need to be done, and there are some problems with
AI and missile guidance.  Let me know the most productive place to work
on eighthfleet!

Larry Leach
PSU CS tutor

Re: [Eighthfleet-development] Installation instructions?

From: TIMOTHY K H. <tkh...@ve...> - 2007-07-27 02:30:03

Fortunately, I'm starting to play with it again, so it looks like there will be more activity. I'm trying to actually put together some code documentation, but that takes so much more work than actually writing code. Maybe it will get done, maybe it wont. As it is, I'm just trying to comment more.

-Tim

Nathan Clow <n_...@ho...> wrote: Ah, nice to see this list is still active.

As Tim mentioned, the 3 required libs are:

ODE (www.ode.org)
SDL (libsdl.org)
OpenGL

For openGL I'm pretty sure you'll need a version of the lib with the development headers, so you can compile with it. I think we used mesa-dev for our implementation. Any linux package manager should be able to install this for you. I regret that there's no documentation for the expected build structure; you'll probably just have to look at the makefile and see what it expects.

Full support will probably not happen unless Tim or I decide to start maintaining the project again, or the project gets some new developers.
----- Original Message -----
From: TIMOTHY K HAMILTON
To: eig...@li...
Sent: Thursday, July 26, 2007 3:01 AM
Subject: Re: [Eighthfleet-development] Installation instructions?

Sorry about that,

SDL should be a standard package you can get for most distros automatically. I'm running Ubuntu and it was easy enough to grab. ODE I remember having to install manually, but it wasn't too much of a pain.
The openGL libraries were another one of those standard things, it should be included with one dev package or another, I'm going to have to look that one up and get back to you.

Also, Just pushed a new revision at ~10pm tonight, that fixed some minor bugs and makes it all run again.

-Tim

Larry Leach <le...@gm...> wrote:
Heyo!

I'm trying to get eighthfleet running on my system, but make fails and
whines about missing stuff i *think* might be libraries I don't have.

thing 1 : Is there a list of required libs somewhere that I can't find?

Thing 2 : I'll be writing this up, and submitting the instructions back
to the dev team. It will be necessary for us new users/contributors to
be able to make & install the program :)

here's the top of the list of errors from make...

leachl@Vanguard:~/src/eighthfleet$ make
g++ -g -Wall -c main.cpp
In file included from main.cpp:15:
main.h:21:19: error: GL/gl.h: No such file or directory
main.h:22:20: error: GL/glu.h: No such file or directory
main.h:23:20: error: GL/glx.h: No such file or directory
main.h:25:21: error: SDL/SDL.h: No such file or directory
main.h:26:21: error: ode/ode.h: No such file or directory

Thanks!

Larry

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Eighthfleet-development mailing list
Eig...@li...
https://lists.sourceforge.net/lists/listinfo/eighthfleet-development

---------------------------------

_______________________________________________
Eighthfleet-development mailing list
Eig...@li...
https://lists.sourceforge.net/lists/listinfo/eighthfleet-development
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/_______________________________________________
Eighthfleet-development mailing list
Eig...@li...
https://lists.sourceforge.net/lists/listinfo/eighthfleet-development

Re: [Eighthfleet-development] Installation instructions?

From: Nathan C. <n_...@ho...> - 2007-07-26 21:40:31

Ah, nice to see this list is still active.

As Tim mentioned, the 3 required libs are:

ODE (www.ode.org)
SDL (libsdl.org)
OpenGL

For openGL I'm pretty sure you'll need a version of the lib with the =
development headers, so you can compile with it. I think we used =
mesa-dev for our implementation. Any linux package manager should be =
able to install this for you. I regret that there's no documentation for =
the expected build structure; you'll probably just have to look at the =
makefile and see what it expects.

Full support will probably not happen unless Tim or I decide to start =
maintaining the project again, or the project gets some new developers.
  ----- Original Message -----=20
  From: TIMOTHY K HAMILTON=20
  To: eig...@li...=20
  Sent: Thursday, July 26, 2007 3:01 AM
  Subject: Re: [Eighthfleet-development] Installation instructions?


  Sorry about that,

      SDL should be a standard package you can get for most distros =
automatically.  I'm running Ubuntu and it was easy enough to grab.   ODE =
I remember having to install manually, but it wasn't too much of a pain. =
=20
      The openGL libraries were another one of those standard things, it =
should be included with one dev package or another, I'm going to have to =
look that one up and get back to you.

      Also, Just pushed a new revision at ~10pm tonight, that fixed some =
minor bugs and makes it all run again.

  -Tim

  Larry Leach <le...@gm...> wrote:
    Heyo!

    I'm trying to get eighthfleet running on my system, but make fails =
and
    whines about missing stuff i *think* might be libraries I don't =
have.

    thing 1 : Is there a list of required libs somewhere that I can't =
find?

    Thing 2 : I'll be writing this up, and submitting the instructions =
back
    to the dev team. It will be necessary for us new users/contributors =
to
    be able to make & install the program :)


    here's the top of the list of errors from make...

    leachl@Vanguard:~/src/eighthfleet$ make
    g++ -g -Wall -c main.cpp
    In file included from main.cpp:15:
    main.h:21:19: error: GL/gl.h: No such file or directory
    main.h:22:20: error: GL/glu.h: No such file or directory
    main.h:23:20: error: GL/glx.h: No such file or directory
    main.h:25:21: error: SDL/SDL.h: No such file or directory
    main.h:26:21: error: ode/ode.h: No such file or directory


    Thanks!

    Larry


    =
-------------------------------------------------------------------------=

    This SF.net email is sponsored by: Splunk Inc.
    Still grepping through log files to find problems? Stop.
    Now Search log events and configuration files using AJAX and a =
browser.
    Download your FREE copy of Splunk now >> http://get.splunk.com/
    _______________________________________________
    Eighthfleet-development mailing list
    Eig...@li...
    https://lists.sourceforge.net/lists/listinfo/eighthfleet-development





-------------------------------------------------------------------------=
-----


  =
-------------------------------------------------------------------------=

  This SF.net email is sponsored by: Splunk Inc.
  Still grepping through log files to find problems?  Stop.
  Now Search log events and configuration files using AJAX and a =
browser.
  Download your FREE copy of Splunk now >>  http://get.splunk.com/


-------------------------------------------------------------------------=
-----


  _______________________________________________
  Eighthfleet-development mailing list
  Eig...@li...
  https://lists.sourceforge.net/lists/listinfo/eighthfleet-development

Re: [Eighthfleet-development] Installation instructions?

From: TIMOTHY K H. <tkh...@ve...> - 2007-07-26 07:01:58

Sorry about that,
   
      SDL should be a standard package you can get for most distros automatically.  I'm running Ubuntu and it was easy enough to grab.   ODE I remember having to install manually, but it wasn't too much of a pain.  
      The openGL libraries were another one of those standard things, it should be included with one dev package or another, I'm going to have to look that one up and get back to you.
   
      Also, Just pushed a new revision at ~10pm tonight, that fixed some minor bugs and makes it all run again.
   
  -Tim

Larry Leach <le...@gm...> wrote:
  Heyo!

I'm trying to get eighthfleet running on my system, but make fails and
whines about missing stuff i *think* might be libraries I don't have.

thing 1 : Is there a list of required libs somewhere that I can't find?

Thing 2 : I'll be writing this up, and submitting the instructions back
to the dev team. It will be necessary for us new users/contributors to
be able to make & install the program :)


here's the top of the list of errors from make...

leachl@Vanguard:~/src/eighthfleet$ make
g++ -g -Wall -c main.cpp
In file included from main.cpp:15:
main.h:21:19: error: GL/gl.h: No such file or directory
main.h:22:20: error: GL/glu.h: No such file or directory
main.h:23:20: error: GL/glx.h: No such file or directory
main.h:25:21: error: SDL/SDL.h: No such file or directory
main.h:26:21: error: ode/ode.h: No such file or directory


Thanks!

Larry


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Eighthfleet-development mailing list
Eig...@li...
https://lists.sourceforge.net/lists/listinfo/eighthfleet-development

[Eighthfleet-development] Installation instructions?

From: Larry L. <le...@gm...> - 2007-07-26 04:15:53

Heyo!

I'm trying to get eighthfleet running on my system, but make fails and
whines about missing stuff i *think* might be libraries I don't have.

thing 1 : Is there a list of required libs somewhere that I can't find?

Thing 2 : I'll be writing this up, and submitting the instructions back
to the dev team.  It will be necessary for us new users/contributors to
be able to make & install the program :)


here's the top of the list of errors from make...

leachl@Vanguard:~/src/eighthfleet$ make
g++ -g -Wall -c main.cpp
In file included from main.cpp:15:
main.h:21:19: error: GL/gl.h: No such file or directory
main.h:22:20: error: GL/glu.h: No such file or directory
main.h:23:20: error: GL/glx.h: No such file or directory
main.h:25:21: error: SDL/SDL.h: No such file or directory
main.h:26:21: error: ode/ode.h: No such file or directory


Thanks!

Larry

[Eighthfleet-development] Big changes with revision 36

From: TIMOTHY K H. <tkh...@ve...> - 2006-12-04 01:30:35

I just pushed revision 36 tonight.  The big change in this one is a purging of nearly all ODE data types from the framework code, replaced with our own data types of point or vect.  Any places where manipulation of ode types is needed has been moved to the util functions.

In several classes, 3 related variables have been condensed into a single point variable.  Functions have had there parameters changed accordingly.  Be sure to double check the function name and/or parameters before you call it, as it is probably a little different now.

I think I've found 99% of all the directly ODE-related data types in the code and removed them, though I'm sure I'll find a few that escaped as time goes on.  For now, it already feels easier to read.

-Tim

Re: [Eighthfleet-development] Succesful Windows Port

From: Nathan C. <n_...@ho...> - 2006-11-29 08:38:27

Ok, well I committed r35 which has a few small bug fixes. I'm not even 
entirely sure where I want to go from here with the nav code. What I have so 
far is kind of frustrating me due to its bugginess and shortcomings and 
difficutly of bug hunting. The code's a mess, but that could always be 
cleaned up. What I really want to do is rip out almost the entire thing and 
rewrite it, using the valuables lessons I gleaned from trying to do it the 
first time. I have several ideas for vastly increasing efficiency with a 
cleaner, better design and getting rid of algorithmic shortcomings  that 
have shown themself thus far.

Oh and if you get some development time tomorrow, check the notes and see if 
you can find that bug I mention so we can use ship2. I'll be working on 
slides tomorrow too. Do you want to create any of the slides?


>From: TIMOTHY K HAMILTON <tkh...@ve...>
>To: eig...@li...
>Subject: Re: [Eighthfleet-development] Succesful Windows Port
>Date: Tue, 28 Nov 2006 21:58:48 -0800 (PST)
>
>I tried math.h and it still couldn't find a defenition.  Didn't think of 
>limits.h, though.  I'll give that a try tomorrow when I work on the 
>presentation.
>
>Right now, as of ~10pm I'm happy with the game code (finally, there were 
>some pretty heinous bugs still lurking in what I thought was good stable 
>framework code), and I'm really going to try to write a primitive GA for 
>finding an optimal position to be at to destroy an enemy ship.
>
>-Tim
>
>Nathan Clow <n_...@ho...> wrote: NAN has all kinds of 
>standardization rules, and sometimes has
>implementation-dependent details. It should be in math.h or limits.h even
>under windows. The value has to exist because it's a real state of the FPU
>processor that needs to be referenced and defined. You can't have a 
>complete
>FPU instruction set without it.
>
>
> >From: TIMOTHY K HAMILTON
> >To: eig...@li...
> >Subject: [Eighthfleet-development] Succesful Windows Port
> >Date: Tue, 28 Nov 2006 15:42:16 -0800 (PST)
> >
> >I've gotten 8th Fleet to run in Windows using Cygwin, so we will in fact 
>be
> >able to have a presentation demo on the big screen on Thursday.
> >
> >A couple of issues:
> >
> >NAN does not seem to be defined under windows.  We're going to need some
> >sort of replacement for this value, currently, I've substituted -999, as
> >it's a value that should hopefully never come up in the current 
>situations.
> >  However, it's is at best a temporary hack, and needs to be addressed.
> >
> >Asteroids do not render properly.  There seems to be some sort of glitch 
>in
> >rendering the surfaces, so that some of them are occasionally 
>"backwards",
> >and you can see right through them.  It's wierd, I'm not sure how to fix
> >it, as it's a standard GLU library call.  It's really not important,
> >though.
> >
> >Point is:  WINDOWS !
> >
> >-Tim
>
>
> >-------------------------------------------------------------------------
> >Take Surveys. Earn Cash. Influence the Future of IT
> >Join SourceForge.net's Techsay panel and you'll get the chance to share
> >your
> >opinions on IT & business topics through brief surveys - and earn cash
> >http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>
>
> >_______________________________________________
> >Eighthfleet-development mailing list
> >Eig...@li...
> >https://lists.sourceforge.net/lists/listinfo/eighthfleet-development
>
>_________________________________________________________________
>Stay up-to-date with your friends through the Windows Live Spaces friends
>list.
>http://clk.atdmt.com/MSN/go/msnnkwsp0070000001msn/direct/01/?href=http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mk
>
>


>-------------------------------------------------------------------------
>Take Surveys. Earn Cash. Influence the Future of IT
>Join SourceForge.net's Techsay panel and you'll get the chance to share 
>your
>opinions on IT & business topics through brief surveys - and earn cash
>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV


>_______________________________________________
>Eighthfleet-development mailing list
>Eig...@li...
>https://lists.sourceforge.net/lists/listinfo/eighthfleet-development

_________________________________________________________________
Stay up-to-date with your friends through the Windows Live Spaces friends 
list. 
http://clk.atdmt.com/MSN/go/msnnkwsp0070000001msn/direct/01/?href=http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mk

Re: [Eighthfleet-development] Succesful Windows Port

From: TIMOTHY K H. <tkh...@ve...> - 2006-11-29 05:58:56

I tried math.h and it still couldn't find a defenition.  Didn't think of limits.h, though.  I'll give that a try tomorrow when I work on the presentation.

Right now, as of ~10pm I'm happy with the game code (finally, there were some pretty heinous bugs still lurking in what I thought was good stable framework code), and I'm really going to try to write a primitive GA for finding an optimal position to be at to destroy an enemy ship.

-Tim

Nathan Clow <n_...@ho...> wrote: NAN has all kinds of standardization rules, and sometimes has 
implementation-dependent details. It should be in math.h or limits.h even 
under windows. The value has to exist because it's a real state of the FPU 
processor that needs to be referenced and defined. You can't have a complete 
FPU instruction set without it.

>From: TIMOTHY K HAMILTON 
>To: eig...@li...
>Subject: [Eighthfleet-development] Succesful Windows Port
>Date: Tue, 28 Nov 2006 15:42:16 -0800 (PST)
>
>I've gotten 8th Fleet to run in Windows using Cygwin, so we will in fact be 
>able to have a presentation demo on the big screen on Thursday.
>
>A couple of issues:
>
>NAN does not seem to be defined under windows.  We're going to need some 
>sort of replacement for this value, currently, I've substituted -999, as 
>it's a value that should hopefully never come up in the current situations. 
>  However, it's is at best a temporary hack, and needs to be addressed.
>
>Asteroids do not render properly.  There seems to be some sort of glitch in 
>rendering the surfaces, so that some of them are occasionally "backwards", 
>and you can see right through them.  It's wierd, I'm not sure how to fix 
>it, as it's a standard GLU library call.  It's really not important, 
>though.
>
>Point is:  WINDOWS !
>
>-Tim

>-------------------------------------------------------------------------
>Take Surveys. Earn Cash. Influence the Future of IT
>Join SourceForge.net's Techsay panel and you'll get the chance to share 
>your
>opinions on IT & business topics through brief surveys - and earn cash
>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

>_______________________________________________
>Eighthfleet-development mailing list
>Eig...@li...
>https://lists.sourceforge.net/lists/listinfo/eighthfleet-development

_________________________________________________________________
Stay up-to-date with your friends through the Windows Live Spaces friends 
list. 
http://clk.atdmt.com/MSN/go/msnnkwsp0070000001msn/direct/01/?href=http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mk

[Eighthfleet-development] Succesful Windows Port

From: TIMOTHY K H. <tkh...@ve...> - 2006-11-28 23:42:24

I've gotten 8th Fleet to run in Windows using Cygwin, so we will in fact be able to have a presentation demo on the big screen on Thursday.

A couple of issues:

NAN does not seem to be defined under windows.  We're going to need some sort of replacement for this value, currently, I've substituted -999, as it's a value that should hopefully never come up in the current situations.  However, it's is at best a temporary hack, and needs to be addressed.

Asteroids do not render properly.  There seems to be some sort of glitch in rendering the surfaces, so that some of them are occasionally "backwards", and you can see right through them.  It's wierd, I'm not sure how to fix it, as it's a standard GLU library call.  It's really not important, though.

Point is:  WINDOWS !

-Tim

Re: [Eighthfleet-development] ODE problems

From: TIMOTHY K H. <tkh...@ve...> - 2006-11-28 04:06:33

I mean that -z is always forwards in every context., +z is backwards. I'm looking at the vectors being translated back and forth from body to world to back now, and all the signs are matching up.

Maybe it's only with the latest commits I've made. Let me know if you're looking at something different, it is quite possibly right in front of my eyes and I'm missing it.

Nathan Clow <n_...@ho...> wrote: You mean -z is backwards from a body-relative standpoint? This really only makes some sense to me if there's actually a bug in the drawing code.

I can use a linear thrust to REVERSE and watch the global Z pos decrement, as well as watch the ship seem to go backward. The coordinates are pulled straight from ODE, so it LOOKS right. Is there some bug with engine placement or thrusting as well? Also, why does a [0,0,100] world vector translate to the body as a [0,0,100] relative vector? This tells me at least that the ode global coordinate and body-relative coordinate systems start aligned. If they are aligned, then the given rotation should produce what I expect, not what ODE is giving me. I tried to draw all my conclusions just from evidence culled from ODE, but can't really draw complete conclusions without understanding the values in the rotation matrix.

There are other scenarios too. For instance, from a 0,0,0 starting point, a PITCHUP to relative 0,100,0 scales the vectors exactly as I expect, and this does involve z.

I don't think I get it. I'll try to build an ODE testbed to test my understanding in isolation from all our game code but our deadline looms close.
----- Original Message -----
From: TIMOTHY K HAMILTON
To: eig...@li...
Sent: Monday, November 27, 2006 1:21 PM
Subject: Re: [Eighthfleet-development] ODE problems

So... ready for the next revelation in the "Tim is stupid" saga?

The z-coordinates are reversed.

-z is forward, +z is backwards

Yeah, it's really counter-intuitive, but it's the way things work for whatever strange reason the original minds came up with. I know I've come across this before when working with openGL, but I'd managed to forget as I was getting into the project.

>From the sound of things so far, this may just solve the problem you've been having with ODE rotation, as well. If both systems use the convention of -z as forward, with all the other coordinate systems following the usual intuition, then things seems to make more sense.

Let me know if I need to do some more digging.

I'm going to keep working on the high-level nav AI for the rest of the day.

-Tim

TIMOTHY K HAMILTON <tkh...@ve...> wrote: Wow, that's... bad. Really bad.

I had been suspecting that I might have been mis-translating ccordinates between ODE and openGL, but what you're describing looks like a problem completely internal to ODE itself.

I'll see what I can do with it today, and get you some feedback by this afternoon.

-Tim

Nathan Clow <n_...@ho...> wrote:
Some bad news:

There appears to be a bug in ODE with dBodyVectorFromWorld. I think the
function is bugged and returns sign errors on its values.

Here's my logic:
The body starts at position 0,0,0 with normal (unrotated) rotation values.
The axes of the body are initially aligned with those of the world.

Here are sample dBodyVectorFromWorld translations while the body is
unrotated, with the world vector on the left and the relative vector on the
right.
[100,0,0] -> [100,0,0]
[0,100,0] -> [0,100,0]
[0,0,100] -> [0,0,100]

So, based on this, I created the notion that for relative vectors, +x is to
the right, +y is upwards, and +z is in front. Both the global and relative
coordinate systems seem to be aligned at the start while not rotated.

So, one would expect that, if given a point 100 units to the right, a simple
YAWCW would rotate you 90 degrees to the right until you're facing it. You'd
expect your relative vectors during this time to start with [100,0,0], to
range intermediately between [n, 0, m] with n and m from 0 to 100, and to
end at [0,0,100].

That's not what happens. Here's some sample output from the situation
described above.

Pos: [0.000000 0.000000 0.000000] DestPos: [100.000000 0.000000 0.000000]
Derived world vector [100.000000,0.000000,0.000000] from navQueue
Derived relative vector [98.828865,0.000000,-15.259607] from navQueue
Translated back to world vector [100.000000,0.000000,-0.000000]

See how z is negative? I don't know how this can be. The point is
approaching the "front" of the ship as it rotates. Z should range up to 100,
not down to -100.

This is just an example. The long and short of it is that 0 to 3 of the
values may have the wrong sign depending on the situation, and that I have
no way to tell when this will happen and thus correct the sign errors. I
think the bug occurs because of the way the rotation matrix works in ODE,
but I don't really understand what the values in that matrix are supposed to
be (despite spending a lot of time looking at it).

I've been over this and over this and can't find any error in my
understanding of what is supposed to be happening. I suppose there could be
a problem in the engine code or the graphics code or something else, causing
what we see to be different than what ODE knows, but I think that's pretty
unlikely.

So this was like hitting a brick wall. I have no idea if I could write a
working vector translation function before Thursday. Give me your feedback
if you have any. I'll approach the problem again tomorrow with a fresh mind.

_________________________________________________________________
Get free, personalized commercial-free online radio with MSN Radio powered
by Pandora http://radio.msn.com/?icid=T002MSN03A07001

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Eighthfleet-development mailing list
Eig...@li...
https://lists.sourceforge.net/lists/listinfo/eighthfleet-development

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV_______________________________________________
Eighthfleet-development mailing list
Eig...@li...
https://lists.sourceforge.net/lists/listinfo/eighthfleet-development

---------------------------------

_______________________________________________
Eighthfleet-development mailing list
Eig...@li...
https://lists.sourceforge.net/lists/listinfo/eighthfleet-development
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV_______________________________________________
Eighthfleet-development mailing list
Eig...@li...
https://lists.sourceforge.net/lists/listinfo/eighthfleet-development

Re: [Eighthfleet-development] ODE problems

From: Nathan C. <n_...@ho...> - 2006-11-27 23:21:43

You mean -z is backwards from a body-relative standpoint? This really =
only makes some sense to me if there's actually a bug in the drawing =
code.

I can use a linear thrust to REVERSE and watch the global Z pos =
decrement, as well as watch the ship seem to go backward. The =
coordinates are pulled straight from ODE, so it LOOKS right. Is there =
some bug with engine placement or thrusting as well? Also, why does a =
[0,0,100] world vector translate to the body as a [0,0,100] relative =
vector? This tells me at least that the ode global coordinate and =
body-relative coordinate systems start aligned. If they are aligned, =
then the given rotation should produce what I expect, not what ODE is =
giving me. I tried to draw all my conclusions just from evidence culled =
from ODE, but can't really draw complete conclusions without =
understanding the values in the rotation matrix.

There are other scenarios too. For instance, from a 0,0,0 starting =
point, a PITCHUP to relative 0,100,0 scales the vectors exactly as I =
expect, and this does involve z.=20

I don't think I get it. I'll try to build an ODE testbed to test my =
understanding in isolation from all our game code but our deadline looms =
close.
  ----- Original Message -----=20
  From: TIMOTHY K HAMILTON=20
  To: eig...@li...=20
  Sent: Monday, November 27, 2006 1:21 PM
  Subject: Re: [Eighthfleet-development] ODE problems


  So... ready for the next revelation in the "Tim is stupid" saga?

  The z-coordinates are reversed.

  -z is forward, +z is backwards

  Yeah, it's really counter-intuitive, but it's the way things work for =
whatever strange reason the original minds came up with.  I know I've =
come across this before when working with openGL, but I'd managed to =
forget as I was getting into the project.

  From the sound of things so far, this may just solve the problem =
you've been having with ODE rotation, as well.  If both systems use the =
convention of -z as forward, with all the other coordinate systems =
following the usual intuition, then things seems to make more sense.

  Let me know if I need to do some more digging.

  I'm going to keep working on the high-level nav AI for the rest of the =
day.

  -Tim



  TIMOTHY K HAMILTON <tkh...@ve...> wrote:
    Wow, that's... bad.  Really bad.

    I had been suspecting that I might have been mis-translating =
ccordinates between ODE and openGL, but what you're describing looks =
like a problem completely internal to ODE itself.

    I'll see what I can do with it today, and get you some feedback by =
this afternoon.

    -Tim

    Nathan Clow <n_...@ho...> wrote:
      Some bad news:

      There appears to be a bug in ODE with dBodyVectorFromWorld. I =
think the=20
      function is bugged and returns sign errors on its values.

      Here's my logic:
      The body starts at position 0,0,0 with normal (unrotated) rotation =
values.
      The axes of the body are initially aligned with those of the =
world.

      Here are sample dBodyVectorFromWorld translations while the body =
is=20
      unrotated, with the world vector on the left and the relative =
vector on the=20
      right.
      [100,0,0] -> [100,0,0]
      [0,100,0] -> [0,100,0]
      [0,0,100] -> [0,0,100]

      So, based on this, I created the notion that for relative vectors, =
+x is to=20
      the right, +y is upwards, and +z is in front. Both the global and =
relative=20
      coordinate systems seem to be aligned at the start while not =
rotated.

      So, one would expect that, if given a point 100 units to the =
right, a simple=20
      YAWCW would rotate you 90 degrees to the right until you're facing =
it. You'd=20
      expect your relative vectors during this time to start with =
[100,0,0], to=20
      range intermediately between [n, 0, m] with n and m from 0 to 100, =
and to=20
      end at [0,0,100].

      That's not what happens. Here's some sample output from the =
situation=20
      described above.

      Pos: [0.000000 0.000000 0.000000] DestPos: [100.000000 0.000000 =
0.000000]
      Derived world vector [100.000000,0.000000,0.000000] from navQueue
      Derived relative vector [98.828865,0.000000,-15.259607] from =
navQueue
      Translated back to world vector [100.000000,0.000000,-0.000000]

      See how z is negative? I don't know how this can be. The point is=20
      approaching the "front" of the ship as it rotates. Z should range =
up to 100,=20
      not down to -100.

      This is just an example. The long and short of it is that 0 to 3 =
of the=20
      values may have the wrong sign depending on the situation, and =
that I have=20
      no way to tell when this will happen and thus correct the sign =
errors. I=20
      think the bug occurs because of the way the rotation matrix works =
in ODE,=20
      but I don't really understand what the values in that matrix are =
supposed to=20
      be (despite spending a lot of time looking at it).

      I've been over this and over this and can't find any error in my=20
      understanding of what is supposed to be happening. I suppose there =
could be=20
      a problem in the engine code or the graphics code or something =
else, causing=20
      what we see to be different than what ODE knows, but I think =
that's pretty=20
      unlikely.

      So this was like hitting a brick wall. I have no idea if I could =
write a=20
      working vector translation function before Thursday. Give me your =
feedback=20
      if you have any. I'll approach the problem again tomorrow with a =
fresh mind.

      _________________________________________________________________
      Get free, personalized commercial-free online radio with MSN Radio =
powered=20
      by Pandora http://radio.msn.com/?icid=3DT002MSN03A07001


      =
-------------------------------------------------------------------------=

      Take Surveys. Earn Cash. Influence the Future of IT
      Join SourceForge.net's Techsay panel and you'll get the chance to =
share your
      opinions on IT & business topics through brief surveys - and earn =
cash
      =
http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV
      _______________________________________________
      Eighthfleet-development mailing list
      Eig...@li...
      =
https://lists.sourceforge.net/lists/listinfo/eighthfleet-development


    =
-------------------------------------------------------------------------=

    Take Surveys. Earn Cash. Influence the Future of IT
    Join SourceForge.net's Techsay panel and you'll get the chance to =
share your
    opinions on IT & business topics through brief surveys - and earn =
cash
    =
http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV_______________________________________________
    Eighthfleet-development mailing list
    Eig...@li...
    https://lists.sourceforge.net/lists/listinfo/eighthfleet-development





-------------------------------------------------------------------------=
-----


  =
-------------------------------------------------------------------------=

  Take Surveys. Earn Cash. Influence the Future of IT
  Join SourceForge.net's Techsay panel and you'll get the chance to =
share your
  opinions on IT & business topics through brief surveys - and earn cash
  =
http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV


-------------------------------------------------------------------------=
-----


  _______________________________________________
  Eighthfleet-development mailing list
  Eig...@li...
  https://lists.sourceforge.net/lists/listinfo/eighthfleet-development

Re: [Eighthfleet-development] ODE problems

From: TIMOTHY K H. <tkh...@ve...> - 2006-11-27 21:21:54

So... ready for the next revelation in the "Tim is stupid" saga?

The z-coordinates are reversed.

-z is forward, +z is backwards

Let me know if I need to do some more digging.

I'm going to keep working on the high-level nav AI for the rest of the day.

-Tim

TIMOTHY K HAMILTON <tkh...@ve...> wrote: Wow, that's... bad. Really bad.

I had been suspecting that I might have been mis-translating ccordinates between ODE and openGL, but what you're describing looks like a problem completely internal to ODE itself.

I'll see what I can do with it today, and get you some feedback by this afternoon.

-Tim

Nathan Clow <n_...@ho...> wrote:
Some bad news:

There appears to be a bug in ODE with dBodyVectorFromWorld. I think the
function is bugged and returns sign errors on its values.

Here's my logic:
The body starts at position 0,0,0 with normal (unrotated) rotation values.
The axes of the body are initially aligned with those of the world.

That's not what happens. Here's some sample output from the situation
described above.

See how z is negative? I don't know how this can be. The point is
approaching the "front" of the ship as it rotates. Z should range up to 100,
not down to -100.

_________________________________________________________________
Get free, personalized commercial-free online radio with MSN Radio powered
by Pandora http://radio.msn.com/?icid=T002MSN03A07001

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV_______________________________________________
Eighthfleet-development mailing list
Eig...@li...
https://lists.sourceforge.net/lists/listinfo/eighthfleet-development

Re: [Eighthfleet-development] ODE problems

From: TIMOTHY K H. <tkh...@ve...> - 2006-11-27 17:32:42

Wow, that's... bad. Really bad.

I had been suspecting that I might have been mis-translating ccordinates between ODE and openGL, but what you're describing looks like a problem completely internal to ODE itself.

I'll see what I can do with it today, and get you some feedback by this afternoon.

-Tim

Nathan Clow <n_...@ho...> wrote:
Some bad news:

There appears to be a bug in ODE with dBodyVectorFromWorld. I think the
function is bugged and returns sign errors on its values.

Here's my logic:
The body starts at position 0,0,0 with normal (unrotated) rotation values.
The axes of the body are initially aligned with those of the world.

That's not what happens. Here's some sample output from the situation
described above.

See how z is negative? I don't know how this can be. The point is
approaching the "front" of the ship as it rotates. Z should range up to 100,
not down to -100.

_________________________________________________________________
Get free, personalized commercial-free online radio with MSN Radio powered
by Pandora http://radio.msn.com/?icid=T002MSN03A07001

[Eighthfleet-development] ODE problems

From: Nathan C. <n_...@ho...> - 2006-11-27 09:10:38

Some bad news:

There appears to be a bug in ODE with dBodyVectorFromWorld. I think the 
function is bugged and returns sign errors on its values.

Here's my logic:
The body starts at position 0,0,0 with normal (unrotated) rotation values.
The axes of the body are initially aligned with those of the world.

Here are sample dBodyVectorFromWorld translations while the body is 
unrotated, with the world vector on the left and the relative vector on the 
right.
[100,0,0] -> [100,0,0]
[0,100,0] -> [0,100,0]
[0,0,100] -> [0,0,100]

So, based on this, I created the notion that for relative vectors, +x is to 
the right, +y is upwards, and +z is in front. Both the global and relative 
coordinate systems seem to be aligned at the start while not rotated.

So, one would expect that, if given a point 100 units to the right, a simple 
YAWCW would rotate you 90 degrees to the right until you're facing it. You'd 
expect your relative vectors during this time to start with [100,0,0], to 
range intermediately between [n, 0, m] with n and m from 0 to 100, and to 
end at [0,0,100].

That's not what happens. Here's some sample output from the situation 
described above.

Pos: [0.000000 0.000000 0.000000]  DestPos: [100.000000 0.000000 0.000000]
Derived world vector [100.000000,0.000000,0.000000] from navQueue
Derived relative vector [98.828865,0.000000,-15.259607] from navQueue
Translated back to world vector [100.000000,0.000000,-0.000000]

See how z is negative? I don't know how this can be. The point is 
approaching the "front" of the ship as it rotates. Z should range up to 100, 
not down to -100.

This is just an example. The long and short of it is that 0 to 3 of the 
values may have the wrong sign depending on the situation, and that I have 
no way to tell when this will happen and thus correct the sign errors. I 
think the bug occurs because of the way the rotation matrix works in ODE, 
but I don't really understand what the values in that matrix are supposed to 
be (despite spending a lot of time looking at it).

I've been over this and over this and can't find any error in my 
understanding of what is supposed to be happening. I suppose there could be 
a problem in the engine code or the graphics code or something else, causing 
what we see to be different than what ODE knows, but I think that's pretty 
unlikely.

So this was like hitting a brick wall. I have no idea if I could write a 
working vector translation function before Thursday. Give me your feedback 
if you have any. I'll approach the problem again tomorrow with a fresh mind.

_________________________________________________________________
Get free, personalized commercial-free online radio with MSN Radio powered 
by Pandora http://radio.msn.com/?icid=T002MSN03A07001

Re: [Eighthfleet-development] Algorithm Apologies and Thoughts

From: TIMOTHY K H. <tkh...@ve...> - 2006-11-27 03:36:15

Beware, I lied again...

thrust(int direction, double fraction)
is incorrent, the correct function name is:
partialThrust(int direction, double fraction);

TIMOTHY K HAMILTON <tkh...@ve...> wrote: I've almost got the available accel pre-calculations finished, I just have to find every place in the code where mass can possibly be removed, and make sure that accel is then re-calculated, but the basics are already there.

Fractional thrust is also completely implemented, just call:

thrust(int direction, double fraction)

where fraction is between 0-1. It works exactly like the existing thrust(direction) function in all other ways.

I'll do what I can on the higher-level nav as you suggest, the majority of the tactical stuff needs to wait until we can get a ship to orient itself correctly, not to mention make a missile orient itself correctly... once missiles can be guilded, things are going to be a lot more fun.

-Tim

Nathan Clow <n_...@ho...> wrote: No need to be so apologetic. =)

Angular movement is still wonky. I'll have another go at that tonight sometime. There were two major problems in the linear versions that I think also could have translated to the angular versions, since I translated the derivation straight across. The distance p was supposed to be the distance from the current position to the midpoint, which I treated wrongly at first, and the lack of the special case examining velocity when the position was between p and the goal produced some erroneous behavior. I tried to use the same logic for the fixes applied to the linear code in the angular code but it didn't seem to work as expected before my last commit.

One optimization I can think of off the top of my head is to pre-calculate acceleration available in every direction, updated when engines are added, removed, or stop working for whatever reason.

One thing I will need is a way to thrust at less than 100% of engine power in a given direction. This is necessary to use during the timestep when p is less than a full thrust away. I was going to write it but if you want to go ahead. Something that takes a simple 0-1 percentage should do the trick.

Do you want to work on higher-level nav behavior? For instance, when a ship enters the MIN_DIST from its target it shouldn't stop decelerating if it wants to actually stop at that target, and we need a way to switch off from NAV_GOTO to NAV_STAY when the ship is comfortable with its position. Another thing is that if a ship is traversing several points it may not want to slow down and try to stop at each point. It may want to slow down somewhat according to a provided constant, or depending on where it thinks its next goal point is relative to the current point. There's definitely a lot of work to do at that level in tickAI and navXX functions.
----- Original Message -----
From: TIMOTHY K HAMILTON
To: eig...@li...
Sent: Sunday, November 26, 2006 9:39 AM
Subject: [Eighthfleet-development] Algorithm Apologies and Thoughts

Alright, so it would seem that my contribution to navigation algorithms is to break them, sorry about that.

Your method for lineral acceleration is very obviously superior to mine, the movement once it reaches the target point is much smoother and oscilates less. Angular movement still acts a little funny though, as it doesn't start decelerating until it's completely passed the target angle, instead of approx. halfway there. I'm not going to touch that, however.

What I will do is try to optimize things a little better. I'll keep my hands out of the angular velocity code, but I think I can streamline the linear velocity stuff. One way I think to keep from doing a lot of re-calculating is just to pre-calculate as much of the information as possible during initialization of the ship. One of the most obvious values for this, I think, are the various availableThrusts, which only need to be re-computed whenever an engine is added or destroyed.

Again, I'll be a lot more careful about touching navigation, and just focus on what I promised about tactical behavior instead.

Sorry I broke your code.

-Tim

---------------------------------

_______________________________________________
Eighthfleet-development mailing list
Eig...@li...
https://lists.sourceforge.net/lists/listinfo/eighthfleet-development
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV_______________________________________________
Eighthfleet-development mailing list
Eig...@li...
https://lists.sourceforge.net/lists/listinfo/eighthfleet-development

Re: [Eighthfleet-development] Algorithm Apologies and Thoughts

From: TIMOTHY K H. <tkh...@ve...> - 2006-11-27 01:54:44

I've almost got the available accel pre-calculations finished, I just have to find every place in the code where mass can possibly be removed, and make sure that accel is then re-calculated, but the basics are already there.

Fractional thrust is also completely implemented, just call:

thrust(int direction, double fraction)

where fraction is between 0-1. It works exactly like the existing thrust(direction) function in all other ways.

-Tim

Nathan Clow <n_...@ho...> wrote: No need to be so apologetic. =)

One optimization I can think of off the top of my head is to pre-calculate acceleration available in every direction, updated when engines are added, removed, or stop working for whatever reason.

Alright, so it would seem that my contribution to navigation algorithms is to break them, sorry about that.

Again, I'll be a lot more careful about touching navigation, and just focus on what I promised about tactical behavior instead.

Sorry I broke your code.

-Tim

---------------------------------

_______________________________________________
Eighthfleet-development mailing list
Eig...@li...
https://lists.sourceforge.net/lists/listinfo/eighthfleet-development
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV_______________________________________________
Eighthfleet-development mailing list
Eig...@li...
https://lists.sourceforge.net/lists/listinfo/eighthfleet-development

Re: [Eighthfleet-development] Algorithm Apologies and Thoughts

From: Nathan C. <n_...@ho...> - 2006-11-26 22:09:46

No need to be so apologetic. =3D)

Angular movement is still wonky. I'll have another go at that tonight =
sometime. There were two major problems in the linear versions that I =
think also could have translated to the angular versions, since I =
translated the derivation straight across. The distance p was supposed =
to be the distance from the current position to the midpoint, which I =
treated wrongly at first, and the lack of the special case examining =
velocity when the position was between p and the goal produced some =
erroneous behavior. I tried to use the same logic for the fixes applied =
to the linear code in the angular code but it didn't seem to work as =
expected before my last commit.

One optimization I can think of off the top of my head is to =
pre-calculate acceleration available in every direction, updated when =
engines are added, removed, or stop working for whatever reason.

One thing I will need is a way to thrust at less than 100% of engine =
power in a given direction. This is necessary to use during the timestep =
when p is less than a full thrust away. I was going to write it but if =
you want to go ahead. Something that takes a simple 0-1 percentage =
should do the trick.

Do you want to work on higher-level nav behavior? For instance, when a =
ship enters the MIN_DIST from its target it shouldn't stop decelerating =
if it wants to actually stop at that target, and we need a way to switch =
off from NAV_GOTO to NAV_STAY when the ship is comfortable with its =
position. Another thing is that if a ship is traversing several points =
it may not want to slow down and try to stop at each point. It may want =
to slow down somewhat according to a provided constant, or depending on =
where it thinks its next goal point is relative to the current point. =
There's definitely a lot of work to do at that level in tickAI and navXX =
functions.
  ----- Original Message -----=20
  From: TIMOTHY K HAMILTON=20
  To: eig...@li...=20
  Sent: Sunday, November 26, 2006 9:39 AM
  Subject: [Eighthfleet-development] Algorithm Apologies and Thoughts


  Alright, so it would seem that my contribution to navigation =
algorithms is to break them, sorry about that. =20

  Your method for lineral acceleration is very obviously superior to =
mine, the movement once it reaches the target point is much smoother and =
oscilates less.  Angular movement still acts a little funny though, as =
it doesn't start decelerating until it's completely passed the target =
angle, instead of approx. halfway there.  I'm not going to touch that, =
however.

  What I will do is try to optimize things a little better.  I'll keep =
my hands out of the angular velocity code, but I think I can streamline =
the linear velocity stuff.  One way I think to keep from doing a lot of =
re-calculating is just to pre-calculate as much of the information as =
possible during initialization of the ship.  One of the most obvious =
values for this, I think, are the various availableThrusts, which only =
need to be re-computed whenever an engine is added or destroyed. =20

  Again, I'll be a lot more careful about touching navigation, and just =
focus on what I promised about tactical behavior instead. =20

  Sorry I broke your code.

  -Tim



-------------------------------------------------------------------------=
-----


  =
-------------------------------------------------------------------------=

  Take Surveys. Earn Cash. Influence the Future of IT
  Join SourceForge.net's Techsay panel and you'll get the chance to =
share your
  opinions on IT & business topics through brief surveys - and earn cash
  =
http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV


-------------------------------------------------------------------------=
-----


  _______________________________________________
  Eighthfleet-development mailing list
  Eig...@li...
  https://lists.sourceforge.net/lists/listinfo/eighthfleet-development

[Eighthfleet-development] Algorithm Apologies and Thoughts

From: TIMOTHY K H. <tkh...@ve...> - 2006-11-26 17:39:59

Alright, so it would seem that my contribution to navigation algorithms is to break them, sorry about that.  

Your method for lineral acceleration is very obviously superior to mine, the movement once it reaches the target point is much smoother and oscilates less.  Angular movement still acts a little funny though, as it doesn't start decelerating until it's completely passed the target angle, instead of approx. halfway there.  I'm not going to touch that, however.

What I will do is try to optimize things a little better.  I'll keep my hands out of the angular velocity code, but I think I can streamline the linear velocity stuff.  One way I think to keep from doing a lot of re-calculating is just to pre-calculate as much of the information as possible during initialization of the ship.  One of the most obvious values for this, I think, are the various availableThrusts, which only need to be re-computed whenever an engine is added or destroyed.  

Again, I'll be a lot more careful about touching navigation, and just focus on what I promised about tactical behavior instead.  

Sorry I broke your code.

-Tim

Flat | Threaded

1 2 > >> (Page 1 of 2)

2006	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov (28)	Dec (1)
2007	Jan	Feb	Mar	Apr	May	Jun	Jul (11)	Aug (1)	Sep	Oct	Nov	Dec