it was supposed to run with 24frames/sec and a total duration of 72 frames resp. 3sec.

but look two things i thought about,

max will use the data of the collada model which is needed to make it portable, means there must be a lot of data in the file to make it possible to rebuild the project.

especially animation data, since a pure matrix can't be resolved, at least i never have seen a matrix animated model loaded proper into a editor.

the thing is i guess , that a editor will handle animations almost as i did in a script, with the difference that you don't notice the many things going on in the back.

though to regenerate the animation how it's needed for the editor to have a little more data as the matrix alone, else you will have a situation like when you open a .x mesh.

parts are displaced, some data is lost, because the software would need more information to regenerate the animation with expressions.

expression -> matrix works, but matrix -> expression won't work. it's not possible to resolve the original expressions used from the little data stored in a matrix.

exactly this data must be stored in  a portable format, else it wouldn't be possible to open the model proper in the editor.

what i suspect now, is that "we" take the wrong data.

if we look at the facts,

pioneer plays it back "wrong"

max plays it back "wrong",

the viewer plays it back proper.

how could that be?*

we leave pioneer aside and guess what could be the difference between a viewer and the editor.

the difference is, the viewer only plays back stupidly the matrix animation.

the editor uses the additional data to regenerate the "original" animation or scene.

looks like it's possible to fix it from my side,

but on the other hand if it's true that pioneer uses the data to regenerate the animation like a editor does, then it uses the wrong data.

on a fixed timeline like we have for the landing gear it should not matter how long i set the timeline, neither how many fames/sec or frames i use at all.

to move something linear along a track 2 keys have to be enough, if not, something is wrong.

you can see that this is true if you take a .x mesh, no matter how many frames/sec, no matter if i use 10 or 1000 frames for the total animation, the result is always the same, because this isn't needed to animate it on a fixed timeline with a fixed framerate.

the same i expect from a .dae, else the preview won't work so well,

but there is also different data as needed only for a matrix animation, needed to resolve the animation.

but however, not a very good format imho to make it easy...

it prob. belongs to the web, but not to a game, i feel.

or a corvette is to win a race, a "DAF" to truck hardware. 😉

*differences aren't "possible", i.e. if a .x mesh animation is played back wrong in a viewer, you can be sure it will do the same in the game and vice versa.

i guess i'm not completely wrong if i expect the same of .dae, with the exception that collada stores a lot more as only the matrix animation.

i guess the problem is to "grab" the proper data out of this "tohuwabohu" of a .dae. (remember the small error with the material name and ID, small but such things show me that if something small could get so easy "misinterpreted", what about the more complex things? it's like when i see a tool with a little defect, i won't use it anymore, i didn't trust it, especially if it's something "small" which should be easy to see, maintain or fix).

from my pov you can't say it's "wrong" only because max can't resolve the animation proper, it can't resolve a .x mesh as well and many others to.

of course .dae should be portable that's what it's ment for, but sorry as long as it works proper in a simple playback it's at least ok, if not good.

but good or not good,

one thing for sure a more simple format like .x (which isn't intionally made to "exchange digital assets", it's made to drive games models) didn't allows such errors, it's simply to simple, there is not much or nothing that could only possibly be misinterpretet.

at least a "signal lost" you will never have pointing on a icon of a .x mesh (lol, don't take that serious, but it's true)

i don't know if you understand what i mean, it's simply not made for what we use it i feel, it's made for presentations, for web publishing, it's cool, nice whatever.

but difficult as anything that allows to perform such cool tricks as to play back a tiny animation in a thumbnail (besides i hate such, the result is always the same, bugs are waiting on the next corner for you, for sure. imho we will pay a price once for this...)

perform 0, 1, 2, 3, keys according to their matrix, no "disturbing shit".

there is no "extra data" and by default not even a material name, since the material could be read from the mesh.

maybe another example,

complexity "kills",

i'm a silkscreenprinter, you maybe know already, back in the late 80's digital control moved into industry fully.

