Lisias

Perhaps it's not a bug, but a visual way to tell what's "up" and what's "down" on the part? These markers are purely aesthetic - or at least, I didn't found absolutely any difference by using different markers on my parts. But what I would like is a way to tell where is +Y and -Y on the part. Sometimes, I ended up rotating the parts while stacking them up, and then when I attach something on these parts, that part became 180º rotated and I need to rotate it back. While adjusting the CoL, it's usual to reattach the wings on an adjacent part, and this rotate and rotate again thing can be annoying and error prone. Without visual cues about what's +Y and -Y (as the part you screenshoot), you cannot prevent such errors before they bitting you, and perhaps this is the way the Add'On author found to solve this.

From my times on Windows 3 programming, I learnt that using Modal Windows (what PopupDialog is) to do Modeless Windows job is rarely a good idea. But, granted, things may had changed. This is the time in which one need to call for numbers using Benchmarks. :-) Calling drawing functions, by itself, is not a problem necessarily. But this discussion is going to the same places as the Stacking versus Composite GUI debacle: it depends essentially on the environment you are running them and how you are running them. It's better to find some time to do that benchmarking I mentioned before further talking about, otherwise I would be just exchanging opinions.

Yes, but the argument I'm counter-arguing is that it's useless. My argument is that learning it can worth the pain on the long run. I agree that OnGui is somewhat esoteric (believe me, I worked with "worse" things that worked better), but IMGUI has it uses - mainly, by using just code to handle things instead of creating GameObjects (and all the clutter) just for simple widgets on the Editor screen. What, well... Helps performance.

I beg to differ. From my times on Orbiter, we use to use GDI directly to draw 2D (essential for HUD and MFDs). Then O2016 came, changing everything, and absolutely all the plugins that draw 2D became useless. O2016 provides now a 2D API, that is not that pretty, but it's guaranteed to work in future versions (local or remote). If anything changes badly, we will bash our heads on the wall only once (to update that 2D API), and then everything works again. I think that keeping on OnGui will prevent such problem, mainly due Unity itself.

It's not exactly related to Garbage Collector, but it also hurts as memory is consumed: if you are a helpless Mac user, since El Captain you are forced to tolerate this abomination called Memory Compression (zram for the mobile users). Do you remember Ram Doubler, QRAM and other "ram doublers" on the Windows 3 era? Same thing. Same crap. Compressing memory before swapping it to disk is a nice idea, since the lesser time you spend on I/O is far worths the extra time spent on compression - but as an alternative for swapping, it hurts gaming. Badly. Take this in consideration when gaming on Mac and before hunting down what can be a Unicorn on your mod.

Hi. I found an interesting bug on JSI Advanced Transparent Pods on KSP 1.4.1 for Mac, running on a Mac Mini Mid 2011 & MacOS Sierra. When the camera is at one specific altitude, the Kerbin rendering became flawed, with some faces not rendered at all (see the picture below). I tested it on a plain vanilla KSP 1.4.1 installation, all in the default settings, on a plain new save in sandbox mode. Absolutely nothing changed, besides the plugin and the test craft (all stock parts). The KSP.log from the testing session is here. The Player.log is here, and the craft "source" is here. There's some in situ testing you need me to do? I'm the one with the offending machine, and this kind of error would be detected sooner if this would happen in anything but a exotic hardware configuration. :-)

It just happened. I'm trying to figure out what mod is causing a glitch on the Kerbin rendering from space that, oddly, just happens at a certain distance - and it's the reason I didn't noticed it before. Since I want to make a video for a challenge, this glitch became a showstopper and then I'm hunting it down. So I decided to move all GameData to a backup folder, and copy back a few mods gradually each time to trim down the culprit. Easy, just a bit time consuming. But I forgot to backup my save, the game deleted everything that was using a mod (and *everything* was using a mod), and now I loose the vessel I was going to use on the recording (and some stuff more). =P I'm feeling pretty stupid by now. =D

This is *waaaay* interesting! Time to twist some rules on some challenges...

There's no free lunch. You gain something, you loose something. I used to play Orbiter until recently. There're fabulous work done there. But writing mods to it is far from being for the faint of heart. C++ is not that easy, it's hard to debug and "exceptions" just crash the whole shebang instead of being logged into a file. :-) For *real* space simulation, I don't think anything will surpass Orbiter for a long time. But to having fun, both writing mods and playing (with or without mods), I think that KSP is still the thing. They're not mutually exclusive, however. We can play both (if we manage to find the time, obviously!)

[snip] Anyway, the developer's exodus are not just off-topic, but also covered by a thing called NDA, and believe me - you are even more wrong about this than you think. There's not a single chance that anyone, anywhere, would be transparent about this.Not on this case, not on any other case. Non Disclosure Agreements have this name for a reason. :-)

