frame

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Sign In Register

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Categories

Hi Everyone

I think most of the major changes are done, I think. Now I will be just doing small stuff to improve security and hopefully make everything look better. :)

For help for existing users prior to website update read these posts:

Activating account:
http://spacesimcentral.com/forum/discussion/7019/troubleshooting-my-account-from-the-switch-over

Download Area Info
http://spacesimcentral.com/forum/discussion/7020/download-area-info


Please post to the administration area if you have any problems:
http://spacesimcentral.com/forum/categories/ssc-administration


-D1-

Alpha 21 released

robnrobn Pioneer Developer
edited 2:51PM in Pioneer
The Pioneer development team are pleased to announce the release of Pioneer Alpha 21. This month we revive a couple of favourites from the old games, the original systems from Elite and the targeting tunnels from Frontier. Full changelog and builds for Windows, Mac OS X and Linux are available from the download page.



New features


    [*:rbr7zwrs]Elite systems (Lave etc) with a new start point (#682)

    [*:rbr7zwrs]Manual thrust power control. Use F8 and L-shift to limit thruster power for finer control (#994, #129)

    [*:rbr7zwrs]Navtarget tunnels, a HUD feature to guide you to your destination. Enable it in the "Controls" section of the settings screen (#1146, #1082)

    [*:rbr7zwrs]New small buildings (#1047)


Minor changes and tweaks


    [*:rbr7zwrs]Various moons in the Sol system now appear in the right order on the map (#1050)

    [*:rbr7zwrs]Updated TradeShips module to handle accidental landings and fuel (#1064)

    [*:rbr7zwrs]More precise mouse control under different FoV settings (#1076)

    [*:rbr7zwrs]Added VSync config option (#1085)

    [*:rbr7zwrs]Made background stars less visible through star halos (#1093)

    [*:rbr7zwrs]Added Pioneer badge to menu screen (#1099)

    [*:rbr7zwrs]ObjectViewer updates: buttons to cycle/randomise seeds; don't show attribute for non-terrain bodies (#1100)

    [*:rbr7zwrs]Several stars around Sol updated to use their "traditional" (non-catalogue) names (#1068)

    [*:rbr7zwrs]Rear of Eagle ship now visible to player (#1125)

    [*:rbr7zwrs]Removed tech levels (#1131)

    [*:rbr7zwrs]Added a grid to the modelviewer to help visualise model size (#1132)

    [*:rbr7zwrs]Reverted DeliverPackage module to pre-Alpha 20 (#1162)


Fixes


    [*:rbr7zwrs]Don't take timesteps for dead ships. Stops the player firing during the death screen (#1056)

    [*:rbr7zwrs]Move all the custom stars into the right places (#1080, #1081)

    [*:rbr7zwrs]Fix autopilot handling of fast-moving bodies (#1090)

    [*:rbr7zwrs]Fixed hyperspace checks so they work during hyperspace and don't allow hyperspace to be triggered at odd times (eg docked) (#1101, #999, #1030, #1088)

    [*:rbr7zwrs]Restore Jupiter and Neptune to their correct terrain types (#1100)

    [*:rbr7zwrs]Fixed various old bugs around frame movement, timesteps, AI velocity correction and similar (#1090)

    [*:rbr7zwrs]Fix crash when script tries to set ship label > 16 chars (#1116, #1114)

    [*:rbr7zwrs]Limit max engines to 0 or 1 to prevent certain forms of lunacy (#1140)

    [*:rbr7zwrs]Fix view/panel draw order so that world elements do not draw over the panel (#1141, #1161, #1160)

    [*:rbr7zwrs]Only update ship mass, fuel and equipment stats when necessary (#1112, #1155)

    [*:rbr7zwrs]Fixed huge mixer icon on Win32 (#1158, #860)


Script changes


    [*:rbr7zwrs]New custom system option :explored to explicitly set a system's explored state (#682)

    [*:rbr7zwrs]Lua serializer can now handle multiple references to the same table (#1022, #1025)

    [*:rbr7zwrs]New ShipJumpStatus constants DRIVE_ACTIVE and SAFETY_LOCKOUT (#1101)

    [*:rbr7zwrs]New method Ship.GetHyperspaceDetails() to get hyperspace status, duration and fuel use without regard to current flight state (#1101)

    [*:rbr7zwrs]New ship params 'front_camera' and 'rear_camera'. Sets the camera's position on the ship, and causes the ship's body to be drawn (#1125)

    [*:rbr7zwrs]New attribute SpaceStation.numDocks to get number of docking ports (#1135)

    [*:rbr7zwrs]New SystemBody attributes gravity, hasAtmosphere and isScoopable (#1150, #859)


Internal changes


    [*:rbr7zwrs]configure tweaks for better optimisations and profiling support

    [*:rbr7zwrs]New filesystem abstraction. Files under data/ can now be overriden by placing an identically-named file under /data (#989, #1078, #1079, #1077)

    [*:rbr7zwrs]Ship definitions separated from models (#1051)

    [*:rbr7zwrs]Partial keybinding cleanup to allow a sane init order

    [*:rbr7zwrs]Integrate texture management into renderer (#1061)

    [*:rbr7zwrs]Remove renderer dependencies on Pi and utils (#1071)

    [*:rbr7zwrs]Pack font glyphs into a single texture for faster text rendering (#1106, #1084, #1107)

    [*:rbr7zwrs]Split world cameras out of WorldView (#1113, #1145)

    [*:rbr7zwrs]Use a fixed version and proper CRC for the model cache (#1119)

    [*:rbr7zwrs]Moved ship control code out of Player and Worldview into a new set of ShipController classes (#1083, #1129)

    [*:rbr7zwrs]Silence warnings when building with GCC 4.7 (#1152)

    [*:rbr7zwrs]Various internal cleanups (#1139, #1142)
«1

Comments

  • GeraldineGeraldine SSC Supporter
    edited 2:51PM
    Great news Robn! Looking forward to trying out those targeting tunnels 8-)
  • edited 2:51PM
    Downloading now
  • edited 2:51PM
    Here's your first bug report. Stock alpha 21. Started a new game on Earth, flew to low orbit of Jupiter then selected low orbit of Neptune. At 31.46 AU the music stuttered, then the game crashed. It's happened twice now.

  • robnrobn Pioneer Developer
    edited 2:51PM
    Marcel wrote:
    Here's your first bug report. Stock alpha 21. Started a new game on Earth, flew to low orbit of Jupiter then selected low orbit of Neptune. At 31.46 AU the music stuttered, then the game crashed. It's happened twice now.



    Curious. I'll try to remember to test later. To help me remember, could you put it on the issue tracker please? Cheers!
  • edited 2:51PM
    It's now issue #1173. Thanks!
  • edited 2:51PM
    Just tried that on mine and it was fine.
  • edited 2:51PM
    Notice to navigators: Caution on landing at Essar -3,15,1



    Repair work on platform 1 avalanche ;)



    Issue #1180
  • edited 2:51PM
    walterar wrote:
    Notice to navigators: Caution on landing at Essar -3,15,1



    Repair work on platform 1 avalanche ;)



    Issue #1180






    i don't know if our friends know what it is about, at least i have no idea.

    can you post a screenshot please?





    if you like to get the screenshot in the issue tracker, put it on a picture storage like "photobucket" and link it in the following way;



    ![picname*](URL of your screenshot)



    *optional placeholder name
  • edited 2:51PM
    Hello postmoke. Easy, flies and lands in Essar.
  • edited 2:51PM
    Or you can see here http://youtu.be/Ev_jJkRJxhw It is unedited
  • edited 2:51PM
    One of the many dangers lurking in the galaxy.



    The repairs will take a lot. Avoid this system or pay many $ shipyard.
  • edited 2:51PM
    aha :mrgreen:



    yes, a know problem and the reason why i placed all my stations pads 200m above the ground.



    in certain cities where the spaceport is placed on a steep hillside it can happen that one or more pads are topped by the ground.



    solution:



    wait for a revision of pioneer where this problem is solved in general,

    means perhaps a levelled ground around cities (which i would dislike a bit if all cities where placed on flat ground)



    or try to replace the default stations with mine, they are usually placed high enough to avoid such situations (with exception for the sealed spaceport, i havn't tested it on steep hillsides yet. but i didn't expect complications, because as soon as the docking sequence is engaged the ship has no more collision checking and you could even place the docking bay under the surface without colliding the surface).



    give me a little time and i will put them together in a suitable state, so you can use it to replace the existing stations.

    one possible issue in advance,

    they will lower the framerate somewhat (depending on your machine), first because they are textured, second because they use some animated models.



    further limitations,

    the sealed spaceport comes only with three docking bays and because it has only one lift but three bays the target will unfortunately point to the docking bay instead to the lift floor (height and position will be shown "wrong" when you dock manually), this is not my fault, it has been changed internally in the program to take the last stage as target instead of the first, something of the things that has been changed, of which i quite don't understand why (a very good idea perhaps :roll: , which perhaps was ment for good but hasn't been thought to the end...).






    to the ones who changed that: imagine what would hapen if i specified the docking bay position as waypoint for the autopilot - a hard crash landing.

    that's exactly what you did when you take the last stage for the docking target, not useful imo.

    of course the autopilot didn't recognize this and use only the given waypoints, but it's confusing for humans to have the target on the docking position instead on the geometry which releases the docking sequence, that's the important one to know, the position of the bay i don't have to know since as soon as the sequence is released i didn't control the ship anymore.

    for the mushroom station it doesn't matters because you have four elevators, but i hope it will be replaced once with better looking ones (not especially mine).



    further i have been told that the issue tracker has been released to avoid that such useless changes happen, but if you ask me -

    i have seen a lot of imho useless changes which have been taken immediately into the game, without thinking of the consequences.



    fortunately ;) no one asks me...
  • edited 2:51PM
    One of the many dangers lurking in the galaxy.


    That must have been an avalanche of mud! I love the way you sank down to the pad. :lol:
  • edited 2:51PM
    i nnoticed since a while a empty model folder (in the mac build at least) named apollo ;)



    is that a way to say "we would like it" or just a remnant?
  • edited 2:51PM
    i think, i say I THINK,



    it was again one of those imho useless ideas to split the ship specs from the models.



    do you really think it makes it easier?



    do you think one, perhaps not very experienced user, will find that comfortable to place a new ship in several folders?



    or is the goal to restrict user made mods from pioneer?

    or to make it at least less easy?



    is that such a problem for developers to scroll down in the script, or simply to search for a keyword?



    or do you like to reach absolute control?

    (pioneer is NOT your game neither it's mine, it's ours. means users in first degree, developers and modelers)



    i didn't posted that to the issue tracker, because else i've been polluting it to much (again),

    anyway whatever doubts i have, they will mostly be disregarded.



    but can't you think a little of the consequences in advance?

    can't you imagine a common users longings?



    perhaps i'm the complicated one, but i didn't think so.






    further i still wonder what exactly is so lunatic, when i fitted more then one drive?

    or please let me have some lunacy, i'm a weirdo i know ;)

    (sometimes a bono, sometimes a bozo)

    if i havn't posted it here no one would have noticed it and i should have told it only per PM to some selected friends?*



    please leave some to the users, they should decide themselfes how they like to play their PIONEER.

    if they like to cheat, let them cheat, please!

    i never have earned more laurels, as for my gathering and adding of some own hacks for frontier,

    USERS LOVE THAT!



    pioneer is a single player game...



    if one feels to change my models for his longings i neither mind, feel free to do so and i'm also curious and like to see the result,

    even when you pulled the inside out.

    any other way i would feel is eager of me, you are free and you can do what you like.

    pioneer is free and a user should be able to do with it what HE LIKES.



    i don't like if others decide what i can do with my install of pioneer.

    that's bossing and i don't like that.



    one cool part of a scripting language is that you don't have to be a programmer to modify your game (and i'm pretty sure that this was the idea behind), please keep that in mind, or else you can code all in "C" and leave it up to you ore more experienced users.



    i know it would be easy to restrict also using any other then a hyperdrive as "fake drive", but i would neither like it.

    similar i did in good old FE2 and fittet as experiment anything as a drive to see if that get's me a little further.

    i like to have quasi realistic flights as with the "atomic", but i also like to do sometimes something absolutely weird and leave the common gameplay.

    (due to that it took me only a hour to get to the centre of the galaxy..., how many have been there at all?)

    if such is possible with a simple hack, why not?

    does such leave a scratch on your varnish? :roll:



    to gave it by default a, let's say a communal look and feel, is self-evident, but apart from that...



    or put it under a different licence, then you can have absolute control...



    question:

    where would we be without lunatics like me?



    ...perhaps sitting still in front of a abakus and play chess or backgammon :mrgreen:



    *this let's me think i should post the next "hack" really only to trusted friends, only to avoid that it will be restricted in the next release.

    do you think that's cool?






    in that spirit, enjoy this



    http://www.facebook.com/video/?id=106341636057080
  • robnrobn Pioneer Developer
    edited 2:51PM
    potsmoke66 wrote:
    it was again one of those imho useless ideas to split the ship specs from the models.


    No, it was not. The attributes of a ship are entirely separate from the model. They are being decoupled in the core in order to support the new model system that is being built.


    do you think one, perhaps not very experienced user, will find that comfortable to place a new ship in several folders?


    Actually its only two folders.


    or is the goal to restrict user made mods from pioneer?

    or to make it at least less easy?


    The plan is to enable a user to drop a straight zip file into their user dir and have it just work, without even having to unpack it. We've been building out the infrastructure to support that over the last couple of months. The actual zip file piece is still missing, mostly because its not that hard and we have no immediate need for it.



    Following that an in-game mod manager will be just a short step away.


    is that such a problem for developers to scroll down in the script, or simply to search for a keyword?


    You assume that's the only work we do. There's a hell of a lot of work going on to make things easier for users and artists to contribute to the game. This separation is part of that.


    or do you like to reach absolute control?

    (pioneer is NOT your game neither it's mine, it's ours. means users in first degree, developers and modelers)


    I'm not aware that anyone is looking for control. Every day there are many many people discussing short and long term goals for this game, trying to find a way to make into a complete, commercial-quality game that has something for everyone. Not every idea goes forward, but lots do with the agreement of those doing the work.


    but can't you think a little of the consequences in advance?

    can't you imagine a common users longings?


    I am somewhat confused by your continued assertion that somehow you're the only one considering the needs and wants of our players. Have you simply never heard the continued demands from players on this forum, in the issue tracker, in IRC and in many other forums all over the internet for more interesting gameplay mechanics, more coherent ship and station design, a working economic and political system and everything else? I see you designing ships which in isolation are fine work, but have very little in the way of balance or cohesion, and contribute nothing to the other aspects that will, in the end, make Pioneer a game and not just a graphics demo.



    My personal goal (one shared by many others) is that one day anyone will be able to download Pioneer and without any extras be able to play an exciting and meaningful role in the ongoing story of a vast galaxy filled with adventure and intrigue. And, when they get bored of that I want them to be able to pick from a huge selection of add-ons that add new missions, ships, gameplay mechanics and other things to give them whole new reasons to continue playing. Every single line of code I write or review, and every single design discussion I contribute to is done with that in mind.



    You've been offered countless opportunities to contribute meaningfully. For whatever reason you have been unable or unwilling to do so. You often raise issues that are of interest you, and as I've always said before, they are considered and discussed. But more and more it seems that you simply want a platform to show off your models. And that's fine - no problem with that. You already have one - every version of Pioneer released so far. There's nothing requiring you to follow more recent releases, just as there's nothing requiring anybody who wants to use your work to stop using an older version.


    further i still wonder what exactly is so lunatic, when i fitted more then one drive?


    It didn't work. The code only ever uses the first drive in the engine slot when computing engine characteristics.


    please leave some to the users, they should decide themselfes how they like to play their PIONEER.

    if they like to cheat, let them cheat, please!

    i never have earned more laurels, as for my gathering and adding of some own hacks for frontier,

    USERS LOVE THAT!


    Previous releases are there. The entire source code is there. Anybody is free to use older versions or take the whole code and go and make their own game according to meet whatever criteria they think good. In fact, I actively encourage this. Make sure you let us know too - I'd love to see what people come up with!


    i don't like if others decide what i can do with my install of pioneer.

    that's bossing and i don't like that.


    When have I touched your installation of Pioneer? Did I force you to change anything?


    one cool part of a scripting language is that you don't have to be a programmer to modify your game (and i'm pretty sure that this was the idea behind), please keep that in mind, or else you can code all in "C" and leave it up to you ore more experienced users.


    Actually that's not true. Lua is every bit as much a programming language as C++, and the complexity and unmaintainability of some of the models make it crystal clear that they were not written by a programmer.


    or put it under a different licence, then you can have absolute control...


    None of us have any power to change the license even if we wanted to. And that's good for you - its that license that makes it impossible for any of us to take the game away from you or any other player.
  • edited 2:51PM
    The plan is to enable a user to drop a straight zip file into their user dir and have it just work, without even having to unpack it. We've been building out the infrastructure to support that over the last couple of months. The actual zip file piece is still missing, mostly because its just an idea we have at this point. There's been no actual demand for it.




    LIKE IT!


    You assume that's the only work we do




    certainly not.


    It didn't work. The code only ever uses the first drive in the engine slot when computing engine characteristics.




    not quite true, i've done it and was surprised myself (i know it hasn't worked in older releases rather alpha20 but at least in this build it has worked) ;)

    but of course it's something "evil".


    But more and more it seems that you simply want a platform to show off your models




    true, the place for this is here, i guess.


    I see you designing ships which in isolation are fine work, but have very little in the way of balance or cohesion




    yes and no, ships like the "bloodrunner" or the "atomic" never ment to be in cohesion, ships like the "Typhoon", are straight to that goal.

    even if i would like to see a complete "steam punk" pioneer.

    i need to express my ideas each time i have some, sorry.

    creativity isn't something you can control, else it's no longer creativity.



    besides, what is a coherent style? i mean who decided it or is that written down somewhere?

    facsimile elite ships only?

    or like the "plattenbau" buildings all boring concrete jungle type?

    choices are different, some like this, some like that.



    personally i would like to see a pioneer without any elite ships, even when that would mean that many of my ships would disappear from it.


    ...that somehow you're the only one considering the needs and wants of our players




    no, but i guess i look at a problem from as many as possible point of views and foremost i know what i like, many times (not always) i pointed it right.

    i think i know for some parts what a common player likes, not only in a game like pioneer.

    further i guess i dare to speak out loud what others perhaps only think in the back of their minds.



    i'm neither fish nor bird, that can be (is) a problem, but i never wanted to be something else.

    sometimes in any discussion i take a contrary position, just that at least someone counters.

    people are sometimes confused by that and feel insecure because they might don't know what's the reason for.



    conclusion; if you say yes, i will say no, even if that isn't my conviction.


    When have I touched your installation of Pioneer? Did I force you to change anything?




    a little bit... (not seriously)


    the complexity and unmaintainability of some of the models make it crystal clear that they were not written by a programmer.




    fortunately?

    it's true i'm not a programmer, but i see myself as a link between...

    (over)complexity, true!

    unmaintainable, hm..., i can't see that, but perhaps if pointed out, it could help.



    or to tell (again) in other words, to get a "shoebox" running in pioneer you need nothing, really nothing only a few lines.

    to have a ship that appears in different states, which is "alive", needs a little more and ends up in complexity, unfortunately but unavoidable in some way.



    that scripted geometry comes out extremely complex is offense i guess, you have to find very different ways to do things which look in the end common.

    e.g. no problem to stick a hollow cylindre into a body with a cad, to do the same with a scripted geometry, needs a lot more effort and uncommon ways to go.

    if you have a better solution as i have for this, let me know.



    anyway i chose often the latter way, even for .obj based models, the reason is simply the result, if i can't get rid of creases in the common way i choose the one i use also for scripted geometry (using transparent parts and models hierachy).



    mainly and thats also true, i copied the way FE2's models was made, by using little tricks to let them appear so they please me.



    yes, a cool piece of code, those new buildings, but sorry, exactly this they appear to me, boringly all the same, just as there would be only one architect in the whole galaxy.

    we have millions of architects and many different styles, as well as we have a lot of brands and different cars,

    why should our spaceships look all the same? is there only one "brand" in pioneers galaxy? certainly not.

    i expect a lot of different styles in a sci-fi universe, airplane like, spheres, tubes, discs, and even boxes or irregular shaped ships (a "mechanical" race will build ships only by reasonability, think of the borg cube i.e. which already didn't goes far enough imo, i like "Perryverses Positronic-Biological Ships" shaped by all stuff the can inherit).



    congruent is ok, conformity is tying me.



    interesting for me to recognize sometimes that ships which i made but i didn't like to much myself beeing credited by users...



    and sorry again, until i havn't seen many i like,

    the "wave" is super! but needs a better landing gear imo, i would like to see more such ships, really (but fit a cool UC, please!)

    the turtle is also a nice ship, even when it wouldn't be my choice,

    i like s2odans python and panther (caribou), both have a cool appearance, one agressive like a predator the other simply BOLD.

    the talon, a unique little fighter, i love it, could be a perfect default ship.

    of course coolhands viper, but she's out of concurrence for at least two reasons, also the lanner is a fine ship else i wouldn't have converted it, but both are FFED3D ships, which i see personally like all FFED3D conversions rather as "placeholders" (not ment as criticism).



    let's make a small list of ships i see as somewhat congruent a which give pioneer a unique look.

    i guess we have already enough to choose from unlike 2 years ago.

    this will exclude all FE2 ships :( , no 8-)



    - wave

    - turtle

    - python (if named different perhaps, the design is very loose based on the original i feel)

    - talon

    - hammerhead (we need a transporter)

    - caribou (i wont miss that bold one)



    not yet included, but i see them as future contents

    - typhoon

    - gunboat (why not, we need some different classes, if really needed i can remove the colored stripes :( )

    - defender (if revisited)



    personally i would like also

    - shift (needs to be overhauled)

    - hullcutter (to have a really complex script ;) )



    the rest by choice, of course i like most of the others i made, but i guess the listed ones are congruent more or less, ships like the "gul" or what i've been working on right now i see more as mod, anyway this reflects only what i like, i really wouldn't mind to get rid of my FE2 ships, not because they look bad, but because they are 99% Elite/FE2.

    but i know also that i.e. tomm loves them very much.



    and robn, thanx ;) (for your patience)
  • edited 2:51PM
    ...to support the new model system that is being built




    something i have foreseen and fear of most...





    this i see as a challange for me


    define_model('vip_lever_up', {<br />
    	info = {<br />
    			bounding_radius = 40,<br />
    			materials = {'n_cv'},<br />
       		},<br />
    	static = function(lod)<br />
            set_material('n_cv', 1,1,1,1,1.2,1.2,1.3,30)<br />
    		texture('timberwolf.png')<br />
    		use_material('n_cv')<br />
    		load_obj('lever_up.obj')<br />
        end<br />
    })<br />
    <br />
    define_model('vip_lever_lo', {<br />
    	info = {<br />
    			bounding_radius = 40,<br />
    			materials = {'n_cv'},<br />
       		},<br />
    	static = function(lod)<br />
            set_material('n_cv', 1,1,1,1,1.2,1.2,1.3,30)<br />
    		texture('timberwolf.png')<br />
    		use_material('n_cv')<br />
    		load_obj('lever_lo.obj')<br />
        end<br />
    })<br />
    <br />
    define_model('vip_shoe_r', {<br />
    	info = {<br />
    			bounding_radius = 40,<br />
    			materials = {'n_cv'},<br />
       		},<br />
    	static = function(lod)<br />
            set_material('n_cv', 1,1,1,1,1.2,1.2,1.3,30)<br />
    		texture('timberwolf.png')<br />
    		use_material('n_cv')<br />
    		load_obj('shoe_r.obj')<br />
        end<br />
    })<br />
    <br />
    define_model('vip_shoe_l', {<br />
    	info = {<br />
    			bounding_radius = 40,<br />
    			materials = {'n_cv'},<br />
       		},<br />
    	static = function(lod)<br />
            set_material('n_cv', 1,1,1,1,1.2,1.2,1.3,30)<br />
    		texture('timberwolf.png')<br />
    		use_material('n_cv')<br />
    		load_obj('shoe_l.obj')<br />
        end<br />
    })<br />
    <br />
    define_model('vip_track_0r', {<br />
    	info = {<br />
    			bounding_radius = 40,<br />
    			materials = {'n_cv'},<br />
       		},<br />
    	static = function(lod)<br />
            set_material('n_cv', 1,1,1,1,1.2,1.2,1.3,30)<br />
     		texture('timberwolf.png')<br />
     		use_material('n_cv')<br />
    		load_obj('track_0r.obj')<br />
        end<br />
    })<br />
    <br />
    define_model('vip_track_0l', {<br />
    	info = {<br />
    			bounding_radius = 40,<br />
    			materials = {'n_cv'},<br />
       		},<br />
    	static = function(lod)<br />
            set_material('n_cv', 1,1,1,1,1.2,1.2,1.3,30)<br />
    		texture('timberwolf.png')<br />
    		use_material('n_cv')<br />
    		load_obj('track_0l.obj')<br />
        end<br />
    })<br />
    <br />
    define_model('vip_track_1r', {<br />
    	info = {<br />
    			bounding_radius = 40,<br />
    			materials = {'n_cv'},<br />
       		},<br />
    	static = function(lod)<br />
            set_material('n_cv', 1,1,1,1,1.2,1.2,1.3,30)<br />
    		texture('timberwolf.png')<br />
    		use_material('n_cv')<br />
    		load_obj('track_1r.obj')<br />
        end<br />
    })<br />
    <br />
    define_model('vip_track_1l', {<br />
    	info = {<br />
    			bounding_radius = 40,<br />
    			materials = {'n_cv'},<br />
       		},<br />
    	static = function(lod)<br />
            set_material('n_cv', 1,1,1,1,1.2,1.2,1.3,30)<br />
    		texture('timberwolf.png')<br />
    		use_material('n_cv')<br />
    		load_obj('track_1l.obj')<br />
        end<br />
    })<br />
    <br />
    define_model('vip_uc_0r', {<br />
    	info = {<br />
    			bounding_radius = 40,<br />
         		},<br />
    	static = function(lod)<br />
    	end,<br />
    	dynamic = function(lod)<br />
            local trans = .99 - math.clamp(get_animation_position('WHEEL_STATE')-.3,0,1)*1.4286<br />
    <br />
    		call_model('vip_shoe_r',v(0,0,0),v(1,0,0),v(0,1,0),1)<br />
    		call_model('vip_track_0r',v(0,0,1.825-trans*.866),v(1,0,0),v(0,1,0),1)<br />
    		call_model('vip_track_1r',v(0,0,3.206-trans*1.687),v(1,0,0),v(0,1,0),1)<br />
    		call_model('vip_track_0r',v(0,0,4.415-trans*2.31),v(1,0,0),v(0,1,0),1)<br />
    		call_model('vip_track_1r',v(0,0,5.826-trans*3.18),v(1,0,0),v(0,1,0),1)<br />
    <br />
        end<br />
    })<br />
    <br />
    define_model('vip_uc_0l', {<br />
    	info = {<br />
    			bounding_radius = 40,<br />
         		},<br />
    	static = function(lod)<br />
    	end,<br />
    	dynamic = function(lod)<br />
            local trans = .99 - math.clamp(get_animation_position('WHEEL_STATE')-.3,0,1)*1.4286<br />
    <br />
    		call_model('vip_shoe_l',v(0,0,0),v(1,0,0),v(0,1,0),1)<br />
    		call_model('vip_track_0l',v(0,0,1.825-trans*.866),v(1,0,0),v(0,1,0),1)<br />
    		call_model('vip_track_1l',v(0,0,3.206-trans*1.687),v(1,0,0),v(0,1,0),1)<br />
    		call_model('vip_track_0l',v(0,0,4.415-trans*2.31),v(1,0,0),v(0,1,0),1)<br />
    		call_model('vip_track_1l',v(0,0,5.826-trans*3.18),v(1,0,0),v(0,1,0),1)<br />
    <br />
        end<br />
    })<br />
    <br />
    define_model('vip_constraint_0r', {<br />
    	info = {<br />
    			bounding_radius = 40,<br />
         		},<br />
    	static = function(lod)<br />
    	end,<br />
    	dynamic = function(lod)<br />
            local rot = .99 - .5*math.pi*math.clamp(get_animation_position('WHEEL_STATE')-.3,0,1)*1.4286<br />
    <br />
    		call_model('vip_uc_0r',v(0,-1.549,-1.64),v(1,0,0),v(0,math.cos(.65*rot+.15),-math.sin(.65*rot+.15)),1)<br />
        end<br />
    })<br />
    <br />
    define_model('vip_constraint_0l', {<br />
    	info = {<br />
    			bounding_radius = 40,<br />
         		},<br />
    	static = function(lod)<br />
    	end,<br />
    	dynamic = function(lod)<br />
            local rot = .99 - .5*math.pi*math.clamp(get_animation_position('WHEEL_STATE')-.3,0,1)*1.4286<br />
    <br />
    		call_model('vip_uc_0l',v(0,-1.549,-1.64),v(1,0,0),v(0,math.cos(.65*rot+.15),-math.sin(.65*rot+.15)),1)<br />
        end<br />
    })<br />
    <br />
    define_model('vip_uc_1r', {<br />
    	info = {<br />
    			bounding_radius = 40,<br />
         		},<br />
    	static = function(lod)<br />
    	end,<br />
    	dynamic = function(lod)<br />
            local rot = .99 - .5*math.pi*math.clamp(get_animation_position('WHEEL_STATE')-.3,0,1)*1.4286<br />
    <br />
    		call_model('vip_lever_lo',v(0,0,0),v(1,0,0),v(0,math.cos(.65*rot+.15),math.sin(.65*rot+.15)),1)<br />
    		call_model('vip_constraint_0r',v(0,0,0),v(1,0,0),v(0,math.cos(.65*rot+.15),math.sin(.65*rot+.15)),1)<br />
        end<br />
    })<br />
    <br />
    define_model('vip_uc_1l', {<br />
    	info = {<br />
    			bounding_radius = 40,<br />
         		},<br />
    	static = function(lod)<br />
    	end,<br />
    	dynamic = function(lod)<br />
            local rot = .99 - .5*math.pi*math.clamp(get_animation_position('WHEEL_STATE')-.3,0,1)*1.4286<br />
    <br />
    		call_model('vip_lever_lo',v(0,0,0),v(1,0,0),v(0,math.cos(.65*rot+.15),math.sin(.65*rot+.15)),1)<br />
    		call_model('vip_constraint_0l',v(0,0,0),v(1,0,0),v(0,math.cos(.65*rot+.15),math.sin(.65*rot+.15)),1)<br />
        end<br />
    })<br />
    <br />
    define_model('vip_constraint_1r', {<br />
    	info = {<br />
    			bounding_radius = 40,<br />
         		},<br />
    	static = function(lod)<br />
    	end,<br />
    	dynamic = function(lod)<br />
            local rot = .99 - math.pi*math.clamp(get_animation_position('WHEEL_STATE')-.3,0,1)*1.4286<br />
    <br />
    		call_model('vip_uc_1r',v(0,-1.582,-1.762),v(1,0,0),v(0,-math.sin(rot*.7222),math.cos(rot*.7222)),1)<br />
        end<br />
    })<br />
    <br />
    define_model('vip_constraint_1l', {<br />
    	info = {<br />
    			bounding_radius = 40,<br />
         		},<br />
    	static = function(lod)<br />
    	end,<br />
    	dynamic = function(lod)<br />
            local rot = .99 - math.pi*math.clamp(get_animation_position('WHEEL_STATE')-.3,0,1)*1.4286<br />
    <br />
    		call_model('vip_uc_1l',v(0,-1.582,-1.762),v(1,0,0),v(0,-math.sin(rot*.7222),math.cos(rot*.7222)),1)<br />
        end<br />
    })<br />
    <br />
    define_model('vip_uc_2r', {<br />
    	info = {<br />
    			bounding_radius = 40,<br />
         		},<br />
    	static = function(lod)<br />
    	end,<br />
    	dynamic = function(lod)<br />
            local rot = .99 - math.pi*math.clamp(get_animation_position('WHEEL_STATE')-.3,0,1)*1.4286<br />
    <br />
    		call_model('vip_lever_up',v(0,0,0),v(1,0,0),v(0,-math.sin(rot*.7222),-math.cos(rot*.7222)),1)<br />
    		call_model('vip_constraint_1r',v(0,0,0),v(1,0,0),v(0,-math.sin(rot*.7222),-math.cos(rot*.7222)),1)<br />
        end<br />
    })<br />
    <br />
    define_model('vip_uc_2l', {<br />
    	info = {<br />
    			bounding_radius = 40,<br />
         		},<br />
    	static = function(lod)<br />
    	end,<br />
    	dynamic = function(lod)<br />
            local rot = .99 - math.pi*math.clamp(get_animation_position('WHEEL_STATE')-.3,0,1)*1.4286<br />
    <br />
    		call_model('vip_lever_up',v(0,0,0),v(1,0,0),v(0,-math.sin(rot*.7222),-math.cos(rot*.7222)),1)<br />
    		call_model('vip_constraint_1l',v(0,0,0),v(1,0,0),v(0,-math.sin(rot*.7222),-math.cos(rot*.7222)),1)<br />
        end<br />
    })
    




    this is easy as 1,2,3 to make in blender.



    ADDER01.gif



    i know many would like the latter, to make and export animations from the CAD.

    neither they like to fiddle around with ship specs or how the model is bind in the game.

    unfortunately i do, i really like that, i like the challenge.



    foremost i like the scripted animations, even when not all is possible i can do in the CAD and when it's 10x more work.

    but it's exactly something i miss from some modelers, a real understanding how a animation works.

    personally i guess one who understands the first example will make better animation even with a CAD.

    really i have seen many nice models which i really like, especially in FFED3D, but with some exclusions most are animated poor.

    i strongly believe it is because of the CAD, because you don't have to understand what stands behind.

    to me a general problem of nowadays.



    only a rough idea i had once,

    max_h_01.gif

    imagine, it's possible to let that guy read any text, such can only be done with a scripted geometry

    the rough shape could be replaced with bezier stuff, it would be also possible to generate different characters then (by randomly changing the size of the "bones").

    THAT MEANS MODELLING TO ME!



    if you dare, we could have a "Max Headroom" in Pioneer, including the tic.

    such will never be possible with a CAD exported anim



    but i can't do it alone i guess, i would need a team

    and in first degree a dynamic modeling system,

    further some people who understand that at least as much as i do.



    this will set new standarts
  • robnrobn Pioneer Developer
    edited 2:51PM
    I've posted before about why dynamic scripted geometry is a bad thing (hard to write, hard to optimise, etc) so I won't address it again. But I wanted to pick up on this:


    potsmoke66 wrote:
    unfortunately i do, i really like that, i like the challenge.


    That's probably the clearest indication of where our ongoing disagreements come from. You want something challenging, so a system that is more constrained but easier to use is undesirable for you. I want a game that anyone can work with and contribute to, so a system that is difficult to use is an obstacle.


    imagine, it's possible to let that guy read any text, such can only be done with a scripted geometry


    No, that's not true. There's a lot of research being done into codifying facial structure such that it can be moved and manipulated (see eg Evaluating Face Models Animated by MPEG-4 FAPs [PDF link]. If we ever wanted to pursue something like this then we'd build a separate system to make it happen rather than trying to force everything through the regular model pipeline. Of course its only half the solution - we'd still need a system to decompose text and convert that into appropriate animation parameters, and we have to make it happen for arbitrary languages.



    I honestly doubt we'll ever see anything like this in Pioneer unless it somehow becomes available as a commodity technology. Our brains know a lot about faces, so anything that does look like a face had better work pretty much like a real face or its going to look terrible. Part of the charm of the current facegen is that its obvious that they're caricatures, so its not a jarring experience. Other things like ships are less well known to our brains, so we're less likely to spot small problems with them.
  • edited 2:51PM
    potsmoke66 wrote:
    i nnoticed since a while a empty model folder (in the mac build at least) named apollo ;)


    Opps.. my fault - that must have been left behind when I was experimenting with my apollo eagle luna lander ship. It is on a personal branch of mine, but the folder structure looks like it is still there (it is definately not in the main repo).



    I'll clean that up when I get home. :oops:



    It is safe to delete it, as it shouldn't be there.
  • edited 2:51PM
    i thought so ;)



    besides, i would like to see it.

    is it a scriptet geometry?

    how do you launch the lunar lander, with a saturn? (decoupling, i think would be a problem)



    even when i feel personally that pioneer isn't ment to do realistic spaceflights, but as a sidetrip it's a cool idea.



    i have watched a clip of orbiter and i must say, no i wouldn't like it, it's to sophisticated for me.



    you could do a favor for me, i can't compile pioneer on my mac, due to the fact that my machine refuses to install the needed libraries and i havn't the patience to hunt that error.

    but i would appreciate the modelviewer in the mac build (next release) if that is possible, but i also remember that i couldn't compile the MV since a while in the windows build, perhaps you got the same problem?



    and please forget the issue i posted last night, i'm a idiot, i have missed the changes to the adverts* and further i took the wrong version for comparison.

    this has produced a big confusion. sober i'm good for nothing i guess** :lol:

    it's running fine now



    *only curiosity, no criticism, what's the purpose of the tagging for the adverts?

    **even a reason for my actual agression level, i hope it will change soon, because i start to dislike myself. but i will keep on staying sober it's better.

    yes me, the "40 year old hippie" starts to lock away his pipe - perhaps a fruit of pioneer and all of thee.
  • edited 2:51PM
    potsmoke66 wrote:
    you could do a favor for me, i can't compile pioneer on my mac, due to the fact that my machine refuses to install the needed libraries and i havn't the patience to hunt that error.


    It is on my list of 'things to do' with the OSX port. I need to have a rethink on how I package up the binary distro. Currently it is packaged up as a nice single .app folder, but adding the modelviewer as an .app it also needs access to the same data directory as pioneer.app.



    I might have to seperate the data directory out of the .app folder but that just makes it 'messy' IMHO. (I like keeping things simple).



    I'm currently away on business (hence why I'm quiet) but I'll have a closer look when I get back.
  • edited 2:51PM
    yet another question from "stupid" me,



    i've read a while ago on the issue tracker (i guess) that you don't like to get sub-models from the "sub_models" directory called for building.

    actually this is the case now.



    what i wonder now what is the reason for it?

    personally i feel it's a bit stupid (for me) to have models doubled, if i wan't to attach i.e. a scanner sub-model to a building.

    well, i can tell you why i did that, i simply copied the behave of FE2, means the little scanner build from three bezier flats you see on the ships is a scalable sub-model and appears even as the terrestrial radar in cities.

    as well as the buildings on the LRC are the industrial park you see in the cities, personally i think that's a clever thing.



    keep it short and simple, though a idiot like me can understand it ;)






    don't get angry, but i feel it all heads into a direction that in the end only "shoe-boxes" will work in pioneer.

    really i feel it heads to solid meshes like ".X", with matrix animations and no more dynamic use of submodels.

    i think, like some other changes that has happened, it's all based on the unwill of some to get comfortable with the LUA model system.



    a promise, if it ever comes to that point, you finally get rid of me and i will never disturb you anymore.



    that fear is also based on things like the absolut needless change of the UV for .obj*, this has lead (i repeat myself) that many of my models still look disranged.

    actually the "viper x" is destroyed and it's hull is completely transparent (if it's still there at all) th adder is still textured wrong and i can't say what else to.

    to me it's like someone likes to destroy all i've contributed to pioneer, please understand that such makes me a bit angry.

    you can tell me FACE TO FACE if you dislike me and my models, that would be far better, i don't like sly things!



    *well actually it is wrong now for righthanded models, but even if it would have been wrong before (which is not the case), it would have been better to left it "wrong".

    as example, in the very beginning of electrical engineering the current flow has been set to a given direction (assumed from positve to negative) decades later it has been made proof that the current flow is vice versa, but to avoid complications it has been left "wrong". it doesn't matteres and our computers work fine even when the layout didn't reflects the true physical situation.



    farther, i've been told that i have a low bus factor and that my models are unmaintainable for others, i still wait for a tangible explanation to what exactly is so complicated or unmaintainable, a reason why i opened the "let's point it out" thread here (no, it didn't belongs to the issue tracker).

    if no one can tell me what exactly is "wrong", sorry, then i feel this is a raid against me and nothing else.



    i've been also told that i'm, let's say excluded, from contributing because i don't fully participate via github or because i have no presence on the IRC channel.

    well, many here know me as a kind guy who likes to help beginners, i don't mind much how experienced one is in a certain thing, i'm willing to help.

    what i don't understand, why no one of you is interested to back up me?
  • robnrobn Pioneer Developer
    edited 2:51PM
    potsmoke66 wrote:
    i've read a while ago on the issue tracker (i guess) that you don't like to get sub-models from the "sub_models" directory called for building.


    I don't recall the specifics, but I probably just didn't like its ad-hoc nature. The general concept (a library of reusable parts) is fine.


    don't get angry, but i feel it all heads into a direction that in the end only "shoe-boxes" will work in pioneer.


    You continue to say that without any data to substantiate it. If you could explain why you think that perhaps I could do a better job of allaying your fears.


    really i feel it heads to solid meshes like ".X", with matrix animations and no more dynamic use of submodels.


    Every other game out there manages to have beautiful models with great animations without the need to generate new geometry every frame. Why do you think a traditional pipeline won't work for Pioneer?


    i think, like some other changes that has happened, it's all based on the unwill of some to get comfortable with the LUA model system.


    As I've stated repeatedly, the internals of the Lua model system is a mess. In its current form it relies on leaky GL state which makes it impossible to refactor to use the new renderer system (I spent three weeks on it; I know). The complex state transitions also make it very difficult to optimally batch geometry on the GPU, so there will always be a limitation to how much performance we can get out of the systems.



    If there was something truly compelling in the Lua model system we could perhaps work to keep the changes to a minimum, but so far nothing particularly unusual has been done with it and as you say, no one is willing to get comfortable with the system. Without exaggeration I can say that I turn away an interested artist every few weeks. They come in with solid knowledge of 3DS or Blender, often with experience with modelling pipelines used in common 3D engines (eg UDK or Source), and some great ideas. The moment they're told that they have to write a script to get anything done, they leave because its outside of their comfort zone.



    I don't want to turn these people away. They're keen, and we have an entire universe to fill - we need them. If we have a more traditional system, something that the entire games industry is familiar with, then we have a much better chance of attracting and retaining this kind of talent.


    a promise, if it ever comes to that point, you finally get rid of me and i will never disturb you anymore.


    I have no desire to see you gone, but if that's what you end up choosing I would not try to persuade you otherwise.
  • edited 2:51PM
    Without exaggeration I can say that I turn away an interested artist every few weeks. They come in with solid knowledge of 3DS or Blender, often with experience with modelling pipelines used in common 3D engines (eg UDK or Source), and some great ideas. The moment they're told that they have to write a script to get anything done, they leave because its outside of their comfort zone.




    not without egoism, i would say, it let's mine look odd perhaps :mrgreen:



    i know and i remember that i've said a long time ago that i'm perhaps not the best choice, therefore i loved TomM's decision for the LUA modelling system from the very start. mainly because of the closeness to FE2 and i feel personally that it offers much more as what is possible with "industrial standards".



    i remember TomM feared to find any modeler at all who get comfortable with it and he was more then happy to find at least one ;)

    like i said before, i know it has limitations and it's true it limits the range of modelers contributing to pioneer.



    but on the other hand, i would say let them contribute to whatever they like, there are masses of games under development, some of the comrades of FFED3D doing actually commercial models, they have evolved a lot (compared to me, i got stuck with LUA, but i LOVE it).



    perhaps i'm only angry because i will vanish from the scene without pioneers LUA modeling system :mrgreen:



    besides of that, if that's a fact (...turn away an interested artist every few weeks...), why don't you pipeline them to me? i could help, i would like to help.

    i mean if a beginner like me can handle it, what will close out a more experienced modeler? i'm pretty sure they are able at least what i'm able to.

    i really would like a close coop with some more experienced modelers, i could learn a lot in this way.



    of course i understand to, that some do professional work, freelancing or on the staff and have no interest to waist their time with LUA.

    i remember coolhand told me once that he isn't able to do what i do with the LUA system, i don't believe that ;) , but for above reason it's obvious.
  • robnrobn Pioneer Developer
    edited 2:51PM
    i feel personally that it offers much more as what is possible with "industrial standards".


    I have nothing to support and much to refute that. If you know something that that is both a) useful and b) possible with LMR that is not with a traditional pipeline, please do share!


    i remember TomM feared to find any modeler at all who get comfortable with it and he was more then happy to find at least one ;)


    At this point there's a lot more people involved than tomm, and we're all trying to build Pioneer into a real game. Having something deliberately designed to make life difficult for people just isn't going to work in the long run.


    but on the other hand, i would say let them contribute to whatever they like, there are masses of games under development, some of the comrades of FFED3D doing actually commercial models, they have evolved a lot (compared to me, i got stuck with LUA, but i LOVE it).


    Sure we could say that, but they come here wanting to contribute to Pioneer. This game is the fulfilment of a dream for so many people that for years have wanted to relive their memories of Frontier. If someone has the skill and the desire to add a little bit of themselves to our game, why should they be denied?


    besides of that, if that's a fact (...turn away an interested artist every few weeks...), why don't you pipeline them to me? i could help, i would like to help.


    I have directed some to your tutorials in the past. Its hard though - surely you must see that if you're used to working in a highly visual environment, having to start thinking in code could seem daunting? It doesn't matter if it actually is or not, it looks complicated, and that's enough to turn a newcomer away.


    i mean if a beginner like me can handle it, what will close out a more experienced modeler?


    You underestimate your own skill. You are the person most experienced with the use of Pioneer's model system by a very large margin. The difficulty is that the skills required to drive LMR effectively aren't quite the same as those that are needed to drive a modelling package.
  • edited 2:51PM
    I'm personally a big fan of moving away from having Lua be the up-front system.



    Ideally you don't want to have anything outside of Max/Blender/Maya to get between an artist and the game. Having worked with quite the gamut of artists I've seen some who not only got used to our build pipelines, but then extended them with their own scripts/suggestions/tools... I've also had an artist who couldn't use our build system even after we simplified it to the point where all he had to do was double click on a ".bat" file on his desktop :evil:



    The simple fact is that most artists will be familiar with exporting meshes; I.e. solid meshes, with texture mapping (diffuse, normal, specular, etc) and it would be good to make it easier for them to get up and running so we can get more peoples ideas into the game.



    This doesn't mean that we lose the use of sub-models, there are plenty of games that manage ok with those, but even if it did it would be a minor sacrifice to get more people aboard in my opinion. :shock: I know, I know, controversial.



    What we could do with for models even if we stuck with the existing LMR/Lua system is a tool that makes creating, verifying and getting them into the game a LOT easier. Possibly even generates the Lua for you, lets you select models and sub-models from a list - positioning and all. What you eventually end up with though is going to look a lot like a full 3D editor.



    The way forward, and I bet it's what the people on FFED3D found as well, is that meshes are better from just about every possible viewpoint. They can be better animated, textured, are easier to create and so open up that creation to more people and you can still have sub-models, plus there are massive performance benefits. Even better than that though, those sub-models aren't there because of a script which decides if they're attached or not, but are instead added as sub-objects in the game - that means you could blow the antenna off if we wanted! Visually as well as in the game logic.



    Gernot, I find these arguments against moving towards meshes to be weird. Whenever I've given an artist bigger textures, a higher polygon budget, easier animations and simplifed getting their work into a game... they're generally really happy rather than threaten to quit :?:
  • edited 2:51PM
    ok, that's a argument



    still i would miss it :cry:



    it's not that i'm completly against solid meshes, i only FEEL it will limit things a bit.

    because, certain things like real dynamic changes of a mesh arn't easy possible, as example the wiggling tail of the "Turner Class".

    yes, it can be done i know, you can animate a vertex group of course to do such, but 1st you need a fitting game engine, 2nd a fitting file format, 3rd i'm not sure if this is really better as a animated bezier in a scripted geometry.

    besides all of that, making models with 4LOD's with meshes needs to make 4 meshes, while the scripted geometry has it's divisions set by the LOD and you don't have to care for such.



    nostalgic? certainly yes :D



    i guess i can get comfortable with whatever modeling system, i mean i've hacked them as example for FFED3D to make some stuff appear in the way i like or to work around some limits given by XNA (dx6 or 7 i guess) dreamzz used to create his wrapper.



    and i said that before, i really feel i'm not good enough to compete with guys like coolhand or solcommand. perhaps i shouldn't idolise them that much but....

    i know its egoism of me, because i know as long as we have the LUA models i havn't much competitors. ;)



    btw, underestimating isn't a bad thing, no?

    at least better rather the opposite :mrgreen: (yes, it can be a handicap, no one has to tell me that, that's why i'm only a construction worker, only helper often and perhaps one reason why i'm still unemployed, or why i never made a cent with my artworks at all, i'm not good in selling myself. sometimes this simply lets me think i'm not good enough, i can't help, it's me. i remeber i presented some of my paintings to a artist in the netherlands and he enforced me to do more and that he can see i could get some out of it, but i'm still not convinced. i guess i'm cowardice one could say. farther every "i don't like it", which is common and i have to expect such, tears me down ten times more rather a compliment could upright me).



    argh, it's shitty to have a inferiority complex, you get nowhere and often useless agressive...
  • edited 2:51PM
    ok, i found out why i couldn't get it running properly now.



    yes, i remember i've read such on the issue tracker (i guess), you removed the .mtl parameter.

    very rarely used and never fully supported anyway.



    i know that i'm by myself often recommended not to use it, but actually i don't know if it's good or not ;)

    i guess good, since it never was fully supported, i only stumbled over that.



    on the other hand...

    it's not that bad, i mean perhaps i would have liked it if it would have been fully supported.



    of course this means that the same texture will get used for all LOD's, but anyway you have to restrict them from LOD1 and make a different mesh for LOD1 at least, else you get a remarkable performance hit. farther i stopped since a long time to use different sized textures, this since we have mip-mapping and i have been told that it's as good as to use different sized textures (right?).



    still a voice in the back of my head is telling me that it perhaps might be still clever to use a very basic small texture for LOD2 instead of the full sized sheet.

    e.g. like what you've got in many games, a little "box" on which you plaster a "lookalike" texture (like a shot from each side of the model).



    though i'm a little torn... was it good or not :?



    anyway it's fact now and i'm happy that i found the reason at all. :D






    not without to squeeze a little tear out of the corner of my eye, i think it's not a complete bad idea to give up the scripted geometry.

    but if you do so, do it quick and painless :mrgreen:



    that would mean some models won't work anymore,

    actually since my PC isn't running yet i'm not able to make quick conversions of the scripted models, else it would be no problem to snapshot them with OGLE.
  • robnrobn Pioneer Developer
    edited 2:51PM
    potsmoke66 wrote:
    yes, i remember i've read such on the issue tracker (i guess), you removed the .mtl parameter.

    very rarely used and never fully supported anyway.


    Not sure exactly what you're referring to, but nothing has been deliberately removed from LMR for a long time (if ever). If you could point me to the issue or post where you read that this was changed I can investigate it and see if a bug has been introduced somewhere.
Sign In or Register to comment.

SpaceSimCentral

| The largest Space and Scf-Fi Gaming Community
@ 2008-2016 SpaceSimCentral.com, All rights reserved.
Powered by VanillaForums, Designed by ThemeSteam

Contact us

Like I am going to give you my phone # :)

Get In Touch