Greys

Ok so both of you are pretty far off, Justin is closer but critically incorrect, and I believe the best way to explain this is a short class on how plugins in KSP work Coding for KSP consists primarily of exploiting two mechanisms for making code run, MonoBehaviors, and PartModules, now the tricky part here is that almost everything is a monobehavior. Monobehavior is a class provided by Unity which has access to a set of event-like systems for making code run when you want it to, mostly by using the KSPAddon attribute to control what scene the code fires on, and specifically named methods that Unity looks for and executes as needed. PartModule is a class provided by KSP which is itself a monobehavior, with additional built in fields and methods that define a context, the big two are part, an instance of Part, and vessel, an instance of Vessel (you'll see this theme a lot in Squad's code) PartModules get executed by being added to a Part instance's Modules object (part.Modules), usually via cfg file. The intent of PartModules is to section off functionality so they can be applied to any part, and any part can have many of them, allowing for the mixing of features with minimal custom code. PartReplacement has Nothing to do with PartModules. As mentioned there is a class Part which is instantiated for every part that actually exists. Now Part is what remains of an older system intended to allow for the reuse of functionality, Module, or PART{module=Part} in a cfg file. The problem with Modules is that the Part instance can only have one Module, so you can't mix features provided by Modules. Over time Squad has deprecated most of the Modules by converting their functions into PartModules, but there are a few notable remaining Modules, Part is likely to stay forever, but there's also FuelDuct and Strut, which are a weird sort of magical mystery box of disappointment and anger when you look into how they work. Much of the base features that PartModules make use of to actually achieve stuff is defined within Part, or within Vessel. For example, if a PartModule wishes to charge a resource cost for the use of it's function, such as engines burning fuel to produce thrust, they do so via part.requestResource() (remember, lowercase p is the Part instance). This is all great unless you don't like how Squad decided to make something work, or want to expand upon it. If you want to change the way something in Part works, you can, maybe. Because Modules are defined per part in the cfg file, you can make a class that inherits from Part (public class BetterPart : Part), and then change the cfg files to use your class instead. The limiting factor is whether you can override the methods that provide the function you want to change, and a good handful of them are Virtual, so you can override them, but most are not. The other limiting factor is that you cannot change signatures, if the class you're overriding took 3 arguments of these types and returned a float; you must also take 3 arguments of those types and return a float. You can of course add wholly new methods without issue, and this can be very useful for adding new functionality; or circumventing access levels. And here is the problem. There Can Be Only One Module On A Part. So if I make a class that inherits from Part, and you make a class that inherits from Part, and our classes do completely unrelated things to Part, only one of us gets to make a given part use our Module. That is what PartReplacement solves. it Replaces Part and slips in a system that lets other assemblies insert changes to the Part instance through it. Thus, now two plugins that want to make unrelated changes to Part, can do so and be compatible with each other. PartReplacement is exactly what it is, if you found the name confusing it meant that you didn't understand what this project does.

Here is the complete log exemplifying the NRE that results from reverting-to-launch https://gist.github.com/Greys0/70fec163ca1677f17803 NullReferenceException: Object reference not set to an instance of an object at Part.requestResource (.Part origin, Int32 resourceID, ResourceFlowMode flowMode, Double demand, Int32 requestID) [0x00000] in <filename unknown>:0 at Part.RequestResource (System.String resourceName, Double demand, ResourceFlowMode flowMode) [0x00000] in <filename unknown>:0 at PartReplacement.PartEventTypes+SingleCallBack3Arg`4[System.Double,System.String,System.Double,ResourceFlowMode].Invoke (System.String arg1, Double arg2, ResourceFlowMode arg3) [0x00000] in <filename unknown>:0 at PartReplacement.PartTapIn.RequestResource (System.String resourceName, Double demand, ResourceFlowMode flowMode) [0x00000] in <filename unknown>:0 at PartReplacement.PartTapIn.RequestResource (System.String resourceName, Double demand) [0x00000] in <filename unknown>:0 at PartReplacement.PartTapIn.RequestResource (Int32 resourceID, Double demand) [0x00000] in <filename unknown>:0 at ModuleReactionWheel.ActiveUpdate () [0x00000] in <filename unknown>:0 at ModuleReactionWheel.FixedUpdate () [0x00000] in <filename unknown>:0

