vegastrike-devel — Development forum. State your wishes for VS features and suggestions for develo

[Vegastrike-devel] Free Game Alliance - send all your questions so I can...

[Scott M. <dar...@ya...>]

let them know if we will be joining or not. Going to contact them soon with whatever questions I can think of and hopefully any extras that the rest of you (whoever you are) has as well. We may not be anywhere near our peak anymore but vegastrike still carries a bit of weight as far as an opensource project goes. With access to a greater pool of programmers and artists this could be a very good change for us. Hopefully some of the original developers (ace and gang) still gets this mailing so we can make a serious go of this. Maybe Sirikata (spelling) could even join up.
 
Anyway, need some feedback people.

Re: [Vegastrike-devel] Fwd: Free Game Alliance proposal.

[ghoulsblade <gho...@sc...>]

Heya,

you might want to make a thread on http://forum.freegamedev.net also,
the opensource-game community board associated with the freegamer blog,
lots of opensource enthusiasts and projects there.

regards,
ghoulsblade

Am 22.08.2011 13:50, schrieb Claudio Freire:
> I got this message from the PlaneShift guys.
>
> I guess we have some discussing to do :-)
>
> I see lots of questions to be answered before jumping in, but in
> general it sounds like an interesting idea worth some consideration.
>
> So... readers, lurkers, and of course ya developers, please comment.
>
>
> ---------- Forwarded message ----------
> From: Luca Pancallo<pan...@ne...>
> Date: Sat, Aug 13, 2011 at 8:52 PM
> Subject: Free Game Alliance proposal.
> To: kla...@us...
>
>
> Dear Sirs,
>
> my name is Luca Pancallo and I am the project leader of PlaneShift, an
> online and opensource 3D MMORPG. I would like to make a proposal to
> join a newly created alliance of free opensource games : Free Game
> Alliance.
>
> I've always been very interested in open-source and I'm actively
> involved since more than 10 years into it. I'm not a purist of
> freedom, but the three principles I like of open source are the idea
> of allowing others to know what runs on their machines, allowing them
> to contribute, and having the project as a platform for us and
> everyone else to learn.
>
> Open Source projects are often weak, split and often without a good PR
> department (just because there is already too much to do) which gives
> them little visibility compared to commercial games.
>
> The purpose of the alliance is to help all of its members to reach a
> wider audience of players and also new potential developers. We would
> achieve this by creating a perfect package of open source games which
> includes one game for each genre: the best mmorpg, the best fps, the
> best rts, etc.. Choosing only one game per genre will avoid
> competition inside the alliance, so we can share the same audience
> without problems. The main prerequisites for a project to participate
> in the alliance are to be open source, to be active, and to be free
> for players. With open source in that sentence I mean the source code
> should be available to everyone and in general the project accepts new
> contributors. Art, music or other special assets can be in a more
> proprietary license, as long as the game it's free and everyone can
> access to it.
>
> The whole initiative will be sponsored and maintained by Atomic Blue,
> which is our non-profit organization. We will provide a logo, a web
> page with full explanation of the principles behind it, cool facts
> about the games, link to game videos and other material. We will
> provide support to place the alliance's advertisement in gaming
> magazines and websites. The website is actually nearly ready.
>
> There are no plans to spend any money on this, but to make it
> successful thanks to the notoriety of the selected games. Every member
> of the alliance would be advertising the alliance on its own player
> base, through different channels, like forums, mails, rss, news, or
> even in game.
>
> The fact I send you this email is no coincidence as you have been
> selected as one potential member of the alliance. We are selecting
> projects right now, and I want to know your opinion on it.
>
> Besides the PR benefit I think the alliance can also be very useful as
> a platform for developers to exchange ideas, techniques and knowledge
> to develop even better games. I envision a monthly meeting where each
> project presents its progresses and multiple occasions where
> developers tag-along for discussing new shaders, techniques, problems
> faced. Can also be a good platform for the press. If we stay strong
> and unite it can become the "standard" open source package people
> speak about.
>
> PlaneShift, our game, is the selected project to be part of the
> alliance in the mmorpg genre, so let me introduce you a bit more of
> what we do.
>
> PlaneShift is a fully free game to play, which means there are no
> limitations in skills, ranks or items you can get. There are no
> premium tricks, or hidden costs. Our license is GPL for sourcecode and
> proprietary for art assets because we want to protect the uniqueness
> of the game. The game is not a finished product, and not stable yet,
> but under heavy development. Nonetheless it is played by hundreds of
> active players, and we have a large fan base. You can see for yourself
> when you download it from www.planeshift.it. When you do so, you will
> enter a medieval world full of magic, warriors, ancient races like
> dwarfs, elves and also many new and unknown races (and bugs!!).
>
> Please let me know what you think about it, we hope you will submit
> your project as one candidate to be part of the alliance to make more
> opensource games well known.
>
> Best Regards
>
> Luca Pancallo,
> PlaneShift Director and Founder.
>
> ------------------------------------------------------------------------------
> uberSVN's rich system and user administration capabilities and model
> configuration take the hassle out of deploying and managing Subversion and
> the tools developers use with it. Learn more about uberSVN and get a free
> download at:  http://p.sf.net/sfu/wandisco-dev2dev
> _______________________________________________
> Vegastrike-devel mailing list
> Veg...@li...
> https://lists.sourceforge.net/lists/listinfo/vegastrike-devel

[Vegastrike-devel] Fwd: Free Game Alliance proposal.

[Claudio F. <kla...@gm...>]

I got this message from the PlaneShift guys.

I guess we have some discussing to do :-)

I see lots of questions to be answered before jumping in, but in
general it sounds like an interesting idea worth some consideration.

So... readers, lurkers, and of course ya developers, please comment.


---------- Forwarded message ----------
From: Luca Pancallo <pan...@ne...>
Date: Sat, Aug 13, 2011 at 8:52 PM
Subject: Free Game Alliance proposal.
To: kla...@us...


Dear Sirs,

my name is Luca Pancallo and I am the project leader of PlaneShift, an
online and opensource 3D MMORPG. I would like to make a proposal to
join a newly created alliance of free opensource games : Free Game
Alliance.

I've always been very interested in open-source and I'm actively
involved since more than 10 years into it. I'm not a purist of
freedom, but the three principles I like of open source are the idea
of allowing others to know what runs on their machines, allowing them
to contribute, and having the project as a platform for us and
everyone else to learn.

Open Source projects are often weak, split and often without a good PR
department (just because there is already too much to do) which gives
them little visibility compared to commercial games.

The purpose of the alliance is to help all of its members to reach a
wider audience of players and also new potential developers. We would
achieve this by creating a perfect package of open source games which
includes one game for each genre: the best mmorpg, the best fps, the
best rts, etc.. Choosing only one game per genre will avoid
competition inside the alliance, so we can share the same audience
without problems. The main prerequisites for a project to participate
in the alliance are to be open source, to be active, and to be free
for players. With open source in that sentence I mean the source code
should be available to everyone and in general the project accepts new
contributors. Art, music or other special assets can be in a more
proprietary license, as long as the game it's free and everyone can
access to it.

The whole initiative will be sponsored and maintained by Atomic Blue,
which is our non-profit organization. We will provide a logo, a web
page with full explanation of the principles behind it, cool facts
about the games, link to game videos and other material. We will
provide support to place the alliance's advertisement in gaming
magazines and websites. The website is actually nearly ready.

There are no plans to spend any money on this, but to make it
successful thanks to the notoriety of the selected games. Every member
of the alliance would be advertising the alliance on its own player
base, through different channels, like forums, mails, rss, news, or
even in game.

The fact I send you this email is no coincidence as you have been
selected as one potential member of the alliance. We are selecting
projects right now, and I want to know your opinion on it.

Besides the PR benefit I think the alliance can also be very useful as
a platform for developers to exchange ideas, techniques and knowledge
to develop even better games. I envision a monthly meeting where each
project presents its progresses and multiple occasions where
developers tag-along for discussing new shaders, techniques, problems
faced. Can also be a good platform for the press. If we stay strong
and unite it can become the "standard" open source package people
speak about.

PlaneShift, our game, is the selected project to be part of the
alliance in the mmorpg genre, so let me introduce you a bit more of
what we do.

PlaneShift is a fully free game to play, which means there are no
limitations in skills, ranks or items you can get. There are no
premium tricks, or hidden costs. Our license is GPL for sourcecode and
proprietary for art assets because we want to protect the uniqueness
of the game. The game is not a finished product, and not stable yet,
but under heavy development. Nonetheless it is played by hundreds of
active players, and we have a large fan base. You can see for yourself
when you download it from www.planeshift.it. When you do so, you will
enter a medieval world full of magic, warriors, ancient races like
dwarfs, elves and also many new and unknown races (and bugs!!).

Please let me know what you think about it, we hope you will submit
your project as one candidate to be part of the alliance to make more
opensource games well known.

Best Regards

Luca Pancallo,
PlaneShift Director and Founder.

Re: [Vegastrike-devel] vegastrike.config cleanup

[green <gre...@gm...>]

Claudio Freire wrote at 2010-10-04 09:46 -0500:
> On Sun, Oct 3, 2010 at 10:03 AM, green <gre...@gm...> wrote:
> > Would there be interest in patches to clean up vegastrike.config?
> >
> > I'm thinking of several patches:
> > - whitespace
> 
> Unless it really hurts readability, I wouldn't bother.

Hmm, well maybe it is a matter of opinion, but to me the vegastrike.config file 
seems rather messy.  If vssetup works, then everything is great.  Otherwise, 
the config file is a mountain of undocumented config variables with blank lines 
in weird places and a seemingly random amount of spaces/tabs before lines.

> > - removal of variables that are set to default values
> 
> I'd rather add more of those. People don't usually read the code, so
> defaults (in code) are obscure. Having every variable explicitly stated in
> the .config file is beneficial for modders that don't code.

I can't really disagree with that, except for variables that are unlikely to 
need adjustment from default values (which could just go in a section labeled 
as such).

> > For the whitespace, I would do like this unless something else is
> > preferred:
> 
> I don't get it... what's the difference with what is already there?

Um, the whitespace! :)


Maybe it would be better if I instead worked on extending the configuration 
documentation in the wiki manual.

[Vegastrike-devel] vegastrike.config cleanup

[green <gre...@gm...>]

Would there be interest in patches to clean up vegastrike.config?

I'm thinking of several patches:
- whitespace
- grammar/spelling (in comments)
- removal of variables that are set to default values

For the whitespace, I would do like this unless something else is preferred:

<vegaconfig>

<bindings>
 <bind .../>
<!-- #no_mouse -->
 <bind mouse="0" player="1" button="0" modifier="none" command="FireKey" />
<!-- #end -->
 <bind .../>
</bindings>

<colors>
 <section name="nav>
  <color name="destination_system" r="0.0" g="0.0" b="0.0" a="0.0"/>
 </section>
</colors>

<variables>
 <section name="graphics">
<!-- #extremeshader
  <var .../>
#end -->
 </section>

</vegaconfig>


Comments?

Re: [Vegastrike-devel] CONFVAR wiki page & default values

[green <gre...@gm...>]

(Returning to list)

Claudio Freire wrote at 2010-09-30 11:19 -0500:
> On Wed, Sep 29, 2010 at 9:08 PM, green <[1]gre...@gm...> wrote:
> > I am working on the advanced configuration wiki pages and am wondering about
> > the CONFVAR page at: [2]http://vegastrike.sourceforge.net/wiki/CONFVAR
> >
> > Is the page up-to-date with current SVN and are the values listed there the
> > hardcoded defaults (with only a skeleton config or none at all)?
> 
> If you take a look at its history:
> http://vegastrike.sourceforge.net/mediawiki/index.php?title=CONFVAR&action=history
>
> It's quite outdated.
> But most of it should still be valid, outdated means there may have been
> changes to default values, removed variables, or new variables that aren't
> there. But I bet 99% of it is still valid.

Okay, thanks.

Are there any bindings defaults in the source?

[Vegastrike-devel] CONFVAR wiki page & default values

[green <gre...@gm...>]

I am working on the advanced configuration wiki pages and am wondering about 
the CONFVAR page at: http://vegastrike.sourceforge.net/wiki/CONFVAR

Is the page up-to-date with current SVN and are the values listed there the 
hardcoded defaults (with only a skeleton config or none at all)?

Also, I don't see any mention of binding variables.

Thanks.

Re: [Vegastrike-devel] Vegastrike for Haiku - Patch

[Michael O. <mic...@ya...>]

> Thanks for this patch. I'm surprised at how simple the port was.
> Does everything really work out of the box after you apply it (with
> GLUT)? 
> Just so we know, how do you compile it? Did you test with cmake or
> autotools?
 
Firstly I tried with autools:
./bootstrap-sh
./configure --prefix=/boot/apps/VegaStrike --disable-sdl
 
Then I faced a lot of problems, like python not found (had
to manually include the path) without
glXGetProcessAddressARB (we use glutGetProcAddress instead),
libpthread dependency (Haiku does not have one), add our
libnetwork instead of libsocket, and add libavutil togheter
with libavformat. 
Then I did some little modifications into configure file
(see file attached, I will create a wiki file for this)
 
With the patch that you applied, it builds without any
problems! 
The only thing that I notice is that I got bigger binaries
from both: vegaserver and vegastrike (11mb and 18mb).
 
