Jump to content

firefox5926

Members
  • Posts

    14
  • Joined

  • Last visited

Everything posted by firefox5926

  1. OK so this idea is stolen straight out of flight sim x for those of us lucky enough to have 2 or more screens it would be nice to be able to undock the orbital/map view and have it open of a second screen (undock means (as best i can tell) to open it int a separate windows window)
  2. mean while on the outskirts of town ... did bac9 just say After all, there is still a pile of unreleased parts over here. ... .... new...unreleased...parts... as in shine new parts?? and everyone else is talking about sabers...
  3. in that case if u could allow the docking ports to be docked in the editor and make there connection as strong as a normal part then...is that possible ie like a node attached strut instead of a surface attached strut
  4. i see your point. but just want to throw some ideas out there. i know that u can connect at least two branches together with docking ports but only i believe after the physics has loaded after the vab/sph. now if the physics engine was enabled in the editor then that could be allowed to happen inside the editor and instead of using docking ports could be applied to the node system. then most of the code i assume could stay the same since it already works in both scenarios and just patching the docking port code into the node system. as for how it would be save it maybe could be saved as some sort of proxy node that only gets saved as a connection if the to nodes are withing a certain proximity to each other. but u know what they say about assuming it makes an ... anyways i was told no questions to stupid to ask and no ideas to stupid to say maybe like save run check node is node connected yes/no if no is node within xyz of another unconnected node yes/no if yes if check for manual connection flag yes/no if yes then save as connected then again now that i think about it this would only be a quasi mesh system cose it wouldn't work with surface attachment unless u were to define the edge of the part as a line of nodes placed close together or a gird of nodes very close together and then finding witch of them is closest to the node to be attached but im not sure how computational taxing that would be but then again if it were done so that node attachment wasn't connected to the animation then approximate node alignment wouldn't be necessary as any node pair below a certain distances would be connected regardless of whether the objects they are attached to look like they line up and any node pair above a certain distance wouldn't ie when the object appears to the eye to be out of alignment
  5. ok after doing a quick search of the what not to suggest and the forums and no seeing this here is my suggestion or at least question why are you using a tree type network topology for construction or at least why haven't u changed it to a say a mesh type or a fully connectable type see diagram http://upload.wikimedia.org/wikipedia/commons/thumb/9/97/NetworkTopologies.svg/508px-NetworkTopologies.svg.png i don't no how much re-codeing it would take but it also occurs to me the the longer u leave it the more codeing you'll have to redo when/if u do do it so it would be better to do it sooner rather than later i bring this up because the tree type network is quiet limiting especially for aircraft not so bad for rockets but still limiting anyways thats all i have to say about that ...probably not anyways keep up the good work viva la ksp
  6. sorry i forgot to mention also the cargo m2 adapter and the cargo m2 body thx
  7. hi i wasn't sure to put this in add-on support or here but since add-on support didn't have a b9 page i thought i would go here any ways my question is regarding the s2 wide bodied parts and the m2 cargo parts not having surface attachment node coordinates but the s2 (slim bodied ?) parts do i was wondering why but more importantly does anyone know what they would be so i can manually add it to the con
×
×
  • Create New...