To anyone who has been following #KSPModders or myself over the last 3 days this is not much of a surprise, but I have been developing a proof of concept for a centralized project that will allow other mods to modify the behavior of certain classes in KSP's Part class, with minimal conflict between us. The concept is simple, certain methods in Part are virtual, these can be overridden already, but the way that it currently works is that you must make a class which inherits from Part and then edit all the cfg files (or use an MM patch) to make every part you care about use your class. The problem here is that every part has only a single class such as this, so if there exist two projects which need to do this, they are inherently incompatible with each other. PartReplacement steps in to fix this, and replaces the class itself, but then offers an Event style system for other assemblies to tap in and access things happening, or change how those things happen. So the two projects instead of making their own Part replacement, interface with this one, and can now be compatible with each other. There do remain, and will always remain situations where there can be only one, but many of the reasons you would override Part are completely unrelated to each other. As it stands this is only a prototype and proof of concept. In my testing it does function, and presents a standard for expansion; but it does not yet offer access to every virtual class in Part, as that is simply time consuming. I am only aware of a single bug in the current implementation, if during a flight the player reverts to launch, and presumably reverts to quicksave, some object reference is broken and an NRE spam results. I don't entirely understand where so I'm not going to let that stand in the way. Please understand that this is not ready for distribution to users Please also understand that this is very much a Request For Comments PartReplacement is available here https://github.com/Greys0/Virgin-Kalactic/blob/master/Source/Virgin_Kalactic/BetterPart/PartReplacement.cs There are two classes contained, -PartTapIn, which via an MM patch is set to be the PART.module for all parts during the loading process -PartEventTypes, this contains the types that are instantiated in PartTapIn to form the event system, there are only two types currently but this will be expanded as necessary; Though I am trying to keep all the event types as generic as possible so they can be reused PartTapIn contains the instantiated events, OnRequestResource and OnResourceRequested, and a type casting funnel to cover the six different overloads of Part.requestResource(), bringing them all down to a single point. At that point the request is passed to OnResourceRequested to be fulfilled, and the results are then broadcast to OnRequestResource. I personally find the nomenclature at this point a bit easily confused, if anybody has a better naming scheme for these two events I'd be glad to hear it. Without any other action, PartTapIn defaults to sending the OnResourceRequested event to the original handler from KSP, so until another assembly sets it otherwise, the original behavior is maintained. Like I said, I have not populated the rest of the virtual classes, but it should at this point only be a matter of deciding on an event type that will work for it, making that if needed, and then assembling the event instance and override. I have also updated my TrackResource system, entirely rewritten actually; to use this new interface and test that it works, you can see that here: https://github.com/Greys0/Virgin-Kalactic/blob/master/Source/Virgin_Kalactic/TrackResource/TrackResource.cs You can see on lines 43-46 how I add the ResourceStats instance to every part's OnRequestResource throughout the vessel; but if you were running from a PartModule you'd only need the regular part reference So, big questions, is this a good way to do this? How can I improve the nomenclature? What's the next most important method to expand this to? Anybody know where that object reference went? (error log to follow) Really anything. Regarding Licensing. I do not care whatsoever about having my name attached to this project, I'm pretty proud of what I've achieved and that's good enough. But, the reason this project exists is as a sort of solution to the There Can Only Be One problem that comes along with overriding Part, as such I really want to dissuade any competing PartReplacement projects. I have to begin with licensed this as all rights reserved to the Virgin Kalactic Group, I am willing to discuss changes to this.

SurfaceAttach Joints are not part of the stack, regardless of the configuration they have crossfeed disabled and there's only 1 way to fix that. The intent is that for any radial fuel tanks you would connect them with a fuel duct but NathanKell has found the time to make a plugin that implements a partmodule which enables crossfeed on surface attached joints for the parts with the prescribed cfg modification. http://forum.kerbalspaceprogram.com/threads/76499-0-24-2-CrossFeedEnabler-v3-0-2-9-12-14

Yea, in Unity you get a double collision which might or might not destroy the world, it seems to be a dice roll. I've had parts that would jump 20 meters into the air when I walked up to them because of that