So, now I tried compile the game using CMake. No big
surprise: I had to make small adjustments also, because we
don't have gtk2 too (using autotools, gtk is not
required).The only thing I found odd is that now the
endianess.h  file don't find the endian.h header. 
Anycase, here comes another patch (see the file attached).

Thereafter, it generates smaller binaries of vegaserver and
vegastrike (4,6 mb and 8,6 mb) and now, vegaserver don't
show the OS description at beggining.

Running the game, I got the following results:

Please consider that:
* I'm running the game in Vesa mode, because I have a
unsupported radeonhd (only geforce drivers have some 3D
performance)
* Our mesa renderer is in alpha quality still (in very bad
shape).
* Gallium port already started, so we'll have a better 3D
support soon

I configure it to start into a windowed 1024x768
resolution, later I resized it to a 512x352 to save some fps
in order to be playable.

Here, a screenshot
http://img442.imageshack.us/img442/204/screenshot4oj.png
http://img295.imageshack.us/img295/3769/screenshot1hce.png

Focusing on the first visible planet visible, I got this
funny rendering
http://img199.imageshack.us/img199/5465/screenshot3xu.png

I remember when I ported Celestia, it crashed when viewing
a planet, so this could be a mesa renderer problem. Any tips
about how solve that?

Anyway, it's very playable. 
Later, I create a icon, in HVIF format (Haiku native icon
format, see the file attached and the screenshots)
Then I posted the game here, int the official Haiku app
store:
http://haikuware.com/directory/view-details/games/3d/vegastrike

> If there are any complicated directions, feel free to
add a page at
> the vega strike wiki at http://vegastrike.sourceforge.net/wiki/
 
Ok! I'll work on that
 
** THANK YOU FOR ALL THE SUPPORT**
 
Regards,
Michael Vinícius de Oliveira


      

Re: [Vegastrike-devel] Vegastrike for Haiku - Patch

[Patrick H. <ac...@us...>]

  Thanks for this patch. I'm surprised at how simple the port was. Does 
everything really work out of the box after you apply it (with GLUT)?

Just so we know, how do you compile it? Did you test with cmake or 
autotools?

If there are any complicated directions, feel free to add a page at the 
vega strike wiki at http://vegastrike.sourceforge.net/wiki/

I'll see that it gets committed if it hasn't already been.

Thanks,
Patrick

On 9/9/10 9:44 AM, Michael Oliveira wrote:
> Hi!
>
> I'm doing a Haiku por of VegaStrike
>
> As you may know, Haiku is a BeOS clone
>
> The port is based on GLUT, because our SDL implementation don't work with 3D graphics yet..
>
> I did this patch to enable a sucessfull haiku building. I'd like that you commit it in the SVN trunk, please.
>
> Soon will be released at Haikuware
>
> Thank you for this AMAZING GAME!
>
> Regards,
>
> Michael
>
>
>        
>
>
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
>
>
> _______________________________________________
> Vegastrike-devel mailing list
> Veg...@li...
> https://lists.sourceforge.net/lists/listinfo/vegastrike-devel

[Vegastrike-devel] Vegastrike for Haiku - Patch

[Michael O. <mic...@ya...>]

Hi! 

I'm doing a Haiku por of VegaStrike

As you may know, Haiku is a BeOS clone

The port is based on GLUT, because our SDL implementation don't work with 3D graphics yet..

I did this patch to enable a sucessfull haiku building. I'd like that you commit it in the SVN trunk, please.

Soon will be released at Haikuware

Thank you for this AMAZING GAME!

Regards,

Michael


      

Re: [Vegastrike-devel] Hello there.

[Samuel N. <nic...@gm...>]

hey Toan,

I've been subscribed to this list for years and at most gotten a handful of
emails.

I think most communications go through the forums.
http://vegastrike.sourceforge.net/forums/

<http://vegastrike.sourceforge.net/forums/>Cheers,
Enetheru

On 11 July 2010 23:01, Toan Phuc Nguyen Tri <ngu...@ya...>wrote:

> Hi everyone,i just check out Vega Strike game and i want to have some
> contributions.First of all i am a Sci-fi fan,i have some experiences about
> Sci-fi universes.Secondly i have used some 3d program like Sketchup and 3Ds
> max,i also work at Flightgear opensource project and Orbiter project.I hope
> i can help you as a universe expander,database development or simply a Test
> Pilot.
>                              Toan Phuc
>
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Vegastrike-devel mailing list
> Veg...@li...
> https://lists.sourceforge.net/lists/listinfo/vegastrike-devel
>
>

[Vegastrike-devel] Hello there.

[Toan P. N. T. <ngu...@ya...>]

Hi everyone,i just check out Vega Strike game and i want to have some contributions.First of all i am a Sci-fi fan,i have some experiences about Sci-fi universes.Secondly i have used some 3d program like Sketchup and 3Ds max,i also work at Flightgear opensource project and Orbiter project.I hope i can help you as a universe expander,database development or simply a Test Pilot.
                             Toan Phuc 
  



      

Re: [Vegastrike-devel] Vegastrike-devel Digest, Vol 10, Issue 1

[Ludwig O. J. S. <lud...@gm...>]

Re: A monologue
Hi, everybody.
I'm not a developper, not a junior programmer, and I'm not English native,
but I have some skills in assembler x86, and I studied just a bit about some
programming, so I understand the job is very, very hard.
For two years, I've been playing Vega Strike intermitently, but with some
very intensive periods. I love about it the realism it has, mainly the way
it manages inertia, making it very realistic. Also the way it manages, in
0.5.0, the gravity wells. I think it makes a very difference with shoting
based space flight simulators. The way it manages distance, the jump gates,
the needing for a careful approach. I don't have much experience with many
other games, but I like, almost everything but.. (1) the bugs: althought the
game doesn't use to crash (0.5.0 didn't crash on my new decent PC); (2) ¡the
astronomical distances!: some planets are less than 1M km each other, and
some stars in binary systems are much pretty close, and some jump gates,
supposedly having worm holes, are too much close to some installations, like
factories, or planets, or stars; (3) the monotony: although it's a dynamic
universe, one can have a behavior making it too boring. I think (1) is a
MUST BE FIXED, NOW. I can help identifying massively bugs, on getting
playing intensively, searching for bugs; (2) can be fixed by
non-programmers; (3) multiplayer could do wonders with it. If our friend
wants to do something, I think he can begin working on bugs and on
multiplayer; graphic engine can be refactored later.
Thank you all developpers and artists for making this great game.
2009/10/15 <veg...@li...>

