CAPFlyer

Guys, this is the FIRST RELEASE of the Tech Tree on a BETA program. Stop getting your panties in a wad and instead of bashing Squad for it. Instead, try putting forth constructive suggestions on how you would arrange the tech tree. If you want to build a new tech tree, great! Here's the link to r4m0n's "TreeLoader" and where you can submit your suggestion - http://forum.kerbalspaceprogram.com/threads/53192-0-22-TreeLoader-Custom-Career-Tech-tree-Loader-1-0 Don't say that Squad is "anti-realism" or make assumptions for them. From the interviews they made and by r4m0n's own admission in the above thread, this is the first iteration of the tree and the main push here was to get it in the game and working, not to have it be perfect from the get go. They will be not only allowing for modders to create custom trees, but they will be tweaking the default tree as users figure out better progressions.

Satellites should be, at least in the basic, early in the progression. Remember, we were sending up satellites before people. The amount of science they could do was very limited due to bandwidth and power restrictions, but even Sputnik gave a lot of useful information just with its little beep being tracked that allowed some initial mapping of the Earth's gravity well by noting changes in speed as it orbited. Some Amateur Radio operators also were able to map some of the ionosphere and even magnetosphere by measuring the variations in the signal strength and frequency on each orbit.

Looks like a good start. With 0.22, having good satellite buses will be a major need. I would suggest if you're looking for ideas to look at some of the real world busses that are comercially available for ideas for your "body" and then I would make the instruments addons that can either be installed in or on that bus. Here's links to a few of the major Bus families/maufacturers- Boeing - http://www.boeing.com/boeing/bds/satellites_space/satellites/index.page? Lockheed - http://www.lockheedmartin.com/us/what-we-do/space/satellites.html Astrum/EADS - http://www.astrium.eads.net/ Loral - http://www.ssloral.com/ Orbital - http://www.orbital.com/SatellitesSpace/ NASA also has the "Modular Common Space Bus" that was used operationally for the first time on the LADEE mission, but I don't have a link with any of the specs as the spaceframe and not in the LADEE configuration.

I agree that's pretty tricky, but it's still technically possible to do it, you just have to be really careful.

Cliph, maybe I can suggest a simplified way forward? Have RT do both the signal connection and delay as originally designed. Then, re-enable the original RT1 autopilot. All it needs to do is point, and give a way to run a pre-planned burn (by time or dV). Finally, integrate RT with the KSP maneuver nodes. The execution of them would be simple. In the map view, or MechJeb, or the Maneuver Node Planner/Editor, or whatever other addon, you setup the maneuver node(s). Once you're done, you then hit "Execute Node" or something similar on the RT autopilot. This then "uploads" the maneuver node to the craft. As long as you remain in contact until the node is uploaded, the craft will be allowed to execute that node. That's all you need. You don't need the rover autopilot (although it'd be nice down the road), you don't need any complex computer. As long as you can point the craft, execute a pre-planned burn, and follow the maneuver nodes, you can fly any mission. Let everyone else deal with flight computers, complex autopilots, and the like.

Define better. Fixing bugs? Continuing what r4m0n was working on? Then yes to both. Don't know about any other measure.

I too would like to see some mesh/soft dishes in addition to the stock one for a similar reason to what was shown above. I would also like to see maybe some antenna models similar to the TDRSS multi-access antenna which are phased-array type antenna and can support up to 5 "download" connections and 1 command connection at a time. See - http://www.nasa.gov/centers/goddard/pdf/97440main_TDRS_fs_9.18.pdf Also, I would like to ask that maybe you consider either enlarging the existing AIES command parts into 1m equivalent parts or build new "satellite buses" to support these bigger dishes that are being built as the existing half meter parts "prope" are just really too small for use as tracking or relay satellite bases. Not to mention they are too small for use in a Figaro network as well.

There are several issues - 1) The SRB's are producing no useable thrust at separation in the real world. KSP does not simulate SRB burnout properly. As such, you must allow the SRB to burn out and give a half second prior to activating separation to allow the thrust to fully decay and acceleration to normalize. If you trigger the SRB's while they are still burning, you are separating them while they are producing 100% thrust, thus why they act like they do. 2) The separation motors on the skirt are only designed to relieve the aerodynamic forces on the connection as the separation occurs. The primary thrust for separation are the upper separation motors. In KSP, with aerodynamics not working 100% accurately on them, you can almost just have an effect for the skirt motors and no thrust at all. The positioning of the skirt motors give a short (less than 1 second) burst of momentum away from the wings of the STS. If you watch the SRB videos on Youtube, you'll see that the motors don't even give enough thrust to keep up with the launch vehicle for a fraction of a second. The upper motors burm for only slightly longer than the skirt to give a bigger impulse and ensure that the SRB's are pushed away from the stack by aerodynamic forces.