The prior discussion of this thread does not apply any more, node_collider has been obsolete since PartTools was introduced in 0.18 Concave colliders are permissible but they are much more expensive, orders of magnetudes of magnetudes more expensive, and if two concave colliders touch each other weird things happen up to and including the heat death of the universe. Keep in mind that terrain is a concave collider. The better option would be for you to section the hollow collider into a bunch of fingers, this can be done via duplication and rotation once a single one is configured properly. As mentioned, concave colliders are very expensive to compute collisions against, so a large number of concave colliders will likely still be cheaper; and if you can built and animate it using cube primitive colliders then it will be almost free. However, if this part is to be any of the normal stack diameters we're used to in KSP, having that many colliders in a small space may very likely result in krakens, and if something were in the mouth of it when it closed, they would likely both explode. Finally, I know of no way without a plugin to toggle the collideability of colliders, I also haven't really ever seen anyone try so you'll have to test; but you may just have to live with all of these colliders being active at all times. I recommend you start a new thread on the matter once you get to trying things, this thread will only confuse people trying to help you and won't appropriately attract people with applicable knowledge

looks like rescaled parts that use NODE{}, which parts are those or could you pastebin their cfg files?

doing it with MM only cleans up your UI, all the assets will still be there taking up space. Deleting them manually is the correct way but if you just want to hide them there are several mods for sorting parts in the editor, and I believe most of them allow you to hide given parts.

I can't really contribute to the problem at hand, but I recommend you switch to .Blend, .Play doesn't play nice, only one .Play can be operating on an object at a time, this is why KSP partmodules don't play well together. .Blend is functionally the same as .Play but it's totally cool with multiple animations playing at once; it might not matter to what you're doing, but it'll make your stuff play well with other people's stuff, as long as they use .Blend too.

Users have the right and I would even say obligation to use adblock soas to not experience unwanted, distasteful, and potentially harmful fourth party content; If they have any respect for content creators they should manage adblock to permit ads from creators they like and sources they trust, which is why I suggested ProjectWonderful which I have as a content consumer benefited from greatly over the years. Given the common availability of this tool on nearly every platform, I don't think users have any right to complain about creators getting money for their work. And I trust that SirCmpwn has access to the skill, either in himself or those around him to integrate ads into the site in such a way that would not be detrimental to the site as a whole.

I have a very small opinion about this matter, but the way I would be most comfortable with is you providing an interface for modders to access ProjectWonderful, and then the advertising money is between them and you don't have to be involved at all; I feel you probably will like this option in theory too because you being involved is potentially dangerous.

That would take a pretty significant modification of the workflow, but I'm not against it. As it is every part has an object which contains all the AttachNodes, what NodeToggle does is copy that object into itself, and then based on user input delete AttachNodes from the part; when the user enables them again it takes the copy it made and puts it back. Tav has asked me about making it remember when they've been disabled and the feature you're asking for would go hand in hand with that; I would need to add a new thing, probably a list or dictionary of binary values. It's doable, I can see exactly how, I'm not certain I will do it any time soon and I can say that adding the code to load state designations from the cfg file might double the amount of code. Life is complicated, I just took the tire off my car, took it to the gas station to refill it with air, and put it back on; hopefully in the morning it's still full. Point is, the time I can spend on games and games related activities is much smaller than the time I do spend, and life is starting to pull back it's foot. So, reviewing some things, I wanted to conclude this with a message that VirginGeneric.dll is effectively MIT license so I checked to see how I had modified that and I was very confused to find that it is not, I must have messed up with that. I'm a bit tired but I have monday off and I should have it fixed then. As a holdover in case I forget or somebody wants to add the feature tomorrow (today (sunday)): I hereby grant Bac9, Taverius, K3|Chris, and anyone authorized by them the rights to modify, compile, publish, and distribute the source code of VirginGeneric.dll provided the terms of the public license are fulfilled. Derivative versions of VirginGeneric.dll released while this license is valid will be permitted but not required to operate under this license indefinitely. This license will be rendered null and void at the time that the Public License pertaining to this source code and binary is updated to be less restrictive. Public License as of this posting: https://github.com/Greys0/Virgin-Kalactic/blob/43915239202aa003b921b12d1476a6ab4f6875b7/Source/Virgin_Kalactic/VirginGeneric/LICENSE Most current Public License (same thing as of this posting): https://github.com/Greys0/Virgin-Kalactic/blob/master/Source/Virgin_Kalactic/VirginGeneric/NodeUtilities.cs I say permitted but not required because I expect that the wording of whatever license I end up assembling will be more open then what I've authorized above, and it will certainly be more clear. I also want to be clear on my opinion of licensing mods. I feel that any plugin which patches a bug in the base game and nothing else, or adds a very small feature, should be released under very open terms, MIT/BSD where possible. Because of potential legal conflicts I strongly suggest against bug patches being GPL; I feel that the terms that KSP is sold under may directly circumvent GPL being used in certain ways, but people will still try and that dispute over the base game being fixed is bad for everyone. GPL is fine for larger projects which are incredibly unlikely to be 'bought' by Squad, or 'inspire' similar features which sufficiently resemble the GPL content that it would be a problem. The smaller your feature is the fewer ways there are to achieve it, and I feel that also circumvents GPL claims in the same way you cannot trademark "the". The one exception to being open is where openness potentially induces conflicts. BetterPart is All Rights Reserved because there can only be one BetterPart in play in a given instance of KSP at any given time, if there were a fork of BetterPart, the existence of 2 directly reduces both. I would however like to say that I have been working to rewrite BetterPart to be an event based system that any plugin can register with, and will in the long run be overhauling TrackResource with similar systems that will hopefully provide a lot of the base features that are generally wanted alongside in an event based system. I'm rambling and I've spent over an hour composing this. Just want to say that last time I worked on the update to BetterPart I got to a point where it looked like it worked, but then this happened