> Send Vegastrike-devel mailing list submissions to
>        veg...@li...
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        https://lists.sourceforge.net/lists/listinfo/vegastrike-devel
> or, via email, send a message with subject or body 'help' to
>        veg...@li...
>
> You can reach the person managing the list at
>        veg...@li...
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Vegastrike-devel digest..."
>
> Today's Topics:
>
>   1. A monologue (Cornelius Thiele)
>   2. Re: A monologue (Claudio Freire)
>   3. Junior Developer Would Like to Enlist (Chris Hiestand)
>
>
> ---------- Mensaje reenviado ----------
> From: Cornelius Thiele <th...@gm...>
> To: veg...@li...
> Date: Mon, 21 Sep 2009 17:57:00 +0200
> Subject: [Vegastrike-devel] A monologue
> Hi there,
>
> I'm interested in space flight simulations since Privateer 2 and have
> been playing M$s Freelancer on and off again for some time now. Despite
> its obvious problems with massive multiplayer (Windows server, no
> multithreading, closed source), it still has a big community supporting
> the game, and great mods have been released and are still in development
> despite the games real support for them.
>
> I have been looking for a free alternative and have only recently come
> across Vegastrike, and I have to say it comes pretty damn close.
> I am an able coder and would be willing to start an undertaking to make
> it more like Freelancer. This would require (some rather massive)
> gameplay and technical changes, but I think if it were done, a lot of
> players/modders could be attracted to it. Freelancer lacks so many small
> and big features that just can't be added, because it is closed source.
> A lot of the improvements I can think of for Freelancer are already in
> Vegastrike, that's what makes it such a good starting point.
>
> On to the plan:
> First of all, I believe the focus should be completely on multiplayer.
> Almost everybody has the possibility of Internet play and the game is so
> much more fun if you can interact with other players. From a technical
> standpoint, this would mean removing the campaign and built-in
> singleplayer mode completely. It can be re-added later by integrating a
> local server, but from a coding standpoint, it would make things easier
> to focus on multiplayer first and get everything running there.
>
> Then, the GUI. It has be updated to a more modern system. I'm thinking
> of CEGUI, although I admit I have never done anything with it myself. It
> seems to be a good choice, and it plays well together with Ogre. (I
> know, Z-Buffer hacks et al are currently in place; more on that later).
> I found evidence of somebody trying this port already two years ago, but
> apparently the efforts were abandoned. If someone could point me to the
> reasons why, please don't hesitate.
>
> On to gameplay changes. I am inclined to remove some of the realism,
> sorry =).
> The biggest change concerns the realistic distances between and sizes of
> objects in a star system. The velocities needed for traveling between
> objects and maneuvering around are so many orders of magnitude apart
> that a player doing one thing will hardly notice a player doing the
> other thing. (300m/s vs. 97c).
> Sizes of objects and distances should be changed to bring these
> velocities to at most one order of magnitude from each other. This
> should also eliminate the need for special tricks to handle these
> distances in the rendering pipeline.
>
> As as side note, I also don't mind having the "flying stars" effect,
> even if there is no such thing. It gives a sense of speed and makes
> space flight more interesting.
>
> So far I have just skipped over the code, to get a general idea of its
> structure and to fix some things to get it to compile.
> I have noticed a lot of things that would benefit from a general
> clean-up and I guess while making the changes outlined above, lots of
> that will have to be addressed first.
> This is not meant in a bad way; the fact is, that many things have been
> done by many different people, and considering the number of
> refactorings that every part must have gone through over the years, it
> is suprisingly clean.
>
> I know all of this is a massive undertaking, and I really don't know if
> I can pull it off, but I like a good challenge. I don't want to get
> anyones hopes up, so I will be working locally and maybe publish it if
> and when I have some success.
>
> So, I guess what I really wanted to say with this monologue is: Wish me
> luck and if you can provide me with any pointers to anything that might
> help, please do.
>
> Kind regards,
>        Cornelius
>
>
>
>
>
> ---------- Mensaje reenviado ----------
> From: Claudio Freire <kla...@gm...>
> To: Cornelius Thiele <th...@gm...>
> Date: Mon, 21 Sep 2009 13:47:16 -0300
> Subject: Re: [Vegastrike-devel] A monologue
>
>
> On Mon, Sep 21, 2009 at 12:57 PM, Cornelius Thiele <th...@gm...> wrote:
>
>> ...and would be willing to start an undertaking to make
>> it more like Freelancer.
>
>
> I believe you'll have to branch for this.
> I'm not opposed, a lot of Freelancer's aspects really benefit gameplay.
>
> But there was a strong feeling from the core devs against making it "like
> freelancer". Otherwise we would have had nebulas long ago ;-)
>
> It's no big deal, you can work on a branch (ie:
> /branches/<branch_name_here> instead of /trunk/ ).
>
>
>
>> First of all, I believe the focus should be completely on multiplayer.
>> Almost everybody has the possibility of Internet play and the game is so
>> much more fun if you can interact with other players.
>
>
> Perhaps so, perhaps not.
> We have quite a few (very active) users with modem connections.
>
>
>> >From a technical
>> standpoint, this would mean removing the campaign and built-in
>> singleplayer mode completely. It can be re-added later by integrating a
>> local server, but from a coding standpoint, it would make things easier
>> to focus on multiplayer first and get everything running there.
>>
>
> That's a mighty big refactoring. Are you sure you know what's involved?
>
>
>> Then, the GUI. It has be updated to a more modern system. I'm thinking
>> of CEGUI, although I admit I have never done anything with it myself. It
>> seems to be a good choice, and it plays well together with Ogre. (I
>> know, Z-Buffer hacks et al are currently in place; more on that later).
>> I found evidence of somebody trying this port already two years ago, but
>> apparently the efforts were abandoned. If someone could point me to the
>> reasons why, please don't hesitate.
>>
>
> I was the one that pushed that move forward, and the one that abandoned it.
> :-(
>
> Reason: lack of time, and change of priorities.
>
> The project became rather overdesigned (ie, I was spending too much
> thinking of ways to accommodate for features rather than actually porting),
> which made times get longer and longer. With longer times, there were little
> results, and with little results, focus moved into backporting some features
> into non-ogre VS. That combined with a really busy time in RL killed the
> ogre branch - but it's there and anyone can continue my work - I would
> gladly help and guide anyone in that task. I might even retake it, if I had
> someone to offload work from time to time.
>
>
>> On to gameplay changes. I am inclined to remove some of the realism,
>> sorry =).
>> The biggest change concerns the realistic distances between and sizes of
>> objects in a star system. The velocities needed for traveling between
>> objects and maneuvering around are so many orders of magnitude apart
>> that a player doing one thing will hardly notice a player doing the
>> other thing. (300m/s vs. 97c).
>>
>
> There has been a lot of talk about how to solve that without getting rid of
> realism.
>
> Freelancer had a few major structures that pretty much guaranteed
> interaction between players: jump points, docking rings, stations and trade
> lanes (or were they space lanes, whatever).
>
> Those concentrated activity around them, and thus no matter how big or
> small the system was, you could be certain you'd encounter someone at those
> points. In fact, if you wanted to go by unnoticed, you would stay away from
> them - save patrols.
>
> But patrols and "random encounters" were a hack, they were scripted. VS
> also lacks proper scripting support - the power is there with Python, but
> Python is too complex for modders (I wouldn't want to script in pure python
> either - there must be an easy-to-use supportive framework).
>
> One of the options to mimic this in VS that has been discussed more than a
> year ago was to make trade lanes, but instead of being something that moves
> your ship faster, as in freelancer, more like how naval trade lanes are in
> RL: buoys, and you're either coerced (by law and patrols) or encouraged (by
> an autopilot that goes through buoys, or patrols that make those routes
> safer).
>
> And, VS *needs* something like a SPEC disruptor, but nobody ever found a
> clean form for such a weapon. Without it, pirates can't attack SPEC'ing
> ships, and it makes SPEC an easy escape venue. Lots of nerfing made SPEC'ing
> out of combat less attractive, but still the underlying problem remains.
>
>
>> As as side note, I also don't mind having the "flying stars" effect,
>> even if there is no such thing. It gives a sense of speed and makes
>> space flight more interesting.
>>
>
> There's support for that in the engine, it's only disabled by config. You
> can enable it in your mod, no problem whatsoever.
>
>
>> So far I have just skipped over the code, to get a general idea of its
>> structure and to fix some things to get it to compile.
>> I have noticed a lot of things that would benefit from a general
>> clean-up and I guess while making the changes outlined above, lots of
>> that will have to be addressed first.
>>
>
> The port to Ogre, and the ongoing rewrite of the sound system are both
> cleanup efforts.
> The idea was to clean up by rewriting an aspect and putting it into a
> clearly separated module.
>
> Still, lots of physics and AI code is very hacksome, and cleaning up that
> code pretty much involves cleaning up behavior, because behavior itself is
> messy.
>
> And with that you break mods.
>
> And with that you get a lot of resistence.
>
> I would support such a "behavioral cleanup" though. Lots and lots of bugs
> remain to be fixed because fixing them is *hard*, very, but not
> inherently, only the code makes it hard. So a cleanup of this particular
> area is really important. But in order to even think of it, you have to
> think of ways to make modders' life of adapting their mods to the new branch
> easier. Either with automated migration tools or transitional versions... I
> dunno.
>
>
>> I know all of this is a massive undertaking
>
>
> Good to know you know ;-)
>
>
>> ...
>> I can pull it off, but I like a good challenge.
>
>
> Bad approach.
> Rather, slice it into manageable bits, and approach that bit as a smaller
> challenge.
> The "good channel" approach leaves unfinished tasks - I should know (Ogre?)
>
>
>> I don't want to get
>> anyones hopes up, so I will be working locally and maybe publish it if
>> and when I have some success.
>>
>
> That's one way - you could certainly send patches to be committed to the
> branch, and should they be clean enough for the trunk they could be applied
> to the trunk as well.
> And if admins see you provide quality stuff you *will* get SVN access, and
> then you can do that yourself.
>
>
>> So, I guess what I really wanted to say with this monologue is: Wish me
>> luck and if you can provide me with any pointers to anything that might
>> help, please do.
>>
>
> Too big of an undertaking to even begin to think of helpful pointers.
> Rather ask about particular aspects - I know the heaviest development there
> was was on multiplayer at one point. It's rather slow now, but still, there
> was a big move on multiplayer, so you may have your task of separating into
> client-server mostly laid out for you already.
>
> I know nothing about multiplayer code, BTW ;-)
>
>
>
>
> ---------- Mensaje reenviado ----------
> From: Chris Hiestand <chi...@sa...>
> To: veg...@li...
> Date: Thu, 15 Oct 2009 17:39:53 -0700
> Subject: [Vegastrike-devel] Junior Developer Would Like to Enlist
> Hi everyone,
>
> I've just started playing Vega Strike and I am really enjoying it. I played
> Wing Commander Privateer so this gives me a warm and fuzzy feeling.  I'm
> also a full time IT guy who has been meaning to beef up on Python and C++,
> but I'm not sure that I will be a good fit because I won't be able to jump
> in and start coding immediately. I've also been a user of OSS for a long
> time and have been wanting to contribute.
>
> I think the ideal way for me to get involved is if I could be somebody's
> coding wingman, where they could assign me very small projects or bug fixes
> to help me get my feet wet and help me as I go along. So is there anyone out
> there who has time and energy to spare to be something of a mentor?
>
> My resume as it applies:
>
> ==Things I know very well==
> * PHP5 (javascript and xhtml too)
> * OO Programming as it generally applies
> * subversion
> * Linux and OS X from the user and system administrator perspectives (not
> much from the C/C++/ObjC development perspective)
> * debianizing packages
>
> ==Things I have limited experience with but would like to expand on==
> * python (I have only written a couple production scripts)
> * C++. I understand the basics but don't have much experience with memory
> management, pointers, the STL - in short many of the things which people
> need to be proficient.
>
> Let me know if I might be of assistance,
> Chris
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Vegastrike-devel mailing list
> Veg...@li...
> https://lists.sourceforge.net/lists/listinfo/vegastrike-devel
>
>

