HarvesteR

Yes, when defining an attachment node, parameters 4, 5 and 6 represent the direction of the 'up' vector for parts connected to that node. node_stack_bottom = 0.0, -3.02662, 0.0, 0.0, 1.0, 0.0, 1 So, by default, these are set at 0,1,0, which means the up vector points up. But if one were to change those values, to, say, 1,0,0, parts connected to this node would be sideways. Cheers

Yeah, the planet is insanely dense This little departure from realism is because the planet must be smaller than Earth, so as to make orbiting a more dynamic and fun experience, but the force of gravity must 'feel' earthly, so that means the planet needs to be very very massive and dense to make that happen. 5.29e22 is pretty close, I recall someone else did the same calculations, and came up with a very similar number. Interestingly enough, this number doesn't figure at all on the gravity model. Gravity is calculated starting from a G-at-surface value, which is then converted to a G-at-center value based on the square of the distance, so the mass of the planet is cancelled out of those equations. The idea behind this is that it's possible to very easily tweak the gravity values of planets, and also achieve non-realistic, but possibly very fun scenarios. Cheers

What version of the game are you using? In 0.7.3 there was a big stability problem with side-mounted parts. This was corrected in version 0.8. If you're on version 0.8, I suspect it might be related to the mass of the new part (might be too much), or maybe the position of the part's center of mass (version 0.8.1 addresses this, and sets the center of mass of all parts to their origin, as defined in the 3D model). Hope this helps, Cheers

