Jump to content

mjl1966

Members
  • Posts

    142
  • Joined

  • Last visited

Everything posted by mjl1966

  1. That sounds like a proposal for discussion to implement an improved process to solve the problem. Has pjf responded?
  2. Very well, sir. Thank you for your honesty.
  3. Although a reconciliation between pjf and the development community can only come by their own efforts, I would submit that at least part of the solution would be a formalization of the control of that index. A certificate which would constrain the control of an index entry to pjf and the developer of a particular mod might be a useful tool in developing a process that works effectively for all. Thanks for sharing your thoughts.
  4. Sir, you have created a logo, detailed descriptions of your mods, videos, a Wiki and a donate button. Your actions are not consistent with the notion that you do not have a sincere interest in sharing your mods with the user community beyond a casual coincidence of convenience to yourself. You may very well take issue with my proposal, which is your prerogative, and one that I respect. But I honestly see a very real interest on your part in sharing your mods with the community. And we have benefited from that.
  5. *Puts on business project manager hat* As a data security analyst, I've had to do things like stand in a room and tell developers they need to put a password on their source code server while they look over the rims of their glasses with that look that says six shooters will be produced if I pursue the topic any further. Yeah, things that seem "obvious" on the outside are often impeded by deep cultural paradigms which have to be understood, navigated and eventually changed. So, here's my attempt on this subject. Let's look at the business case here. There are three parties: content creators, a content distributor and content consumers. The *common* business objective is to create mods and distribute them to as many consumers as possible such that the mods are easily installed with minimal problems for any party. That's kind of broad, but that's usually how you have to start off these things. Currently, we have conflicting interests between two of these parties: content providers and distribution. Content providers want their mods to be installed as they intend, according to technical specifications which determine the functionality of their content. Distribution wants consumers to use their system to distribute as many mods as possible. Now, at this point, there's usually a lot of coffee drinking, refereeing, questions, answers and brain storming. But we don't have a conference room. I'm going to have to assume that all parties will agree that they at least *understand* the other's objectives, even if they don't support them. Just understand. Putting them together, we get a business objective: The centralized distribution of as many mods as possible such they are properly installed according to technical requirements as defined by the content developer. OK, this requires distribution part to give a little bit of ground up front. Let's talk about that. Currently, there is a paradigm that says, in effect, we all have the right to distribute as much content as we want due to open licensing. OK, but let's examine that in the context of the business mission. We still have the issue of content needing to be installed by consumers according to technical requirements as defined by the content providers. Here, we have to ask if there can be agreement on that. Can distribution agree that content needs to be installed by consumers according to technical specifications defined by the content providers? If we can, we have a next step. If not, we're dead in the water. Read it again. To distribute without taking into account the need for adherence to technical requirements set forth by the developers leads to several problems, among them: 1. Incorrect installs - unhappy users. 2. Incorrect installs - overworked developers who don't trust the distributor. Neither of these serve the *common* business mission of getting as many working mods as possible into the hands of users. This, in my mind, is the core problem that needs to be solved in order for this team to move forward in the achievement of the common business mission. (Again, everyone has to agree on that mission for it to work.) Let me redefine it: There is currently an inadequate process by which developers and distribution can coordinate their efforts to ensure content is distributed to facilitate installation by users in accordance with developers' technical requirements. The problem isn't devs. The problem isn't distribution. The problem is a missing process. Given this definition of the problem then the solution is for the developers and distributor to design and implement a process whereby content is distributed and installed according to technical requirements as defined by the developers. The goal, then, becomes the development of such a process. If enough of you can agree on this, then my suggestion would be to assemble a closed-door committee of leading developers and the distributor to work on developing that process so that you all can achieve the common business goal of getting as many working mods as possible into the hands of users. It's an effort that requires commitment, good faith and an initial dose of trust for the sake of the mission. Goal. Problem. Solution. Whether or not that happens is up to a small group of very smart people who created all this stuff for us humble users who really do appreciate all your hard work. Work it out.
  6. More on orbital instability: Put a station in orbit around Mun. Dock a smaller craft (lander) into a side mounted docking port. Orbit falls completely apart in a matter of minutes. Apo remained more or less steady at 33K while Pe plummeted from ~30K to 0 and craft crashed into Mun. What's really odd here is that Apo remained stable while only Pe deteriorated - and it deteriorated fast. Verified all engines off. Disabled all torque. Whatever Unity broke in the physics engine, they broke good and hard. I can't keep trying to play the game. I don't have time to continue tripping over broken physics that used to work and are now unpredictable and unstable.
  7. 1.1.3.1289 General --> "Orbital Drift Compensation" on (green). This is default setting. After watching craft in orbit around Mun for several minutes in 1x, orbit did decay, but then it magically adjusted itself back up. Still seeing .002 g force. Looks like this is a true compensation that dynamically adjusts forces acting on craft to compensate for decay. Guess that'll work. Interesting workaround. Maybe we'll just call it a "realistic compensation for natural perturbation." Maybe they should put it in the tech tree. "Perturbation compensator." 5000 science. heh.
  8. Still getting phantom forces in Munar orbit. G force bouncing between .002 and .004 with gradual orbital decay. :\ And... game crashed switching back to space center. If there are any files I can provide to help, let me know.
  9. How does this affect the linking to attach objects to existing craft? Or is that what you're referring to?
  10. Thanks for the update, Igor. I love how Kospy stays right on top of this stuff.
  11. KAS links BROKEN in 1.1.3. You can physically link ports and pipes, but the objects linked do not actually become part of the same craft.
  12. Just started my first round of 1.1.3 and Mechjeb tab is no longer available in the UI. Went to VAB, loaded craft, confirmed MJ available in controls category. Go to launchpad - no MJ button. Anybody else?
  13. OK, so I've searched around for some info on this, and all I seem to find is "use moar radiators." Well, that's nice, but is there a way to interpret the numbers so we can actually plan our loadouts? My problem is not understanding the correlation between the power rating on the active devices and the radiators. For example, the 1.25 ISRU converter requires 100 kW of cooling. But if I strap on three 200 kW radiators, for a total of 600 kW of cooling, the converter still overheats in a matter of minutes if it has enough ore to run at full grunt. Also curious is that I can keep one junior drill at around 650 degrees if I give it 600 kW of cooling even though it says it "requires" just 50. Well, so, what's the deal here? How can I calculate what to strap onto things to actually remove enough heat to keep them operational? Obviously a kW of heat and a kW of cooling don't line up in the thermodynamics model. (Which isn't saying it's wrong - I just don't understand it.) Thanks.
  14. I would tend to agree that some of the basic elements of the game have become destabilized that are essential to what it is. It's an orbital mechanics sim. Orbital mechanics need to work. But I'm willing to give them a pass this one time because of the update to Unity 5. That's a major engine update and I'm sure much of what they're doing is to compensate for unexpected changes and bugs in the engine. We'll call it the Unity Update Compensation Pass.
  15. NO no no no no. NO! That's called... DLC. NO!
  16. Good to hear. Thanks for letting me know. Across the darkness, that which had slept awoken. That which had lain undisturbed became disturbed. Across the void, it reached out with its mind. They screamed. They ran in terror. They knelt down and prayed, but it was a pointless gesture. Mostly, they asked, "Why? Why have you invoked the wrath of Steve the Kraken?" You were warned. Yes, this! I'm glad to know that it's not just me and now I know why it's happening. Landers were the first ships where I saw this happening. Non-landers just decay, which just confuses the issue further. I never would have figured that out.
  17. This is not a question, it is a bug report. I have reliably reproduced this ten times with various craft, the last one being a full stock vehicle. There are various symptoms that tell me the orbital mechanics model in the program are totally broken at this point, but a simple and obvious one to describe is this: After TMI, the projected munar periapsis expands rapidly. In my latest experiment, the projected periapsis started at 17.4K after TMI burn. After letting it coast for just a few seconds, it expanded to 17.7K. If I time accelerate, it stabilizes, but if I leave it in normal time, it continues to expand. May not sound like a big deal until I start doing unaccelerated time activity like exploring the surface of the Mun (which is how I discovered this bug in the first place.) Once I'm in orbit around the Mun, my orbit further destabilizes. I've seen both decay and "anti-decay". On my last experiment, the orbit simply decayed for both apoapsis and periapsis, But I have seen some scenarios where apoapsis actually increases over time. Has anybody else seen this? Is this a known bug? Is it being worked on? -MJL
  18. Bill, newly annointed Master of Space Engineering, is eager to get to work excavating exotic ores from faraway places. Imagine his excitement when he receives his first mission to the Mun. "Am I going to learn to drill?" he asks. "No. It doesn't work that way. You're going to plant a flag on the Mun." "Why?" "For experience." "Oh, then I'll get to drill?" "No. It doesn't work that way. Next, we'll send you to Duna." "Oh, there's a drilling academy there where I'll learn about drilling?" "No. You'll plant another flag." "Why?" "For more experience." "But I'll already have flag planting experience. I need drilling experience." "Well planting that flag will give you drilling experience." "Oh. OK, then I'll just take a drill with me so I can use my experience after I plant the flag." "Well, no." "Why not?" "Because we need to bring you back to officially log the experience in your record." "Can't I just radio it in?" "No." "So, I'm going to spend a year planting flags so I can get experience in drilling. Without ever touching a drill. For a year." "Or longer. That's right." "Um, that's not what I signed up for." May I humbly suggest that the XP mechanic for engineers be tied to engineering tasks such as actually drilling, repairing and repacking and science experience be tied to things like conducting experiments, manning a lab and surveying planets? Pilots can get XP planting flags because they're kind of stupid anyway and we need to give them something to pin on their chest.
  19. Oh, gee whiz, I don't know why I'm replying here - this belongs on a release of Threads Gone Wild. It sounds like Squad is a training camp company. I worked for such a company when I first started in I.T. I ran all over the country implementing software, then became the head fred in supporting said software and eventually was involved with development of said software. At first, I was way underpaid. This was in the early 90's in the Silicon Valley and I had a wife and new baby to support. We lived in a roach-infested one bedroom apartment for two years while I did technical support, field implementation and development for extremely low pay compared to what other software companies were paying. I did one session in field that went for 36 hours straight. I often worked well over 40 hours a week. It never really occurred to me to complain. I was too busy getting a street PhD in software development, management and business. As a direct result of that experience, I went on to live very comfortably as a self-employed consultant. This notion that people who work for training camp companies are somehow owed something beyond what they have agreed to accept is something I honestly don't understand. If it's the best you can do at the time, that's reality. If you're worth more, then you should be able to find a job at a company that will pay you more. It's really that simple. If you can't qualify for a job that pays more, then being in a company that works your ass off for low pay leads to that magical thing called experience. I am eternally grateful for having worked for such a company. I dunno, if it were me, I'd be inclined to tell prospective employers that I was a key contributor to the success of one of the most successful indie game dev/publishing companies in history and leave it at that. If, on the other hand, you are seriously interested in changing how the industry treats its employees, then grab a copy of Unity, develop a game on your own and put it in early access on Steam. That's exactly how KSP started. Then, go ahead and hire people, treat them fairly, pay them well and invite every gaming pub in the world to write articles about your new and better game dev company. Go ahead. Nobody's stopping you. But it's a touch more difficult than poodleing on reddit.
  20. Game ran great for almost 24 hours straight after building three ships and parking a munar ore bot and letting it mine overnight. Today, was humming along just fine when for no apparent reason, it CTD'd out of nowhere. Now cannot complete even a simple ship in VAB without CTD after about 10-15 minutes. I changed NOTHING from the time it was working to the time it stopped working. Only mods are mechjeb and redux. 1.1.2.1260 Win7 64 8G. Been playing since 0.25. This is by far the most unstable release ever.
  21. FTL not allowed. No wormholes or Tesseracts either. For the sake of argument, we're using high impulse, low thrust propulsion. We can thrust half way if we want. How much time will that actually save?
  22. Any travel between orbiting bodies is going to be orbital. It doesn't matter if the intercept with another body requires a short piece of orbit or a long piece of orbit. It's still an orbit. However, if we are able to use an exceedingly small segment of an orbit around the galactic core, then it could be considered negligible. That's where the meat lies. Can we use a super small segment or do we have to use a longer segment? More importantly, what is the difference in dV? This is what determines the realistic feasibility. I don't know the numbers, but I imagine if we could have point and burned to the Moon, we would have. Why didn't we? Why would it be any different from Sol to another star? Here's a different perspective on the same problem. At the beginning of our trip to Alpha Centauri, or any star for that matter, we are in orbit around the galactic core. Just because we leave the SOI of Sol does not change this fact. Any maneuvers are changes in that orbit, just as maneuvers between Earth and Mars are changes in the initial orbit of the Earth around Sol. That orbit is baggage you can't get rid of. You can just shift the weight around a little bit. So the question becomes, can we change the initial orbit sufficiently to make the trip to AC substantially shorter in time than it would be with a regular Hohmann transfer orbit? What kind of dV are we talking about? Is it feasible?
  23. So when we send probes to Saturn and beyond, it's just point and burn? Is this how they do it or is it just theoretically feasible? I'm very curious about when it becomes practical to abandon a transfer orbit because that solves a lot of problems.
×
×
  • Create New...