Au contraire, this time is the exact opposite. They said what they think was going to happen ("1.4.3 next week"), something change or gone wrong, and then we have a situation created exactly by the transparency you say is the way to go. Sometimes we forgot that people do what people do, and not all the people are like "us". I'm pretty confident that such transparency would work with you as much as it would work with me - but it didn't worked for a lot of people, and know the guys have another fire to put out. The "sweet spot" of communication level is somewhere "lower" than this, if we take in account what's happening on this thread. But, granted, somewhat higher than the usual practice. I think you're mistaking transparency with communication skills. Low transparency is actively hiding information. Low communication skills is failing to show that information effectively. These are two different problems that happens to have the same final result - but being different problems, they need different solutions. "Use the right tool to do the job right" Nops. No new depot on steamdb.

Sausages, laws and software: too much transparency and it will affect your stomach. :-) The "level of transparency" is not that bad - you can find the information (or infer it) with proper research and perception - and this appears to be the problem. I think the problem is on the Communication level - and this can be happening even inside the Team itself, and the communication problems with the customers is more an effect than a cause.

I saw the light, I mean, read again some PMI essays. :-D Developing KSP is a *PROGRAM*, not a *PROJECT*. Any attempt to handle KSP as a Project will fail.

IMHO stock is what everybody gets by buying the game. The DLC is a paid add-on. An "official" add-on, but yet, something added to the game after being drafted from the shelf.

Google for it. What happened at that time leaved a lot of scars around here, and it's probable that the moderation would intervene to prevent a flame war.

And this is a problem. Believe me. The number of customers that complain are small compared with the customers that just go away. The complaining ones are the ones willing to stay, and since they are facing some problems to get what they want (stay), they complain in the hope of get things fixed. Happy people don't bother others because they are happy. Unhappy people does. And unhappy customers are customers going away (with their money).

As I said before, KSP is like a vintage operating system (in size and complexity). Features as added as the current ones are stable, but now and then a new feature breaks a stable feature, and then we have a patch issued. The usual life-cycle of a nowadays game *DOES NOT APPLY* (and I wondering if someone at TTI's HQ is reading this and learning something). A main stream game usually are developed for years (two is usual, but some ones took 10 - I'm looking at you, Last Guardian) in closed quarters, being published only when someone decides it's time to go gold. It's essentially a Cascade Development Process from the user's point of view (internally, God knows what goes). Once it hits the Box Office, it's a product, with a product's life-cycle. KSP is like Windows on this point: it's a Featured Driven Development (anyone knows RUP?). There's no way anyone but the biggest players could deliver such complexity in a one shot development process, so the features are delivered as soon as they are implemented. However, this leads to a problem: cash flow. Once a customer buys a version, it had paid for the features the product already have, but who pays for the new features? New customers. If by some reason these new customers declines in number, it affects directly the cash flow and, then, the capability to finance the resources to keep the development! The efforts being (fiercely) applied in some non-critical features (as Mission Builder and Localization) appears to corroborate my thesis: these guys are fighting for cash flow. We, current customers, are out of the cash flow. We already had given them the money, and the money was already been spent. So, given the choice between fixing a bug that affects a loyal customer (but that already has paid), and one the potentially increase the user base (what means *incoming*), it's easy to understand why the Management (probably TTI's management) are taking such decisions. What can be done? Essentially, what's being done: understanding that sometimes "things" happens, but actively complaining when something stupid happens due absolute lack of attention of the development team to us, current user base (being such lack of attention a demand of the management or not). The best and only way to help Squad to deliver a good product (or service perhaps?) is voting with our money. Things goes fine (or the finest it can be), we buy the DLCs and/or whatever they sell to finance the development. Things goes to the tubes? So the cash flow - we stop spending money with them. This is the only argument that Squad can use to counter-argue a short vision decision from the management: "You will loose more money on the long run than you will win in the short". Mainly because this is the only argument that really matters to Management: money

Disclaimer: It's all pure speculation, I'm pulling all of this out from my... hat... :-) and I'm extrapolating using what I learnt from my previous work on a multinational corporation. It's essentially a fictional short story. :-) A plausible one, nevertheless. The 1.4.0 launching date was a business orientated decision (ie., something that must happens to satisfy a business interest, and not necessarily decided by a business man). I think this is what happened due the somewhat large number of unhandled bugs - but hey we got Parachutes and some product Localizations (Brazil, Italy, German and French - exploring new markets may be the business need to be addressed ASAP). The 1.4.1 version was probably already scheduled (or at least planned) by the tech staff, as these guys are not stupid and already knew that 1.4.0 was going gold before being ready. Something messed up in the mean time, and 1.4.1 was launched before being ready too. *THIS* is the real issue, as it appears. 1.4.2 was so *fiercely* rushed into production, in the most corporate style: in the blind believe that 9 pregnant women can deliver a baby per month in the next 9 months.