I find it important to point out that Squad, the authority in this situation; has no legal standing to demand anything regarding licensing as a whole. The only say they have is as mandates on a service; such as this forum and curse. If Squad mandated that mods released on these forums required to have a license of certain attributes, people who disagree would simply post their mods in other places that Squad does not have authority over; such as Kerbal Stuff, other places on reddit, other forums, personal websites. Not only is this Not A Problem, this is a situation for which no action can be taken. If you dislike that a mod you use is closed licensed, go try to convince the maker of that mod why they should change using polite words and well constructed arguments. Do not be surprised if that author didn't particularly have a reason for being closed licensed, or if they have very strong personal reasons that you will never change. Many mods are ARR because the author didn't want to put in the effort to pick out the right license, and many mods are ARR because open licensing can be terribly problematic for the people who provide support.

The current release version should be working just fine, nothing changed as far as normal parts go

yes and no, I'm in the middle of a major overhaul project and KSP is super broken so work is currently not possible

Trivial as in it would be a great project for anybody who wants to get into KSP modding but has always thought it would be too daunting to learn. Somebody who already knows how might get around to it, but most of them are busy with their own projects so unless it particularly ticks them off, well it's not exactly unlikely, but it's also not likely.

that's only true in the editor, in flight there's no mechanical restrictions on which parts can be the root part of the vessel because debris with a single part is a vessel and any part can be isolated.

not really. Color is broken down in a bunch of different ways, one of them Hue Saturation Value, I like to think of value as Intensity, basically white has an intensity of 100%, and a saturation of 0%, which means the hue is unimportant; Black has an intensity of 0%, making everything else unimportant. With the emissive layer set to black the part is emitting black in the same way an unpowered lightbulb is emitting dark.

This is really looking amazing, and I strongly feel that the 'axehead' design of the disk, mixed with the greater ratio between the disk and the capsule sections is a whole lot better than your experimental mockup. Now, you might consider making your own alternate model for the rings, in the IXS the rings are almost as long as this disc section, but ISM's rings don't have much more length than the struts holding them up. All I'm saying is that they're fairly insubstantial, and something with more meat would go well with this piece. There's a few ways to do it, I'd recommend making your own ring part; but you could also straight replace the model of the ISM part, which would replace it for existing ships too.

ModStats uses json to encode the statistics package for transmission to the collection server *goes for coffee* https://github.com/Majiir/ModStatistics/blob/master/ModStatistics.cs the very first line is: using JsonFx.Json; https://github.com/jsonfx/jsonfx

Update~, little change, recompile against 0.24.2, updated ModuleManager and CrossFeedEnabler in the release download, and updated ALL THE LICENSES~ There's one more change that I need to make the license and that's write it into BetterPart's license that it may be included unmodified without specific authorization. As always, download here: https://github.com/Greys0/Virgin-Kalactic/releases

