raceintospace-developer Mailing List for Race Into Space

Hello,

Anyone cares to provide the recently added missStep.dat referenced from future.c?
Do we have a repository for datafiles somewhere?

Regards,
-- 
Krzysztof Kościuszkiewicz
Skype: dr.vee,  Gadu: 111851,  Jabber: ko...@ja...
"Simplicity is the ultimate sophistication" -- Leonardo da Vinci

Moving discussion from the "General discussion" forum on sourceforge.

The following functions do the trick:

options.c:setup_options():336 <- this is called from main
options.c:read_config_file():184 <- this is called from setup_options
options.c:write_default_config():260 <- this is called if read_config_file fails

The options has type game_options, and the type is declared in options.h

The config file parsing is driven by the table config_strings that is defined
in options.c:85.

These functions have been around since 0.3 or so, so it's not possible
you don't have them/they do not work for you in either linux or windows
(unless something is buggy, of course). In the latter case please bump up
debug level and check what happens during startup.

Best regards,
-- 
Krzysztof Kościuszkiewicz
Skype: dr.vee,  Gadu: 111851,  Jabber: ko...@ja...
"Simplicity is the ultimate sophistication" -- Leonardo da Vinci

On Mon, Jun 22, 2009 at 05:53:42PM -0700, Eric Conrad wrote:

> Sorry for the late reply...  I have a question for you.  What compiler was
> being used for this?  I'm wondering if these errors I was having might be
> related to that...

Mingw32 in cross-compilation configuration, ie. the compiler was built
to run on linux and generate object code for windows.

Regards,
-- 
Krzysztof Kościuszkiewicz
"Simplicity is the ultimate sophistication" -- Leonardo da Vinci

Sorry for the late reply...  I have a question for you.  What compiler was
being used for this?  I'm wondering if these errors I was having might be
related to that...

2008/8/1 Krzysztof Kościuszkiewicz <k.k...@gm...>

> On Thu, Jul 31, 2008 at 10:19:05AM +0100, Krzysztof Kościuszkiewicz wrote:
>
> > Make sure "DIR" is defined somewhere. I believe it is a macro.
> >
> > From race.h:
> > > /* Define to 1 if you have the <dirent.h> header file, and it defines
> `DIR'. */
> > > #define HAVE_DIRENT_H 1
> >
> > If find youreself struggling with that code please find a way how to:
> >
> >  * open directories
> >  * read entries from directories
> >  * close directories
> >
> > on the Windows system (possibly in a simplest way).
>
> One should be able to get dirent.h for Windows.  For
> example, see http://en.wikipedia.org/wiki/Dirent.h and
> http://poli.cs.vsb.cz/c/help/dir0.htm
>
> That will allow you to leave fs.c untouched and progress in building the
> software.
>
> Eric, can you please keep a journal of what steps were tried/successful
> in getting RISP to compile on Windows? This will help future developers.
>
> Regards,
> --
> Krzysztof Kościuszkiewicz
> Skype: dr.vee,  Gadu: 111851,  Jabber: ko...@ja...
> "Simplicity is the ultimate sophistication" -- Leonardo da Vinci
>

Hi All,

I think we have enough bugfixes since 0.4.6 to mandate 0.4.7
release... I'm still discussing some endianness-related bugs with Ramsay
who reported build and runtime errors on PPC platform. As soon as he
confirms that my patches work for him, I'm ready to roll out the 0.4.7
for win32.

Can other devs confirm that the current CVS version works fine on other
architectures/systems? (modulo PPC and other big endian archs, see
above).

If I remember correctly, last time Pace was doing Fedora RPM builds and
Will took care of MacOS packages - do you have some time to make sure that
everything builds fine and prepare binary packages for Linux and MacOS?

Regards,
-- 
Krzysztof Kościuszkiewicz
Skype: dr.vee,  Gadu: 111851,  Jabber: ko...@ja...
"Simplicity is the ultimate sophistication" -- Leonardo da Vinci

On Thu, Jul 31, 2008 at 10:19:05AM +0100, Krzysztof Kościuszkiewicz wrote:

