SpaceSimCentral

a few words to the font i used for the labels, the font is called "Sailer" and it's based on the font of Intellivisions "TRON - Solar Sailer" game. i used different ones before mostly with rounded edges but since every curve needs a lot of tringles to be displayed auch a simple font based on rectangular tiles is much lower in polygon use, each rectangle needs only two triangles to be displayed, and it didn't looks bad - no in fact it looks pretty good and has a fixed with, much better as what we used before when the glyphs stood such close together that it was sometimes very hard to read also stuff like clocks will look better with a monospaced font. further i can tell more exactly how the width will be if i use my auto fontscaler to bound a fontsize to a given space of glyphs in a determined scale.

because Cyrapi means piracy (the ship is loosely based on the design of the "Krait") i drove this further and pirated the FE2 materials (as good as i could) and they turned out pretty good, 16 materials by the way, as if we wouldn't have guessed already that they will be 16.



mostly grey, red, green, yellow or blue scented grey, but i like them, they look so FE2-ish.

then displayed name "Lunar Pod" in the model viewer and on the ship displayed in the main menu is a complete coincidence, totally random, i changed a little the way i randomized them and it turned out that now the random name generation leads to "Lunar Pod", just if one guesses it was forced it isn't.

i really had to laugh when i displayed my shuttle and readed "Lunar Pod" yes that what it is a lunar pod, not much more.

btw you can imagine the sixteen fe2 colors are all based on...
multiples of 16, what i captured wasn't exactly but very soon i noticed that the values are all close to multiples of 16. except the two non-colors white & black. the colors harmonize very well and i already think of something similar, more aren't needed for spaceship and all look very good as hull, most are grey which gives the hull a metallic look in a scent of a color, the only exclusion is the bloodred which is simply 50% red (128), it's surprising how good this simple color looks, mostly it was only used as accent color but i guess the eagle mkiii is sometimes bloodred. for the specular colors i just added "0.5" to each so that it keeps the note likewise for fe2.

the "Native Father" (of the "Cyrapi MKI")

the most saturated blue in the fe2 colorset



more saturation isn't good for shiphulls, the colorset is really very good looking.

due to the very bright texture my old adder has always a very metallic look.

if i'm not wrong this is what i named "blue steel" there is also a green and a yellow scented one but they are very close.



recently i only used it for the FE2 ships and the Cyrapi, but i really like the colorset.
i prefere it to the often to much saturated and to dark random materials of the generic pioneer.