So uh, I was away for all of that, I watched it in horror on my phone as many of you deftly avoided getting in a fight several times. Thanks Vanamonde. I just want to say that I really don't think there's any need for 'experts' to be that mechanical, but if yalls really wanted the way to do it would be with user managed user groups, similar to Guilds on Gaia Online or Outfits in Planetside 2, anybody who wants can make one and they're in charge of who joins and who stays, and there's some kind of badge thing; The problem is that any solution which displays on the post will be limited in how many groups a user can display next to their posts simply because too many would mess with the page layout. I took a look and couldn't find any decent looking thing for vBulletin, closest I could find was a bunch of things for minorleague esports team roster epeen billboarding, so it'd need to be made from scratch and in a lot of ways that's not something we can expect Squad to go along with, my main concern would be that a custom solution may be unstable or insecure. Still, I don't think we need it on the forums, but what we could do is have sig ribbons, and even that I wouldn't bother with. The support doesn't need to be the exclusive source of assistance either, by no means should the modder picking a guy or few to help equal the modder telling everybody else to shut up and let the professionals handle it, but through the relationship those people would be able to help better, and the modder would be able to step back, and if somebody else is wrong, the designated support should know and be there to inform all parties of the correct truth. Where it is helpful for the support to have legitimized authority is on other-sites, knowledgebase, bugtrackers, maybe the mod gets it's own forum, maybe the mod has it's own reddit, maybe there's a multiplayer server, or a planetside 2 outfit. In these places there's more to do than just posting and if a lot of users descend upon them it'll take a lot of work to keep up with.

I think working on a knowledgebase very much fits within the job description of a support group, developing and exploiting resources makes everybody's job easier, even if they still have to walk users over to the information on the wiki, if it exists there they can, and they can refine the page over time when people have trouble understanding it, and continue to help people as they follow the wiki's recommendation; but it will also eliminate some problem cases because the user did find it, and it will reduce some cases because the user did understand it; and hopefully over time, just as the modder can train the support to be more correct, over time the support can train the userbase to use, improve, and inform about the wiki. If done right it will snowball and you'll have a small team of official helpers, and a large core userbase who are also able to help maintain, develop, and direct to the wiki. I've always found that if you just have a wiki, it will almost certainly be unused, underdeveloped, and because of those two, frequently incorrect. By The Way, reference KSP's wiki, which is all of that. By having a wiki and a group pushing it's use and actively developing it, you can give it the kick start it needs to become worth using, and once it's worth using it's worth anonymous investing in to make it even better, and worth anonymous using as a source.

Well, more because NASA had nothing to do with this thing, it's a piece of art thought up by a scientist in his spare time, and he paid for a CG version of it 'to inspire the youth' But who's gonna complain about fictional things in a videogame? On topic; I think the saucer bit is a lot wider in the image, relative to the cockpit 'bullet' section. Also I believe from the image that the saucer is not a complete disk, it has hooks at the back

Yea, time to get back on topic There's two directions to go with this concept, "what if there were a singular group that modders could turn to", or "Should Modders create their own support groups", I think it's pretty clear that Monolithic Support Incorperated is probably just not going to work, disregarding whether it's a good idea or not. But modders developing their own organization of people they have personal reasons to trust using systems that are readily at hand seems like a powerful step forward from what apparently is happening way more than I thought when I started this. I feel that as I said before, the difference between helpful people and support is the relationship between the modder and the helpful people that permits the support to get valuable information to the modder; and the modder to kind of 'train' the support in how to provide support most correctly, which I think will happen naturally. But in addition to to that the support process makes it easier to funnel users to things such as wikis, making it easier to build them; and funnel users to, and train them on the use of bug trackers to further enhance the effectiveness of everybody involved. But, how formal does it need to be in order to get any of the advantages of being formal at all? I think not much. Having a list in the threads of people to treat as authority and also seek out for assistance, getting and setting up a bug tracker so that they are authority figures on it, as well as setting up the basic structure of a wiki with the assumption that it can be completed over time. Again, if you use github this is only a matter of getting the support people to sign up for github, and setting them as collaberators on the repo, and convincing users to sign up to. There are a lot of other bug trackers and wikihosts if you don't want to leverage on github, I'm not sure if there are any bug trackers that support anonymous(accountless) reporting though.