Real world, you have to use rockets of some sort for all staging events because explosive bolts just shear themselves, they don't actually give any "push" and springs big enough to impart any serious dV on stages would be too big and heavy. The Delta & Atlas rockets use a combination of retro rockets and ullage thrusting of RCS to execute their separations, so I would imagine that SLS will be similar.

Your problem is probably one I have if I'm not careful - MechJeb is still on. Make sure that you DISABLE MechJeb whenever using the RT flight computer to execute maneuvers and you turn off MechJeb Control in the RT control window. This will ensure that when you click "Maneuver" on RT and set the burn and delay, that RT's Flight Computer will have control. Otherwise, MechJeb will lock up the pointing controls as RT is setup to give MechJeb priority over itself.

I usually put in a decoupler and discard it after I'm through the upper atmosphere.

KW went with high/low res textures on their addon many moons ago and that made a lot of people happy. I think it's great that you want to do both because it'll help everyone. Those who only want to run a few addons and those who want to have a good selection. I like having a bit of selection. Makes it more fun when you're launching a variety of missions.

Have you thought about integrating KerbCom Avionics? It is specifically designed for fixing that problem. Also, remember the new SAS (there is no ASAS) is pretty much a KILLROT module, so it's not going to care about CoM or assymmetric RCS, it just wants to keep the ship pointing in the last zero input direction. You need to either balance your RCS manually (i.e. changing the maximum thrust output of them to "balance" their exerted force) or use a module to automatically throttle them. Remember, both BURAN and the Shuttle used digital autopilots for all maneuvers, so there was never direct manual control of the RCS or control surfaces like with KSP. There was always a computer interpreting control inputs and then commanding the RCS or surfaces to generate the result.

While it's your choice, let me strongly suggest you be careful about it because you will put yourself in a corner as the models and texture sizes become larger. As Unity has a memory limit on it, no matter how big and powerful your computer, the more complex the models, the fewer total parts you can have in your KSP without hitting that limit. This is the problem with BobCat's addon. If I have it, I have to eliminate almost all my other mods because I hit the limit if I just use BobCat, ULA, RemoteTech 1 and KSPX. I can't even include Lionhead's ESA pack or NovaPunch, much less Procedural Fairings and Ferram. BTW, for those wondering, I have over a TERRABYTE of paging file available, 8 GB of DDR3 RAM, and 1GB of Graphics RAM. The fact of the matter is, if I pull BobCat, BAC9, and Romfarer, I can put 9+ more addons in simply because of the amount of space they take up in the preload.

Really? Guess you and I are looking at two different bug trackers - https://github.com/Cilph/RemoteTechExtended/issues/15 https://github.com/Cilph/RemoteTechExtended/issues/24 Both of these clearly show that MechJeb compatibility will continue to be supported as much as possible and that they are trying to make them work together. The problem is not with RT though. It's the fact that the MechJeb crew has gone almost silent on any of the public forums making collaboration much harder. The only time I've read either developer say something along your lines is that they've stated that the RT flight computer will not ever be as advanced as MechJeb and told people to stop asking them to make it that way.

The problem is they aren't vaild concerns being voiced. They are statements being made (i.e. "I'm not using this because of the changes made to the flight computer that conflict with MechJeb"), and those statements are based on assumptions made from information that either doesn't exist or from information that has been put forth by other users whom have been complaining about things that are known bugs and are being put forth by those users as if they are intentional changes and not bugs. If someone "loves" the program and they want it to be better, then don't come on this thread and say you're leaving because of something being changed. Either leave, or say "hey, I hear all this about the flight computer being changed, is it being changed?" instead of making demonstrative statements. I have no problems with people bringing up concerns about existing functionality that they want preserved, but there is a way to say you support keeping a function versus saying "I'm gonna take my ball and go home unless you do it the way I want it," which is how it's being put forth by many of the users here. Call it inflammatory if you want, I'm just tired of every 3rd or 4th post being someone complaining about woe is them because RT2 is in playtest and doesn't work perfectly and they're gonna take their ball and go home because of it.