> Make sure "DIR" is defined somewhere. I believe it is a macro.
> 
> From race.h:
> > /* Define to 1 if you have the <dirent.h> header file, and it defines `DIR'. */
> > #define HAVE_DIRENT_H 1
> 
> If find youreself struggling with that code please find a way how to:
> 
>  * open directories
>  * read entries from directories
>  * close directories
> 
> on the Windows system (possibly in a simplest way).

One should be able to get dirent.h for Windows.  For
example, see http://en.wikipedia.org/wiki/Dirent.h and
http://poli.cs.vsb.cz/c/help/dir0.htm

That will allow you to leave fs.c untouched and progress in building the
software.

Eric, can you please keep a journal of what steps were tried/successful
in getting RISP to compile on Windows? This will help future developers.

Regards,
-- 
Krzysztof Kościuszkiewicz
Skype: dr.vee,  Gadu: 111851,  Jabber: ko...@ja...
"Simplicity is the ultimate sophistication" -- Leonardo da Vinci

I'll be sure to place the file in the win32 folder...

On Thu, Jul 31, 2008 at 2:19 AM, Krzysztof Kościuszkiewicz <
k.k...@gm...> wrote:

> On Wed, Jul 30, 2008 at 07:58:16PM -0700, Eric Conrad wrote:
>
> > static DIR *save_dir;
> >
> > 84 C:\RIS\race\os_win32\fs.c expected init-declarator before '*' token \
> > 84 C:\RIS\race\os_win32\fs.c expected `,' or `;' before '*' token
> >
> > Getting those errors for the above line.  Any thoughts?  My online
> searching
> > is fruitless...
>
> Make sure "DIR" is defined somewhere. I believe it is a macro.
>
> From race.h:
> > /* Define to 1 if you have the <dirent.h> header file, and it defines
> `DIR'. */
> > #define HAVE_DIRENT_H 1
>
> If find youreself struggling with that code please find a way how to:
>
>  * open directories
>  * read entries from directories
>  * close directories
>
> on the Windows system (possibly in a simplest way).
>
> Cheers,
> --
> Krzysztof Kościuszkiewicz
> Skype: dr.vee,  Gadu: 111851,  Jabber: ko...@ja...
> "Simplicity is the ultimate sophistication" -- Leonardo da Vinci
>

On Wed, Jul 30, 2008 at 07:58:16PM -0700, Eric Conrad wrote:

> static DIR *save_dir;
> 
> 84 C:\RIS\race\os_win32\fs.c expected init-declarator before '*' token \
> 84 C:\RIS\race\os_win32\fs.c expected `,' or `;' before '*' token
> 
> Getting those errors for the above line.  Any thoughts?  My online searching
> is fruitless...

Make sure "DIR" is defined somewhere. I believe it is a macro.

>From race.h:
> /* Define to 1 if you have the <dirent.h> header file, and it defines `DIR'. */
> #define HAVE_DIRENT_H 1

If find youreself struggling with that code please find a way how to:

 * open directories
 * read entries from directories
 * close directories

on the Windows system (possibly in a simplest way).

Cheers,
-- 
Krzysztof Kościuszkiewicz
Skype: dr.vee,  Gadu: 111851,  Jabber: ko...@ja...
"Simplicity is the ultimate sophistication" -- Leonardo da Vinci

Hey Eric!  I'm glad to hear someone's coming back to Raceintospace after all this time.  I was afraid the game was permanently on hold!  Yes yes please, don't let the project die now.  It's so close to being better than the original.  Say, one of the other programmers has a beta executable for .4.7 which fixes three bugs, including the 900MB bug you mentioned, so you may be able to get a step ahead of where you thought you would.
 
Leon


      

static DIR *save_dir;

84 C:\RIS\race\os_win32\fs.c expected init-declarator before '*' token \
84 C:\RIS\race\os_win32\fs.c expected `,' or `;' before '*' token

Getting those errors for the above line.  Any thoughts?  My online searching
is fruitless...