My point is that it's pointless (pun not intended) to address this to the developers. This is a business decision, and should be handled as such. Devs do what the guy with the money tells them to do. We must address our concerns to these guys, not to the devs. Since we don't know who's this guy, then we address our rage =P to the Squad Team as a whole, and then they have an argument to be used with that guy, Well, clearly someone there really *do not* care about present customers, and are focusing on new ones. You are right, devs usually love what they do. But they need money to pay their bills, not love. And this money come from someone that doesn't love the game, but the incoming the game can provide him. We, users, need to find a way to to use money to tell someone, somewhere, what they should not do with the game we love.

What, IMHO, it's the right way to address the thing. The dev shielding is (between other things) precisely a way to redirect the backslash to the group as a whole, and not to individuals. From now on, it's over the Squad's shoulders the responsibility to address the issue and fix the problem. How? Who? When? It's their decision, not ours. They will win as a whole, or they will fall as a whole.

My bad, I didn't expanded the idea correctly: the same things that break mods, break the game internally. You can see KSP as a small, general physics and world drawing Kernel, and a ton of mods interacting with themselves in order to have something useful drawn on the screen. Some of these mods are written by Squad theirselves, some others by third-parties (us). I have the feeling that when they updated the "kernel" to cope with Unity's new version, they didn't propagated correctly all the changes to their "mods", and then someone above them told them to rush the thing out the door at some arbitrary (from their point of view) date, and then they crunched things the best they cold to meet the deadline demands, not the quality ones.

People do what people do. We need to draw a line somewhere to prevent verbal abuse escalation, but if you draw the line too low, people just leave. Paying people, I must remember. One need to learn to tell bad from evil. Bad can be handled and it's not rarely useful. People needs venting. It's what allow them to come back and try again. We need to learn to cope with that. The same can and must be said about users. Users invest they scarce free time on the game. Time that cannot be recalled. And they demand some satisfaction in exchange of such time invested - otherwise, they get angry. The very angry you get when your money invested didn't rewards as you was told it would. Developers are being paid to develop. Users are paying to use. This is a HUGE difference.

Yes, or at least it''s what I'm being told. However, I have no 1.3.1 legacy to worry about and the bugs on the 1.4.1 doesn't bugs me - but there's one on 1.4.2 that got into my nerves. So I just rollbacked to 1.4.1 and I'm having fun since them (but granted, eventual grinds too). Being a developer myself, I'm recognizing the reasons the 1.4 series are breaking up 1.3.1 mods, and let me tell you : they had no choice but to do it. This will make things better and faster on the short and long run for new players (as me). Sooner or later they would have to migrate to a new Unity's version anyway - new versions for key components, death and taxes: no one can run from them. No. :-) So they can focus in what *need* to be done, and not what a myriad of stalking-holders "think" they should be doing. Someone, somewhere is responsible for this work, but not the developers. Developers should focus on developing the thing. What should be developed is, usually, a task for a third person. Development *is hard enough*. I'm peeking the published API and let me tell you, the Dependency Structure Matrix for this thing must be... Intimidating at best. :-) Managing customer's expectations is a full time job by itself. I can think of may reasons this had happened, the two main ones IMHO are: the developers *knew* what's going to happen, but some business need had to be coped with and someone above them told them that this heat is a less undesirable collateral effect that what would happen by not doing it. there's no one handling customer's expectations right now, and the dev team is handling this themselves. The first option has no remedy - the guy with the guns, I mean, money is the guy that take the shots, I mean, decisions. If this is the reason, we must deal with TTI, not with Squad, in order to have this sorted out. The second option appears to be easier to fix.

"Oh, my God! Another patch delay? So I will have to play 1.4.1 KSP for another week?" Ok. This is not a problem. :-) And this is the very reason devs should be shielded from stake-holders, by the way.

I think I found a conceptual bug on AGex. I built a space station, set AGs 8 to 0 to Toggle Navigation Lights, Toggle Fuel Cell Generators and Toggle All Solar Panels. Then I built a Escape Vehicle, where AGs 8 and 9 match the station ones, but 0 toggles the service module's engine doors. Everything works fine until I dock the vessel into the station. From this point on, "0" acts on the docked vessel's engine doors and not the solar panels. I tried to "Control from Here" the station's command module. I tried to go back to the Tracking Station and then select again the Station to fly. No good. Can anyone confirm this behaviour on AGex? It's something I'm doing wrong? It's something on the game, and so AGex is helpless on the issue?