of course we had to have such a modern "tool", a 10tons heavy and 30 meters long "tool".

of course "gernötli" was predestinated to work with the "new toy".

but i learned to hate that machine, that crippled thing had more blackouts as i have when i'm drunk.

the machine didn't worked proper most of the time, while the old electromechanical, run and run and run and run and run and run.

it's not that the digital control would be really a bad thing, but it's extremely complex and extremly sensible,

errors are programmed (not intentionally programmed, but to foresee).

just to explain why i like, no prefer simpliticity in certain cases.

to compare further, well to look into the old electromechanical controlled machine is like you look at a wavefront or a .x mesh, neat and clean, proper arranged easy to examine and to understand. if something has failed at all you could really smell it and i mean smell it, it stinks if a relay burns.

i know it's a bit a long way with my thoughts back to collada.

but i feel it's a bit like my "beloved" digital controlled machine, a "cool toy", a "fantastic technology", "amazing" what i can perform with it (except to cook a egg).

but leaks exactly in complexity, fails often and it's a hell to maintain.

while let's take a look at the result...

you won't see any difference, you can't tell if i used a digital controlled or a conventional mechanical controlled,

but the one who has to work with it can tell you the difference for sure.

and it's not that like one would assume, and also i assumed it would make my work easier, vice versa, it has made my work harder.

plus the "bonus" to hire a programmer from time to time to fix the broken "computer".

well, no change in result?

no profit in worked hours?

a additional well payed man?

summasummarum

a bad thing, not clever, not profitable.

reason,

(over)complexity, to much comfort has resulted in the opposite.

---

further you might guess i'm not able?

ok, we will see what happens to the models of other contributors, i know i'm "lousy" and dindn't even give a damn about that 😉

probably i'm really lousy, but most of a i have been called lousy.

if we have the first animations not made by me which use a little more as only a translation in one direction.

but well if you or someone else can really show me the error i made, i accept that as well.

but if it's needed to have a timeline for a model whichs animation is driven by a fixed framerate and duration, i dont' know who's wrong then.

it's not needed and it seems the viewer doesn't needs that to, it gets played back exactly how it was made.

again import to max tells nothing, only that the animation cant be resolved.

if pioneer shows the same effect as max then pioneer uses the wrong data, the one which is needed to resolve the animation instead of the simplified matrix animation.

at least thats how i look at it, i'm pretty sure i get countered, everyone will say i'm a idiot,

just to find out half a year later that i was right, it's "common".

---

sorry for the long text, if it helps you won't hear a word from me next week until weekend, so"enjoy" this. 😉

also this is a bit the reason why i'm in a "hurry", i need some stuff to take with me as homework.

after all not a really bad situation, a bit complicated to port things on a micro SD, but on the other hand i can work undistracted when i have no access to the web and make usually better progress then.

something certain was on my mind...

ah, well, i will link the blender project, for those who like to take a look at it, probably there is something i have overseen.

but i dindn't think so.