Thanks,
Eric

2008/7/27 Eric Conrad <ewc...@gm...>

> I'm curious...  Was fc.c created using C++ or C?
>
> 2008/7/27 Eric Conrad <ewc...@gm...>
>
> I've added myself.  I was previously only on the CVS list...
>>
>> After researching that #error command, I realize that I'm getting the
>> error that is defined.  In other words, it's supposed to happen because it
>> can't verify the file system.  Fair enough.  I'm working on it tonight.
>>
>> Thanks for your help.  I'll be asking more I'm sure.
>> Eric
>>
>>
>> On Fri, Jul 25, 2008 at 6:27 PM, Krzysztof Kościuszkiewicz <
>> k.k...@gm...> wrote:
>>
>>> Eric,
>>>
>>> On Fri, Jul 25, 2008 at 06:09:02PM -0700, Eric Conrad wrote:
>>>
>>> > I tried to go to
>>> > http://pleple.ict.pwr.wroc.pl/~files/<http://pleple.ict.pwr.wroc.pl/%7Efiles/>
>>> <http://pleple.ict.pwr.wroc.pl/%7Efiles/>but
>>> > I got the dreaded 404 error.
>>>
>>> Sorry, the correct link is http://pleple.ict.pwr.wroc.pl/~kokr/files/<http://pleple.ict.pwr.wroc.pl/%7Ekokr/files/>
>>>
>>> > The raceintospace-developer...  Is that http://www.raceintospace.org?
>>> > If so, I didn't see a place for notes.  Or are we talking about
>>> > sourceforge?
>>>
>>> We're talking about mailing list here. We have two developer lists:
>>> rac...@li... - for discussions, and
>>> rac...@li... - for notification on commits to
>>> CVS - whenever commit happens, all subscribers get an email with the
>>> summary.
>>>
>>> Whenever you post to one of these addressess, all subscribers will get
>>> your
>>> message. Maybe you're not subscribed to the lists, if so please subscribe
>>> ->
>>> http://sourceforge.net/mail/?group_id=129186
>>>
>>> Cheers,
>>> --
>>> Krzysztof Kościuszkiewicz
>>> Skype: dr.vee,  Gadu: 111851,  Jabber: ko...@ja...
>>> "Simplicity is the ultimate sophistication" -- Leonardo da Vinci
>>>
>>
>>
>

I'm curious...  Was fc.c created using C++ or C?

2008/7/27 Eric Conrad <ewc...@gm...>

> I've added myself.  I was previously only on the CVS list...
>
> After researching that #error command, I realize that I'm getting the error
> that is defined.  In other words, it's supposed to happen because it can't
> verify the file system.  Fair enough.  I'm working on it tonight.
>
> Thanks for your help.  I'll be asking more I'm sure.
> Eric
>
>
> On Fri, Jul 25, 2008 at 6:27 PM, Krzysztof Kościuszkiewicz <
> k.k...@gm...> wrote:
>
>> Eric,
>>
>> On Fri, Jul 25, 2008 at 06:09:02PM -0700, Eric Conrad wrote:
>>
>> > I tried to go to
>> > http://pleple.ict.pwr.wroc.pl/~files/<http://pleple.ict.pwr.wroc.pl/%7Efiles/>
>> <http://pleple.ict.pwr.wroc.pl/%7Efiles/>but
>> > I got the dreaded 404 error.
>>
>> Sorry, the correct link is http://pleple.ict.pwr.wroc.pl/~kokr/files/<http://pleple.ict.pwr.wroc.pl/%7Ekokr/files/>
>>
>> > The raceintospace-developer...  Is that http://www.raceintospace.org?
>> > If so, I didn't see a place for notes.  Or are we talking about
>> > sourceforge?
>>
>> We're talking about mailing list here. We have two developer lists:
>> rac...@li... - for discussions, and
>> rac...@li... - for notification on commits to
>> CVS - whenever commit happens, all subscribers get an email with the
>> summary.
>>
>> Whenever you post to one of these addressess, all subscribers will get
>> your
>> message. Maybe you're not subscribed to the lists, if so please subscribe
>> ->
>> http://sourceforge.net/mail/?group_id=129186
>>
>> Cheers,
>> --
>> Krzysztof Kościuszkiewicz
>> Skype: dr.vee,  Gadu: 111851,  Jabber: ko...@ja...
>> "Simplicity is the ultimate sophistication" -- Leonardo da Vinci
>>
>
>

