CaptainKipard

I take your point, and in other areas we'll definitely work to fit into KSP. In this case however we can't ignore physics, because KSP is based on it. If I don't angle the thrust, the ship will tend to spin out of control, or at the very least be extremely difficult to control in space. If you look at an image of Skylon you'll notice the engines sit below the center of mass. There's just no other way to make it work with the exception of redesigning the whole look of the ship, and I really don't want to do that. Not only would I have to raise the engines and wings, I'd have to lower the tail because the tail also has a pair of small orbital engines. The wings house the landing gear so now the gear would have to be placed somewhere else and redesigned. It's too much work. I'm no engineer, and REL have already presented a design that's workable. The only difference to KSP players will be that the nose will not be pointing prograde, but hopefully EatVacuum and I can figure something out to make this as painless as possible.

Hmm I keep hearing good stories about this...Bee(?).. Nein(?), is it? I should probably download it and see what that engine looks like before posting spammy messages about how I'm going make a realistic model. LOL *sigh* I love useless naysayers like you Mekan1k. Decent entertainment, thanks. 0 for effort of course because vacuous comments are easy to make, but a solid 6 for attainment.

Of course. If that's true then that will solve one problem, but that's only half of it. The other is that because Skylons Sabre and OMS (Orbital Maneuvering System) thrust vectors are both angled to intersect the center of mass (Sabres are angled down, while OMS is angled up because it's above the center) then the actual heading of the craft will NEVER be aligned to the prograde vector. Now I know that all pods and cores have a "forward" direction (it's what determines what you see on the navball), but I don't know if that's determined by the model importer or the cfg. If it's the importer then I have an idea for solving this particular problem. If it's cfg then that's your area. I'll keep a record of all the important angles and dimensions and if it's necessary then I can always tweak the model later when we start testing. Also if there's no way to change the "forward" direction of a single part at runtime then I'm thinking we might need to create two seperate control cores both with different "forward" directions and allow pilots to choose which one feeds info to the navball (by simply clicking "Control from here") depending on which engines are in use. Mine too. Initially i thought I'd build them right into the nose and tail, because that seems most realistic, but that has it's drawbacks when trying to balance a craft with a full cargo bay. And yeah if they haven't figured it out then i guess there's nothing wrong with allowing players to place RCS wherever they want. I'm thinking of making them somewhat similar to those flat B9 RCS units. The only drawback of doing it this way is they'll have to stick out a bit from the fuselage in order to be visible. Actually I had a look at Lapcat before I even started and I think you're confusing two different engines. Skylon uses Sabres (which are hybrids), but Lapcat uses Scimitars. Scimitar (that's the straight one) is based on a Sabre but it has all the rocket parts taken out. It's just an advanced air breathing jet engine. I don't want to promise anything. I'd like to make a Lapcat one day, but let's concentrate on this first. What do you think? Also one last thing. I'm curious how you'll make the Sabre behave like a hybrid without programming a plugin. Does that functionality already exist in KSP? Because when I first decided to do this I though I'd just make it an addon for B9 and use his module(s) in the config file.

[table] [tr] [td]Reaction Engines Limited Skylon C2 Announcements I'm currently waiting for KSP 1.0 so I can develop this further for the new aerodynamics model. resting my tired brain. An alpha version for stock aerodynamics is now released Download Skylon Alpha for Stock Aerodynamics Released under the Attribution-NonCommercial-ShareAlike 4.0 International license Extract KipEng to GameData. If you have any of my other mods windows will ask you to merge the KipEng folder. Dependencies: Firespitter (plugin only) Community Resource Pack Kerbal Joint Reinforcement (Might not be necessary. If anyone wants to risk it let me know how it goes) If you don't want the parts from Firespitter, you can delete all the files from that folder but keep the plugin directory structure the same just in case. Recommended LoadOnDemand OR Active Texture Management. Not both. [/td] [td][/td] [/tr] [/table] It flies well and can be used effectively, but is far from finished. Showcase video by White Owl. Thanks! White Owl's Module Manager file for the tweaks he made to various parts as mentioned in the video Download Usage: Skylon Control Core 2 has an animation that allows you to change the "Control from here" vector between the Sabre engine thrust vector, and the orbital engine thrust vector. This will change where the navball is pointing to be in line with the corresponding engines. The Sabre vector is selected by default. Skylon Control Core 1 is a regular part. Selecting "Control from here" on this part will let you control the craft easier with the RCS thrusters and reaction wheel since they are aligned with that part. The included craft file has all the parts and action groups set up as follows: The control surfaces are set to use specific user input Main landing gear has the brakes on by default Sabre engines are set to Manual Switching. AG 1 set to change Sabre engine mode AG 2 set to toggle Sabre engines AG 3 set to toggle the Skylon Orbital Maneuvering Assembly In order to perform a successful launch with the Skylon you need to do the following. Load the included craft file and launch Right-click on the Skylon Control Core 2 and click "Control from here". SAS on, Breaks off. Stage. Towards the end of the runway pitch up as far as you can without destroying the tail. As soon as you leave the runway, pitch up more to start gaining altitude and retract the landing gear to decrease drag. Fly in air-breathing mode to about 20km and accelerate to about 900-1000m/s. Watch your IntakeAir. Switch to rocket mode, and continue as you would with a rocket. The craft has enough resources to achieve an orbit of ~300km with a heavy payload. If you want to use the SOMA engine you must change the vector on the Skylon Control Core 2. If you have a dockable payload in the payload bay and you want to dock using RCS, you need to click "Control from here" on Skylon Control Core 1. Remember to switch back to the correct core and vector before returning to Kerbin. Current progress Modelling - 95% Colliders - 95% Unwrapping - 0% Rigging - 50% Animations - 70% Texturing - 50% Unity Import - 10% Config - 80% To-do list (subject to change) Remodel control surfaces Unwrap everything again Re-do RCS placement Tweak the steering curve Configure the parts for FAR and DRE, and release MM configs Finish adding colliders Fix Main gear animation Configure intake animations Add solar panels to the cargo bay doors. Fix cargo bay mechanism and animation. Finish the texture Look into changing over to DDS format for textures Configure techtree placement Consider ModuleMirror for wings, canards and main gear Better engine FX Consider using LFO for the RCS. Create the Skylon Personnel and Logistics Module as the first addon for this mod Current list of parts Nose/Core 1 Core 2 Forward Monopropellant tank Forward Hydrogen tank Cargo Bay/Oxygen tank Side doors Aft Hydrogen tank Aft Monopropellant tank SOMA (Skylon Orbital Maneuvering Assembly) Vertical stabiliser with rudder Wing with aileron (Left and right) Pre-cooler (Hopefully using the plugin from Interstellar) Intake Sabre engine Canard (Left and right) Nose gear Main gear (Left and right)

But only 12 years until it dies.

When creating parts inspired by real craft how do people usually work out the right dimensions? Is is just dividing by 2 and seeing which standard width it's closest to? Say for example I wanted to make a Skylon. Its fuselage is 6.75 meters wide. Should I make it 3.75 meters wide? Oops can a mod plz move this to the modelling and texturing section

Does this display longitude the same weird way Kerbal Engineer does?

With respect I think you should allow people to round values themselves.

What format is latitude and longitude stored in. Printing those only shows two decimal points. Is that all the accuracy we have?

If that's true then whatever variable you're using is not actually a heading. Maybe Kevin made a mistake, or maybe you're confusing concepts, but a heading is your compass direction, and compass directions aren't useful for holding an inclination during orbital insertions for the reasons I've stated.

You can't launch into a precisely inclined orbit by simply following a heading. Your heading is only related to the inclination value at the ascending and descending nodes. Half way between those your heading is basically east or west ALWAYS (except when you're in a perfectly polar orbit). The farther away you move from the nodes the bigger the difference is basically until you're half way between the nodes where the difference between your heading and inclination IS the value of your inclination. You'll need to do some serious orbital maths to keep a steady inclination during your ascent.

