spacetrek-users — Spacetrek 3D Users Mailing List

[Spacetrek-users] Commit

[<st...@bu...>]

Hi,

just commited some new files, mostly manpages:

Checking in ChangeLog;
/cvsroot/spacetrek/spacetrek/ChangeLog,v  <--  ChangeLog
new revision: 1.13; previous revision: 1.12
done
Checking in Makefile.sgi;
/cvsroot/spacetrek/spacetrek/Makefile.sgi,v  <--  Makefile.sgi
new revision: 1.12; previous revision: 1.11
done
RCS file: /cvsroot/spacetrek/spacetrek/spacetrek.1.z,v
done
Checking in spacetrek.1.z;
/cvsroot/spacetrek/spacetrek/spacetrek.1.z,v  <--  spacetrek.1.z
initial revision: 1.1
done
RCS file: /cvsroot/spacetrek/spacetrek/spacetrek.man,v
done
Checking in spacetrek.man;
/cvsroot/spacetrek/spacetrek/spacetrek.man,v  <--  spacetrek.man
initial revision: 1.1
done
RCS file: /cvsroot/spacetrek/spacetrek/spacetrek.pdf,v
done
Checking in spacetrek.pdf;
/cvsroot/spacetrek/spacetrek/spacetrek.pdf,v  <--  spacetrek.pdf
initial revision: 1.1
done

-- =

Stefan Stapelberg         RENT-A-GURU=AE INET-TV=AE/INET-RADIO=AE NETSTOR=
E=AE
RAG3-RIPE                 Neuer Weg 16 =B7 D-69118 Heidelberg =B7 Germany=

http://www.netstore.de/   Phone: +49.6221.803802 =B7 Fax: +49.6221.803899=

Todays spezial offer:     Microsoft spel chekar vor sail, worgs grate!!

[Spacetrek-users] Re: commit: some fixes for linux

[Alexander R. <ale...@us...>]

Hi,

On Thursday 24 January 2002 00:42, you wrote:
> Alex,
>
> do you also use the Makedepend file on Linux?  I mean can gcc create

I don't use it.

> it automatically? Or do you use makedepend or some other utility?

No idea. Never tried to use it, or something like it?

> On the SGI it's updated by the compiler everytime a binary is created,
> so I didn't add it to the CVS tree. Shoul I add it (if you use it as a
> static file, I would add it)?

I think the gcc keeps track of dependencies in some other way??

Honest, I've got no idea.

> I have stripped down the Makefile and deleted all older crap like
> the AMIGA macros :-) I have changed the call from "make" to "$(MAKE)"
> to be able to verify with "make -n linux" that all files are still
> considered with your make rules.
>
> Thanks again for your help!


Sure - general interest :-)

I'm now also on the reaper3d-mailinglist 
(http://www.dtek.chalmers.se/groups/reaper/)
and just signed up the glelite-mailinglist - let's see what they have to say 
and show :-))




Alex

-- 
                   Alexander Rawass
          Email: ale...@us...
http://tuxfleet.sourceforge.net http://qtreemap.sourceforge.net
...but some day you'll be a STAR in somebody else's SKY...

Re: [Spacetrek-users] Fwd: [Vegastrike-devel] Netrek multiplayer

[<st...@bu...>]

Hi,

On Jan 23, 22:51, Alexander Rawass wrote:
> Subject: [Spacetrek-users] Fwd: [Vegastrike-devel] Netrek multiplayer
> Hi,
> =

> did you read this?

oops, I missed this one in the digest. I have some problems to keep up
with my email; there is a spammer who subscribes me to every mailing
list and newsletter he can find. In January alone my anti-spam software
refused 9,600 emails out of 10,000 :-( Therefore I sometimes miss the
real important emails, but that's not by intention, sorry.
 =

> That means, the game is calculated and run on the server, and the clien=
t only
> displays what the server tells them.

That's correct, although in spacetrek several things can be "localized"
such as orbiting a planet or exploding the ship.
 =

> This protocol may be fine for Netrek, and it may work also fine for VS =
in a
> local LAN, but I doubt that this sort of protocol will work over modem =
lines
> or thorugh the internet.
> =

> a) VS will have to transport much more data - more ships, more laser bo=
lts.
> b) The reaction time for the client will be
> lag_from_server_to_client+lag_from_client_to_server, so when the player=
 fires