I've added myself.  I was previously only on the CVS list...

After researching that #error command, I realize that I'm getting the error
that is defined.  In other words, it's supposed to happen because it can't
verify the file system.  Fair enough.  I'm working on it tonight.

Thanks for your help.  I'll be asking more I'm sure.
Eric

On Fri, Jul 25, 2008 at 6:27 PM, Krzysztof Kościuszkiewicz <
k.k...@gm...> wrote:

> Eric,
>
> On Fri, Jul 25, 2008 at 06:09:02PM -0700, Eric Conrad wrote:
>
> > I tried to go to
> > http://pleple.ict.pwr.wroc.pl/~files/<http://pleple.ict.pwr.wroc.pl/%7Efiles/>
> <http://pleple.ict.pwr.wroc.pl/%7Efiles/>but
> > I got the dreaded 404 error.
>
> Sorry, the correct link is http://pleple.ict.pwr.wroc.pl/~kokr/files/<http://pleple.ict.pwr.wroc.pl/%7Ekokr/files/>
>
> > The raceintospace-developer...  Is that http://www.raceintospace.org?
> > If so, I didn't see a place for notes.  Or are we talking about
> > sourceforge?
>
> We're talking about mailing list here. We have two developer lists:
> rac...@li... - for discussions, and
> rac...@li... - for notification on commits to
> CVS - whenever commit happens, all subscribers get an email with the
> summary.
>
> Whenever you post to one of these addressess, all subscribers will get your
> message. Maybe you're not subscribed to the lists, if so please subscribe
> ->
> http://sourceforge.net/mail/?group_id=129186
>
> Cheers,
> --
> Krzysztof Kościuszkiewicz
> Skype: dr.vee,  Gadu: 111851,  Jabber: ko...@ja...
> "Simplicity is the ultimate sophistication" -- Leonardo da Vinci
>

Eric & all,

I'm CC-ing this to raceintospace-developer, so it stays in archive.
Let's keep the discussion there, so others can join it.

On Thu, Jul 24, 2008 at 07:34:05PM -0700, Eric Conrad wrote:

> Yikes.  I had no idea that this hadn't been compiled in Windows
> before.  That's incredible.  Okay, challenge accepted.

It might have been, but I never heard of anyone trying :) It builds fine
using windows version of unix-compatible compiler toolchain (mingw -
minimalist GNU for windows).

> I'll start doing the research to get this working.  I'm not quite sure
> how this is going to work.  It's possible we'll have to seperate the
> Windows and Linux programming files.  It might even be probable, but
> I'll see what I can do.

It would be a good idea to keep changes 1) localized and 2) minimized
:) If needed, you can add files required only by the windows build to
os_win32 subdirectory. Probably you will have to provide a "project"
file for your build environment (compiler) of choice.

If many changes to some existing file are required, then it might be
easier to provide separate, OS-dependant functions in different source
files (say fs_linux.c for linux, fs_windows.c for windows etc)

> Conditional compilation.  I've never heard of that.  Does that mean it
> compiles under different rules with different conditions?  Meaning, compile
> like this in Linux, like that in Windows?  I'll have to look into that.

Conditional compilation depends on the C preprocessor. Say you have code:

  #ifdef CONFIG_BUILD_WIN32
     /* code for windows */
  #else
     /* code for anything else */
  #endif

This is self-explanatory, but you need to define (or not) the
CONFIG_BUILD_WIN32 somewhere. The "configure" script is responsible for
that, and the definitions go to the file "race.h". Once you #include
"race.h", then you have the configuration definitions accessible for
your code.