You mean the immersion you got when you fit several thousand men into a single bireme?

I'm not that great at mathematics. Can someone explain whether or not calculus allows you to accurately calculate infinite series? If so, aren't there integration and differentiation functions in programming languages?

So "The fall" from Total Recall is nonsense then?

Isn't it strictly a matter of staying at terminal velocity?

Have you made a config file?

Perhaps a separate optional narrow window that extends from the side of the main window that just lists the values in a column. I would group them according to the axes they represent

Payload can you rename all your variables to something more descriptive so i can debug your scripts more easily.

Ok I've tested your ascent script with my test rocket and it works pretty well. I got 101193m by 100023m on my first try. I also got 0.3 inclination which is not too bad. My biggest gripe is that when running your script the rocket wobbled a LOT which sucks because when i launched it manually i was able to keep it very steady. I've tested this too and the throttle doesn't stutter, but with this particular script I got a maximum difference of 7m. That's a large step in the wrong direction.

Kevin already said he'll get around it. I love the new update Kevin. Thankyou for trigonometry.

distances along all 3 individual axes straight line distance velocities along all axes velocity in straight line alignment angles in all axes delta angles in all axes all of those with 3 decimal points with the exception of two of those, lazor cam has it all, and I use it all, mostly to roleplay really. I treat KSP like a sim and frankly the way some people dock is just insane. They launch their craft at stupid angles and stupid speeds that would NEVER work IRL.

If you look at a dictionary definition for "Red Herring", then you'll see the above post. But that's ok, I'll just wait for your script.

In other words wrong. You keep confusing concepts and variables. All you did was calculate the difference between orbital speeds of two different circular orbits. That's not the same as calculating the necessary dv for each burn. Even on that page it tells you how much dv you need to expend: periapsis: 1250.0000 km, apoapsis: 1300.0000 km periapsis: 650.0000 km AMSL, apoapsis: 700.0000 km AMSL velocity at periapsis: 1697.0 m/s, at apoapsis: 1631.7 m/s Hohmann delta-v at periapsis: 16.4 m/s, at apoapsis: 16.2 m/s Vesc at periapsis: 2376.7 m/s, at apoapsis: 2330.5 m/s period: 80.2 minutes semimajor axis: 1275.0000 km semiminor axis: 1274.7549 km eccentricity: 0.0 specific orbital energy: -1384.4682 kJ/kg Why is this so hard to grasp? You keep screwing up because you're trying to do short cuts and it's getting ridiculous. If you want to time your burn with a variable then just do what I explained to you.

You're right I didn't know what your code was doing, and I see where the confusion comes from now. It would never occur to me to do it your way because that's not how real rocket scientists do it. They do it by calculating thrust and timing the burn correctly, which is what I was attempting to show you. This way doesn't care about checking for the desired orbit. it only measures the initial orbit and calculates necessary dv to get to the desired orbit. And that's where precise acceleration and timing come in. Maybe it's just a matter of preference. I like to do things realistically when I can. Just no. I have to assume you mean average speed, because the average orbital velocity is 0 for all elliptical orbits, but still.... no. Just forget that notion. It's irrelevant. I really don't know what else to do. I've explained how to calculate the burn time and how to calculate dv and assuming a constant force (which is also easy to do by dynamically throttling down) that is ALL you need to change your orbit. Nothing else. Maybe it'll be better if each one of us just tries their own way and we'll test each one. Well if you code works then we should use it although (correct me if I'm wrong) your script will use more processor time, because it loops. I don't know. My way just does the initial calculations and locks the throttle to a function of mass then waits a specific amount of time.

Um. when I said "current" i meant "during the burn". And that doesn't change for circularisation does it. Why would you assume that I'm telling you to calculate burns NOT at the place where you actually burn, come on... I do. Just read what I gave you carefully and apply it. I've used it before for very precise orbit changes and it works. LOL WTF? Are you telling me you don't understand orders of operations?