[Vegastrike-devel] Junior Developer Would Like to Enlist

[Chris H. <chi...@sa...>]

Hi everyone,

I've just started playing Vega Strike and I am really enjoying it. I  
played Wing Commander Privateer so this gives me a warm and fuzzy  
feeling.  I'm also a full time IT guy who has been meaning to beef up  
on Python and C++, but I'm not sure that I will be a good fit because  
I won't be able to jump in and start coding immediately. I've also  
been a user of OSS for a long time and have been wanting to contribute.

I think the ideal way for me to get involved is if I could be  
somebody's coding wingman, where they could assign me very small  
projects or bug fixes to help me get my feet wet and help me as I go  
along. So is there anyone out there who has time and energy to spare  
to be something of a mentor?

My resume as it applies:

==Things I know very well==
* PHP5 (javascript and xhtml too)
* OO Programming as it generally applies
* subversion
* Linux and OS X from the user and system administrator perspectives  
(not much from the C/C++/ObjC development perspective)
* debianizing packages

==Things I have limited experience with but would like to expand on==
* python (I have only written a couple production scripts)
* C++. I understand the basics but don't have much experience with  
memory management, pointers, the STL - in short many of the things  
which people need to be proficient.

Let me know if I might be of assistance,
Chris

Re: [Vegastrike-devel] A monologue

[Claudio F. <kla...@gm...>]

On Mon, Sep 21, 2009 at 12:57 PM, Cornelius Thiele <th...@gm...> wrote:

> ...and would be willing to start an undertaking to make
> it more like Freelancer.


I believe you'll have to branch for this.
I'm not opposed, a lot of Freelancer's aspects really benefit gameplay.

But there was a strong feeling from the core devs against making it "like
freelancer". Otherwise we would have had nebulas long ago ;-)