> a laser, then the client has to send that to th server and then the ser=
ver
> has to send the pos of the new bolt back, and then the player can see t=
he
> bolt.
> c) When the connection to the server hangs, the client will hang.
> =

> =

> Stefan, can you confirm these problems in some way?

Yes, you are right that the protocol is probably to weak for VS.
Netrek is slooow. Usually you fire torpedoes in the direction
where you suspect the ship to be in a few seconds ...

However, much of the code for the protocol was optimized back in the
days when modem lines were used to connect to the Internet. With today's
bandwidth (ISDN, T-DSL) I never had a typical lag like in old days, even
not with distant servers.

And: netrek doesn't need collision detect, see below.

> Spacetrek won't get 'true' 3D?
> =

> I mean, the server sends only 2D coordinates, so you only can display t=
he
> ship and it surroundings in 3D, but you'll play in a 2D area and you ca=
n't
> fly in the 3rd dimension?

Correct. This makes it very easy to port if you just begun to learn
3D like me :-) :-) I have divided the 3rd dimension into four planes:
the upper plane is for text decoration (planet names etc.), the next
plane is for the own ship, the following plane is for all other ships
and the last plane is for planets.

This way, every player sees all other ships flying around slightly
below the own ship (ships can be above each other in 2D). Therefore,
I also don't need collision detect (the server doesn't know this
either).

I still have some problems with the distances between planets and
ships which work well for a 2D window, but result in a "small"
universe where objects seem to be nearer when viewing into the Z
direction than they actually are. If I reduce the ZFAR clipping
plane, planets are culled and then suddenly appear - doesn't look
very realistic.

Even if the system is fast enough to render 15-20 frames per second,
the ships are moving according to the speed at which packets are
received from the server - usually at 5 to 10 fps. I'm currently
thinking about interpolating the position of a ship during the
frames where no packets are being received, but so far it's just
an idea and I don't know whether this helps to get smoother
movement. Another alternative is to hack the server and change
the coordinate system and also the resolution at which ships
move through the space. But this would break compatibility with
all other brands of netrek servers and so far I would like to
retain that compatibility, at least as long as I have no other
players in a pure spacetrek server (just kidding :-)

Best whishes
Stefan



-- =

Stefan Stapelberg         RENT-A-GURU=AE INET-TV=AE/INET-RADIO=AE NETSTOR=
E=AE
RAG3-RIPE                 Neuer Weg 16 =B7 D-69118 Heidelberg =B7 Germany=

http://www.netstore.de/   Phone: +49.6221.803802 =B7 Fax: +49.6221.803899=

Todays spezial offer:     Microsoft spel chekar vor sail, worgs grate!!

[Spacetrek-users] VS textures/etc for Spacetrek

[Alexander R. <ale...@us...>]

Hi,

On Wednesday 23 January 2002 20:55, you wrote:
>
> Unfortunately I haven't heard from DanielH, neither for my question

DanielH was in holiday some time, maybe he has missed it in the lot-of-mails 
in that time. Try again.

> whether I can use some of his fine textures from Vegastrike nor for

Such questions should better be directed to the VS list.

I generally think that _all_ mail related to Vegastrike (unless private or 
containing big attachments) should go to one of the lists, so that everyone 
(especially me and my bigmouth :-))) can comment on that.

> the comments that Vegastrike has become more or less un-compileable
> on the SGI due to missing files? I have put some work into finding

Didn't know that - you should have said earlier!

> those things, but there were just too much errors, so I gave up.
> Should I probably load the whole thing again?

Well, at least you should get in sync with cvs - and then you can send me 
what's missing/not working.

> From your comments on the VS list I saw that you were requesting
> help for new textures etc. Are the VS copyrighted? I ask because

<scratch my head>

Hmm - that's a good question.

The source code is GPLd, that's clear.

But what about the textures?

I'd prefer them to be GPLd - what do the authors of the textures and models 
have to say about that?

> I really would like to abuse the explosion if Daniel or whoever
> owns it permits it.

I think 'sharing' of textures/models is rather useful for us - and all 
others, cause there's still a lack of free models/textures.

In any way - don't use anything that's in VS 0.1.3 or before, or any data 
that was in the cvs.

