Page 9 of 14

RE: "Phoenix" (former Sputnik)

Posted: Tue Oct 23, 2018 5:49 am
by Gernot66
and the link to download this tohouwabohou:
[url]https://www.dropbox.com/s/eorl6z5nwjh11b6/Phoenix0.0.4_Pioneer31.zip?dl=0[/url]

RE: "Phoenix" (former Sputnik)

Posted: Tue Oct 23, 2018 8:15 am
by Gernot66
your'e right marcel, it could be as well a jet ski :)

"big burn", in FE2 respectively the CD32 version of you can fool the game if you save to the non-volatile memory of the CD32 (there wasn't any other option in fact except to save a common savegame to ram which will be erased after a reset), complete the mission even if you're to late, save to nv memory, reload, mission successfully completed, while unfortunately you have to approach a second time, the nv savegame saves resp. reloads the state as you enter the system that's also why you complete the mission successfully because you finished the mission but when you load the time is when you entered the system (sometimes it fails but if you restart the game and reload it should work everytime). usually i avoid missions to "alpha centauri" in FE2.
i played FE2 this spring, started a career in both the PC-DOS version and the CD32 version, i prefere the CD32 version, you can't cheat using the "wormhole bug" and most of all you have the "new zz1 navigation aid" whithout that it can get very boring to zoom always to the navigation targets in system view.

"Frontier" is after all this years still a gem. as deeper i get into "pioneer" as more i respect the work of david braben. all the clever solutions packed into "a couple of kbytes" that really overwhelms me.

certain things we can never reach, like the clever arranged cities from city tiles, sometimes buildings get exchanged on a tile and overall it's not possible with a shaded surface like we have in pioneer. in FE2/FFE the cities fly above the real surface but you won't notice this thus you can arrange the tiles, center the buildings on one corner instead to the center and they will appear in a reasonable way when they are rotated. one must have first all this ideas, i just copy them or try to if it's possible.

damned i thought i can copy this for pioneer and recentered all the new buildings to this scheme until i recognized it won't work, either they stand in the air when they are positioned on a hillside or the whole building vanishes in the hill, stupid me i should have known this.

the tiles would be possible if we (i) would pick up s20dan's idea to flatten the terrain for the cities. first i wasn't convinced of this idea but it would be the best way for pioneer, it would allow me to design the cities from larger city tiles instead of the disorderly arranged way (you might remember that i did that once, but it works halfaways for i.e. London, but it won't work for a city which is placed on a spiky asteroid, the whole city would fly above the ground if it would be leveled to the spaceport.

ok, that's something i still like to get solved, outdoor and underground cities, it's stupid to have common buildings like skyscrapers on a planet with no breathable atmosphere, imo they should be seperated, unbedingt! (there is no getting around).

the only other solution would be to get rid of all outdoor stuff, this would make much more sense because we have 1000's of times more hostile worlds as outdoor and "Earth" (or earthlike) is an exception.

pardon me, but sometimes i guess the designers look only at the situation on earth.
but i guess the "standard" is a system and hostile worlds like i selected for my starting locations.

check them out and you know what i mean.

RE: "Phoenix" (former Sputnik)

Posted: Tue Oct 23, 2018 8:46 am
by Gernot66
geraldine,
you will need some patience for the "Sidie" (and the rest of FE2 ships).
i downloaded the recent release and it runs fine on my notebook but i first have to get warm with the changes in pioneer.

it's somehow far easier for me to script a complicated rig as to get into that.
also i still remeber the troubles i had to export animations if they exceed a simple translation rotation (connecting rods problem). i evaded this problem by using .x meshes, but also here, the common blender scripts to export a matrix animation fail. thus i need to install my old blender version because i had i clever scripted exporter for .x meshes which blantantly exported what you see in blender. any else use either "normal keying" or "visual keying" but non of them exports exactly what you see and the animation fails afterwards. if you set the visual keying for especially connectiing rods it mixes all up, that shouldn't be i guess or is a leak of blender, respectively the "advanced" export scripts, shit advanced - "wysiwyg" export exactly what you see this was the right way. unfortunately the old export script won't work for new blender releases.
i miss a lot of things which was very good in blender 1.49, how to create a hose? i've done that before by pressing of a button and even the UV was generated.
there might be a similar script or module for this but now i have to search for every tidbit, in the extended release of 1.49 was all packed in ready to use and also more logical to find. "like to create an object/mesh by a script? look for the script under objects", since 2.x it is i don't know where or you have to start the script from the terminal, very uncomfortable imho.
i think a user won't like to learn how to start a script from a terminal
he will LOVE WYSIWYG press a button and the result is what i expect of by what i see.

as example, before when i leked to create a cylinder i entered the size and divisions before i create the cylinder, logical. now i i have to create the cylinder and enter the divisions and size after it's created, unlogical. it took my a full afternoon only to find where i can enter this, i remembered it's vice versa but i couldn't find that goddamned option anymore it's hidden, unlogical and stupid imho.
likewise the standard to have the "pulldown menus" on the bottom, that's stupid menus belong to the top and not to the bottom who ever had this idea must be an idiot in my opinion, of course i can still have them on top but it isn't the default behave anymore. it's stupid mostly because windows has this strange behave now to show the taskbar even in fullscreen, sometimes it also appears when i play pioneer in fullscreen and instead to press "lower landing gear" i press on something on the taskbar even if it's not visible.

goddamned such can make me very angry it's so stupid and unpractical.
very "useful" if the menu bar of the application is on the bottom, you will constantly click on the taskbar instead to select something from the menu. argh!

reminds me a bit of this:


"new doesn't equals always to better"
most often it's just more complicated, dunno why, developers with no practical experience?
but maybe just to many cooks.

i even don't know if pioneer still supports .x meshes.

RE: "Phoenix" (former Sputnik)

Posted: Tue Oct 23, 2018 9:16 am
by Gernot66
and the scotsman he said "nay" ;)

RE: "Phoenix" (former Sputnik)

Posted: Tue Oct 23, 2018 10:18 am
by Gernot66
a few words to this:
[url]https://www.dropbox.com/s/eorl6z5nwjh11b6/Phoenix0.0.4_Pioneer31.zip?dl=0[/url]

phoenix creates now a own directory in "documents" so it won't conflict anymore with "Pioneer" or any other release of pioneer.

there is a small file "phoenix.sdb", it's a compatibility setting (a patch to be exact) created by
Win10 "Compatibility Toolkit" resp. "Manager" (32bit version for a 32bit application, you would have to download that from MS it's not part of the default installation, the .sdb should even work for the win7/8 compatibility manager if this setting is available, the database is interchangeable. overall it's a to recommend tool for everyone who likes to run old windows applications, it comes with a lot of preset patches and searches for apps when installed the first time and applies the recommended known compatibility setting even for countless games and it allows to play i.e. "SimCopter" on a win10 x64 if it's patched right, thus you won't need any other help and it's 100 times better as to play an old game this way as in a virtual machine).

the only thing it does for phoenix is to center the window if phoenix or the modelviewer runs in windowed mode. unfortunately win10 has this strange behave to open certain windowed applications staggered from "top left" to "bottom right", often the apps window appears in a stupid position half off the screen and especially for the by me often used modelviewer this is very annoying.

the patch is setup also for "pioneer.exe" and recognizes the app simply by it's name (it would be possible to patch a specific version recognized checksum, size, vendor or whatever can be readed out of the file of the app to seperate patches if that is needed).

to apply the patch you will need the "compatibility toolkit" (of course), and to load this database into it. after loading it you only have to tell the toolkit (application manager to be precise) to apply the patch - that's all.

a small but helpful thing especially for retro gamers.
"game crashes because the old style file requester won't work? - this is THE help you need".

i guess these are the most important two things.

i moved all documents to a directory "docs"
in it are some docs to "phoenix" where you wil find additional information to what changed while this is all without any warranty that it is up to date or that i listed all changes i've made.

certain things especially to the vast amount of model functions are explained in the scripts themself.
i need to sort that once, while to just play the game all this isn't of interest.

a last tip:
if you start the game there is apart from the random start location still the location "Sol".
it's not recommended to start at Sol, you will gain very little with deliveries here.
BUT
it's quite easy to change this to your preferred start location.
just open "data/ui/MainMenu.lua"
look out for
local yourpath = fixedpath('Sol')

right above this variable is a table (which you must have seen when you open the file)
named "StartLocations", just enter instead of "Sol" any of the names from the table,

i.e. local yourpath = fixedpath('Achernar')

thats it, now you can start always at Achernar, if you like that.

dunno if i can achieve this but coolest would be of course if you could enter the name in the running games mainmenu, on the other hand you won't know what is possible to enter but of course you would remember which system you liked best to start in.

in future i hope i can use the factions table to generate the start locations table.

if you like to switch between the possible 5 starting ships just leave the game to mainmenu and next start you will have probably a different one, while the shuttles are similar in capacity they only differ in look. the lander offers a little more capacity and the dinghy is the weakest of the five.
the performance is the same for all 5 ships, this i reached with a "thrust calculator" which recently uses the tara (hull mass + fuel mass + standard drive (if it has a hyperdrive)) as base, thus if i enter the tara each ship has empty the same (or any given) thrust. equipped are all 5 the same with the exclusion that it would be possible to mount a gun to the "mining vessel", recently this is not of interest because the mining laser is far to expensive to make any senseful use of it. neither i can fit it to the "mining vessel" as standard equipment, or i won't because this would give you again the possibility to bargain with the equipment and exchange the laser for an autopilot or radar mapper, this i don't want. best would be if i could make the mining laser to a non removable equipment of the ship, this would give the "mining vessel" reasonability.
a sixth shuttle is planned (respectively the dinghy will be probably trashed for this) a "container lifter" but it's still in the dock. of corse capacity and cost will be the same, the container it can lift isn't very large, prob. it will have a little more capacity due to that.

if i remember it right you can fit a couple more of extra passenger cabins to the "sightseeing boat", recently it didn't makes sense without interplanetary taxi missions.

all shuttles, the lander and the dinghy can be overload, they have twice capacity as cargo mass.
this means you can fit i.e. the extra passenger cabins and still keep the cargo capacity it has.
but this has a drawback, the ship can hardly lift off a planets surface and will use much more fuel.

also the rest of the smaller ships have some extra capacity it equals to the standard drives mass, this leaves especially for the fighters like the "rapier" more space for equipment but lowers the performance much if you load additional goods or fit a lot of equipment.
a fighter is a fighter and not ment to carry goods from a to b.

unfortunatly the game shows off the thrust for a ladden ship based on capacity and not on cargo space, this i will have to change in future, cargo space (mass) is what is standard capacity. "total capacity" means overloading the ship. thus the values for a ladden ship don't reflect how the thrust is for the common maximum loaded ship it reflects the thrust for the overloaded ship. but hardly you will overload your shuttle without extra passenger cabins, goods or extra fuel you can load only "cargo mass" what is labelled as "capacity" (minus cargo mass) works only for equipment.
in other terms, the "express shuttle" has 10 tons of cargo space and 20 tons capacity, this means you can load 10 tons of goods or extra fuel but you can still add 10 tons of equipment to it this is what will overload the ship. usually you will have only a autopilot and a radar mapper fitted to the shuttles and them are totally only 2 tons. as more equipment you fit as less good will be the performance except you load less cargo equal to the amount of equipment mass.

the shuttles are exceptions, and there is only one other ship which can be overloaded in such a way, the "shyrka" (former "gelios"). this ship as ship will be probably removed in future, but however i will keep the "animalic" part of the ship for the special purpose of "space whaling".

perhaps one can gain the "shyrka" in future as a space ship as reward for completing a special mission. (prevent the "shyrka's" from beeing hunted? shoot down AI "space whalers"? that would be the right idea).

RE: "Phoenix" (former Sputnik)

Posted: Tue Oct 23, 2018 4:37 pm
by Gernot66
a couple of handy "stapelverarbeitungsdateien" (batch files).

you like to switch between a special fullscreen and a windowed .ini?
then you can put something like this in your "documents/phoenix" (or pioneer) directory and use a shortcut in your games directory to switch between them (assumed you use 7zip and that you put the several pioneer.ini 's in a zipped folder).

"c:program files7-zip7z.exe" e -y "config fs.zip"
for the fullscreen settings or
"c:program files7-zip7z.exe" e -y "config win.zip"
for the special windowed mode settings
they will extract the content of the respective zipped folders.
option "e" is for extract, "-y" means overwrite in quiet mode without asking.

might be you like to empty the model_cache by pressing of a button (especially when you change models often it can stuck and prevent pioneer from running without to tell you a shit what has happened, it's in such a case a quick method to be sure it isn't caused by the cache to simply empty the cache).

del model_cache*.* /q

option /q means quiet, don't show any output.

quick, dirty, but very handy.

the "windowed mode" settings differ in my case mostly for the non-standard resolutions i use for pioneer. my notebook has a resolution of 1366x768 this i use to run it in fullscreen mode. if i like to capture pioneer with either the built in "x-box live" capture device or or with virtual dub i use a resolution of 1152x720 windowed to fit to yt's 720HD mode so the clip won't be streched respectively sized down which lowers the quality much. you could capture very well a fullscreen application using x-box game capture, but it's only to recommend if the fullscreen resolution fits to any of the yt HD resolutions, the next would have a height of 1050.
i said it's a tiny notebook, but it's very good for the exception of the small screen and the extremely limited view angle the screen has, this is what was most critized at the "dell latitude".
low contrast and limited view angle.

wish 'n wash, slap 'n slew?
(i like to do the washmachine boogie with you)
i stripped my long text about the backdraws of a tablet OS.

RE: "Phoenix" (former Sputnik)

Posted: Tue Oct 23, 2018 6:06 pm
by Gernot66
in despite of that i will repeat myself for a n'th time (perhaps someone new drops in and doesn't knows me).
there is a simple reason why i hang to the lmr, it suits me.
it's limited and whatever but it suits gernot, it has even become a part of my identity.
i fell in love with it at first bite and it won't let me go.
i'm aware that i can work much quicker and do much more with any cad software, but it will never mean the same to me.

"phoenix", i guess i chose the right name for this small project of mine i see as honor to Tom Morton, John Jordan and even the not so widely known Theunis de Jong who all made a good job to show us the guts of FE2. (yech, don't show us YOUR guts gernot)



what's the problem with that, fellows?

TomM with his project "Pioneer" inspired so many of us with his work and for this i'm still grateful.

neither i will forget Geraldine who kicked my ass to take a closer look at TomM's Pioneer, since this moment i'm addicted to it.

"Phoenix" already the name is to remind of all that what inspired us lurking around on Frontier forums. (and waiting patiently for E4)

just imagine where we would be without all that, "pioneer" would be still some not well recognized project somewhere on source forge like countless projects on source forge (which in fact are sometimes sleeping beauties who just wait to be kissed by a brave hearted princess or prince).

perhaps even E4 wouldn't have become true without the pressure from the offsprings of FE2/FFE.

in my personal opinion or as i see the progress over the years, perhaps this whole genre of space sims would look quite different without all of us "space sim veterans", developers AND players.
yes ok some idiot had to the job :) if that was me or anyone else doesn't matters to me.

one thing i still wish since we met on frontier forums is to meet all of you in "real life" (eh the terminal is to me as real as, almost as, something many don't understand), i know to me it's out of question at the time, but it's a wish a dream i have.

hmmm. i guess i'm lame, i get always a little jealous if i notice that the atari and intellivision dudes meet so often in the states. they hold their meetings yearly and we know us (and i even them) only from the web. yes it's a matter of the wallet size i know most of us aren't wealthy unlike some of the collectors in the states (with all their freaky and super exclusive collector items). but on the other hand i must say they even spend more money and time for such occasions. i guess some of them even bypass their own family for such, the whole thing of collecting rarities is that important to some, while ok this goes to far.

perhaps, who knows some of us can really meet one day and exchange the memories we have.

(question, what do you think if i start a crowd funding just for such a meeting and no productive thing is their a chance to collect enough money to hold such a meeting and to pay even the travel costs for some of us? i mean the supporters wouldn't have any profit of that. i guess i should try it instead to speculate about it)

RE: "Phoenix" (former Sputnik)

Posted: Wed Oct 24, 2018 12:57 am
by Marcel
Got it running under PlayOnLinux. I get 7-8 fps at the spaceport no matter what resolution I choose. It looks promising. I'll give it a proper test after I finish some Halloween stuff. ;)

RE: "Phoenix" (former Sputnik)

Posted: Wed Oct 24, 2018 8:16 pm
by Gernot66
that's pretty lame 7-8 fps, while i assume it's caused because you run it in some kind of virtual windows (?).

i have no idea about linux, for sure it would be an option to windows but my recent notebook is to tight in space for a second OS that i could promise to compile a linux version in the near future. recently i didn't even compiled the win32 Pioneer i use still as base, this simply because it's not yet needed to reach the goals i have with modeling and scripting around the existing old release. once i'm satisfied with that i can caare again about this task (unfortunately i lost the source i used and worked with from around 2015, the source of alpha31 is still available one thing which hinders me also is that the third party sources for alpha31 are not longer available and what is used for the recent releases won't work for some tidbits and i have to reconstruct it and that's a piece of shit. i know this because i started to compile what i found still on my old machine, which like i said before also exhaustet it's last blue cloud of smoke, that was horrible but it happened now for the third time to me so it starts to get quite common. certainly backupdrives would prevent from such but one must have such a drive first. the HD isn't lost neither of the macbook nor from my old machine but also to recover what is on them i need to invest a little money. really such doesn't worries me anymore "shit happens - let's move on"). Fortunately i copied a lot of games and things to the notenbook before the powersupply brok, i assume it's the powersupply, i'm not sure i didn't opened it yet, but the smell of a burnt large eloctrolyte capacitor is pretty telling that it's the powersupply, assuming this my old machine should still run after fixing it but i lost patience with that and the notebook i use is that good i don't have much interest to fix the old crap. it became to me a waste of time in some way to fiddle around with broken or old hardware, i really like to use a computer and not to fix a broken one, perhaps when i'm in the mood for it, i fixed last year an even older one which i took home, it was left on the streetside so it asked for to be carried home. it was an easy thing to fix it, the processor cooling vent was stucked with dust. but it's besides an even older one as my machine and the powersupply i guess won't work it's a quite weak standard one. if im in the mood and recently i'm not (before i pick up the soldering iron for this task i would build a small composite out for my intellivision, that's more important to have for me and i made some theoretical suggests to that so i like to make proof what i claimed. it's because joe and the rest use a cheap pair of transistors for the purpose. in no way i like to say joe doesn't knows his job, apart from being a machine coder he's also a very good electronics engineer, the "LTO Flash" for my inty is his design, but dammit i guess it was my dead father who whispered in my ear "that isn't suitable for an amplifier it's ment for controllers or logical gates and controllers don't mind about oszillating or noise", the composite out is a sort of amplifier however oszillating of the circuit is to prevent at all cost and murphys law tells "every amplifier tends to oscillate and every oszillator tends to amplify". even the exact type i almost remembered immediatly, it surprised me myself. to invest 1$ more for a transistor isn't much money but it can have a big effect on the result. however i digged through the specifiction tables of the vendor and bingo i was right, theoretically at least).

what did i liked to say? transistors?
no!
back to fps and phoenix.
to be honest i reach also only about 15fps, but my notebook has not a good gpu i can't expect more of it and i guess neither i reach more running the official release, it runs quite good but i haven't yet compared the resulting framerate. pioneer makes the notebook sweat and the vent immediatly starts to go on maximum rpm when i start it. the fps i reach are about the same i reached with my old machine and a cheap gpu (yet another broken thingy and the one i used in the last years was an old one i removed from a piece of junk, but better a cheap graphics card as no graphics card.

but also i can't reach better esults with a thinner phoenix, when i started the project i limited it as much i could, near to no dynamic models, no textures, simple buildings, no pilots or extras like this even the adverts i banned, but the impact on framerate by slowly adding one after the other isn't worth to debate about, some single fps, but reaching a final framerate of 16 or 15 is pretty the same. yes the stations and especially, foremost the cities use a lot of fps. it's quite a riddle to me since it didn't gets much better if i use i.e no textures for the buildings. them are simply to many little buildings i guess and something like my "city tiles test" would probably reach better framerate even if the tiles are larger, but you won't use as many of them to display a reasonable looking city (i will see this project still lurks around on my HD so it won't be a big thing to test it). i assume the lmr uses more power to run but on the other hand all models are cached and they should run as fine as anykind of meshes/models. so said i don't reach much better framerates if i use wavefront objects instead of my scripted geometry, in the end it's pretty the same.

perhaps if i disable the random adverts it will be for some fps better, but don't expect no wonder i assume from your 5-6 to 8-10. i know that they eat up fps. but i re-enabled them and didn't noticed a big impact on my notebook. like i said perhaps from 16 down to 15.

similar settings similar fps, after a quick comparison i have to correct myself 20 to 24 for "Phoenix"
24 to 26 for the recent "Pioneer", settings are high, high, and medium for the cities (i ran it before high for the cities to that's why i reached before only 14 -16).

imho no big difference, and to be honest i expected better results of the recent release, at start i wondered "wow 32 fps!" switched to settings and noticed low, low, low "phew" i thought ;)

i know the lmr is clumsy and i'm aware the 100s of functions (modeling helpers) won't make it better in performance neither my global material tables will help to run it faster (while if i remember that right tables are no big problem, they are cached on the hd and have no big impact on performance).

the city tiles could really help to gain fps, since you could run it at low and still get a large city as result. but there is a design problem with them. they look miserable if the terrain is hilly and horrible if it's a steep mountainside. if something like that should work at all the terrain for the cities must be flattened.

but guessing that i use so many new functions, new model functions, even "evil" global stuff i must say what i reach with the lmr isn't really bad. it has an impact on performance but it's for me not worth to think about to change to something else.

using a middle priced gpu it would certainly easy run at 30fps, guessing of that my notebook isn't ment for gaming purposes. it's just a notebook not even a laptop, if you know what i mean, calculators was almost bigger in the '80s and for sure bigger in the '70s ;) that thing isn't larger as a modern handy, nah ok as a tablet, it almost fits in my pocket.

i could spare most of the new functions for myself, but also to be honest for every function i made i remembered your troubles with the lmr and kept in mind to make it as easy as possible to create models with it, not that i expect that you will, just as a goal.

else i wouldn't have created something like a texturemapper, ok it teached me also many things about U,V, projection i didn't knew so well before, but the idea was really to simplify the model creation with the lmr.

and well
local scale = 1
local radius = 70*scale
local pixels = {25,50,100,0}
local texoffice1 = 'textures/office/office1.png'
local size = v(70,20,50)
--[[
"size" isn't only valid for the projection, as you can see
all vectors refere to this vector, if you change a value here
it will change the whole geometry in its dimensions, since the mapper referes
to the same values it will also keep the texture mapping.
mostly i've done this to fiddle around here with this so you can see
that the mapper is bound to the models extensions
--]]
local diagonal1 = Diagonal[3] -- simple but trustworthy "Diagonal" projection, requested from a table
local diagonal2 = Diagonal[5]

define_model('office1', { info = { scale = scale, lod_pixels = pixels, bounding_radius = radius, materials = {'concrete','aluminium','darkgrey','grey'}, tags = {'city_building'}, }, static = function(lod) local v0 = v(size.x/2,size.y + (size.y/25),size.z/2) --[[ "v0" is in the upper right corner (viewed from front) of the building and equals to the maximum extension of "U" & "V", here it's viewed from the front and the respective section of the texture map is as well right below half of the textures vertical extension thus the front projection hasn't to be moved, it's exactly in midst of the texture map, the building is designed for an easy use of the texturemapper, but if you start in the upper right corner it will always be "v0" which represents maximum "UV" and you can use "v0" for the position vector of the texturemapper. --]] -- building local v1 = mirx(v0) -- with mirx,miry,mirz you can easy flip coordinates local v2 = mirz(v0) local v3 = mirx(v2) local v4 = v(v0.x,size.y/25,v2.z) local v5 = mirx(v4) local v6 = v(v0.x,v4.y,v0.z) local v7 = mirx(v6) -- basement local v8 = v(v0.x,-size.y*2,v0.z) local v9 = mirx(v8) local v10 = v(v0.x,v8.y,v2.z) local v11 = mirx(v10) -- vectors for the cuboid function local cube1 = {v(size.x/4,v2.y,-size.z/4),v(size.x/8,size.y/6.25,size.z/4)} local cube2 = {v(size.x/4,v2.y,size.z/10),v(2,size.y/25,size.z/12.5)} local cube3 = {v(size.x/4,v2.y,size.z/3),v(2,size.y/25,size.z/12.5)} local cube4 = {v(-size.x/8,v2.y,0),v(size.x/8,size.y/6.25,size.z/4)} local front = texmapper(v0,size,v(0,0,1),v(1,-.25,1)) local top = texmapper(v0 + v(0,0,.5),size,v(0,1,0),v(1,1,-.49)) -- "+ 0.5" corrects --shifting of the "wrong" divisor "-.49" instead of "-.50" local side = texmapper(v0 + v(0,size.y*2,0),size,v(1,0,0),v(1,.25,1)) -- size.y*2 --shifts the geometry in the proper section of the map material('concrete') -- preset materials from a table, recognized by their names (name --is given) material('aluminium') material('darkgrey') material('grey') if lod == 1 then use_material('darkgrey') -- lod 1 buildings are visible but untextured thus this dark material end if lod > 1 then --top texture(texoffice1,top[1],top[2],top[3]) -- request values from texmapper output use_material('concrete') end quad(v2,v3,v1,v0) if lod > 1 then --front texture(texoffice1,front[1],front[2],front[3]) texture_glow(texoffice1glow) end quad(v0,v1,v7,v6) quad(v2,v4,v5,v3) if lod > 1 then --side texture(texoffice1,side[1],side[2],side[3]) end quad(v0,v6,v4,v2) quad(v1,v3,v5,v7) texture_glow(nil) if lod > 1 then --basement texture('textures/150.png',diagonal1[1],diagonal1[2],diagonal1[3]) -- request Diagonal projection from global table use_material('grey') --front quad(v6,v7,v9,v8) quad(v4,v10,v11,v5) --side quad(v4,v6,v8,v10) quad(v5,v11,v9,v7) if lod > 2 then -- extras -- cool function to easy texture a cuboid with the same texture from -- all sides, tiling or stretching is controlled with the last vector -- "divisor" texcuboid(cube1[1],cube1[2],'textures/113.png',v(1,.5,2)) texcuboid(cube4[1],cube4[2],'textures/113.png',v(1,.5,2)) if lod > 3 then use_material('aluminium') texture('textures/113.png',diagonal2[1],diagonal2[2],diagonal2[3]) cuboid(cube2[1],cube2[2]) cuboid(cube3[1],cube3[2]) end end end end, dynamic = function(lod) -- ventilator if lod > 3 then call_model('ventilator',v(-size.x/4,size.y +(size.y/25),-size.z/4),v(1,0,0),v(0,1,0),1) call_model('ventilator',v(-size.x/12,size.y +(size.y/25),-size.z/4),v(1,0,0),v(0,1,0),1) end end
})



it can't be much easier as this,
the whole vector listing is based on the size, change any of the size x,y, or z and the whole model will be build and textured reflecting this change.
i'm quite proud of that i can say.

one of the most helpful things i guess are the mirror functions, this let's you write vector listings in "no time", especially for something simple like a building.

the rest is except of the main building (5 quads) and the basement (another 4) all either a model function (cuboid, textured cuboid) or a sub-model of any kind (ventilator).

yes, the ventilators could spare another single fps if disabled ;).

one could create a very very simple building with
texcuboid(v(0,0,0),v(30,10,20),'textures/any.png',v(0.0333,0.1,0.05))
and ready is the textured concrete cube (without any windows, or if the texture has windows on it the roof would have as well because "texcuboid" uses only one texture but maps it from all sides).

and i guess this is worth an impact of a few fps.

RE: "Phoenix" (former Sputnik)

Posted: Thu Oct 25, 2018 12:10 pm
by Marcel
PlayOnLinux is a front end for WINE. WINE Is Not an Emulator, it's a translation layer between Linux and Windows. My graphics card plays the Windows version of Mass Effect very well. I'll look at the PlayOnLinux settings. I may have to add some libraries or something. Looking at that LMR code takes me back to the days when I could get a model into Pioneer. I may try it in Phoenix, who knows? Speaking of old lost files, I had a faction mod that gave different buildings and stations to the different factions. Actually the player would have to load the mod for the faction they were in manually. The Independent faction had two color stations with the colors generated by the station's name.

RE: "Phoenix" (former Sputnik)

Posted: Mon Nov 05, 2018 8:20 pm
by Gernot66
that nice laybird again

yes, phew recently this is a knot i can't solve without to change the source.
of course no problem to generate colours by the label (while evwen here, for ships labels had been disabled in alpha31 for preview and the label won't work for ships to randomize something a mean change of which i... whatever i suspected)
recently i use the ships random material to generate i.e. the "legal name" from (i.e. "flying toaster") or to select materials from a own table of preset materials such as the "fe2materials"

but that's not really what i like to get in the end for the architecture problems, much more as random generated or labelled buildings, even if that would be a nice little extra, i would like to seperate them for hostile and outdoor worlds, you this is something i care about since we started.

if i can't have this, all groundstations will be in the near future the type of sealed stations for hostile worlds even on outdoor planets because it mekes more sense as the outdoor type on a hostile world. a similar thought i have for the buildings itself, "type hostile" will be more reasonable for all as "type outdoor".

stations labels (city name in fact) works also well for a couple of new adverts i've created. i dismissed the random adverts and made them simply changing in a given order (while this didn't saved me a single fps) therefore i added a couple of station different adverts. the initial idea was to label some factories different, but since i can't have this i took the name generation for the a few adverts which will show different company names for each station. i guess that's quite good.

wine isn't an emulator you're right i used it on my macbook with yes even very bad results for pioneer or ffed3d, ffed3d was almost playable but pioneer sucked completely using wine, the framerate was below or around 1 fps, absolutely useless even just to check your work (while ok pioneer runs under osx). it's still a sort of virtual machine the whole environment is solved via replacement libs. it's cool that wine exists at all and besides it's better as any else virtual machine, even windows on windows. you can use wine easy for games but it has some limits.

certainly running a lot of scripted stuff is slowing down any machine, all this nice opportunities we have with such high levelled speechy programing languages are only possible due to the extreme gain of speed in the last decades. interpreters are something worse if one thinks right about, but well i'm not "joe zbiciak" and i will never reach to program in machine code. the world will leak of the "joes" once they are dead, i'm pretty sure.



that looks familiar, no?
i revived my hostile spaceport as scripted geometry, t'was a piece of work especially with the changes in docking anim to respect the leaking capability of geometry flagging for collada, the stations are now bound to which animation stage you are in and it seems i can't release the docking procedure anymore by colliding with a special flagged geometry (complete bullshit in other terms).

well, imho it could had been solved by keeping the flagging, collada is a script and it's quite easy to enter any specific data you will need, that could be even something which could be read only by a certain program and will appear as comment for other programs.

in other terms docking works by autopilot but no manual release of docking procedure, i'm not quite sure what all causes this misbehave but i'm unfortunately bound to stage 2 any else won't work to release the docking procedure for ground stations. (a similar probelm i had with the orbital spacestation that's wha it's still unfinished because the docking sequence is destroyed since the use of miserable collada, just to tell it right. besides AI ships can still hang uselessly in the port but it happened only once in the whole travel back to sol from somewhere of the rim of settled space)

once i even found out that it's even bound to collision mesh size (unscaled!) all this are changes which made me once very angry and they come now to surface one after the other. this i found out by rebuilding the "mars station" type from fe2. it's a very large station and i gave it a small size and scaled it up, i searched and searched for the error why the docking procedure wasn't released until i found out that something is depending on the size of the unscaled collision mesh. if i used the same station unscaled 10 times smaller the sequence worked well. somehow it's also bound to collision mesh size (unscaled!) and/or to bounding radius, they had to find a way to make docking animations possible for collada, that's where this change comes from.

not proper at all, in any case you use flagged geometry for such stuff, just guess of lap's in racing games, it's the same stuff, an invisible special flagged geometry you "collide" with your model and you receive the lap or round time. (sometimes it's solved different but i see such rather as a workaround because of certain leaks, eg for old streets of simcity you simply can use the tile you pass with your car and won't need flagged geometry).

due to the opening and closing (which also leaks still somewhat) of the gate i can't use stage 2 to dock i need it to open the gate (i had similar fuzz with the orbital station). i could use stage one but then it takes 5 to 10 minutes to open the gate (durance of stage 1 is the docking timout).

if i guess that all such has worked before....

however, i'm even not sure if my not working manual release is caused by the half sized "hostile port" (scaled up twice, i mismatched the size when i started, i haven't thought of the size of the flowerfairy heavy trader, for the spheric "galactic cruiser" it would have fitted).

the flowerfairy has been gifted with an own texture (yeah), also the XF MKI.
while texturing my scripted copy of the x-wing i found many errors, i must have been in a hurry when i made this model.

back to leaking performance, wine project is grateful for any reports what you play and which problems you have, in this way it can be continousely made better.

RE: "Phoenix" (former Sputnik)

Posted: Mon Nov 05, 2018 8:22 pm
by Gernot66


a couple of screenshots from the recent changes, while pardon me "1 pic per post" else my posts have to be authored.

RE: "Phoenix" (former Sputnik)

Posted: Mon Nov 05, 2018 8:23 pm
by Gernot66
label stuff ;)

RE: "Phoenix" (former Sputnik)

Posted: Mon Nov 05, 2018 8:33 pm
by Gernot66
the font i use recently is another "inty" font based on the standard intellivision screen font.
it's not easy to find a free to use monospaced font without roundings or much serifes, but monospaced works best for the labels

once ment as example how simple a ship can be scripted the xf mk1 has grown to a full model.



changes i've also made to the hullcutter there are now no more parts which cut out occasionally other geometry of it, that was also a hard piece of work to reach and i almost thought there is no way to solve it and i needed many naps to find the solution for this problem.

RE: "Phoenix" (former Sputnik)

Posted: Mon Nov 05, 2018 9:00 pm
by Gernot66
it's abit a dark color for the xf mk1, but i decided to use the "camouflage colorset" for it, which contains a version of "blood red".

the rest of most ships uses now a set of brighter colors and less greens or dark grey colors. lot of bright steel grey in variations, gold and copper that stuff really looks nice on the ships.
you can influence which colors are selected by specifying a number which i simply add to the seed i use and which i use also to seperate the names for the colors. i.e. you enter "matset1('somecolor',4)"
and the resulting material has the name 'somecolor4' and adds "4" to the generic seed to grant that you can use at least two different per ship (in fact you could use as much variations you like from different tables) odd numbers result in semitransparent material (if the texture has spaces in alpha channel lower as 255), even in opaque. even the standard materials you can use have been simplyfied a lot, material('steel') will select and return "set material,'steel'.....)" (if it's part of the standard material table of course, the selection is name sensitive and you could even specify a different table to use with an optional third variable. i.e. "material('anything',mytable" will return set_material('anything',....) from the table "mytable") you just have to list and use it.
this is because you will use very often the same materials, especially such as "steel", "black", "white", "grey" or "absolute" (an unshaded absolute black), some special ones like "ceiling" which adds a glow and disables shading, it becomes handy for cockpits or rooms if you don't like to use "local lighting" or if the lighting fails and this simplyfies it a lot.

besides in my opinion after using unshaded materials for the sealed spaceport it's somehow the better option as "local lighting". using the glowmap you can control exactly how it should be lit and this is often better as if i use a local lighting. for the cockpits i used both options, pilots and cockpit are locally lit but the ceiling can't be lit proper because the lightsource is usually to close to it, therefore i created material "ceiling". it's really to think about only to use such unshaded glowing material or glowmaps to light things locally up.


RE: "Phoenix" (former Sputnik)

Posted: Mon Nov 05, 2018 9:06 pm
by Gernot66


nothing new so far, but it no longer cuts out the cockpit in this angle.

RE: "Phoenix" (former Sputnik)

Posted: Mon Nov 05, 2018 9:17 pm
by Gernot66
return of the decal stuff



this is in fact u.s. ww2 "3rd pursuit squadron", a very nice one i think.

RE: "Phoenix" (former Sputnik)

Posted: Sun Nov 11, 2018 6:20 am
by Geraldine
These look great Gernot! :)

RE: "Phoenix" (former Sputnik)

Posted: Thu Nov 15, 2018 10:31 am
by Gernot66
thanks, i do my worst ;)

the decals (some of) i discovered while i was looking for a shark mouth (jaws).

recently i'm working on the buildings because i found them somewhat odd. it won't help to gain fps (that's why i simplyfied them before) but they look quite good now.


RE: "Phoenix" (former Sputnik)

Posted: Thu Nov 15, 2018 10:40 am
by Gernot66
i'm aware skyscrapers won't look reasonable on a hostile planet, but i can't seperate them yet thus i create both sort of buildings but mostly common for outdoor worlds.
i know i said once "i don't like skyscrapers", but well the highrise buildings look very big city like.



again i decided to put them on large basements, kinda mix of "city tiles" and the common way.
quarters will be to large or else i have to lift them 50m above the ground so they won't be covered by a possible hillside. i think a tilesize of ~100m is not bad and i only have to lift them 15m above the ground to display them right in most cases (on very steep mountainsides they will still be covered by half). however, maybe i still arrange them in tiles if the collision mesh is sized properly in ralation to the basement they will be almost seamless (maybe you remember the experimental city tiles i made once).