It's no big deal, you can work on a branch (ie: /branches/<branch_name_here>
instead of /trunk/ ).



> First of all, I believe the focus should be completely on multiplayer.
> Almost everybody has the possibility of Internet play and the game is so
> much more fun if you can interact with other players.


Perhaps so, perhaps not.
We have quite a few (very active) users with modem connections.


> From a technical
> standpoint, this would mean removing the campaign and built-in
> singleplayer mode completely. It can be re-added later by integrating a
> local server, but from a coding standpoint, it would make things easier
> to focus on multiplayer first and get everything running there.
>

That's a mighty big refactoring. Are you sure you know what's involved?


> Then, the GUI. It has be updated to a more modern system. I'm thinking
> of CEGUI, although I admit I have never done anything with it myself. It
> seems to be a good choice, and it plays well together with Ogre. (I
> know, Z-Buffer hacks et al are currently in place; more on that later).
> I found evidence of somebody trying this port already two years ago, but
> apparently the efforts were abandoned. If someone could point me to the
> reasons why, please don't hesitate.
>

I was the one that pushed that move forward, and the one that abandoned it.
:-(

Reason: lack of time, and change of priorities.

The project became rather overdesigned (ie, I was spending too much thinking
of ways to accommodate for features rather than actually porting), which
made times get longer and longer. With longer times, there were little
results, and with little results, focus moved into backporting some features
into non-ogre VS. That combined with a really busy time in RL killed the
ogre branch - but it's there and anyone can continue my work - I would
gladly help and guide anyone in that task. I might even retake it, if I had
someone to offload work from time to time.


> On to gameplay changes. I am inclined to remove some of the realism,
> sorry =).
> The biggest change concerns the realistic distances between and sizes of
> objects in a star system. The velocities needed for traveling between
> objects and maneuvering around are so many orders of magnitude apart
> that a player doing one thing will hardly notice a player doing the
> other thing. (300m/s vs. 97c).
>

There has been a lot of talk about how to solve that without getting rid of
realism.

Freelancer had a few major structures that pretty much guaranteed
interaction between players: jump points, docking rings, stations and trade
lanes (or were they space lanes, whatever).

Those concentrated activity around them, and thus no matter how big or small
the system was, you could be certain you'd encounter someone at those
points. In fact, if you wanted to go by unnoticed, you would stay away from
them - save patrols.

But patrols and "random encounters" were a hack, they were scripted. VS also
lacks proper scripting support - the power is there with Python, but Python
is too complex for modders (I wouldn't want to script in pure python either
- there must be an easy-to-use supportive framework).

One of the options to mimic this in VS that has been discussed more than a
year ago was to make trade lanes, but instead of being something that moves
your ship faster, as in freelancer, more like how naval trade lanes are in
RL: buoys, and you're either coerced (by law and patrols) or encouraged (by
an autopilot that goes through buoys, or patrols that make those routes
safer).

And, VS *needs* something like a SPEC disruptor, but nobody ever found a
clean form for such a weapon. Without it, pirates can't attack SPEC'ing
ships, and it makes SPEC an easy escape venue. Lots of nerfing made SPEC'ing
out of combat less attractive, but still the underlying problem remains.


> As as side note, I also don't mind having the "flying stars" effect,
> even if there is no such thing. It gives a sense of speed and makes
> space flight more interesting.
>

There's support for that in the engine, it's only disabled by config. You
can enable it in your mod, no problem whatsoever.


> So far I have just skipped over the code, to get a general idea of its
> structure and to fix some things to get it to compile.
> I have noticed a lot of things that would benefit from a general
> clean-up and I guess while making the changes outlined above, lots of
> that will have to be addressed first.
>

The port to Ogre, and the ongoing rewrite of the sound system are both
cleanup efforts.
The idea was to clean up by rewriting an aspect and putting it into a
clearly separated module.

Still, lots of physics and AI code is very hacksome, and cleaning up that
code pretty much involves cleaning up behavior, because behavior itself is
messy.

And with that you break mods.

And with that you get a lot of resistence.

I would support such a "behavioral cleanup" though. Lots and lots of bugs
remain to be fixed because fixing them is *hard*, very, but not inherently,
only the code makes it hard. So a cleanup of this particular area is really
important. But in order to even think of it, you have to think of ways to
make modders' life of adapting their mods to the new branch easier. Either
with automated migration tools or transitional versions... I dunno.


> I know all of this is a massive undertaking


Good to know you know ;-)


> ...
> I can pull it off, but I like a good challenge.


Bad approach.
Rather, slice it into manageable bits, and approach that bit as a smaller
challenge.
The "good channel" approach leaves unfinished tasks - I should know (Ogre?)


> I don't want to get
> anyones hopes up, so I will be working locally and maybe publish it if
> and when I have some success.
>

That's one way - you could certainly send patches to be committed to the
branch, and should they be clean enough for the trunk they could be applied
to the trunk as well.
And if admins see you provide quality stuff you *will* get SVN access, and
then you can do that yourself.


> So, I guess what I really wanted to say with this monologue is: Wish me
> luck and if you can provide me with any pointers to anything that might
> help, please do.
>

Too big of an undertaking to even begin to think of helpful pointers.
Rather ask about particular aspects - I know the heaviest development there
was was on multiplayer at one point. It's rather slow now, but still, there
was a big move on multiplayer, so you may have your task of separating into
client-server mostly laid out for you already.

I know nothing about multiplayer code, BTW ;-)

[Vegastrike-devel] A monologue

[Cornelius T. <th...@gm...>]

Hi there,

I'm interested in space flight simulations since Privateer 2 and have
been playing M$s Freelancer on and off again for some time now. Despite
its obvious problems with massive multiplayer (Windows server, no
multithreading, closed source), it still has a big community supporting
the game, and great mods have been released and are still in development
despite the games real support for them.

I have been looking for a free alternative and have only recently come
across Vegastrike, and I have to say it comes pretty damn close.
I am an able coder and would be willing to start an undertaking to make
it more like Freelancer. This would require (some rather massive)
gameplay and technical changes, but I think if it were done, a lot of
players/modders could be attracted to it. Freelancer lacks so many small
and big features that just can't be added, because it is closed source.
A lot of the improvements I can think of for Freelancer are already in
Vegastrike, that's what makes it such a good starting point.

On to the plan:
First of all, I believe the focus should be completely on multiplayer.
Almost everybody has the possibility of Internet play and the game is so
much more fun if you can interact with other players. From a technical
standpoint, this would mean removing the campaign and built-in
singleplayer mode completely. It can be re-added later by integrating a
local server, but from a coding standpoint, it would make things easier
to focus on multiplayer first and get everything running there.