No it doesn't. This is a PRIVATE forum. As such, you have no rights. Add to that you didn't pay for anything and you have no legal, moral, or "implied" standing to demand anything of the mod creators. Period. Two issues here - 1) You are not reading JDP and Cliph's statements to make the above comment. There has been nothing implied or phrased to say they are scrapping the current system. What they have said is that they are having to rebuild the system to function with the new way the core program handles certain things and to clean up the badly written (by their own admission) code in RT (v1). The statement has been made several times, quite clearly, that the end product for RT2 will contain the SAME FUNCTIONALITY as RT1 with additional features added. It may go about handling that functionality differently, but it will still be the same functionality. The only ones talking about changing functionality are USERS, most of whom haven't read what JDP and Cliph have stated nor have they actually looked at RT2, they're just making assumptions based on a few users complaining about how parts of a very early alpha of a new version isn't working (and which they were told wouldn't work) and then running with it and then 3 pages later, suddenly it's now "fact" that something has been removed, added, or changed, all without a single post from either of the developers. 2) Issues are not what you were stating. You stated that the flight computer has been changed when it hasn't. The CORE PROGRAM has changed and that caused the problem between RT and MJ, not the developers. They even put as a "bug" on the GitHub tracker before they even released the playtest version that it was a known issue. That says they are going to *FIX* the issue and that it is not a design or implementation change that is planned or permanent. I'm sorry you feel that way, but I can't help someone who doesn't want help. When every 3rd or 4th post is someone saying how they're "not going to use this mod" or something to that effect based on incomplete and/or flat out false information being posted by other users instead of what's being posted by the developers or users actually involved in the testing and trying to get it to work, then why should I try to help them? They've already shown they don't want to spend a few minutes to read the bug list or read the posts by JDP and Cliph about the development progress, so how would I be able to help them when they make assumptions based on the assumptions of assumptions?

Guys, I'm glad everyone is reading the github bug list because I see multiple people abandoning ship and claiming that certain things are done and over with and are decisions being made based on absolutely NOTHING. The MJ/RT2 problem is known, listed, and will be fixed. This was a problem with several of the early versions of RT too. Because both modules need to be able to manipulate the same things and they need to work independently and cooperatively (because some people may use one or the other... I know, what a concept, not everyone wants every addon), it doesn't always work right, especially when major changes in the BASE PROGRAM occur that makes both addon makers have to rewrite entire sections of code just to work with the stock game much less work with other mods that may or may not be installed on a given system. There's a reason RT2 has multiple warnings it's in PLAYTEST. If you don't understand what that means, then you need to go sit on the bench a while and not post here unless you know what you're talking about. In fact, I would submit that maybe you re-think participating in an OPEN BETA of this program all together because too many on this thread alone (not to mention several others) don't seem to understand that this is still a game in major development and the mods are all in major development and thus guess what - stuff is gonna break, get broken, and need to be fixed. If you don't like where RT2 is right now - then go elsewhere. Don't fill pages upon pages of your whining and crying about how woe are you because your "favorite" addon doesn't work. You didn't pay a dime for RT. You don't have a right to complain. Let JDP and Cliph do their thing and come back when they're done. If you want to be a CONSTRUCTIVE part of helping them improve the product, then stay here and do so. Otherwise, I think it's time for some of you to go away for a while.

The ESA service module won't fly until EM-1. The original service module will be used for EFT-1.

I too would like expanded programming, but not command-line programming. I'm not a big fan of that kind of programming, but I want the difficulty of the delay and I want more "pre-programmed" maneuvering than exists in the current RT. However, instead of doing anything really complex, why not just allow RT to execute a limited number of maneuver nodes? Squad did a lot of work to make that system work as it does and it would allow for you to use MechJeb fully, but yet not have some of the "issues" of what happens if you loose contact. The idea would be that I could (for example) setup MechJeb to make the Holmann transfer to Duna and a mid-course correction and then let the probe "sleep" and not worry about it's signal until it got out to near the SoI change at Duna when I need to start making my insertion burn(s). I would also like to have the option to command at the end of those maneuvers or at an SoI change (or something like that) to have an action group activate (say orient in a certain attitude and then deploy a dish and target Kerbin or something like that). That way, in the meantime I can't change the commands, but the ones programmed will execute (like it would on a real satellite) and then be able to re-establish contact in time to send the next set of commands (which will take time to be sent and then "upload") requiring me to ensure contact be held for long enough for that to occur (i.e. require 5 second for each maneuver node or action group to upload plus the signal delay). This way we get the challenge of having to pre-program things and make sure we do it right, but not without having to learn a programming language or spend time actually putting it in.