> I'll keep open communication with you.  Thanks for letting me know
> about some of those bugs.  I know there's people anxious to see them
> fixed.  So if I can compile this, I'll just start testing and see if
> it's worth releasing 0.4.7.

Some time ago I was fixing bugs, and Peyre was doing the
testing. Bugfixes went into CVS, but we have never released
0.4.7. I have some "private" builds for win32 hosted at
http://pleple.ict.pwr.wroc.pl/~files/, these include the bugfixes I
mentioned. So please make sure that bugs you're planning to fix are
still there :)

Regards,
-- 
Krzysztof Kościuszkiewicz
Skype: dr.vee,  Gadu: 111851,  Jabber: ko...@ja...
"Simplicity is the ultimate sophistication" -- Leonardo da Vinci

Hi Eric,

I'm moving the discussion to raceintospace-devel list.

On Wed, Jul 23, 2008 at 07:58:22PM -0700, Eric Conrad wrote:

> I was out for so long, living life.  Kinda strange how life gets in the
> way.  In any case, I'm this close to compiling this thing and looking into
> the code.  The code is a bit advanced for me, so I'll probably be looking
> into the easier bugs (like why does the budget go 900+ around the year
> 1970?).

Good to have you back, Eric. But I believe the "900" bug is fixed in CVS
version.

> I've also seen a lot in vtest.c.  I assumed vtest.c was a test file,
> especially since vtest2.c seems okay.

These don't matter, they're internal test files (if you look at the
Makefile, which shows dependencies and rules how to build the code
you'll see that vtest... are not compiled by default).

> But I'm wondering how I can fix
> these errors in fs.c?  And also has anyone else seen these errors?
> I could fix them, but if we have compiled code in sourceforge, I
> would hate to ad hoc the changes and see progress go backwards.  Any
> thoughts, guys?

The issue is that up to date RISP has been only compiled in linux
environment, and the windows version was cross-compiled (compilator
running on linux, but generating code for windows).  I'll say that again
- nobody (I know) has compiled this game on windows natively (as you're
trying to do). That alone makes it harder for you, one needs to set up
build environment (project) and dependencies, add libraries etc.

Functions in fs.c are responsible for accessing the filesystem. The
operations differ a bit between different systems, so you need to change
that file (possibly using conditional compilation) so it compiles on
Windows and performs the functions required.

Right now the "configure" script is responsible for testing the build
environment - unfortunately it probably won't work on windows right
away, as it requires lot of linux utilities. Depending on commandline
options given to "configure" script it processes Makefile.in and
race.h.in and produces files Makefile and race.h. You can look at
file race.h.in, it contains all preprocessor definitions that will
be produced by configure script. If you make your own copy of race.h
(with proper definitions for windows) then you'll be able to compile
everything. For example if HAVE__MKDIR is defined, then _mkdir(dirname)
function is assumed to be available (I believe this is the case for
windows). You will also have to check for syntax (or replacements) for
opendir() readdir() closedir(), and the struct dirent. These are the
only non-standard functions used in fs.c

If you have further questions please fire them at will ;)

Regards,
-- 
Krzysztof Kościuszkiewicz
Skype: dr.vee,  Gadu: 111851,  Jabber: ko...@ja...
"Simplicity is the ultimate sophistication" -- Leonardo da Vinci

hol...@gm... schrieb:
> As you might have noticed I committed a number of changes today. They
> will allow writing to the screen using Lua.
> The commits I've sent are rather weak. You need to have the Lua in
> ./scripts/menu.lua for it to work and I've used strcpy. I will fix these
> later on but I was too anxious to show this to you.

I did some more fiddling with Lua over the last few days.
The Lua-script will now draw a primitive button just like the c-function
ShBox() [main.c] does.
It does not use the ShBox-function but the underlying gr* functions.

I plan to enhance the example until it can draw the main menu mostly in
Lua. During this quest I stumbled over the "letters.dat" file which
appears to contain graphics for... well... letters.
Is that correct?