Then, the GUI. It has be updated to a more modern system. I'm thinking
of CEGUI, although I admit I have never done anything with it myself. It
seems to be a good choice, and it plays well together with Ogre. (I
know, Z-Buffer hacks et al are currently in place; more on that later).
I found evidence of somebody trying this port already two years ago, but
apparently the efforts were abandoned. If someone could point me to the
reasons why, please don't hesitate.

On to gameplay changes. I am inclined to remove some of the realism,
sorry =).
The biggest change concerns the realistic distances between and sizes of
objects in a star system. The velocities needed for traveling between
objects and maneuvering around are so many orders of magnitude apart
that a player doing one thing will hardly notice a player doing the
other thing. (300m/s vs. 97c).
Sizes of objects and distances should be changed to bring these
velocities to at most one order of magnitude from each other. This
should also eliminate the need for special tricks to handle these
distances in the rendering pipeline.

As as side note, I also don't mind having the "flying stars" effect,
even if there is no such thing. It gives a sense of speed and makes
space flight more interesting.

So far I have just skipped over the code, to get a general idea of its
structure and to fix some things to get it to compile.
I have noticed a lot of things that would benefit from a general
clean-up and I guess while making the changes outlined above, lots of
that will have to be addressed first.
This is not meant in a bad way; the fact is, that many things have been
done by many different people, and considering the number of
refactorings that every part must have gone through over the years, it
is suprisingly clean.

I know all of this is a massive undertaking, and I really don't know if
I can pull it off, but I like a good challenge. I don't want to get
anyones hopes up, so I will be working locally and maybe publish it if
and when I have some success.

So, I guess what I really wanted to say with this monologue is: Wish me
luck and if you can provide me with any pointers to anything that might
help, please do.

Kind regards,
	Cornelius

Re: [Vegastrike-devel] Proposal: Open Game Lounge System / Community

[Sven P. <kal...@gm...>]

Hi Dave!

Dave Cridland wrote:
> On Wed Apr  8 12:33:31 2009, Sven Pfaller wrote:
>> The vision is an open, cross-platform game lounge system, used to play
>> online with people from around the world, browsing through and easily
>> joining multiplayer games. Its core elements will be:
>>
>>  * a set of open standard protocols describing the communication between
>> a game-lounge-server, a game-server and a game-client
>>  * an open API for games implementing these protocols
>>  * a game-lounge-server including community features (user-database,
>> statistics, chatting, etc.)
>>  * a game-browser
> 
> Sounds like a job for XMPP - I know there's some people in the XSF quite
> interested in building things like this, and the vast majority of it we
> have already.

Nice. I'll see if I can contact someone from the XSF.

We'll discuss the posibility of using XMPP as protocol on the Glou
mailinglist. Maybe you'd like to join?

https://lists.sourceforge.net/lists/listinfo/glou-devel

What exactly do you mean by "the vast majority of it we have already"?
The vast majority of a XMPP game-protocol?

Thank you for your input :) .

> Dave.

Best regards
- Sven

[Vegastrike-devel] (no subject)

[Dave C. <da...@cr...>]

On Wed Apr  8 12:33:31 2009, Sven Pfaller wrote:
> The vision is an open, cross-platform game lounge system, used to  
> play
> online with people from around the world, browsing through and  
> easily
> joining multiplayer games. Its core elements will be:
> 
>  * a set of open standard protocols describing the communication  
> between
> a game-lounge-server, a game-server and a game-client
>  * an open API for games implementing these protocols
>  * a game-lounge-server including community features (user-database,
> statistics, chatting, etc.)
>  * a game-browser

Sounds like a job for XMPP - I know there's some people in the XSF  
quite interested in building things like this, and the vast majority  
of it we have already.

Dave.
-- 
Dave Cridland - mailto:da...@cr... - xmpp:dw...@da...
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

[Vegastrike-devel] Proposal: Open Game Lounge System / Community

[Sven P. <kal...@gm...>]

Hello everyone!

Today I'd like to present you an idea that is centered around free and
open source games. It was born via a discussion on mailinglists and
IRC-channels between people from Freedesktop-Games, freegamedev.net and
GGZ [1] in the course of the last two weeks.

The vision is an open, cross-platform game lounge system, used to play
online with people from around the world, browsing through and easily
joining multiplayer games. Its core elements will be:

 * a set of open standard protocols describing the communication between
a game-lounge-server, a game-server and a game-client
 * an open API for games implementing these protocols
 * a game-lounge-server including community features (user-database,
statistics, chatting, etc.)
 * a game-browser

The main goal of the project is to make the creation of an open
community for games and gamers eventually possible.

Most of you will certainly know services like Gamespy, Steam,
Windows-Live, Xfire and possibly more. It seems like there currently is
no free and open alternative to them, and this project aims to change
that. Maybe we can change that together.

A more detailed overview of how the system could look like, what the
goals and what the benefits are is available at:
http://apps.sourceforge.net/mediawiki/glou/index.php?title=ProjectOverview

Just a word about what this project is not: it is not a replacement for
your current lobby-system. It may be if you want, but it will be created
in a way that it can be used in parallel to your own system.

I have sent this mail (or forum-post, wherever you read it) to the most
influential [2] open source games. You can see a complete list here:
http://apps.sourceforge.net/mediawiki/glou/index.php?title=Projects

Ideally this project will be a cooperation between the major open source
games out there. But that's for you to decide. I invite you, game
developers and people interested in open source games, to the Glou (=
Game LOUnge) mailinglist, a place to join the efforts and discuss how
this project should look like. You can join the mailinglist here:
http://lists.sourceforge.net/lists/listinfo/glou-devel

To hear from you would be great. As a starting point it would be
interesting to know...
 * what features the lounge system definitely should have
 * what features the current lobby system of your game has
 * if you feel the need for an open gaming community
 * if you would use the system in your game if it is done "the right way"
 * and what you think about the idea in general

For now that's everything. Thank you all for your attention and patience
:) .
Hopefully we'll see each other on the mailinglist to shape the future of
this project together.

Best regards
- Sven Pfaller (aka Noya)

[1] http://freedesktop.org/wiki/Games
    http://wiki.freegamedev.net
    http://www.ggzgamingzone.org
[2] This is obviously subjective. Feel free to contact projects that may
be missing and add them to the list.

[Vegastrike-devel] Hi there,

[<get...@gm...>]

I think not much help I can offer being a Perl hacker (not knowing
C++/C enough), but if my knowledge can somehow be integrated, drop a
mail.
With Perl it is fast to write parts that need little speed - esp. those
concerning user action, eg. dialogs, maps, file processing (regexp),
also C/C++ codes can interact with Perl (as with Python).
Sure, Perl is a dependency, but for Linux Perl is a second language
(with Python, probably), so it is problem for those on MS or Mac
platforms.
Anyway, if idea comes, happy to help.

With regards,
salmonix

Re: [Vegastrike-devel] Pause button

[Patrick H. <ac...@us...>]