I love the fact that we are having this problem!! The download count was so much higher than what we've antecipated, that we've realised now that our puny little server won't cope with the demand for much longer... So we're planning an emergency move of the downloadable files to a new hosting service. We estimate that if things continue at this rate, we'll reach maximum capacity on wednesday, so we gotta scramble to make that move. We'll be moving the downloadable packages only. The forums and wiki can stay here for now (which is better, since we don't want to risk bad things happening to the databases). Just wanted to let everyone know, in case anyone has trouble downloading Cheers

Some drama during countdown! At T-0:31 the countdown went into hold. A short while later they picked up the count and it was a beautiful launch! Godspeed Atlantis! Good luck on your last mission! :thumbup: :cheers:

Shift Esquerdo - Aumenta Throttle Ctrl Esquerdo - Diminui Throttle :cheers:

Hello once again! KSP Version 0.8 is now up in the Downloads section! The new version includes the following changes: New for v0.8: * Saving and Loading buttons in the interface, as well as a ship loading dialog for picking new ships. * Ship name field in the editor, allows saving ships with any filename. * Screenshot button to capture the screen to file. * functioning MET indicator in the flight UI * Pages in the VAB part list, whenever the parts exceed the size of the list. * New skins for the UI windows that pop up. (like the flight results dialog) * A new splash screen before the main menu enters. * SAS toggle with 'T' key * Option to Simulate in Background in the settings.cfg file * Undo/Redo actions in the VAB, by Ctrl+Z and Ctrl+Y * Fuel tanks are now stackable to increase fuel amount (and weight ) * On-screen text popup to let you know the current camera mode * Cfg interpreter can now parse 2D, 3D, and 4D Vectors, as well as rotations (in angle-axis format) * Cfg-defined thrust positions and orientations, make retro-rockets and any other craziness open for addon parts. * Parts may now create new stages for themselves through the cfg (used to be decouplers only) * New texture for the Solid Rocket Booster * The game now checks for updates against the KSP site, and let's you know if there is a new version available * Loading screen moved to before the main menu appears. Bug fixes: * Liquid Engine particle effects responding to engine cutoff * Icon indicators for all parts that need to show information * Custom icons for all part types * VAB placement bug with tricouplers and fuel tanks (and decouplers) * Pause also affecting particle effects * Pausing the game no longer produces a G-force peak * SRB mesh normals correction * Complete rewrite of the flight camera code. No more jitters and a number of new options in the settings.cfg * Relaunch button on pause menu. No need to end flight to relaunch. * Version text on main menu resetting after returning to it from game. * Inverted the middle mouse button zoom. Now mouseing forward brings the camera closer. * The text on the stage indicators no longer appears over other interface elements * Fixed excessive wobbliness with side-attached parts * Radial decouplers now have their own module (they used to share modules with the stack decoupler) * Increased the inclination range for the VAB camera from 45° to 80° * Updated tutorial to reflect the changes made in this update (like the new cameras in flight). * Tweaked the Radial Decoupler separation. It can now eject lit SRBs safely away from the ship and not kill the crew everytime. Cheers, and :hailprobe:

I've added a reminder about this in the tricoupler's description Easy mistake to make Cheers

Hi everyone! Very happy news for us here! The download count has reached (and passed) the 5000 mark! Not bad at all, considering our best-case prediction was 900 in one full month! (it hasn't been 2 weeks yet) So I'm really very very happy right now!!! Just wanted to share the good news with everyone, and say a great big [glow=green,2,300]THANK YOU![/glow] for everyone who downloaded the game, and especially all who joined the KSP community and are actively participating and giving feedback! This has really been an awesome week! Cheers :cheers:

The Tri-coupler isn't a separator. That's what went wrong The tricoupler is merely an adaptor. And the game analyses the ship you've built, and based on the decouplers it finds, it builds a staging sequence (which can also be edited manually if you happen to disagree with it). So by not adding a decoupler in between the top boosters and the lower ones, they all fired at once, destroying the whole stack About the future of the project, you've pretty much hit the nail on the head there. That's exactly what will happen to the game in the near future, even the features you mentioned. :thumbup: Cheers

Seria algo como um acelerador? O comando de Throttle da nave faz exatamente isso. Ele regula a potencia dos motores, e isso influencia o consumo de combustível. A coisa é que somente motores de combustível liquido tem controle de throttle. Os motores sólidos são muito mais simples. Eles acendem, e continuam acesos até que o combustível deles acaba. :cheers:

Hi, We've been having a little trouble with spam on the forums these days... It seems the bots are capable of going through the captcha at the registration page... So I've set up a required verification for first posts. If you're posting for the first time, you'll see a captcha box (those 'type the letter in the image above' things) before you post. This only happens for first-time posts though. If you're deemed human you can keep on posting normally after that. I just wanted to let everyone know about this. I reckon very aggressive anti-spam measures can make a forum seem unwelcoming, and that's the last thing we want to do. So I hope a simple captcha on your first post (and only on the first post) is a reasonable compromise. Cheers

A data prevista para a versão 0.8 é 18/Jul. Mas é possível que essa versão seja lançada antes dessa data. A versão 0.8 não tem novas peças planejadas, mas se for possível lançar a 0.8 antes do dia 18, estamos planejando subir o update 0.8.1, com novos features, e possivelmente novas partes também. :cheers:

Não sei se entendi exatamente o que seriam essas peças... Atualmente ja é possivel entrar em orbita com as peças que estão no jogo.... Não que isso seja facil Mas peças novas são algo que vão ser incorporadas ao jogo a medida que avançamos. É possivel que o proximo update ja tenha algumas novas peças. (Ou senão nesse, no proximo) Cheers :cheers:

This is awesome man! Very good initiative. Thanks for sharing with the community! Later we plan to set up a more 'official' space somewhere so people can upload and share their addons... for now, the forums will have to do Cheers

Hmm interesting... do you remember what you did exactly to make it work? I'm trying to get information about all possible problems when adding or tweaking a part, so we can offer as much insight as possible on all those scenarios. Nice job BTW! :thumbup: Cheers

Hmm, the CFG entry looks right... what happens exactly? Do you see the node but can't connect to it? Or does it not appear? here's a run-down of the parameters for a node entry... while the SDK isn't up, I'll try to explain everything as it gets asked: node_stack_bottom = 0.0, -1.07, 0.0, 0.0, 1.0, 0.0, 1 node_stack - identifies this entry as a stack node definition _bottom - is a unique identifier for this node now the numbers, in order: X Position, Y Position, Z position, upVectorX, upVectorY, upVectorZ, size All positions are in model space, assuming Y-up convention. UpVector is the direction of 'Up', that is, if the node is supposed to be oriented the same as the ship, it should be 0, 1, 0, which is the same as saying Y is up. This direction affects the orientation of any part that connects to this node. Size is a number, from 0 to 5, that indicates the size of the attachment node. This is to later require use of adapters to connect larger parts to smaller ones (think Saturn 5 and it's cone sections) Also, the 'scale' parameter has an effect on the node definitions. It's used to convert the model-space coordinates in node and effect definitions to the proper scale. This depends on the scale you're working at. KSP uses 1 unit = 1 meter, so if your 3D scene is setup like that, leave scale at 1.0... if, for example, you're using 1 unit = 10cm, the scale parameter should be at 0.1. This is to make life easier when writing down positions for the nodes... this way, you can just get the node's scene position, and paste it directly (you only have to remember to swap Y and Z if your modelling program uses Z-up instead of Y-up, like 3Ds Ma does) The SDK will include a 3Ds Max script (made by Moach, modified by me) that automatically outputs the correct coordinates for any given node. So you can paste it directly to the cfg file. Hope this helps, I'll try to get that SDK up as soon as possible! Cheers

Hang on, I'm gonna see if I can tweak the file size limit for attachments. BTW, I'm moving this thread to the Texturing section. Cheers EDIT: Ok, I've increased the file size limit for attachments. You can try reuploading it now. Cheers again!

Hi, Yes, this is an important detail, indeed Since the parts are all modular, we've decided on a few standards, to make sure all parts will match each other as much as possible. Basically we have 2 standards right now. Later, as more and different size parts are added, we'll settle on other standards as well. So, basically it works like this: For a generally cylindrical part of size 1 (fits under the pod), we use a diameter of 1 meter. The height doesn't matter as much. If the part will accept other parts, like winglets, to connect to it by the surface, the collision mesh should have 12 sides, so it's possible to arrange parts symmetricaly in 2's, 3's 4's, 6's, 8's and 12's. This collision mesh is then rotated 15 degrees, so that there are flat sides on each axis, instead of edges. As a general rule, the main cylinder for the visual mesh is 24 sides, but that depends also on the design of the part. Then there is standard 0, which is for small parts (that fit over the pod), for these, the main diameter is 0.43m, and we usually use 18 sides for the main cylinder. But that, again, depends on design. Currently the only part that uses this standard is the Mk16 Parachute, but later on more size 0 parts will be added. For parts that attach sideways, like radial decouplers and winglets, there isn't much of a standard format. Those parts can have pretty much any format, so it's just a matter of tweaking until it looks good Anyhow, we'll release the SDK shortly, which will explain all this in a lot more depth. In the meantime, I hope this helps. Also, if all the above fails, you can import one of the DAE meshes in the Parts folders, and use it as a baseline Cheers

The most common cause for freezes at startup is when the game tries to load a .dae model, and fails to find a material. It's a problem with the DAE importer. It requires every mesh to have a material, even the collision mesh. So, what I recommend is giving the collision mesh a default, semi-transparent material. It won't be visible in the game anyway. that material gets discarded during the import phase, but if it's not there, the game will hang on load. We'll release an SDK package this week, that contains an addon debugging tool called PartLab. This tool has a console that let's you see exactly where the loading halted, so you can know what needs to be fixed. Also, we'll be posting a part-making guide in the wiki, that will explain all that is needed to make an addon part. Hope this helps! Happy modding! Cheers

Nice! I didn't expect to see a mod attempt this early on! This is great! We have a tool we made to debug part loading. It's called PartLab. It's going to be released very soon now, along with a few other tools and examples in an SDK package. The PartLab tool has a console that let's you know exactly where the importing halted, I'll see if I can release it as early as tomorrow. I'll try to help you out now anyway. The model for a part needs a couple of special nodes to work. Mainly, you need a convex solid mesh called node_collider, to be your collision mesh, this is a mesh that's supposed to go over the main model, and it's what the game uses to simulate physics. The other nodes are just dummies used to mark the position of the attachment nodes and effects. These aren't even imported. They're just used to get the XYZ position and orientation of the things they represent (there is another tool for that as well). You also need to structure the new part's folder in the same way the others are. It needs a texture map in the 'texture' folder, a COLLADA (.dae) or .obj mesh in the part's root folder, and the part.cfg file. The cfg file is the entry point for a part. The game looks for those first, and parses it to get information about how the part is supposed to work. In there, you have to set an unique name for the part, indicate where the mesh and texture are, and define the attachment points. Your best option is to copy an existing part.cfg from somewhere else, and just change the values you need. We'll be releasing an official part-making guide in the KSP wiki as well. It should cover all of these points in much more depth. If the game is halting on the loading screen, my best guess is that either there is a problem with the collision mesh, or you have a problem with the cfg file. Try using a copied cfg file from the original solidBooster. Just change the 'name' field to something else, and make sure the 'mesh' and 'texture' fields are pointing to the right files. If the game is still halting, it might very well be the collision mesh. If you already have a collision mesh in, and the game is still halting, the next step is to make sure the collision mesh has a material applied to it. It won't use this material in game... the collision mesh is invisible... but the importer will complain if it finds a mesh without a material. This only happens with .dae models though. If you need to give it a material, you can give it a standard grey material, and just for modelling convenience, give it 50% transparency. (I'm assuming you're using 3Ds Max... although other modelling packages should work quite as well) Anyways, We'll try to release the SDK as soon as possible. In the meantime, I hope this helps! Best of luck! Cheers

All Hail! The Almighty Probe cometh! :hailprobe: Cheers

the latest version (0.7.3) is now up for download in the Downloads section! Changelog: * Interactive Tutorials for both the Vehicle Assembly Buiding and Flight Mode * A settings.cfg file containing store game preferences * New workflow option for the VAB. You get to choose between holding down the mouse to drag parts, or clicking to grab and again to release. * Fixed UI Bug when pausing the game just after crashing. Also, we're changing the version numbering scheme to a more 'normal' convention: 0.0.0 (major, minor, revision) Each tri-weekly update is by definition a minor release, and we'll upload revisions if there are bad bugs that went unnoticed at update time. Cheers

Version 0.7 Rev 2 is now up on the Download Section. This version is a quick hotfix for a very annoying little bug. Changelog: * Fixed part attachment in the editor, so that parts can be detached more easily. Cheers

The latest version (0.7 rev 1) is up and ready for grabs in the Download section! This update is a small revision. It contains a few bugfixes and a new feature: ChangeLog: Fixes: * fixed part attachment where a part would not connect to the ship if it were in front of or behind the nearest attach point * completely rewritten editor camera behaviour. It should be much friendlier now. New Features: * New part detail tooltips! Hovering the mouse over any part in the editor's list will display a tooltip with part information. That's it for now. Stay tuned for new updates this week. Cheers