I've cleaned up the cvs some days ago, and stripped it of all models/textures 
with questionable origin - now, there *should* only be free models/textures 
there.

> Oh, and thanks for the reminder re the lists :-} I forgot to subscribe

Grin :-))

I'm currently wrapping some of the TuxFleet textures into a tarball, maybe 
something of that is useful.

I'll make it downloadable when I've got time.



Alex

-- 
                   Alexander Rawass
          Email: ale...@us...
http://tuxfleet.sourceforge.net http://qtreemap.sourceforge.net
...but some day you'll be a STAR in somebody else's SKY...

[Spacetrek-users] Fwd: [Vegastrike-devel] Netrek multiplayer

[Alexander R. <ale...@us...>]

Hi,

did you read this?

----------  Forwarded Message  ----------

Subject: [Vegastrike-devel] Netrek multiplayer
Date: Wed, 9 Jan 2002 06:21:59 +0100
From: Alexander Rawass <ale...@us...>
To: veg...@li...

Hi,

I had a look at the documentation about Netreks networking mode.

Basically, it works like that very basic protocol I've designed for TuxFleet:

At the start of the game, the client connects to the server and log in using
TCP.

Then, when the actual game starts, a UDP connection is established.

In each frame, the server send the position (and rotation) of the ships (in
range) to the client.
The server also sends information about torpedoes etc

That means, the game is calculated and run on the server, and the client only
displays what the server tells them.

Netrek differentiates between critical, semi-critical and non-critical
packets.
Critical packets have to be sent every frame, while non-critical packets can
go amiss without big trouble.

With each package containing pos/rot information (or other info), the server
also sends a timestamp.
If the timestamp is too old, the client ignores the package and looks for
newer packages.

The server minimizes the info to send to the client by sending only the stats
of the ships that are in-range/in-view of the player.

Ok, generally I think I understand what they do, and basically I was doing
the same with TuxFleet, except that I transferred ASCII (for debugging)
instead of binary packages, and I did not yet optimize the ships by
range/view.

This protocol may be fine for Netrek, and it may work also fine for VS in a
local LAN, but I doubt that this sort of protocol will work over modem lines
or thorugh the internet.

a) VS will have to transport much more data - more ships, more laser bolts.
b) The reaction time for the client will be
lag_from_server_to_client+lag_from_client_to_server, so when the player fires
a laser, then the client has to send that to th server and then the server
has to send the pos of the new bolt back, and then the player can see the
bolt.
c) When the connection to the server hangs, the client will hang.


Stefan, can you confirm these problems in some way?

Stefan:

Spacetrek won't get 'true' 3D?

I mean, the server sends only 2D coordinates, so you only can display the
ship and it surroundings in 3D, but you'll play in a 2D area and you can't
fly in the 3rd dimension?

Except of course, if you would patch the server to have a 3rd axis.




Alex

--
                   Alexander Rawass
          Email: ale...@us...
http://tuxfleet.sourceforge.net http://qtreemap.sourceforge.net
...but some day you'll be a STAR in somebody else's SKY...


_______________________________________________
Vegastrike-devel mailing list
Veg...@li...
https://lists.sourceforge.net/lists/listinfo/vegastrike-devel

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

-- 
                   Alexander Rawass
          Email: ale...@us...
http://tuxfleet.sourceforge.net http://qtreemap.sourceforge.net
...but some day you'll be a STAR in somebody else's SKY...

[Spacetrek-users] commit: some fixes for linux

[Alexander R. <ale...@us...>]

Hi,

with these fixes, it compiles and runs fine for me.

As you see, I added myself to the spacetrek-users list.


some fixes for linux
 
2002-01-23 Alexander Rawass <ale...@us...>
 
        * fixes to compile on linux
 
CVS: ----------------------------------------------------------------------
CVS: Enter Log.  Lines beginning with `CVS:' are removed automatically
CVS:
CVS: Committing in .
CVS:
CVS: Modified Files:
CVS:    ChangeLog Makefile gldriver.c rgbfmt.h
CVS: ----------------------------------------------------------------------

-- 
                   Alexander Rawass
          Email: ale...@us...
http://tuxfleet.sourceforge.net http://qtreemap.sourceforge.net
...but some day you'll be a STAR in somebody else's SKY...