If you are in flight, the way to pause the game is by hitting either the 
"pause" key, or if that does not work, use the vertical bar 
(shift-backslash).
I believe that still works in 0.5.0 though I don't think I have tested 
it recently.

You'll probably get more responses if you ask at 
http://vegastrike.sourceforge.net/forums/

-Patrick

Ronen Khazin wrote:
> There should be an option to pause the game, so that people can pause
> the game, go somewhere or something, come back, and continue.
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Vegastrike-devel mailing list
> Veg...@li...
> https://lists.sourceforge.net/lists/listinfo/vegastrike-devel
>   

[Vegastrike-devel] Pause button

[Ronen K. <red...@gm...>]

There should be an option to pause the game, so that people can pause
the game, go somewhere or something, come back, and continue.

Re: [Vegastrike-devel] Is vegastrike supposed to work for windows 98?

[Markus S. <mar...@we...>]

| Date: Tue, 29 Jul 2008 20:59:49 +0200
| From: "Markus Selve" <mar...@we...>
| Subject: [Vegastrike-devel] Is vegastrike supposed to work for windows
| 98?
| To: <veg...@li...>
| Message-ID: <000c01c8f1ad$b31fc8a0$6280fea9@marvin>
| Content-Type: text/plain; charset="iso-8859-1"
|
...
Thanks to Claudio Freire.  He advised me to install a new video driver.  That
was the solution.

Markus.

Re: [Vegastrike-devel] Is vegastrike supposed to work for windows?

[Markus S. <mar...@we...>]

 Date: Tue, 29 Jul 2008 20:59:49 +0200
| From: "Markus Selve" <mar...@we...>
| Subject: [Vegastrike-devel] Is vegastrike supposed to work for windows
| 98?
| To: <veg...@li...>
| Message-ID: <000c01c8f1ad$b31fc8a0$6280fea9@marvin>
| Content-Type: text/plain; charset="iso-8859-1"
|
...
|
| I'm attaching stderr.txt and stdout.txt .

Oops, the mailing list is deleting attachments.  So here are stderr.txt and
stdout.txt copied into the mail body:

stderr.txt:

GOT SUBDIR ARG =
Found data in ..
Using D:\bin\Vegastrike\Vega Strike\Vegastrike-0.5.0 as data directory
USING HOMEDIR : D:\bin\Vegastrike\Vega Strike\Vegastrike-0.5.0/.vegastrike-0.5.0
As the home directory
CONFIGFILE - No config found in home : D:\bin\Vegastrike\Vega
Strike\Vegastrike-0.5.0/.vegastrike-0.5.0/vegastrike.config
CONFIGFILE - No home config file found, using datadir config file :
D:\bin\Vegastrike\Vega Strike\Vegastrike-0.5.0/vegastrike.config
MISSION_NAME is empty using : main_menu.mission
'import site' failed; use -v for traceback
running import sys
print sys.path
sys.path = [r"D:\bin\Vegastrike\Vega
Strike\Vegastrike-0.5.0\modules\builtin",r"D:\bin\Vegastrike\Vega
Strike\Vegastrike-0.5.0\modules",r"D:\bin\Vegastrike\Vega
Strike\Vegastrike-0.5.0\bases"]
testing VS randomrunning import sys
print sys.path
OpenGL Extensions supported: GL_ARB_multitexture GL_EXT_abgr GL_EXT_bgra
GL_EXT_clip_volume_hint GL_EXT_compiled_vertex_array GL_EXT_fog_coord
GL_EXT_packed_pixels GL_EXT_point_parameters GL_EXT_secondary_color
GL_EXT_separate_specular_color GL_EXT_stencil_wrap GL_EXT_texture_env_add
GL_EXT_texture_env_combine GL_EXT_texture_object GL_EXT_vertex_array
GL_EXT_vertex_weighting GL_KTX_buffer_region GL_NV_fog_distance
GL_NV_texgen_reflection GL_NV_texture_env_combine4 GL_SGIS_multitexture
GL_WIN_swap_hint WGL_EXT_swap_control
OpenGL::GL_EXT_compiled_vertex_array unsupported
OpenGL::Accurate Fog Distance supported
OpenGL::Generic Texture Compression unsupported
OpenGL::S3TC Texture Compression unsupported
OpenGL::Multitexture supported (2 units)
OpenGL::TextureCubeMapExt unsupported
OpenGL::S3TC Texture Clamp-to-Edge unsupported
OpenGL::S3TC Texture Clamp-to-Border unsupported
OpenGL::EXTColorTable unsupported


stdout.txt:

Windows version 4 10
Vega Strike
See http://www.gnu.org/copyleft/gpl.html for license details.

Using .vegastrike-0.5.0 as the home directory
Found MODDIR = D:\bin\Vegastrike\Vega Strike\Vegastrike-0.5.0/mods
DATADIR - No datadir specified in config file, using ; D:\bin\Vegastrike\Vega
Strike\Vegastrike-0.5.0
SIMULATION_ATOM: 0.15
['D:\\BIN\\VEGASTRIKE\\VEGA STRIKE\\VEGASTRIKE-0.5.0\\BIN\\PYTHON25.zip',
'.\\DLLs', '.\\lib', '.\\lib\\plat-win', '.\\lib\\lib-tk',
'D:\\BIN\\VEGASTRIKE\\VEGA STRIKE\\VEGASTRIKE-0.5.0\\BIN']
['D:\\bin\\Vegastrike\\Vega Strike\\Vegastrike-0.5.0\\modules\\builtin',
'D:\\bin\\Vegastrike\\Vega Strike\\Vegastrike-0.5.0\\modules',
'D:\\bin\\Vegastrike\\Vega Strike\\Vegastrike-0.5.0\\bases']

[Vegastrike-devel] Is vegastrike supposed to work for windows 98?

[Markus S. <mar...@we...>]

Hello,

according to the project page in sourceforge.net vegastrike also list Windows 98
as a possible operating system.

When I try to start it, I get an error message about an illegal access:

VEGASTRIKE verursachte einen Fehler durch eine ungültige Seite
in Modul NVOPENGL.DLL bei 0167:6959e6e8.
Register:
EAX=00002601 CS=0167 EIP=6959e6e8 EFLGS=00010246
EBX=00000008 SS=016f ESP=013cf1ac EBP=00000de1
ECX=0121d7f8 DS=016f ESI=0121d7f8 FS=127f
EDX=00000009 ES=016f EDI=00000000 GS=0000
Bytes bei CS:EIP:
89 43 0c 89 47 14 e9 83 02 00 00 8b 44 24 34 8b
Stapelwerte:
78eb12fc 78eb0e94 ffffffff 00000003 0000000c 0121d7f8 6957145b 6962f214 00000003
695be983 6959ea02 00000de1 00002800 013cf1f0 006a4dea 00000de1

I'm attaching stderr.txt and stdout.txt .

Regards,
Markus.