With the graphics-interface exposed to Lua I plan to dispatch certain
tasks to Lua. For example I'd love to just command Lua to
'drawSpaceport()' and it will start doing so, picking up the needed
information through get-functions.

The next step would be to open the code up to allow Lua to _change_ that
very data. This will enable real modding capabilities.


Cheers,
Fabian

Hey there!

As you might have noticed I committed a number of changes today. They
will allow writing to the screen using Lua.
The idea was to proof that we can have the graphics implementation in C
and call those functions from Lua to draw stuff.

This will allow the following:
1. Keep performance critical graphics code in C
2. Keep game logic in C
3. Move the View to Lua

It basically comes down to MVC if we do it right. The Model is the
game's logic in C, the View is also C and the Controller is a call to
certain Lua-functions.

The commits I've sent are rather weak. You need to have the Lua in
./scripts/menu.lua for it to work and I've used strcpy. I will fix these
later on but I was too anxious to show this to you.

You will find a text printed on the main menu (new game, ..., exit) if
the compile works for you.

Any comments?


Cheers,
Fabian

Krzysztof Kościuszkiewicz schrieb:
> > [Reasons against sqlite]
> > As much as I don't like XML, I'd rather go for XML than SQL  :)

You are correct indeed. I do see benefits by SQL but I do agree that it
is not the best choice for now.
I did not write and commit for a few days but I was not entirely idle.
I created a version of mission_dat.c that writes XML. I've attached an
example.
Please comment.

> > But If you want to experiment that's something worthwile. I'd love to
> > see a resutl showing that it is a good idea...

Maybe I will try it later.

> > Just my 2 cents,

And they are welcome...


Kind regards,
Fabian


PS: I hate it when I send mail to only one of you and not to the list.
Happens much too often ;-)

In my oppinion such solution is an overkill, that doesn't buy much in
the long run. Database would be justified if there would be the need for
at least parts of ACID. Neither there is a lot of data, nor efficiency
and optimisations matter. And for the sake of Consistency alone it's not
really worth it, I guess.

One advantage (especially with sqlite3) is that one don't have to
mess with files, formats, records etc. But now one has to mess with
SQL! Altering table schema now breaks code in various places (exactly
like in current implementation, less so in OO version).

Another thing is that database like sqlite doesn't really give enough
flexibility with regard to data types and expressiveness. So data
marshalling comes to play, and in (near or far) future massaging game
objects into rows and tables and vice-versa. Of course it can be done,
but thats another layer of glue that somebody would have to write.

Scripting SQL backend would be supposedly easier, but only because of
common interface (that is standarised and already implemented - thats
the plus). Except for that - it's exactly the same like in any other
scenario.

As much as I don't like XML, I'd rather go for XML than SQL :)

But If you want to experiment that's something worthwile. I'd love to
see a resutl showing that it is a good idea...

Just my 2 cents,
-- 
Krzysztof Kościuszkiewicz
Skype: dr.vee,  Gadu: 111851,  Jabber: ko...@ja...
Mobile IRL: +353851383329,  Mobile PL: +48783303040
"Simplicity is the ultimate sophistication" -- Leonardo da Vinci

Hi!

I've not been committing stuff these last few days. This is on the one
hand side due to my workload which leaves close to no time for projects.

On the other, more interesting side I've been conducting a local
experiment. I'm not too far along the way but I like the results already.

My main thought was: "Heck... why are all the data structures so...
basic?" - basic as in... close to assembler.
I figured that it's got to do with the history of the game (lately we've
been talking about XML) but also with the power of the CPUs. It was a
good choice to put things in memory and keep it there.

My thesis is that today's machines can handle some more load and thus
make things easier for us.
I'm trying to use a database engine (in my current experiment it's
sqlite3) to provide input data and hold the current game state.

In my eyes this provides a number of benefits:
- data independent of implementation (no more bit shifting and endianess)

- data structure more flexible (new attributes can easily be added to
the database, alterations are only an UPDATE-statement away)

- data referencing - this is like pointers within a structure
"commenting" on the pointer's target

- referential integrity! data can not easily get mixed up (sqlite does
not provide this atm)