don't be surprised that the animation will start at frame 1 instead 0, frame 0 hasn't exeisted in blender 2.49, it's still my preferred blender since i'm used to it, it won't play a role and the collada export script works as good as the one for blender2.6, but i dislike the "max" feel of 2.6 and formost like i said i'm used to work with 2.49 and the new interface i have to get common with, if at all, as long as the result is as good as with the new releases i see no reason (of course there are some who believe only the newest will bring good results, but a broom cleans only as good as the one who uses it. to learn often a new UI cost useless time imho. and besides most changes from 2.49 to 2.6 havent tangent things you need to build a spaceship, certain things have even get less good, like always. it has changed that much that i continously press keys in blender2.6 which didn't exist anymore).

it is like it is, first i was annoyed by the way of old blenders UI, later i wouldn't have liked to miss it.

further fish, in blender you don't have a "fixed" preassumed timeline like in max, the 100 frames are default as i remember and if nothing else is specified max assumes 100, well yet another assumed thing i don't like, computers and software should never guess.

the timeline of blender is endless until i say it stops at this frame, no preassuming of a software.

again it's not needed for a matrix animation, they get played back from first to last key in the speed of the specified framerate, which is in the case for the landing gear overridden, means fixed framerate and duration i can specify what i like, a landing gear animation lasts 3sec in pioneer.

2 keys or 200 keys, 3fps or 300fps, that has no influence or shouldn't have and shouldn't be readed in no case.

neither that most meshes wil contain something like a timeline, it's ONLY needed to resolve a animation, but not for playback.

in case of doubt take again the .x format, there exist nothing except the keys i set and the framerate if that is used at all.

and they work, in the game, in any viewer, whatever softs that handle .x meshes.

sorry fluffyfreak, i'm really not sure which is "buggy", i feel .x is stable, where could hide a bug in a near to clinical clean environment?

but if i look at the collada html "shit", i feel like bugs are awaiting me everywhere, it's like you move into a cavern.

but if i understood you right the collada models have to be "prepared" first to get used in the game is that right?

isn't that already a bit clumsy?

and is such not predestinated to produce bugs of whatever sort?

i'm just asking.

prob. there is something better as .dae? mustn't be .x but something else "clean", something which is error proof like a relay.

i didn't feel this web stuff is really error proof.

something that is not portable, because i predict any portable mesh format will bring problems, else we could take a max or blender project.

i mean collada is not far from that, it's a fully portable project, it could include a scene with lighting and a background, that's what you would use it for if you use it for models. all this project data we don't need in a game and the way animations or a matrix gets written for a resolvable animation isn't probably very good for our purpose.

---

yes it's true i can't accept that i have made a error because there is no error.

two facts,

the same shit works proper as a .x mesh.

the .dae gets played back proper in the preview app.

only pioneer and max can't resolve the animation, which is in case for pioneer the wrong way i guess, it shouldn't be resolved only played back.

but as i said no wonder .dae is a "mess" from my pov.

who could ever know which data is used for what, if it's already not clear what is "material ID" and "material name"?

confusing in this little shit, what have i to expect from the rest then?

certainly nothing neat.

---

i stayed a little longer here, intentionally i would have travelled home today, but i'm to curious.

i really like to know your comments, thoughts and arguments 🙂

while i will pick up a different model to see to what "shit" or "gold" it turns with collada.

it's not that i hate collada, in the beginning i thought it's a good choice, but i learned to dislike it.

take a quick look at what i have been working on today

http://dl.dropbox.com/u/98265626/siegeBarge.7z

its far from ready and only works in the model viewer but should give you some idea of how it should work try importing it in blender aswell

first intersting fact, "i slipped" (not really) and opened the .dae with OSX's default app "preview", it couldn't be opened with it?

something smells "fishy" (sorry has nothing to do with your nick)

if i open your model in blender it works well, but i noticed the animation ends but there is no key set, i was already wondering how that could be.

ok, then i (re)opened my lancet .dae, which i haven't so far, even more strange i have not a single key and the animation works, fully to my own surprise, i expected rather a crippled one.

situation is now, max "fails" to load it proper, pioneer "fails" to load it proper, the preview app plays it well, blender loads it well and plays the animation proper. ok. it's made with blender2.49 using a collada1.4 export script, but loads proper to blender 2.65, i had some problems with 2.65 to export a working model at all (that was the one which leaded to "signal lost", but will try this also to see if there are really some differences.

but hmm... this only shows to me it's not suitable for a game, each is a bit different as i expected in the beginning, it's not the same if you export from blender or max.

it's not the same under whatever conditions who could know and i think such isn't good to exchange games models, just as a general thought.

so still i can see nothing wrong with my model, but something is wrong, what is a riddle and probably not to solve.

what if a mac release of blender produces different .dae files wether a win release?

(or any else idea why i can't open it with the preview app? anyway useless, with one OS it works the other not? one cad works one not? that's certainly not the right format for pioneer. as longer the more i'm convinced of that)

this is let's say "not good" (to be kind) from my pov.

like i said "signal lost" (we don't need such, we need something reliable that works with any OS and CAD)

---

i like the bolts, looks pretty "heavy metal"...

right now i have a idea what the reason could be, thinking of why i have no keys in my imported .dae.

i will check this imm.

on the other hand i din't think they are absent, else the model would have failed to be loaded in pioneer, if a key is specified wrong in the model file it already refuses to load it, if there is no key and you specify a start and end it refuses for 100%.

also i noticed your anim is made with rotation only, while mine uses translation and rotation together, should be no problem, but could be a reason in  some way.

though i'm not convinced that any of my ideas will help at all, i suspect not, like i said i assume it's not useful for us.

just by looking at the many differences from CAD to CAD and prob. even from OS to OS i can tell this is "not good" (guess yourself a four letter word).

since collada is also open source anyone can do with it what he likes and exactly in this way it appears to me, chaotical, there is no "boss" who tells "stop, until here and not a step further, or we lose compatibility".

also since collada is open source and very tight with blender, max can't be reference, max is reference for max or .3ds.

one could say blender is reference for collada, even if that isn't 100% true.

it's a rather "bad" interchangeable format, because it seems it's not the same.

of course not a bad idea to have a interchangeable, portable format, on the other hand, not everybody has to examine my models i feel...

perhaps even some feel the same or think at all they don't like if one only touches them.

there was times when my models have been rescaled and handled like shit, i really wished i could encrypt them.

not because i don't like to see my models spread, but i hate, like any modeler, when things get changed in such a evil way.

you planned it, you modeled it, it's up to you if you think it's to small or to big and not up to someone elses imagination.

i have no problem to share them, but respect the work of others as i do myself.

i copy, i transscript, yes, a lot, but usually i ask and if not or otherwise i hope i always kept the original intention.

(e.g. steve argued once about that he wouldn't have put a pilot in his viper, 5mins later the pilot was "dead".

i didn't even changed the scale, even if i'm convinced that the model export of ffed3d is scaled wrong, it uses one unified scale.

years ago it was a guessing, now i know, since i examined th orbital city and recognized that the parts of which the station is made are scaled different in the exported meshes, conclusion, scale is unified and wrong, FFE/FE2 scales models dynamic, this has been neglected and the models have all the same scale, but that isn't the real situation in FFE/FE2. a tiny spike could be on a different use a 100m tall needle. i have to say i never found the proper scale myself. i assumed it would be to resolve from the objects data. there are three scaling values, one is the bounding radius, two are left. two? hmm - however i used them on the integer values of the model it never resulted something senseful, actually i assume it's a table and the data requests only a value from the table, somehow i imagine this would be faster and saves also a few bytes, which was very important to get FE2 on a single floppy).

Gernot, please stop saying that it's not suitable for a game, it's a brand new system and there are teething troubles. That's all.

Also, OMG HOW MUCH TEXT!?! 😉

Okay, we get that you liked LMR and you think this is more complex, well in some ways yes because it's trying to do more than LMR. That extra complexity is inevitable, and we would have added it to LMR *if* that had been possible. Another reason for this new system is that it wasn't possible!

Also DAE is the format that has been used, it's the one that Luomu tested with (using Blender 2.64) so he was confident that it would work when you tried it. It should work the same across MAC, Windows & Linux if they're all the same version of Blender (2.64). I've noticed problems with 3Ds MAX 2010 and DAE but I knew that version would be a pain anyway.

Right now it sounds like you're animation problems will be fixed when you figure out what your doing wrong and I'm simply not going to read that HUGE wall of text to figure out what else is up or read about silkscreening processes  :alcoholic:

@potsmoke66

take a look at mine again (download it again because its been updated) it now has position changes aswell as rotation

its still somewhat basic but shows that you can have several chunks animated in different ways in the same animation

http://dl.dropbox.com/u/98265626/siegeBarge.7z

Postmoke66 you just need use blender 2.65(2.49 ancient), in 2.64 release  .dae export was totaly  improve: http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.64/Collada

i liked it yes and i'm a bit sad to loose it, thast's all i guess.

for my dislike of collada, sorry in a sort of way not my fault, i'm "luckless" with it, not because of implementation leaks. it's obvious, it won't work in a "few days".

but i struggle a bit with it, have a lot of problems to get it properly exported and can't see a real reason behind.

let's me guess, or i ask myself if it's a good decision, that's all, i mean if i have such problems, not that i would be a luminary, but what about a nube?

nah, perhaps...

some things i didn't tried yet, a had dinner and watched a bit tv with my mom, talked a lot about her life as a child.

prob. only collada1.5 will work proper

the problem is if i export it from blender2.65 it didn't runs at all, the model won't be loaded.

already my OS gets confused by the file (watch the clip "signal lost", that's what happens on my mac with a .dae exported by blender2.65.

it get's recognized as "something else".

neither "fish's" model get's handled proper by my mac.

ervery model depending on CAD and OS acts different that's a fact and somehow this let's me think if it's good at all.

prob. it won't run at all?

i don't know, but one thing i know,

it didn't let's me trust in it.

but, i don't give up so quickly, i will see if it's not a fault from my side, at least if it's only to be sure i didn't made a big fault.

but nonethelees, you must give me right in this point, it's not useful to examine or edit a .dae file.

i guess i will never be able to add a second animation, probably you, but not me, it's to me a "sealed book", i don't know a shit about XML.

but also i see no good reason why "we" chose collada,

or can you tell some advances of it, useful for spaceship models, a different format didn't offers?

i mean, i simply don't know a shit about collada.

if it's really so periculous as it appears to me, to export it in a useful way, it must be a damned good reason.

portability is not enough for me, i can live without that.

but i can't make models if it won't work well or if the result is unpredictable.

already if i have to respect this and that condition, it's also not very good from my pov,

because you will have to explain this "special cases" to "everyone" and "everyone" will stumble over such, i'm pretty sure.

i know also most meshes, whatever format, won't be exported proper without to follow some conditions of the export script,

but less is more, no question.

actually i assume it won't work for me at all, that's no unwill of me, really not, else i would say "it stinks" and simply turn away.

could it be that mac osx...

wait i took a brief look at the "terminal" under OSX,

wow, only faults

failure, failure, failure, when i loaded a .dae model to blender i.e. ???

i didn't knew a mesh can produce so many errors...

something really smells "fishy"

well, you chose the proper format, the one gernot can't participate anymore, lol.

do i expect to much if like something that is as easy to export as a .x mesh? no not "easy", SAFE!

at least that works, no matter OS, no matter CAD...

wouldn't it be sad if you would have to say:

"erm, sorry fellows if you use this or that OS or this or that CAD it won't work"

of course, i assume right now i will have far less problems with the "rotten" PC...

but it's only good that my mom's macbook is such a "special case" which didn't accepts everything,

it has annoyed me often enough, just think of that i have to use the teminal to participate on github, the needed softs refuse to install or run.

or that i can't compile a program, since something is missing and the needed softs refuse to install.

no, i can't throw it out of the window, we both aren't wealthy enough to do such.

the "wealthy" guys in our community should learn to accept that certain things are not in the range of possibilities for some,

that certain people won't own the latest top notch machine and OS.

they need the money for bread and butter, dammit all of it! (it just reminds me of the debate i had with a dude who lost his job and was telling me he didn't get's payed enoough by welfare, SFr 3800 as "flat" costs?

wow, i said, i earned 3000 brutto, had a wife and two children and you say you need more then this amount only for the steady costs?

well, sometimes i feel some lost touch with mother earth (reality) and it's not because of LSD, else i would have lost the ground under my feet since a long time, trust me in this case (probably i have lost it and only didn't know it).

cheer up, i will do my worst

Leech, exactly such posts i expected, oh i guess i use all of them, lol.

means i'm such common with the old interface that i will build only with 2.49, ancient or not (ancient? the roman empire is ancient).

if it's needed because some fileformat has changed (e.g. collada) i still can export it from 2.65.

it's just i don't like to waiste time with learnig a new interface, i would be happy if i understood all features of 2.49.

besides, apart from such changes i didn't see a real profit of using 2.65 for me, but some think only the newest is best.

while me is a different person, if something is good it's good, the new things have to make proof first that they are really as good as the previous.

but if something new is good, i'm the biggest fan of it, you can be sure. so for the new GIMP, i like, no appreciate extremely that it can be run now "fullscreen".

no more messing cluttered windows, everything on one screen (remember my arguments against gimp, fluffyfreak? yeah i still miss a simple "circle" "quad" "polyline", sometimes it's much better as to work with paths, but i guess i will post my wishes on the gimp portal. the path is a good thing, but 1st it's "slow" if i like to get a quick polyline, 2nd i would like to be able to switch between "polygonal" and "bezier" in the same drawed line, i don't need handles just a simple bezier or polyline. the path also looses it's original shape when you store it, so it's not really good to draw polylines or to create a box, check the "crippled" rectangles on the "lancet" skin. there is no good way to make the path really polygonal, i would be already happy with "handles / no handles" or "remove handles" to make the curve to a polygon).

now i can really use it, of course helped has also that i had to use gimp on the mac, i didn't found any suitable else.

and like blender, once you are common with gimp you will never like to miss it.

it must be a really good reason to change in general from 2.49 to 2.65 for me, since it will take double time until i'm comfortable with the "new" UI.

but also somehow i assume as soon as i'm comfortable with it will change again...

on the other hand it has changed again a bit and looks at least a bit more as what i would set up for modeling, i'm old fashioned, i know.

but the real crux are the things under the suface.

i know it's the point for most why they refused to use it before and it has been changed certainly because "john and henry" argued they can't handle the (old) blender interface.

guess to me it's vice versa, not that i can't handle it, but i feel uncomfortable with th UI since 2.5x.

and Leech, erm...

blender 2.65 exported collada refused completely to run with pioneer on my mac.

refuse completely and confuses also the OS, hmm... i guess because of XML?

it performs at least shit on it.

works so far now,

i didn't changed one "screw" on my model, except to move the ipo curves from start @1 to start @0 for blender 2.65.

but i did this each time i tried to export it with blender2.65, so neither this has really changed.

further this shouldn't matter i guess, if the start/end frame is properly set in "lancet.model".

it seems it depends on the day or whatever...

something which is not really under my control at least.

erm one little difference, but i'm not sure if it's the source of the problem.

the direct.x export script needs to have for every object at least one animation key if you export a animation,

else it wont' export the mesh.

this little uncommon setting i removed now for the .dae model, but i didn't think it should hinder something, but i don't know exactly.

prob. pioneer "dislikes" it? i mean there is only one key at start and no end key, for the .x meshes it hasn't played a role, nonetheless i removed the needless animations always from the .x mesh, since that is very easy done.

which i surely not did for the .dae, i don't know where to find that exactly in a .dae. neither if it's so easy possible to strip a animation from the model without "destroying" it, seems that stuff is all linked in some way and i assume if you simply remove something it will be broken afterwards.

it is at least not only a simple mesh as .x or .obj.

don't get mad, but that's the first point i dislike at collada, it's not user maintainable, i can't see what's going on so easy.

it's already hard to figure out where to alter the root frame matrix, if i would like to once, to scale or reorient in a simple and safe way (if you alter the root frame matrix the whole model get's altered incl. animation, much better as to scale or reorient a finished model in the CAD and prob. loose the proper keying). or should, i don't know how collada acts on this, neither i know if there is a root frame matrix at all.

it's unfortunately a bit a "blown up" format, really not easy to maintain. from my pov we don't need 50% of what's in a .dae stored.

that's why i dislike it a bit.

it works, but i couldn't say that i really like it, not before i know what's really behind this behave and how i can control it.

don't mind 🙂

i will see, right now i suspect even collada 1.4 should work, i suspect, according to the behave of the model .dae starts always at frame0,

even if frame1 is set as start in blender (well, neither something i really like, if i set frame1 as first key i expect naturally frame1 is key1 in the exportet model, i have no x-ray vision and i didn't scripted it so how could one know such? that they was so intelligent to change the start frame for .dae.

i mean i did the same with the .x export script, but i did it, of course i know what is to expect then).

at least this will be my next experiment.

"unfortunately" blender2.65 makes my altered .x export script redundant (except for the "legal names" i changed a bit to make it a little safer), since it starts even at frame0 now,

no it does this since 2.5x i guess, and it's good and not bad.

well prob. i'm able to change this or that on a directx or wavefront export script, but collada?

i have no overview to the model, i guess to alter the script (if i would ever like to for whatever reason) exceeds my capabilities for sure.

---

what i still dislike a bit is the change from righthanded to lefthanded.

i really have some reservations, actually it's a mix?

isn't such a source for possible errors?

if i remember right the whole game is righthanded not only the models.

just as a Q

and a possible source of this?

as soon as you release the pause it's upright, but when i start a game this or this is to see

Mmm... Although I hear a lot of grumbling, I perceive that you are enjoying. :))

mumbling and grumbling...

yes.

sometimes even stumbling

worked together like cat and dog or what? 🙂

oh, i would have a similar picture as the "angry cat" with a dog, playing with the globe like it would be a toy.

i had planned once (long ago) to make a serial of such pictures, a whale playing with the earth exists also, both unfinished.

sometimes i stop from painting because i feel then, it's totally naive what i do and the pictures get hidden somewhere.

 the "angry cat" with a dog, playing with the globe like it would be a toy.

A cat playing with the globe, did you say?

ok, clean install and I get the following error on Alpha 30.

Error: Lua custom Systems definition: Surface starport is underwater (height not greater than 0.0) and has been automatically relocated. Please move the starport to another location by changing latitude and longitude fields.

      Surface starport name: Cydonia, Body name: Mars, In sector: x = 0, y = 0, z = 0.

Error: Lua custom Systems definition: Surface starport is underwater (height not greater than 0.0) and has been automatically relocated. Please move the starport to another location by changing latitude and longitude fields.

      Surface starport name: Dante's Base, Body name: Io, In sector: x = 0, y = 0, z = 0.

libpng warning: Interlace handling should be turned on when using png_read_image

LoadSurfaceFromFile: lmrmodels/buildings/buildings_p66/bldp66_sirbld_stalk.png: could not read file

Error: OpenGL error(s) during frame:

GL_OUT_OF_MEMORY

Mods installed are:-

buildings-space&groundstations-alpha30mods

Pioneer-Scout-Plus-light

ships_all_in_1_alpha30mods

any idea what is happening? There seems to an issue with the buildings-space&groundstations-alpha30mods.

launch from earth, turn 180 degrees and head towards the bottom left of the mushroom shaped building.

I have just downloaded the alpha 30 version you posted and I still get the same error after doing a 180 from Los Angeles...

Error: Lua custom Systems definition: Surface starport is underwater (height not greater than 0.0) and has been automatically relocated. Please move the starport to another location by changing latitude and longitude fields.

      Surface starport name: Cydonia, Body name: Mars, In sector: x = 0, y = 0, z = 0.

Error: Lua custom Systems definition: Surface starport is underwater (height not greater than 0.0) and has been automatically relocated. Please move the starport to another location by changing latitude and longitude fields.

      Surface starport name: Dante's Base, Body name: Io, In sector: x = 0, y = 0, z = 0.

libpng warning: Interlace handling should be turned on when using png_read_image

LoadSurfaceFromFile: lmrmodels/buildings/buildings_p66/bldp66_sirbld_stalk.png: could not read file

Error: OpenGL error(s) during frame:

GL_OUT_OF_MEMORY

There seems to be an issue with this texture...lmrmodels/buildings/buildings_p66/bldp66_sirbld_stalk.png and something about interlacing. Now I am sure this is nothing to do with tying shoes.

Edit: could it be because the file does not actually exist?

Another Edit: That's only part of the problem. I created a texture with that name and now the error I get is..

Error: Lua custom Systems definition: Surface starport is underwater (height not greater than 0.0) and has been automatically relocated. Please move the starport to another location by changing latitude and longitude fields.

      Surface starport name: Cydonia, Body name: Mars, In sector: x = 0, y = 0, z = 0.

Error: Lua custom Systems definition: Surface starport is underwater (height not greater than 0.0) and has been automatically relocated. Please move the starport to another location by changing latitude and longitude fields.

      Surface starport name: Dante's Base, Body name: Io, In sector: x = 0, y = 0, z = 0.

libpng warning: Interlace handling should be turned on when using png_read_image

Error: OpenGL error(s) during frame:

GL_OUT_OF_MEMORY

      Surface starport name: Cydonia, Body name: Mars, In sector: x = 0, y = 0, z = 0.

Error: Lua custom Systems definition: Surface starport is underwater (height not greater than 0.0) and has been automatically relocated. Please move the starport to another location by changing latitude and longitude fields.

      Surface starport name: Dante's Base, Body name: Io, In sector: x = 0, y = 0, z = 0."

"There seems to be an issue with this texture..."

I have not had much time to test the mod Vuzz. Would have to check compatibility. Or perhaps a corrupted file.

Hi Walterar, yes it's good to be back.

With a clean install and no mods I get this.

Requested AA mode: 2x, actual: 4x

Error: Lua custom Systems definition: Surface starport is underwater (height not greater than 0.0) and has been automatically relocated. Please move the starport to another location by changing latitude and longitude fields.

      Surface starport name: Cydonia, Body name: Mars, In sector: x = 0, y = 0, z = 0.

Error: Lua custom Systems definition: Surface starport is underwater (height not greater than 0.0) and has been automatically relocated. Please move the starport to another location by changing latitude and longitude fields.

      Surface starport name: Dante's Base, Body name: Io, In sector: x = 0, y = 0, z = 0.

Error: OpenGL error(s) during frame:

GL_OUT_OF_MEMORY

So we can ignore the surface starport is underwater errors, I imagine they will not crash my game.

However the OpenGL error saying it has run out of memory does. I'll create another thread for this issue seeing as it is nothing to do with mods...

Error: Lua custom Systems definition: Surface starport is underwater (height not greater than 0.0) and has been automatically relocated. Please move the starport to another location by changing latitude and longitude fields.
      Surface starport name: Cydonia, Body name: Mars, In sector: x = 0, y = 0, z = 0.
Error: Lua custom Systems definition: Surface starport is underwater (height not greater than 0.0) and has been automatically relocated. Please move the starport to another location by changing latitude and longitude fields.
      Surface starport name: Dante's Base, Body name: Io, In sector: x = 0, y = 0, z = 0.

Red herring. Not model/texture related, and not really an error. I need to simplify that message a lot.

libpng warning: Interlace handling should be turned on when using png_read_image

Might be a bug for us. I'll look into it. I doubt its affecting anything here though.

Error: OpenGL error(s) during frame:
GL_OUT_OF_MEMORY

That's your culprit. You've got every model in the world in your game, and we try to load them all into graphics memory at boot - we have no stuff to load/unload stuff. Probably not much you can do right now except remove a few models.

I'll do some reading soon and maybe open an issue to get some support for unloading unused models (if that turns out to be an actual thing).

I can't make out your pictures (they only open in thumbnail size for me) but I think I read somewhere that A30 uses the bottom of the collision mesh to calculate the landing height, and the collision mesh probably does not surround the undercarriage?

Perhaps this is a property of a material. Its ability to repel?

Vuzz its like Zordey said make sure that your collision mesh includes the open landing gear

deleted

deleted