After a year of not speaking, CVS finally gave me a big wet lickery kiss and we are talking!
Now that it is working, I noticed that the non-Gemini sectors were pulled, the notes saying they do not work. Which part does not work?
The only problem I can see is there is no consistency between the actual directory structure and the referring directory structure in the system files. Once I monkey with that, I can get around.
I did notice that the non-Gemini system files look more complicated than the Gemini sector files do. Does that complicatedness have to do with the 'big planet' thing I read about not too long ago (but cannot find it again)?
-thehawk
Non-Gemini Sectors
-
thehawk
- Merchant
- Posts: 39
- Joined: Tue Mar 22, 2005 1:52 am
- Contact:
-
thehawk
- Merchant
- Posts: 39
- Joined: Tue Mar 22, 2005 1:52 am
- Contact:
More on Non-Gemini Sectors
In poking around some more, it looks like there are at least three 'templates' that were used to write the system files. Personally, I think would be easier to spot a problem if they all have the same layout. Is there a listing somewhere I missed that tells what the markup tags are and what they do? Most of what I have seen makes sense, but there are some contradictions between files that I would like to clear up.
On auto-generated systems, the ones I have been to in Vega seem to work alright, specifically as in, there correct jump points are created with the system. The ones in Sol almost always have just the jump point I came in on. How does the random generator work? Is there a different codeset somewhere for Vega than for Sol? The only place I could find to look was wcuniverse.xml, and it seems to be correct (at least for the systems I looked at).
Is it desired to have all of the systems soft-coded at some point in the future, or is it more desirable to leave some number of them random, only soft-coding certain special ones? If the desire is to have them all soft-coded, I can start creating a framework of systems (to include jump points, a place to refuel, and not a whole lot else) to allow getting from point A to all of the point Bs, then someone can come along later and populate the systems properly.
-thehawk
On auto-generated systems, the ones I have been to in Vega seem to work alright, specifically as in, there correct jump points are created with the system. The ones in Sol almost always have just the jump point I came in on. How does the random generator work? Is there a different codeset somewhere for Vega than for Sol? The only place I could find to look was wcuniverse.xml, and it seems to be correct (at least for the systems I looked at).
Is it desired to have all of the systems soft-coded at some point in the future, or is it more desirable to leave some number of them random, only soft-coding certain special ones? If the desire is to have them all soft-coded, I can start creating a framework of systems (to include jump points, a place to refuel, and not a whole lot else) to allow getting from point A to all of the point Bs, then someone can come along later and populate the systems properly.
-thehawk
-
thehawk
- Merchant
- Posts: 39
- Joined: Tue Mar 22, 2005 1:52 am
- Contact:
No, but I could throw up what I know here, a little later in the cycle, after I get home.
I also have what I think are fixed system files, but have not gotten any responses as to what I should do with them, and whether or not my fixes are indeed correct.
Those I can find a space to put them so's you can grab them.
-thehawk
I also have what I think are fixed system files, but have not gotten any responses as to what I should do with them, and whether or not my fixes are indeed correct.
Those I can find a space to put them so's you can grab them.
-thehawk
-
hellcatv
- Developer
- Posts: 3980
- Joined: Fri Jan 03, 2003 4:53 am
- Location: Stanford, CA
- Contact:
-
crouton
- Bounty Hunter
- Posts: 161
- Joined: Wed Mar 23, 2005 11:03 pm
-
thehawk
- Merchant
- Posts: 39
- Joined: Tue Mar 22, 2005 1:52 am
- Contact:
The story so far...
I have mostly done some poking around and pulling things apart. I have asked some questions, but am guessing I have not found quite the right place to ask, as I have not yet gotten much in the way of answers. I did discover another forum today at work that I will stick a post in, and see what comes of that. I will forward anything else I find in your direction too.
There is not a whole lot here, but it is a start. Most of what is here is my speculation, and has not been confirmed anywhere. Yet. Oh, and one word of warning. I am verbose when I write (anyone know how to put a sentient back into brief?)
-------------------
A few of my definitions
In all cases, ./ equates to the privateer root directory.
'Soft-coded' refers to things that are put in configuration files of some sort (*.csv, *.system, *.xml, you get the idea), and are easily changed.
'Hard-coded' refers to things that are put into *.py or binary (*.dll, *.exe) files, and are not easily changed.
-------------------
Other useful stuff
I changed my jump fuel to something like one hundred so that I could test jump nodes without having to stop all the time. If you want information on this for the same purposes, lemmie know (it is not the sort of something I feel quite right posting for the whole world to see).
I am using this map: [ home.comcast.net/~thehawk-news/wcu ] as my reference for jump nodes and such. I cannot guarantee one hundred percent accuracy, but I think it is pretty close. Any changes, suggestions, questions, comments, bitches, gripes, moans, complaints, please PM me or something with.
-------------------
First thing, there are two places where system files go:
./sectors/
This is where the scripted systems go, divided up by sector.
./.privateer100/sectors/wcuniverse.xml/
This is where the auto-generated systems go. Ideally (at least in my thoughts on things) this directory will always be empty, because all of the systems will be scripted. The engine only puts systems in here when it cannot find a system to jump to in the reference directory structure in the system file you are currently in.
All systems have to be in the ./wc_universe.xml file, but I have yet to determine why, except maybe for the auto-generating process?
I think part about the reference directory structure is what caused the problems with the non-Gemini systems. They all read 'sectorname_sector/system' (it already knows to start looking in ./sectors), while the actual directory structure is just './sectors/sectorname'. This meant that when the engine went to look for a scripted file, it did not find one, so created a new one, hence the reason the Sol system was empty (it was being told to look for './sectors/sol_sector' instead of where things really lived, in './sectors/sol' (Sol system is gorgeous, by the way, for those who have not yet visited the real one). It does not look like the wc_universe.xml has anything to do with making that part work, because all the references are correct there. Heh. Is that horse dead enough?
The auto-generated stuff -seems- to work alright in Vega sector (at least, the few systems I have played with), but the ones in Sol are just all kinds of honked up. Most of the systems I have jumped into have only the one jump point (the one I just came thru) and maybe some asteroids. I do not know enough to know where the problem is, but it is almost like there is a different codeset somewhere that defines how the systems are autocreated. Have not found this file, except it may be the wc_universe.xml that does it (have not looked close enough at it yet).
How does the engine know what items to put into a randomly generated system? My Arcturus system kept random generating with no Weslyn jump point, even tho it is listed as supposed to have one in wcuniverse.xml. I thought it might have had to do with the planets variable, but I do not see one (in the top area, where they are all defined?) for jump points. But then again, I do not see any for bases either, and I have had a mining base auto-generate in the same system.
It looks like at least three people (possibly more) wrote system files, or the templates for creating said system files. The Gemini files are the cleanest (and they all work), but there is a lot of information not included in them. I think one of the more important things to do is going to be to enforce consistancy among those files. That way you can tell almost at a glance (a lot of the time) where the problem is. You will notice in some of the system files that someone ran off with all the LF/CR type characters. Those should be put back too, if it is not going to honk anything up (it should not, they look like pretty standard *.xml type documents).
Two things I -do- like about the Gemini system files are the use of _ characters for spaces, so the names do not all run together, and the spacing (tho the spacing seems a little wonky to me, also not what I would call consistant).
Does it matter what order the entries in the system file are in? This is another 'I do not know yet'. It would make sense to put the planets together, the jump nodes together, and so on, again for ease of finding things when you are looking thru several files for the same sort of thing.
Another place consistancy looks important is the capitalisation in the directory structure. Windows does not care about capitalisation, but *Nix generally does. I do not know if it cares for WCU or not, but, again, (if you cannot tell) I like consistancy.
In some of the other system files, it looks like there are some that are <PLANET.. >..</PLANET> and some that are <PLANET.. />. Are these the same? Does it make a difference which is used? I dunno. I have not yet seen any documentation that tells what all the markup tags and attributes are and what they do, but I am still looking.
-Is- it desired to have all of the systems soft-coded at some point in the future, or is it more desirable to leave some number of them random, only soft-coding certain special ones? If the desire is to have them all soft-coded, we can start creating a framework of systems (to include jump points, a place to refuel, and not a whole lot else) to allow getting from point A to all of the point Bs, then someone can come along later and populate the systems properly.
The jump 'bubbles' are not consistant from one place to another. All the Gemini ones look to be radius 256, while most of the others seem to be in the neighborhood of 100- 140 or so. Heh, well, except the one in the Sirius system leading to the Sol system is absolutely freakin' ginormous (radius 400). Is all of this on purpose, or should there also be more consistancy among the different jump 'bubbles'?
-------------------
My system files. I threw them up at: [ home.comcast.net/~thehawk-news/wcu/wcusystems.html ] I needed to create a few to get to the Sol system, and these I copied from AR-17 and changed the names of everything to work properly for what I needed.
-------------------
That is all I know for now.
-thehawk
I have mostly done some poking around and pulling things apart. I have asked some questions, but am guessing I have not found quite the right place to ask, as I have not yet gotten much in the way of answers. I did discover another forum today at work that I will stick a post in, and see what comes of that. I will forward anything else I find in your direction too.
There is not a whole lot here, but it is a start. Most of what is here is my speculation, and has not been confirmed anywhere. Yet. Oh, and one word of warning. I am verbose when I write (anyone know how to put a sentient back into brief?)
-------------------
A few of my definitions
In all cases, ./ equates to the privateer root directory.
'Soft-coded' refers to things that are put in configuration files of some sort (*.csv, *.system, *.xml, you get the idea), and are easily changed.
'Hard-coded' refers to things that are put into *.py or binary (*.dll, *.exe) files, and are not easily changed.
-------------------
Other useful stuff
I changed my jump fuel to something like one hundred so that I could test jump nodes without having to stop all the time. If you want information on this for the same purposes, lemmie know (it is not the sort of something I feel quite right posting for the whole world to see).
I am using this map: [ home.comcast.net/~thehawk-news/wcu ] as my reference for jump nodes and such. I cannot guarantee one hundred percent accuracy, but I think it is pretty close. Any changes, suggestions, questions, comments, bitches, gripes, moans, complaints, please PM me or something with.
-------------------
First thing, there are two places where system files go:
./sectors/
This is where the scripted systems go, divided up by sector.
./.privateer100/sectors/wcuniverse.xml/
This is where the auto-generated systems go. Ideally (at least in my thoughts on things) this directory will always be empty, because all of the systems will be scripted. The engine only puts systems in here when it cannot find a system to jump to in the reference directory structure in the system file you are currently in.
All systems have to be in the ./wc_universe.xml file, but I have yet to determine why, except maybe for the auto-generating process?
I think part about the reference directory structure is what caused the problems with the non-Gemini systems. They all read 'sectorname_sector/system' (it already knows to start looking in ./sectors), while the actual directory structure is just './sectors/sectorname'. This meant that when the engine went to look for a scripted file, it did not find one, so created a new one, hence the reason the Sol system was empty (it was being told to look for './sectors/sol_sector' instead of where things really lived, in './sectors/sol' (Sol system is gorgeous, by the way, for those who have not yet visited the real one). It does not look like the wc_universe.xml has anything to do with making that part work, because all the references are correct there. Heh. Is that horse dead enough?
The auto-generated stuff -seems- to work alright in Vega sector (at least, the few systems I have played with), but the ones in Sol are just all kinds of honked up. Most of the systems I have jumped into have only the one jump point (the one I just came thru) and maybe some asteroids. I do not know enough to know where the problem is, but it is almost like there is a different codeset somewhere that defines how the systems are autocreated. Have not found this file, except it may be the wc_universe.xml that does it (have not looked close enough at it yet).
How does the engine know what items to put into a randomly generated system? My Arcturus system kept random generating with no Weslyn jump point, even tho it is listed as supposed to have one in wcuniverse.xml. I thought it might have had to do with the planets variable, but I do not see one (in the top area, where they are all defined?) for jump points. But then again, I do not see any for bases either, and I have had a mining base auto-generate in the same system.
It looks like at least three people (possibly more) wrote system files, or the templates for creating said system files. The Gemini files are the cleanest (and they all work), but there is a lot of information not included in them. I think one of the more important things to do is going to be to enforce consistancy among those files. That way you can tell almost at a glance (a lot of the time) where the problem is. You will notice in some of the system files that someone ran off with all the LF/CR type characters. Those should be put back too, if it is not going to honk anything up (it should not, they look like pretty standard *.xml type documents).
Two things I -do- like about the Gemini system files are the use of _ characters for spaces, so the names do not all run together, and the spacing (tho the spacing seems a little wonky to me, also not what I would call consistant).
Does it matter what order the entries in the system file are in? This is another 'I do not know yet'. It would make sense to put the planets together, the jump nodes together, and so on, again for ease of finding things when you are looking thru several files for the same sort of thing.
Another place consistancy looks important is the capitalisation in the directory structure. Windows does not care about capitalisation, but *Nix generally does. I do not know if it cares for WCU or not, but, again, (if you cannot tell) I like consistancy.
In some of the other system files, it looks like there are some that are <PLANET.. >..</PLANET> and some that are <PLANET.. />. Are these the same? Does it make a difference which is used? I dunno. I have not yet seen any documentation that tells what all the markup tags and attributes are and what they do, but I am still looking.
-Is- it desired to have all of the systems soft-coded at some point in the future, or is it more desirable to leave some number of them random, only soft-coding certain special ones? If the desire is to have them all soft-coded, we can start creating a framework of systems (to include jump points, a place to refuel, and not a whole lot else) to allow getting from point A to all of the point Bs, then someone can come along later and populate the systems properly.
The jump 'bubbles' are not consistant from one place to another. All the Gemini ones look to be radius 256, while most of the others seem to be in the neighborhood of 100- 140 or so. Heh, well, except the one in the Sirius system leading to the Sol system is absolutely freakin' ginormous (radius 400). Is all of this on purpose, or should there also be more consistancy among the different jump 'bubbles'?
-------------------
My system files. I threw them up at: [ home.comcast.net/~thehawk-news/wcu/wcusystems.html ] I needed to create a few to get to the Sol system, and these I copied from AR-17 and changed the names of everything to work properly for what I needed.
-------------------
That is all I know for now.
-thehawk
-
crouton
- Bounty Hunter
- Posts: 161
- Joined: Wed Mar 23, 2005 11:03 pm
Wow, hawk. Some good stuff in there. I'll take a more detailed look at work.
I did notice the use of the privateer100 directory.. is that not the save game directory? I don't know the use of putting systems in there, except that it might be where you currently are (so it doesn't have to auto-generate them again??)
I did notice the use of the privateer100 directory.. is that not the save game directory? I don't know the use of putting systems in there, except that it might be where you currently are (so it doesn't have to auto-generate them again??)
-
thehawk
- Merchant
- Posts: 39
- Joined: Tue Mar 22, 2005 1:52 am
- Contact:
The ./privateer100 directory has a ton of stuff in it, but this reminds me of something I thought about at some point, but did not include in the manifesto up there.
So far as I can tell, when you jump from a system, the engine looks at your current system file to check the reference path ( ./sectors/sectorname/systemname.system) to the system you are jumping to.
Next it looks at that path to see if in fact there is a system with the specified name there. If it does not find one, it looks (at ./privateer100/sectors/wcuniverse.xml/sectorname/systemname.system) to see if one has been created previously. If it does not find one, then it creates the necessary system.
In this way, you will have your static (coded) systems, and your dynamic (auto-generated) systems, but the dynamic systems will remain static for the duration of a game. Actually, the way it looks, is that it would remain static for an entire installation, until the file(s) are deleted.
-thehawk
So far as I can tell, when you jump from a system, the engine looks at your current system file to check the reference path ( ./sectors/sectorname/systemname.system) to the system you are jumping to.
Next it looks at that path to see if in fact there is a system with the specified name there. If it does not find one, it looks (at ./privateer100/sectors/wcuniverse.xml/sectorname/systemname.system) to see if one has been created previously. If it does not find one, then it creates the necessary system.
In this way, you will have your static (coded) systems, and your dynamic (auto-generated) systems, but the dynamic systems will remain static for the duration of a game. Actually, the way it looks, is that it would remain static for an entire installation, until the file(s) are deleted.
-thehawk
-
hellcatv
- Developer
- Posts: 3980
- Joined: Fri Jan 03, 2003 4:53 am
- Location: Stanford, CA
- Contact:
hmm not sure why it might not generate the appropriate jump point...
it certainly doesn't generate unless a file is there
it always generates a return route for you when you jump in...
the code to generate looks at wcuniverse.xml to find out the planets that should be there
also we have a few very carefully made sol.system files ... for vegastrike itself--would be trivial to paste 'em in to wcu
it certainly doesn't generate unless a file is there
it always generates a return route for you when you jump in...
the code to generate looks at wcuniverse.xml to find out the planets that should be there
also we have a few very carefully made sol.system files ... for vegastrike itself--would be trivial to paste 'em in to wcu
Vega Strike Lead Developer
http://vegastrike.sourceforge.net/
http://vegastrike.sourceforge.net/
-
thehawk
- Merchant
- Posts: 39
- Joined: Tue Mar 22, 2005 1:52 am
- Contact:
I do not know enough to know that that means. Which file has to be there for it to generate?hellcatv wrote:hmm not sure why it might not generate the appropriate jump point...
it certainly doesn't generate unless a file is there
So it sounds like the wcuniverse.xml is there to tell the auto-generator what to do when it creates a system file? Does it do anything else? It does not seem to care if I rename the file to something else and fly around. In fact, when I jump to a system that does not already exist, I get the same thing: an empty system with only the jump point I came thru in it. It is almost like nothing is looking at the wcuniverse.xml when it goes to create the missing system files.it always generates a return route for you when you jump in...
the code to generate looks at wcuniverse.xml to find out the planets that should be there
Heh. Oh, yea, it looks like it also has to do with the sector maps in the nav computer.
I dunno where the sol system file currently in use came from, but it is really nice. *grins* You just have to build a way to get there.also we have a few very carefully made sol.system files ... for vegastrike itself--would be trivial to paste 'em in to wcu
-thehawk
Systems *chuckles* Engineer
-
thehawk
- Merchant
- Posts: 39
- Joined: Tue Mar 22, 2005 1:52 am
- Contact:
-
spiritplumber
- Developer
- Posts: 1831
- Joined: Mon Mar 07, 2005 10:33 pm
- Contact:
go ahead and play with it please!-
thehawk
- Merchant
- Posts: 39
- Joined: Tue Mar 22, 2005 1:52 am
- Contact:
Heh, I have no idea where to start with the auto-gen thing. It seems to work correctly in some places, but not others, and I am not sure why. Hey Crouton, have you..
..
*thinks*
*a light suddenly goes on*
Unless it does not work in the Sol sector because of the references written the way they are to not only a -path- that does not exist ( ./sectors/sectorname_sector ) but also to a sector that (for all intents and purposes of the auto-gen thing) does not exist in wcuniverse.xml ! So, in theory, if we clean up all the current *.system files to point to the right places at their jump points, then all of the auto-gen stuff -should- work correctly, right?
I will have to test this and see what happens.
You guys are -brilliant-! Thank you so much!
-thehawk
Wannabe WCU Systems Engineer
..
*thinks*
*a light suddenly goes on*
Unless it does not work in the Sol sector because of the references written the way they are to not only a -path- that does not exist ( ./sectors/sectorname_sector ) but also to a sector that (for all intents and purposes of the auto-gen thing) does not exist in wcuniverse.xml ! So, in theory, if we clean up all the current *.system files to point to the right places at their jump points, then all of the auto-gen stuff -should- work correctly, right?
I will have to test this and see what happens.
You guys are -brilliant-! Thank you so much!
-thehawk
Wannabe WCU Systems Engineer
-
hellcatv
- Developer
- Posts: 3980
- Joined: Fri Jan 03, 2003 4:53 am
- Location: Stanford, CA
- Contact:
yes---wcuniverse.xml and .system need to match up perfectly otherwise badness ensues
Vega Strike Lead Developer
http://vegastrike.sourceforge.net/
http://vegastrike.sourceforge.net/
-
thehawk
- Merchant
- Posts: 39
- Joined: Tue Mar 22, 2005 1:52 am
- Contact:
-
spiritplumber
- Developer
- Posts: 1831
- Joined: Mon Mar 07, 2005 10:33 pm
- Contact:
-
thehawk
- Merchant
- Posts: 39
- Joined: Tue Mar 22, 2005 1:52 am
- Contact:
-
thehawk
- Merchant
- Posts: 39
- Joined: Tue Mar 22, 2005 1:52 am
- Contact:
I think I cleaned up some of the nastier stuff, and sent the files to Spiritplumber for a look-see: checked the jump nodes in the Gemini sector for spacing and proper other-end-pointedness, checked the reference path in the Sol and Enigma sector files, and cleaned up some of the LF/CR stuff in two or three of the files.I did not do much with the wcuniverse.xml.
-thehawk
-thehawk
-
spiritplumber
- Developer
- Posts: 1831
- Joined: Mon Mar 07, 2005 10:33 pm
- Contact:
-
thehawk
- Merchant
- Posts: 39
- Joined: Tue Mar 22, 2005 1:52 am
- Contact: