FlowerChild

Hehe...yeah, and I'm also using this as a simple test case to see how the system works overall. More complicated stuff like the mod's life support system and resource processors can wait until I've learned the basics of how everything works Will PM you the relevant portions of the log momentarily.

Cool stuff man. Much obliged for the quick fix. Will have another go at it tomorrow. - - - Updated - - - Well, decided to give it a try with 3.5.2, and unfortunately same crash is occurring. Here's the full source file in case it helps any: using System; using System.Collections.Generic; using System.Linq; using System.Text; using UnityEngine; namespace BTSM { [KSPModule( "Probe Core" )] class BTSMModuleProbePower : BTSMPartModule { private static int m_iNumOutOfEnergyUpdatesForDamage = 20; [KSPField( isPersistant = false )] public float energyConsumedRate = 0.16666668F; // default is same as Stayputnik (6X a stock probe core) [KSPField( isPersistant = false )] public bool canBeDisabled = false; [KSPField( isPersistant = true )] public bool m_bProbeDamaged = false; // persistant variable to track if the probe has been damaged by lack of power private float m_fEnergyRequiredLeftovers = 0F; // variable to store any energy remnants required which haven't been consumed on a previous update private int m_iOutOfEnergyUpdateCount = 0; // acts as buffer to prevent momentary power supply problems due to vanilla bugs causing probe cores to fail [KSPField( isPersistant = true, guiActive = true, guiActiveEditor = true, guiName = "Probe Core"), UI_Toggle( disabledText="Enabled", enabledText="Disabled" )] public bool coreDisabled = false; public bool m_bPreviousCoreDisabled = false; [KSPAction( "Toggle Probe Core" )] public void ToggleProbeCoreAction( KSPActionParam param ) { if ( vessel != null && vessel.IsControllable && canBeDisabled ) { coreDisabled = !coreDisabled; RefreshAssociatedWindows(); } } public override void OnStart( StartState state ) { base.OnStart(state); if ( !m_bInEditor ) { if ( m_bProbeDamaged ) { DamageAssociatedProbeCore(); } else { SetProbeCoreDeactivated( coreDisabled ); } } else { BaseField coreEnabledField = Fields["coreDisabled"]; if ( coreEnabledField != null ) { coreEnabledField.guiActive = canBeDisabled; coreEnabledField.guiActiveEditor = canBeDisabled; } } m_bPreviousCoreDisabled = coreDisabled; m_fEnergyRequiredLeftovers = 0F; m_iOutOfEnergyUpdateCount = 0; } public override void FixedUpdate() { base.FixedUpdate(); if ( !m_bInEditor ) { bool bShouldGUIBeActive = canBeDisabled; if ( m_bProbeDamaged ) { bShouldGUIBeActive = false; } else { if ( m_bPreviousCoreDisabled != coreDisabled ) { SetProbeCoreDeactivated( coreDisabled ); m_fEnergyRequiredLeftovers = 0F; m_iOutOfEnergyUpdateCount = 0; } if ( !coreDisabled ) { if ( !AttemptToDeductEnergyForUse() ) { if ( !canBeDisabled ) { DamageAssociatedProbeCore(); bShouldGUIBeActive = false; } else { coreDisabled = true; SetProbeCoreDeactivated( true ); ScreenMessages.PostScreenMessage( part.partInfo.title + " shut itself down due to lack of power.", 10F, ScreenMessageStyle.UPPER_CENTER ); m_fEnergyRequiredLeftovers = 0F; m_iOutOfEnergyUpdateCount = 0; } } } else if ( !vessel.IsControllable ) { bShouldGUIBeActive = false; } } BaseField coreEnabledField = Fields["coreDisabled"]; if ( coreEnabledField != null ) { if ( coreEnabledField.guiActive != bShouldGUIBeActive ) { coreEnabledField.guiActive = bShouldGUIBeActive; RefreshAssociatedWindows(); } } UpdateStateString(); } m_bPreviousCoreDisabled = coreDisabled; } private bool AttemptToDeductEnergyForUse() { return ConsumeResourceReliable( "ElectricCharge", energyConsumedRate, m_iNumOutOfEnergyUpdatesForDamage, ref m_iOutOfEnergyUpdateCount, ref m_fEnergyRequiredLeftovers ); } private void DamageAssociatedProbeCore() { ModuleCommand associatedCommandModule = FindAssociatedCommandModule(); if ( associatedCommandModule != null ) { associatedCommandModule.minimumCrew = 1; if ( !m_bProbeDamaged ) { m_bProbeDamaged = true; ScreenMessages.PostScreenMessage( part.partInfo.title + " was damaged due to lack of power.", 10F, ScreenMessageStyle.UPPER_CENTER ); } } } private void SetProbeCoreDeactivated( bool bDeactivated ) { ModuleCommand associatedCommandModule = FindAssociatedCommandModule(); if ( associatedCommandModule != null ) { if ( bDeactivated ) { associatedCommandModule.minimumCrew = 1; } else { associatedCommandModule.minimumCrew = 0; } } } private void UpdateStateString() { ModuleCommand associatedCommandModule = FindAssociatedCommandModule(); if ( associatedCommandModule != null ) { string sDesiredStateString = "Operational"; if ( m_bProbeDamaged ) { sDesiredStateString = "Damaged"; } else if ( coreDisabled ) { sDesiredStateString = "Disabled"; } associatedCommandModule.controlSrcStatusText = sDesiredStateString; } } private ModuleCommand FindAssociatedCommandModule() { return (ModuleCommand)FindAssociatedModuleOfType( "ModuleCommand" ); } public override string GetInfo() { string sDescString = "<b><color=#99ff00ff>Requires:</color></b>\n" + "- <b>Electric Charge: </b>" + FormatRateString( energyConsumedRate ) + "\n"; if ( canBeDisabled ) { sDescString += "\n<b>Can Be Safely Powered Down</b>\n"; } else { sDescString += "\n<b>WARNING: Requires constant power to avoid damage</b>\n"; } return sDescString; } public static void FixedBackgroundUpdate( Vessel vessel, uint uiFlightID, Func<Vessel, float, string, float> ResourceRequestFunc ) { Debug.Log( "BTSMModuleProbePower: Persistant update for " + vessel.vesselName ); /* float fResourceToRequest = 10F; float fResourceConsumed = ResourceRequestFunc( vessel, fResourceToRequest, "ElectricCharge" ); */ } } } FixedBackgroundUpdate() callback is right at that bottom there, and is the only thing I've changed from previous versions. BTSMModuleProbePower is basically added to every probe core in the game and replaces the stock energy management for probe cores in the mod to handle them being damaged due to lack of power, and also to get around stock rounding errors in resource management by tracking remainders between ticks. If you take a look at the mod itself, the modules are added in BTSMPartChanges.cfg with an example right at the top of the file for the Stayputnik, like so: // Stayputnik Mk1 @PART[probeCoreSphere] { @TechRequired = start @description = The Stayputnik offers the ultimate solution in crew safety. A "lightweight" sphere equipped with remote receivers, it carries no crew at all, thus keeping them perfectly safe from all harm. This device does require electricity to operate however, and will cease to function if the power runs out. The built-in batteries should keep it going for about 10 minutes. @cost = 500 // 300 stock @mass = 0.5 // 0.6 1.522 // 0.05 stock // noseconeish drag @maximum_drag = 0.1 @minimum_drag = 0.1 @angularDrag = 0.5 @MODULE[ModuleCommand] { !RESOURCE[ElectricCharge] { } } MODULE { name = BTSMModuleProbePower energyConsumedRate = 0.165 // 6X stock core (0.02777778 rounded to 0.0275) } @RESOURCE[ElectricCharge] { @amount = 100 // 10 stock @maxAmount = 100 // 10 } !MODULE[ModuleReactionWheel] { } !MODULE[ModuleSAS] { } MODULE { name = BTSMModulePressureRated } } Let me know if there's any other relevant info I can provide.

I was fooling around with attempting to support BackgroundProcessing in BTSM this evening, which seems to run fine on its own, but soon as I attempt to add callbacks into my own part modules, it appears to crash the game during loading before hitting the main menu. I only added a single function to my part module, as follows: public static void FixedBackgroundUpdate( Vessel vessel, uint uiFlightID, Func<Vessel, float, string, float> ResourceRequestFunc ) { Debug.Log( "BTSMModuleProbePower: Persistant update for " + vessel.vesselName ); } Which is obviously not intended to do anything other than establish that the callback is indeed being called at the appropriate time. Removing the single Debug.Log() call results in the same crash. Any ideas as to what might be causing it? Am I doing something funky or am I simply the first to test out the mod support functionality?

Thanks for the summary man! Much obliged On this one point: Yikes...yes...please

@Oafman Wow. That's probably the single most uncool statement I've seen on these forums. @DavidBowman: Welcome to the forums man. I assure you that not everyone here considers "Dueling Banjos" to be the soundtrack to their lives

True enough. Don't get me wrong, I still very much think making the next version the release version (unless additional modifications are made to the release process to provide mass testing) is a terrible idea, and I've probably been one of the most vocally opposed to it. However, I'd probably be just as vocally opposed to it, and just as convinced of it, if I were the only one that had that point of view. Minority of one and all that. I just don't think that stats alone make a very compelling argument for anything, and that ultimately Squad will either hear the reasoning behind some of the arguments here and potentially modify their plan as a result, or they won't, and even if they do hear them, it's no guarantee they'll choose to respond to them.

I think it would be very hard to predict how low the percentage could possibly go. I think all we really know is that just over 500 of what are probably some of the most hardcore forum goers/players that make up the overall KSP player base think it's not ready for release, and while I have no idea how many copies KSP has actually sold, I'd be willing to bet that's probably a rather small fraction of the overall number of players. Statistics collected from polls are very funny things and are highly dependent on the context in which a question is asked and who winds up responding as a result. Even choosing to respond to a poll in the first place indicates a person has a particular interest in the topic at hand...or just really likes answering polls

Unfortunately, it may not be incorrect either. One key point about the 75% figure is "and dropping". Was 80% a couple of days ago, and the longer this goes on, I suspect the smaller that number will get. I've been watching it rather closely and there's a steady downward trend there. My personal theory is that the longer it goes on, it slowly shifts from being dominated by the more hardcore forum goers that follow issues like this closely, to extend out into the more casual audience that may not feel as passionately about something like this and may not understand what all the hooplah is about in the first place. I also eagerly scanned over the dev notes to see if there was any mention of this, and while I was disappointed there wasn't any, I wasn't entirely surprised either. They may not be able to answer these concerns at this time, beyond what they've already said. They may want to think it over longer before committing to any particular course of action. They may think the answers they've given are already sufficient and addressing it further will only serve to stir the kettle and focus people on it even more. We just don't know right now.

Yeah, I really don't think that comparing a game that calculates physics on a per part basis for arbitrary player-designed vessels to a largely fixed-environment FPS is at all a fair comparison. That kind of flexibility comes at a heavy performance cost, and one of the reasons free-form destructability of environments is such a big deal in FPS games is because it prevents a lot of the more traditional optimization techniques from being applied, that rely on a largely static environment where you can perform a lot of precomputation to speed things along at run time. The less you know about your data set ahead of time, the less of that you can do, and I can almost guarantee that Metro relies on an at least partially static environment to run at a reasonable frame rate. In other words: player freedom comes at a heavy performance cost, and KSP has an awful lot of player freedom. It's a similar situation to how people complain about the performance of Minecraft when it's so graphically simple in comparison to other games, and claim that's because of poor code or what have you. What they're neglecting there is that you're talking about an entirely free-form world where pretty much everything is dynamic and can be manipulated by the player. Some of the optimizations in the code to make that a possibility were actually quite brilliant at the time, and were a part of why that game was a first of its kind in a lot of ways. Do I think there's room for performance improvements in KSP? Almost inevitably. But it's really not fair to Squad to compare apples and oranges in making that point.

Just to return to this post for a second I want to point out that development strategy is actually a recipe for disaster. I've been through this process many times, and reserving bug fixing for the end of a project instead of fixing as you go is a good way to create a living nightmare for your development team. Yes, a certain period of intense bugfixing will ultimately be required, but IMO, that's a result of the failures of a development process, not something that should be expected or encouraged. Unless developers take a certain amount of time to self-test and fix their code as they go, bugs stockpile and exasperate each other until you end up with a horrendous tangled mess that can drive you to madness on large projects, where your attempts to fix one thing will often wind up breaking another, and the actual origin of a particular bug can be obscured by the magnitude of the code base you are now working with. Bugs are usually easiest and least time consuming to fix immediately after writing the code in question, as whomever is working on it is still intimately familiar with the way the logic works, and where the bug actually resides is easier to identify since you just put it there. And really, I think that's part of why I lack confidence here. When something as readily apparent as the radial decoupler bug goes unresolved version after version I question the development principles at play here and how it will all play out when people are crunching like crazy trying to get the game out the door.

I would propose that it's because you (and I both) know what to avoid. Will new players that just bought a released game be aware that landing on the poles of a planet, flying into the sun, or trying to land on Jool could effectively wipe out their save game? Is that a reasonable thing to expect from them, especially when for a new player those probably sound like fun things to try? I think as a community we're habituated to knowing this kind of stuff and taking it for granted. We're used to using stuff like you mentioned about sepatrons for radial decouplers to work around bugs. We're used to rotating our viewpoint ad nauseum to place a maneuver node that's just refusing to show up on a trajectory for no apparent reason. We're used to continually hitting "F5" to back up our saves in case our ships decide to spontaneously disassemble and to avoid playing "hardcore mode" with no reverts because we know things could go haywire at any moment. We're used to our trajectories suddenly shifting onto a collision course instead of the intercept we painstakingly plotted with maneuver node tools that are at best clunky and at worst infuriating when we change SOI's, swearing a bit, and then just moving on. New players do not expect these things, and particularly not ones that just bought a "released" title that is basically putting itself forth as a complete game. Many people avoid purchasing games in early access precisely because they don't want to have to deal with those kinds of issues. Is it theoretically possible that Squad will somehow fix all that stuff and all the new bugs they are bound to generate for the next version while simultaneously rebalancing every part in the game to accommodate the new systems they are adding? Sure. Is it likely they will manage it given the course of action they've stated as planned? That is where I think many of us are saying "no" and are urging them to go through a more robust testing process.

I think this is the underlying assumption many of us here would disagree with. I personally consider the game to be very buggy (and I'm not talking about 64 bit win there, which I don't even use) for one that's shooting for a release with the next update, and beyond that, my feeling is that it's been getting buggier with each of the past few releases rather than more stable, which is a rather alarming trend. At the far end of the severity spectrum, the community likes to joke about "the Kraken" destroying ships with physics bugs, but I doubt any of us would consider bugs that can not only destroy hours of play for no apparent reason, but even corrupt a person's entire save game rendering it unplayable without manually editing the file yourself, to be a reasonable thing to be occurring in a "released" game, or a game that's gearing up for release. And that's without any new content, which Squad is still in the process of adding, and which will inevitably result in more bugs. I consider the real danger point here being that they aren't going feature complete and opening that version up to public testing, essentially working on new features right up until release.

That bug. Man, that one in particular is very relevant to the discussion at hand. It's been in stock KSP what now? 4 releases or so? It makes radial decouplers almost useless as they're just as likely to blow up an entire ship as to actually separate anything, and radial decouplers are such an important part of the game that I can't fathom why such a small issue hasn't been fixed and why the community hasn't been more up in arms about it. In terms of things that undermine my confidence that Squad can pull off a stable 1.0 release, that one is right up there near the top. That bug is very close to being what I would think of as a "show stopper", and letting it even slip through the cracks for a single release was too much IMO, nevermind 4(?).

That may be the case (I didn't know about it mind you), but it doesn't change the validity of the underlying point I was making there that modders tend to be keenly aware of the problems the game has, as we pretty regularly get them dumped into our mod threads

Yeah, I think that's a very good point as well that I should have probably mentioned in my post above. Many modders essentially run tech support for their own mods. As a result, we're exposed to a wide range of player problems, some of which may have to do with us, some which don't, but we generally have to evaluate each one to determine if a bug resides in our code or in Squad's. We thus become very familiar with the wide range of problems players face, and their origin, over time. There have been a number of occasions where I've implemented fixes for stock problems into my mod just to cut down on the tech support hassles and to create a more pleasant experience for players overall. The 64-bit windows thing is a good example. Modders became quickly aware of how many problems there were with that version because we were inundated with bug reports that had nothing to do with us, to the point where the 64-bit version was blocked in some mods entirely, and for myself personally "Are you using 64 bit windows?" has become one of my standard questions when handling tech support for my mod.

Man, as the creator of BTSM, I have absolutely no ambitions in that regard. I am fully aware that the balance of BTSM is NOT the stock balance, nor is it intended to be. It's essentially a total conversion that creates a different gameplay experience out of KSP, thus I do not think Squad suddenly deciding "oh yeah, we should go with this entirely different design paradigm and integrate BTSM into stock" would be even a vaguely good idea. Even that aside, I highly doubt that's what's motivating modders to oppose releasing (and you're right in that many seem to). What I think it more likely is, is that modders are essentially developers (depending on the mod type). Thus, we are more aware of the dangers of releasing a game with features that haven't been sufficiently tested. We are also more likely aware of the bugs that exist within KSP as we have to wrestle with them on a continual basis to get things working the way we would like. Also, I think what modders have mostly been advocating (and definitely what I've been advocating) is a more robust testing period, NOT the addition of more features. I just would really like it if Squad were to consider putting out at least a single feature-complete version to the community so we can hammer on it and potentially find any remaining bugs and balance issues before it goes full release. I've previously suggested in this thread potentially opening up a 2nd stage of experimentals to absolutely everyone to that end. And as an aside: BTSM is NOT a realism mod. It's a gameplay progression and challenge mod

Thanks for the clarification. I hadn't noticed that, and yes, I do agree that we shouldn't be blaming the testers for the massive workload. Just my own interpretation here, but I get the impression it was an acknowledgement that many gamers are getting burned out on early access games in general and the many disappointments that come along with them, so I didn't take it as a comment directly related to KSP.

I'm also confused by this one Nathan. Can you present an example of someone that is "blaming" the testers here? Again, I'm in a situation where I'm getting the impression that this is directed at me given I've been representing the point of view that I don't think that Squad's usual testing procedure is sufficient to handle a release of this magnitude, but that's no way blaming the testers for it, more implying that they may be being handed an impossible task here. I'm also well aware of the number of bugs modders fix

Sorry, but I respectfully disagree on both points (or at least disagree the 1st has been established, and outright disagree on the 2nd), and I do not believe any of the comments on it were hysterical. Is it really necessary to try and belittle a point of view through derogatory language that I've tried to represent civilly and rationally? I can only assume you're referring to me with the above given I'm the only one that's been representing that opinion over the past few pages. I've also already stated my desire to drop that line of conversation, so not sure what purpose bringing it up again serves.

That's way too broad a generalization about people voicing concern man. All I would personally really want to see is one feature complete update before they go release, to give the community a decent chance to hammer on it and make sure it's ship shape before it hits prime time. I have zero attachment to early access, and on a personal level as a modder, I am actually quite looking forward to the release version of KSP as that likely means less drastic design changes for me to adapt my mod to with each release. Modding early access games can be a real pain as you're essentially chasing a moving target. Yup, that's what it looks like to me too.

This does though: http://forum.kerbalspaceprogram.com/content/326-Beyond-Beta Hence why I was suggesting opening up a second stage of experimentals to *everyone* before they release earlier in the thread, as it allows them to stay true to these statements while still getting the community testing of the release some of us believe it will need.

I'm honestly not even particularly attached to this point man, and don't really feel compelled to continue arguing it. It was a simple matter of someone expressing confusion over why people still suspected it to be the case, me trying to offer an explanation about why it's a point of contention in return, and I've been trying to explain my explanation ever since Beyond saying to Squad that it may be a good idea to offer a more credible explanation to the community to cut down on such speculation, I don't think dwelling on it further serves any real purpose. Honestly, if they are having financial troubles, it's not the kind of thing I would expect them to share, I just think it's worth pointing out the explanation they gave doesn't really make much sense and I think that's contributing to the discomfort some of us are feeling over the 1.0 announcement. They may even be burning some of the credibility they are counting on right now in putting things that way.

We seem to be going in circles here. Yes, I realize that Max has denied financial issues being why they're releasing early. What I was explaining previously was why I still think it's the most likely explanation despite him saying it's not. When I said this: I was saying that "we can't share the reasons at this time" being something I would find to be a more reassuring explanation than him saying they just don't want to be in early access anymore. In other words, I'm less suspicious of: I can't tell you yet why we're releasing on this schedule, but it's not financial issues Which I find more credible than: We are not having financial issues, but want to release now because we're sick of early access.

Please reference then, because the explanation from Max I've read is the same one that is in the OP: With the actual explanation part of it bolded, and is the part that makes no sense to me. Throw in the fact that when someone says to me "this is not the reason I'm doing such and such but here's an alternate explanation which makes little sense" (e.g. "I'm not here to rob your house I'm just going door to door selling these handy glass cutters") my natural inclination is to suspect the denied explanation is in fact the one that applies, and it pretty much explains why I'm rather suspicious here.

And contradicted their previously stated plans in the process. What's wild and baseless about thinking that an early access game that is rushing to release for unknown reasons may be running into financial trouble? There's a rather large precedent for that happening. I'm not even saying that's the case. All I'm saying is that in the absence of a more reasonable explanation for why they've suddenly changed their plans and seem to be rushing the game out the door, it seems to be the most reasonable theory. Heck, I'd even have found something like "we can't share the reasons at this time, but don't worry, we're not in financial trouble" to be a more reassuring explanation than "enough with the early access already", because yes, then it opens the door to stuff like you were talking about being a distinct possibility.