Where would I like to use it?
a) data input like the mission blueprints and their steps or the astro data

b) savegames - they can be tables within the database, each just
pointing to the input structures and correcting/amending them where needed

c) current game status - this can be implemented just the savegames


The last idea would make the integration of scripting languages a lot
easier, provide rather loose coupling and still allow the scripters to
use all data as input and change everything. There may be scripts
generating news under the influence of the average skill of the 'nauts,
or mission success can be influenced by technology not used in the
current mission. A lot of ideas come to mind.

What's the current status?
I'm still working on the basics. Currently I'm entering the mission
blueprints into a sqlite3 database. When I'm done with that I'll go to
the game code and make it use the database instead of the missions.dat
file. This should be transparent.

If this works well I'll go a step further and try to save the actual
mission path with the dice rolls and things like that in the database
(this should come in handy on replays if we decide to go for them).

At that point I'll commit the changes to a new branch so others may
inspect and provide feedback.
I'm not counting on finishing this work earlier than December of this
year though.

I'll try to make it work with sqlite3 as this is a rather easy to use
database engine and it's lightweight. We'll see further on.


Comments are welcome, as usual!

Fabian

I've been wondering for some time why there is so much downloads for
0.4.6 for MacOS and almost none for Windows. Now I know - I forgot
to update the download page on SourceForge - all the people were
downloading 0.4.5 instead <zonk>...

Now it's all fixed and a lesson for the future - platform download pages
do not automatically update themselves with new releases...

Cheers,
-- 
Krzysztof Kościuszkiewicz
Skype: dr.vee,  Gadu: 111851,  Jabber: ko...@ja...
Mobile IRL: +353851383329,  Mobile PL: +48783303040
"Simplicity is the ultimate sophistication" -- Leonardo da Vinci

Hi,

I've been working these lasts days to fully understand how the branching
is done and how these various special symbols should be handled.
I've attached an image that should show you how I think the branching
and so on of mission 32 works. The graphic is completely automatically
created and when this is correct I can clean and commit the code.

If the output looks wrong please point me to the error in the graphic so
I can continue work on that.
This should help me to not only understand the code of the
MissionSteps() etc. but also to come up with a DTD file for mission
definition.

On the image: ellipsoid nodes are pad 0, boxes are pad 1. Black arrows
are the success connections, yellow for MMM or Alt routes and red is the
Dbr or AltD death branching connections.



We shall see ;-)


Cheers,
Fabian

Feel free to include anything in the documentaion that you think will help.

Michael

On 9/25/07, holy_moly <hol...@gm...> wrote:
> Michael McCarty schrieb:
> > See if this helps.  I'll talk you through mission 16...
> >
> > [lots and lots of information]
> >
> > I hope this helps...
>
>
> It does! It's a lot of valuable information and I'm glad this got to the
> mailing list. If you permit I'll the info from it somewhere in the code
> as documentation as there are a lot of exceptions to those rules I think.
>
> In any case: great piece of documentation.
>
> Kind Regards,
> Fabian
>
> PS: Is it just my impression or has this been the most active month for
> the mailing list ever? :D
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> RaceIntoSpace-developer mailing list
> Rac...@li...
> https://lists.sourceforge.net/lists/listinfo/raceintospace-developer
>

Michael McCarty schrieb:
> See if this helps.  I'll talk you through mission 16...
> 
> [lots and lots of information]
>
> I hope this helps...


It does! It's a lot of valuable information and I'm glad this got to the
mailing list. If you permit I'll the info from it somewhere in the code
as documentation as there are a lot of exceptions to those rules I think.

In any case: great piece of documentation.

Kind Regards,
Fabian

PS: Is it just my impression or has this been the most active month for
the mailing list ever? :D

See if this helps.  I'll talk you through mission 16...

Mission Data from the mission_dat.c utility
VA[0][16] = 0x20
VA[1][16] = 0x80
Name[16] = "JT MANNED ORBITAL DOCKING",                    //16
Abbr[16] = "JT ORBITAL-D",         //16
None[16][] = 1,0,1,0,0,1,0,2,
Mis[16][] = "+1ABC+2ABF+1I+2GDE!|",//16
MMM[16][] =    -1,-1,-1, 9, 8, 7,-2,-2,-2,-1,-3, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
Dbr[16][] =  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
mCrew[16] = 3
PC[16][]=  27,18,-1,-1,-1, //16

First the VA stuff is a bitfield for hardware requirements for each
pad, the bits are... CAP,LM,SDM,DMO,EVA,PRO,INT,KIC.  I can't recall
the order but the mission/vab sources can confirm what bit is where...

Name/Abbr are obvious

The None[] structure holds from [][0] to [][7]: Days, Duration,
Docking, EA, LM, Jt Mis, Lunar Mission, and mEq (have to look at the
data.h to check this)

Ok the Mission string...
Mis[16][] = "+1ABC+2ABF+1I+2GDE!|",//16

For reference look up the step letter names in fseq_dat.txt.  They're
also named in main.c under S_Name[].  The fseq_dat.txt file has the
letter and name.  Basically it's A-Za-g with some other symbols that
can be seen in MissionParse() in mc2.c, also MissionSteps() as well.
The '|' is an end of mission on that pad marker (I think).


"+1" on the primary pad
do steps "ABC"
"+2" on the secondary pad"
do steps "ABF"
"+1" on primary pad
do step "I"
"+2" on the secondary pad
do steps "GDE"
with the end of mission being "!".

Looking at the failure/death branching stuff....
MMM[16][] =    -1,-1,-1, 9, 8, 7,-2,-2,-2,-1,-3, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
Dbr[16][] =  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,

Since there are no lunar/lem/eva missions where the crew goes in
different directions we have no death branching values.  But they're
pretty simple, they jump to the step index within Mis[x][index] and
continue the mission from there until the '!'.

Failures are the same way.   When there's a failure that causes a
change of mission step then we just skip ahead or skip into an
alternate mission path, usually seen after the first '!'.

For mission 16...
MMM[16][step] =    -1,-1,-1, 9, 8, 7,-2,-2,-2,-1,-3, 0, 0
basically MMM shows that a failure during steps 0,1,2 is end of
mission, recoverable failure during step 3 branches us to step
9/recovery.  step 4 failure to step 8/reentry, etc...

Step 0 is pad 1, A - launch
Step 1 is pad 1, B - Orb ins burn
Step 2 is pad 1, C - Hardware power on
Step 3 is pad 2, A - launch
Step 4 is pad 2, B - Orb ins burn
Step 5 is pad 2, F - orb act
Step 6 is pad 1, I - docking
Step 7 is pad 2, G - deorbit burn
Step 8 is pad 2, D - reentry
Step 9 is pad 2, E - landing/recovery
Step 10 is pad 2, ! - done

mCrew I think is used during future mission drawing to trigger mission
bubbles for a duration or something like that.

The PC is the prestige that can be earned for this mission.

I hope this helps...

Michael

Michael McCarty schrieb:
> [on mission code]
> I'll try to document a little more of how the mission code works.
> What part is the toughest to understand?  Is it the weird mission
> strings and failure branching or something else? 

I got to understand the missions strings as each being a token
symbolizing one special step (Launch, Orb-Burn, ...) and the various
special tokens.

I'm puzzled about the mission branching but I've only had a few hours to
look at the code so far.

> You'll find the original mission code data in
> old-sources/utils/mission_dat.c.   


> The MMM structure is the failure
> branching where the negative numbers are a specific end of mission
> thing and the positive numbers are the step index to go to when there
> is a failure that can be recovered from.

I'll check that and try to understand it.

> 
> If you you want to toss everything into an XML file this is definately
> the place to start with the Mission structure from that file.


You are so right and that file helped a lot.
I'm currently trying to get a visual of the steps and when I have that I
can get to a) document those structures and b) move them to different
format.

So... great info and lots of fun fiddling around with these files.

Cheers,
Fabian