a listing by the nicknames i gave them, though you get an idea what 16 colors they are
brightgrey
darkgrey
copper
sepia (i didn't found a better name for the dark version of copper)
brightgreen
darkgreen
brightblue
darkblue
cyan
blue
greengrey
green
bluesteel
greensteel
tan (turned out to be gold, i gave the names when i wrote down the numbers and i didn't knew exactly how they will look)
darkred

as you see i sorted them (in the table i use) always the bright followed by the darker version, with exception of tan (gold) and bloodred which stand somwhat alone but of course gold harmonizes well with bloodred. i guessed of selecting them in pairs (of even & odd numbers) but as it turned out i haven't to because how i randomized the selection it turned out to be mostly following this rule. mostly is better as always. it uses to select a darker and a brighter one, not always of the same color but at least a bright and a dark one, that's very well.

FE2 or not, i started first with a own colorset, is better as completly random.

in future i will create a special set for fighters with mostly green & brown colors and one with more agresive colors for anything else as fighters. but as you know rules are only valid due to exceptions.

a few words to the buildings.
when i started to adapt my FFED3D buildings i thought of using the same positioning as it's in FE2/FFE. the buildings are centered on the most far left side corner if you view them from front this leads to that they will never be on the exact opposite side when they get rotated and this looks very good in FE2 +--+ | | +----+ 0--+ | | +----0 0----+ | | +--0 +----+ | | +--+






but unfortunately i forgot that due to this some will vanish almost complete in a hill if the are rotated "wrong", means the pivot is on the flank and depending on how it's rotated the building will be either inside or outside of the hill.

unfortunately i had to trash this idea.

overall i would still prefere something made of larger city quarters, two things are in the way, mostly the terrain.

to much code hm? ah it's just code because of the schemas which i made using glyphs, but to display it right it must be a monospaced font like for the code.

in general i like this type of "needleprinter" or typewriter graphics, and yes it had it's revival already. * * / /
/ / / 4-TRIS / +-+ +-+ |o| |o| | |++++++++++++| | |o| |o| | | __ | | |o| / |o| | | |JZ| | |
@@@@@@@@@@@@@@@@@@@@ by Joseph Zbiciak







this one is designed for the "LTO Flash!" a Intellivision Flash ROM which will display manuals (apart from the main task to store all the roms as binary images) in a resolution of 20 rows and 12 lines, which fits to a NTSC tube TV's resolution of 352×240.

a quite differnt type of "CGI"

to some old is just old - to me it's vintage and precious.

one who understands why Tetris is such a long time runner will create better games, i'm convinced about that.

today i was looking for industrial building textures (if i wouldn't be such a lazy ass we have a lot of modern industrial buildings in Wattwil). However, i stumbled over Flightsimulator and how they generate buildings, generate one must say and it's something very obvious. Buildings are background art and doesn't need to be detailed, in general a cube with a texture on each side. The cool thing is that they even dont need to build the buildings, the system is also obvious, you have uniform tiled texturemaps and just say no.xxx is the front face, the front face itself is a quad - nothing else. I guess right now with the mapper function, if i extend that a little, something similar is easy possible, one would just have to tell which sections of the map you like to use for which viewplane and enter the size of the building you like to have, the output will be the finished building.

sidetrip, one was asking for slanted roofs (they turned out very funny), yeah it's possible but well this makes such a mapper very complex if i can even rotate the viewplane and the face, the face is less a problem as to respect that in the mapper, fixed not as much if i tell all slanted roofs have this or a short table of angles, but if i like to rotate free it's a brainfucker to respect that (i'm up to, it just didn't works yet as i expect, the goal is a real use of the projection vector so you can enter i.e v(deg_to_rad(30),1,0) and the mapping will be in this angle, recently my mapper only supports integer vectors, in other terms the three basic viewplanes (6, negative numbers are respected to flip the texture, left is the a little complicated thing to rotate a texture that "up" in the texture becomes left or right, i would need an additional vector for this but this again makes the function call more complex, but if you make a map you can respect this that you can't rotate the projection in this way and rotate the respective texture on the map you create).

if all would be set up perfect one could make a "for" (for 1, #bldtexmaps do) routine which outputs generated buildings in masses based on uniform tiled texturemaps. the only work left would be to assemble the texture maps by a given scheme. it won't have to be a map for variuos bld's like in FS, one bld per map would be fine as well.

generated buildings
next
generated space ships?

OK no this goes to far, i'm happy if i can put together one random assembled ship.

looks like my texturemapper still needs to be moderated, you know me im a "prinzipienreiter" someone who cares a lot (we care a lot ...) aboout the basic understanding of a topic, it's something this button presser generation leaks strongly of.

i found a very deep explanation to 3D view and UV mapping in "Google Books", for those who like to get deeper knowledge about this as just to fiddle around with a software which won't tell you the rules that stand behind.



however i did that in advance all myself and to create something like a texturemapper i had to know how the tard works. most i knew already but there was still some questions i couldn't have answered before i made some test models. the starting point for my texmapper was Tom "noflag" Morton's (noflag is very important to me ) "cuboid" function. I extended this function to a textured cuboid which will be textured automatically from all sides with the same texture (instead of a lousy diagonal projection which is still handy in some cases).

remember this tard is all out of my shitty brain, i have no web at home where i could have referred to something like the above link. +---+---+ +------ / + + + +-----+ +-----+ +------ +-----+ | | / | /| / | | | | | | | | +---- / | / | /___ +-----+ +-----+ +---- +-----+ | | / | / | / | | | | | +------ / | | / | | +------ | =================================================================================== THIS IS SUCH AN IMPORTANT FUNCTION THAT I DECIDED TO PUT IT IN A SEPERATE FILE (should have done this a long time ago)

INPUT
-----

- position & size of the geometry on which the texture will be projected on
- projection = view plane - side from which you look at the geometry, v(0,1,0) = top (bottom), v(0,0,1) = back (front), v(1,0,0) = right side (left side)
- divisor, correctional vector either to repeat a texture i.e. v(1.5,1,1) to tile it 1.5 times along "x", or to adjust the result if the size doesn't exactly fits
OUTPUT
------

a table which contains the three vectors for the texture projection
why didn't use the texture() function rightaway?
just because
just because it allows to store the vectors as a variable and
reuse them in the script if needed and foremost this allows manual tuning and if i
output the fished call for the texture function you can't do such.

USAGE
----- +----------------------------------------------------------------------------------------+ | | | local front = texmapper( position, size, v(0,0,1) ) | | texture( 'texturepath', front[1], front[2], front[3] ) | | | +----------------------------------------------------------------------------------------+
THEORY
------
a texture is always 1 in relation to the geometries dimensions. to calcultae the factor
to scale a geometry on any texture no matter what size or aspect it has we have to divide
1 with the dimensions of the geometry we like to project the texture on, resp. project the
mesh on the plane of view).
this wil strech a texture sometimes so much it turns out quite ugly
to keep a texture in it's aspect & size (repetive use of the texture) we must recompensate
this default behaviour by multiplying the resulting scale with the models dimension
so it turns back to the original size in relation to the texture.
the use varies, often you simply like to project atexture on a couple of geometries.

SCHEMA
------

Geometry (righthanded): +y | | | front/back | side 0---------- +x / / top/bottom / +z
Texture plane (righthanded): +V +---------+ UV max | | | | | | | | UV min 0---------+ +U

though....
one likes to map a geometry on a texture map which contains different textures for
the model(s).

TEXTURE DIMENSIONS
------------------

if you have a special texture map or need
to project the mesh on a given section in the texture you need to precalculate
the correctiomnal values for the position of the mesh and its size in relation
to the textures dimensions.
i didn't liked to implment this function in the mapper, it's fine for 'everyday use'



it's a quite simpler explanation as to read a book, of course you won't have deep understing after my explanation but it will make you clear why certain things are as they are.

btw, it's possible to use this function also for texture maps which contain different textures for various parts/viewplanes. i wasn't sure how and if when i wrote it and wrote also a second function the "texture calculator" it didn't turned out well and thus i returned to my mapper an i experienced it's suitable also for this task.

i didn't expect that the interest will be big in this but i'm very proud of what i elaborated myself.

finally a picture which i already posted (but i unfortunately made a mistake with the labelling, at 6:00 am after a 24h session your brain starts to get very tired)



i guess the picture tells more as a thousend words you can lose about this topic.

yes, i remember one link per per post else it has to be moderated, ok.


except that i created the bunch of shuttles i did some work to the lmr functions and it gets easier step by step. finally i achieved it to make a texturing function, it's not perfect and still you need to edit the output of it especially if you like to map the geometry in a certain section of the texture (map).

but it's already cool and i should have written this a long time ago, it's a very useful function, you no longer have to fiddle around emdless until you find especially the proper scale, the positioning is somewhat rough, for a simple mapping it's ok but if you measure a texture and use the "UV" data it multiplies small errors to big ones.

to reach this i started with the cuboid function and used it to find out how it can work and how the UV projection is for a righthanded model system (remember i have no web at home, so no help from any wiki or else, this is all my personal work) +---+---+ +------ / + + + +-----+ +-----+ +------ +-----+ | | / | /| / | | | | | | | | +---- / | / | /___ +-----+ +-----+ +---- +-----+ | | / | / | / | | | | | +------ / | | / | | +------ | =================================================================================== THIS IS SUCH AN IMPORTANT FUNCTION THAT I DECIDED TO PUT IT IN A SEPERATE FILE (should have done this a long time ago)

INPUT
-----

- position & size of the geometry on which the texture will be projected on
- projection = projection vector - side from which you look at the geometry, v(0,1,0) = top (bottom), v(0,0,1) = back (front), v(1,0,0) = right side (left side)
- divisor, correctional vector either to repeat a texture i.e. v(1.5,1,1) to tile it 1.5 times along "x", or to adjust the result if the size doesn't exactly fits
OUTPUT
------

a table which contains the four vectors for the texture projection
example
why didn't use the texture() function rightaway?
just because
just because it allows to store the vectors as a variable and
reuse them in the script if needed further and this is most important you can trim the result
which is unfortunately needed if you use a texturemap divided in sections for parts/viewplanes.

USAGE
----- +----------------------------------------------------------------------------------------+ | | | local front = texmapper( position, size, v(0,0,1) ) | | texture( 'texturepath', front[1], front[2], front[3] ) | | | | check the test model to understand how to use the functions results | | | +----------------------------------------------------------------------------------------+
THEORY
------
a texture is always 1 in relation to the geometries dimensions. to calcultae the factor
to scale a geometry on any texture no matter what size or aspect it has we have to divide
1 with the dimensions of the geometry we like to project the texture on, resp. project the
mesh on the plane of view).
this wil strech a texture sometimes so much it turns out quite ugly
to keep a texture in it's aspect & size (repetive use of the texture) we must recompensate
this default behaviour by multiplying the resulting scale with the models dimension
so it turns back to the original size in relation to the texture.
the use varies, often you simply like to project atexture on a couple of geometries.

SCHEMA
------

Geometry (righthanded): +y | | | front/back | side 0---------- +x / / top/bottom / +z
Viewplane (righthanded): +V +---------+ UV max | | | | | | | | UV min 0---------+ +U

though....
one likes to map a geometry on a texture map which contains different textures for
the model(s).

TEXTURE DIMENSIONS
------------------

if you have a special texture map or need
to project the mesh on a given section in the texture you need to precalculate
the correctiomnal values for the position of the mesh and its size in relation
to the textures dimensions.
i didn't liked to implment this function in the mapper, it's fine for 'everyday use'
--]]


yep you can learn something here



isn't that a nice textured cube?

as one can see pioneer makes a fraction of an failure when projecting a texture, you can see here a very small border from the black groundlines to the next repetion ( a reason why i made this one sided border because i noticed this slight failure before). as larger the object is and as more the texture will probably streched as larger this error will be - unfortunately.

Wonderful work here Gernot. It's nice too to see the Shuttle be much more useful for a change and the Kestrel looks really great in the colour too!

i agree the FE2 colorset fits very well but will be reserved for the FE2/FFE ships.

i've spent 2 days creating a 256 colors palette (table) - which i can't use
i can use it partwisely or as template, anyway 256 materials no one needs.

the base was the "atari 256" a very nice palette, quite natural looking with less saturated colors, i like it and even mom said "hey they look nice" (much better as the windows or mac standard 256 colors).
i needed two days to fit the colors to multiples of 8 of 256 to 1 (because we use in pioneer values from 0 to 1 for r,g,b)

the palette isn't exactly "atari256" anymore i had to fit them to multiples of 8 (wanted to because it will alter them slightly) and changed a few because i liked to have a the best possible color gradient i could reach and i guess i reached it well. like i said i can use the paltte
i elaborated for other things to (like converting pictures as wallpapers for the Amiga OS3 using a standard palette or similar tasks). it has no big use for pioneer but it was at least a good job i've made.



yes, it was the biggest fault of the factory which educated me as textiletechnician not to engage me as a colorist (they preferred to take a relative of the owner for the job, i'm still somewhat angry about that even if that is 35 years ago). "idiots!" it costed me my carrer as textiltechnician because i lost interest to work for the industry and moved to the construction site, mostly because of the salary and because they put an uneducated in a position where someone like me would belong, education and talent, i earned nearly double as an unskilled on the construction site as i earned as educated in my branch (no responsability as unskilled worker), fault no. 2 of them, from my pov. in general nepotism is something which has cost us to much in the past, wrong ppl in the wrong place, "dead wood".

something different



doesn't that looks like a stormtrooper riding a bearded giant?
happened under circumstance with a seamless texture i made of a simple piece of rock.

To me it looks like one of the flying monkeys from The Wizard of Oz riding a jet ski.

i like the shuttles much. you have to manage fuelconsumption and time well for distances above 300 AU, it's a task of its own. the autopilot isn't a big help even once you have earned enough to buy one you need to load extra fuel but not to much else you will be to slow. you can use the autopilot set the course to target, then you will have to accelerate manually until you used up a little more as half of the fuel you loaded totally (you need less to break because you have only about half of the mass). after you passed the "zenith" of your flight you can re engage the autopilot and let it break and finally dock. sometimes i miss the point even if i should know when to stop it can easy take 15 minutes until you reached the "zenith" (or point of no return) and sometimes i oversleep it simply, sometimes i forgot to reload the fuel and engage the "stardreamer" and miss the right point, a couple of AU to late it might be to late to brake and you won't have fuel reserves to make a lot of maneuvres if you overshoot. overall it needs experience, load to much fuel and you're to slow and will need to much time and even to much fuel, you need to find the right balance for the ship, distance, time.

you need many such "boring" transports to earn enough for a ship with a hyperdrive and then probably a pirate will vaporate you, the will await you more often as i remembered from std. pioneer. i changed them from "slow transporters" to "agressive fighters" and spawn them near to you so you will have to fight.

certainly one likes to get to sol - good luck!

i already think about a hidden mission for that, something special you will earn if you reached this goal e.g. some points which will release further missions or a permission for something which was restricted (one could even just play a fanfare - ta taa ).
fortunately you can depend on a co-pilot this will help a lot, i'm still clumsy in fighting down enemy ships. fortunately you can escape them often without to battle and if it's a scout mission which spawns an enemy you can most probably trick him by simply rough landing your ship or get very close to the surface, he will crash.
similar to "FE2" i also like to prevent that you can enter certain systems, in my case "alpha centauri" is such a system which is ment to enter it only with permission, it's already an "enclave" and i "only" have to find a way to respect such, similar could be done with any of the factions or at least some of them. many starting locations are already the home system of a faction this i already said i like to get in future from the table of factions and you will be probably bound to this faction except for the independent, federal, imperial & corporated until you reached a certain goal. i.e. some scout missions end already in a different system as you contracted for the mission, this could be extended to if you successfully transferred the data to the client you will earn the permission for a faction - sometimes, i don't like to tell the player which mission that will be, this should be hidden and randomly, if you reached it certainly you will be told that you reached it and of course it should be reflected in your profile which permissions you obtained. it could also be a taxi mission and because you contracted with this or that client you could gain or lose something. attractive ones like in FFE, makes you rich very quick but will prevent you from something which appears later. all should be as much random as possible so that unlike in FFE you won't know in advance which client/mission even if you play it for a 2nd time, you shouldn't exactly know what awaits you. with the "gelios", recently i renamed this beast to "shyrkay", i still have something in mind, i like spawn them at least in the orbit of gas giants what i like to do with them is open, the idea is that you can hunt them but will be fined in some way for doing so or vice versa gain something or both an advantage/disadvantage so you won't know exactly if it's good or not to hunt them, something like whaling in space, could be fined i.e in well policed systems while other systems will even pay for hunting them "charged for the crime of space whaling" . one could prevent the player to enter i.e. the federation until you did something special to get rid of this criminal record, even this should change from game to game, if i fine you "forever" no one will hunt them at all, but if it's open if you can get rid of the criminal record and the restriction it will be interesting again. this is all future music, recently i'm still creating models and didn't work to much on the mission scripts, this exceeds a little my capabiities, resp. i have to learn a lot. but at least i know what i like to reach and it gets step by step a little clearer how to make of this still bareboned game something which can be attractive to play.

dammit yes, we have the factions and military we just have to do something with that.

The "big burn" method, that takes me back Gernot. I used this method all the time in FE2. Was pretty much essential if you had a mission to Alpha Centauri! Using just the autopilot would take far too long.

yes it comes close to this with the exception that there is no getting around this method at beginning of the game. or yes there is a getting around start at "Sol", but you will earn only little money at Sol which means it will take years to get an autopilot and "decades" to get the money for a better ship. to gain 20'000 bucks with a profit of 25 to 100 credits each run won't get you far. systems like "Alpha Centauri" which is again a triple system and a distance of 500AU between the stations will offer you around 500 bucks and more each run.

you are truely a nobody, a "jameson".
like to do some scout missions, to make some extra credits?
you will have to decide to buy an autopilot with your first hard earned money or a radar mapper.

this makes the start to a game without that i had to change a lot of things, i only fitted walterars missions to the posible large distances. the taxi stuff i still didn't solved, i like to have interplanetary taxi missions, so that the "sightseeining boat" makes some sense even if such is in reality out of question, to enjoy a space flight while you meet on the leisure deck and drink some syntherol while you visit mars.

unfortunately the bulletin board is still quickly filled with missions in populated systems with many spaceports. i did my best to remove them earlier, they are removed now after roundabout half of the mission durance, also depending on the urgency, urgent missions will be removed after 1/3 of the durance. perhaps i have to make this even tighter because there is even no way to finish a low urgency mission already after 1/3 of the suggested durance. in very wide systems above 1000AU the missions will stay for many months (up to three and more for scout missions) this fills the bb quite easy with "junk". to restrict that by a sort of limit i didn't find a good option, this will mean that you probably have to wait very long for a mission you can contract to which suits to your lousy ship. some locations might have only three spaceports and one is on a planet with low density, once i stated in such a system and had already to wait almost a year until one appeared to the station which was farthest away from me, on the return i hadn't wait so long, there was only one spaceport in this corner of the system and three in the other. missions which last only a day will be removed after 12 hours, sometimes they get removed this fast you won't have time to stop the stardreamer before it's removed, even if i limited the shortest time to 24hrs. this was needed because i count in days and the logarithm turns "1" to a negative fraction of "1", even if i remove the key signature it will be only a fraction of a day. of course one or two hrs is enough to fly from London to New York, but like i said they will be removed to quick to react on them. the logarithm is needed to respect that i need relatively longer per AU for a distance of 10AU as i need for >100AU or 1000AU. i use a estimated middle of 300000000000 meters per day which is in other terms ~2AU/day. if you lower this you can make it harder or vice versa easier. perhaps it would make sense instead to divide the traveltime to days to do it vice versa to multiply the suggested mission durance to hours, in this way the logarithm will never output negative values and the curve is probably better and even more acute for long distances. i'm not very good when it comes to using a logarithm, in fact it was pretty the first time i used one at all and i'm sure it could be used better if i.e. TomM would do it or guide me through that.

on the other hand i'm satisfied, it does what i expect of it to lower the mission durance more as longer the distance is. maybe a table would be better as to use a logarithm in this way i could control the resulting curve better.

i guess i wrote this already we have multiple systems in pioneer with up to 1500AU, or to say it right this was the widest system i have visited so far i don't know if there is a limit to that, neither i know if we can count such still as multiple star system. it's the problem we have already with "alpha Centauri" is it or is it not? the distance is extreme and it's impossible even in many decades to recognize a movement resp. an orbit of proxima around alpha.

for at least one multiple system i discovered a whole subsystem passing through the giant main star, there couldn't be such a thing it's a impossibilty. the FE2 like structing of them at all is out of the question but ok for a game.
obviousely you get no mass reading for the small companion in this example, not to guess about its planets. however it's sad i couldn't engage the stardreamer because i would have liked to make a clip of the situation when the subsystem passes through the main star and leaves it without to get a scratch from that, in fact it would simply be vaporized or assimilated by the main star, not so in pioneer.

what i wonder at all, does anybody except lunatic gernot have ever explored the outer rim of the explored space? you find many exceptions there, extreme wide systems, contact binaries and even this very strange system.

it was a good idea to start at the outer rim it's also part of the fun. i debated this when we decided to make the galaxy as big as it is in reality, "do you ever will fly this far out? do you still know where you are?" most won't fly this far off to even reach one of the 99 (in my case 150) generated factions, mostly they are far from Sol and coincidentially "150" turned out that at least some was in reach if you start at Sol or any of our common 3 factions. but since you are on the outer rim you will or like to return to sector "0,0,0".

a clip of the WIP