All my RT networks have pretty much replicated the real world TDRSS and DSN networks. I start by launching the first TDRSS satellite (usually pretty small to replicate an early relay satellite that I can launch using a Falcon 1 or similar light rocket that has 2 medium folding dishes and 1 small dish or VHF/omni antenna) and getting it into an orbit about 45* EAST of KSC to give me downrange coverage. Then I launch the first DSN "station". This is usually a bigger, heavier, setup where I have 4-5 large dishes (I don't think I've ever managed to put 3 identical DSN's together as I always think of something between launches or a new mod comes out...) and an antenna or two and launch it suborbital. I use a *LOT* of parachutes and target it's landing to be about 120* east of KSC. I then make sure that I'm still under TDRSS A's coverage for most of the flight so I can tweak the final landing, but I also have the parachutes modded to auto-deploy at 10KM on the way back in in case I loose connection. Next, I tweak TDRSS A's orbit so that I can communicate with both KSC and the new DSN station. Next, I launch the second TDRSS satellite and deploy it to be about 50-55* EAST of DSN B (DSN A is KSC). I usually run the TDRSS A configuration on this satellite too. I always try to ensure that TDRSS B can "see" both DSN B and TDRSS A with its omni antenna so that I have redundant connections. Next, I launch the second DSN and position it to be 120* WEST of KSC. This gives me 100% hemispherical coverage outside the Kerbin orbit. By deploying TDRSS B to a point almost over the horizon from DSN B, I get full connection to landing again. DSN C will then allow me to ensure coverage when I launch TDRSS C to a point between it and KSC. Once the 5 stations are in place, I tweak the location of the TDRSS satellites so that they are as close to in synch with each other as possible (MechJeb gives a couple of readouts that I use where I can get them to have relative velocities that allow the network to stay in position for several years before needing to make any tweaks) This gives me full coverage of all launches and most trips to the Mun and Moho from just the TDRSS network, and then the DSN with their big dishes gives me full coverage beyond that. I can continuously handle 4 long-range flights with this setup and "comm share" several more, especially once I put manned flights up that can serve to "supplement" the relay network. I also sometimes deploy a "DSN A" at KSC that is rover based so that I can quickly re-aim my DSN and TDRSS dishes when launching a new flight or when getting ready to make a navigation change on a long distance one.

I have to go back to this as well, what do you mean "wasteful"? I see the minimum number of components based off the NASA animations of the SLS launch. Stevincent - just ignore them. They know not what they speak of. I will say however, be sure to use textures and normal mapping for the fine details in the final model. You will gain a *LOT* of performance by minimizing the physical model's poly's and making up for it with normal mapping.

Okay, I guess I misread the previous pages when I was scanning through them. Will check the bugtracker to see if the one major issue I've found has been reported. Other than that, seems to be working okay so far.

Okay, maybe I missed it, but how do I eliminate the unrealistic minimum 1s delay. There should be at most, 0.1s delay on launch. I'm sorry, but even the 1960's technology didn't have an appreciable delay between pushing the firing command and it actually doing it.

Not totally true. Even your own description is lacking in factual basis because you are making examples that aren't relative to the topic at hand. For example with the movie - I pay for the ticket to see the movie. That is the binding contract by which I have legal standing to demand a refund if the movie has a technical fault during its showing. Being given the mint, while technically part of the "service" provided as part-and-parcel to the experience in some theaters, is not a contractural item, but there is an expectation created that the mint will be provided in a health-conscious manner in a sealed packet and not be expired or stale. If it is not, I have a right to request another mint, and if the mint makes me sick due to something the movie theater did, then I do have a right to seek damages. But that's a different issue. In the software environment, there are donations (to a person or group) and there is donationware. What most people consider to be a "donation" is actually "donationware" and a contract IS created in this case. However, most developers don't understand the difference and don't clarify what the donations are for, and thus where the legal problem comes in and what happened in FS. Simply putting a "donate" button on the website isn't enough. There has to be a clear statement as to what the donation is for and what it does or doesn't entitle the donor to. When you donate to the Red Cross, there is a disclamer. When you donate blood, there is a disclaimer on the information sheet you fill out. When you donate to GoodWill, there is a disclaimer. The disclaimer is the contract. It specifies what the donation is being used for and what (if anything) you are entitled to from your donation. As long as the terms of the donation are fulfilled, then there's no issue, but it must be in writing. This is why I stay away from donations. There's more to it than you think.