Greys

I'm not gonna judge the topicity of this, but it's certainly possible and I feel that for a lot of mods it's probably a really enticing choice with little obvious downfall, that being that the support pushes a recompile which isn't stable because either they aren't familiar with the code, or aren't familiar enough and the testing they did didn't find an issue. And that's not so much a problem with the idea as something that they'll just have to strive to not let happen. And of course they could make it very clear that the support pushed version is a holdover until the modder can step up (because life yo), and may be buggy so back up your save file. I fully accept this potentiality, unfortunately I don't at the moment have any real response for it except 'well hopefully that wont happen' Again, that is certainly a thing to be very very concerned with and I don't have a solution; I think more so than the first one this is a problem that doesn't have "a solution", it's likely a thing that modders and support will just have to be conscious of and act together when these users show up to satisfy them so that it does not become the former situation.

For mods hosted or using github, there are a lot of add-on services available. For one, there is a built in wiki system, users must have a GitHub account to edit, and it can optionally be restricted to collaborators on the repo. It's also well known that Git has a built in bug tracker, Issues, I find it's quite good though it could certainly be more powerful, I'd like to see it have mandatory custom fields and (mandatory) file attachment to reports. Lastly, it has a wiki-style site builder, which for anyone interested does support custom URLs, you have to own them but it's there. These are rarely taken advantage of and there's no real reason for that. A lot of mods, whether they're hosted on github, or just use github as a repo, have access to this. Have at thee? Also as a note to any github hosters, nowhere on the site will it give you download stats, but as long as you provide a download package when creating the release, instead of just offering the whole repo as an automatic zip package, it does give that stat in the API, https://api.github.com/repos/Greys0/Virgin-Kalactic/releases That's api.github.com/repos/username/reponame/releases; you can look at a specific release by then taking it's ID and adding /ID to the url, such as https://api.github.com/repos/Greys0/Virgin-Kalactic/releases/436795 The difference is critically the formality of it. I'm sure there's a lot of people who want to be helpful, but until it's been stated those people can only be the helpful people who were already there, they can't speak authoritatively on anything, and the modder is unlikely to just step back from assisting because people disappear some times, but most critically, there needs to be an active relationship between the modder and the support precisely so that the support can act as a funnel for the good info and a filter against the time consuming confusion

Yea, I was doubtful as I typed that, if they can understand the source they're also capable of writing their own plugins or even pull requests for the mod in question; but I left it in so that it could be debated

Before we get this going let me lay down some terms of participation. Number Zero, This is not a fight. Do Not Start A Fight. Number One, You are welcome to think this is a perfect idea, or a terrible idea, and dismiss it without reason; and you are welcome to state that, but please do not try to argue without reasons. If you dislike it, that's valuable, but if you think I should dislike it too, you'll have to convince me with reasons. Number Two, All points are valid until invalidated by reasons. Do not dismiss what other people say unless you can support doing so. Number Three, This conversation must start under the assumption that this is a bad idea which must be examined, supported, validated, and proven to be not a bad idea, anything else is worthless. I would very much appreciate any administrative action to keep this civil, coherent, and friendly. There was recently a thread attempting to discuss flaws with how modders mod, and among the few things that anybody managed to agree on is the fact that modders of successful mods spend an undesireable portion of the time they can dedicate to their volunteer effort supporting user having what is sadly by-in-large user caused errors, and for their effort they don't get much in return, and the cost is time spent developing the mod and fixing actual errors. So What If modders could choose to offload supporting their users to a group of volunteers who would make themselves familiar with the mod's source and personally assist users in solving user-error situations, and aid in the creation and curation of useful bug reports to be passed to the author, as well as helping the author to seek down where bugs may exist in the source and include that information in reports. The goal is to alleviate the modder of dealing with users who've installed the mod wrong, have an old version, are using version X of this with version B of that even though it's clearly stated that version X only works with version F and how did you even find version B that's like two years old bro I mean really. The major drawback that I see is that it's difficult to quantify if the support group is trustworthy while also staying out of their hair, and if things go bad it reflects negatively on the modder 'employing' them, but surely there are more ways it could go wrong, and hopefully ways to account for that, as well as ways to make it go right. So, anybody think this can be made workable?

Regarding the textures, I think any sentiment that they're inadequate is taking things a little too seriously. Good textures are important, but they're far from the top of the list. The first thing I said in IRC upon looking at your pictures is that they were a little simple, but your models are great. For your money, the fastest way to make basic textures look better is by spending some time making the UV unwrap more workable, and then do an Ambient Occlusion bake; which will add shadows to the texture and make it look less.... made out of wet clay. Then, because what you've got is pretty awesome already; ask for help? I've spent a lot of times on my mod recently redoing models to optimize the UV map to support AO bakes and boy do I wish I had done it the first time around.

That's going to be hard due to how symmetry works, but I imagine if you could decide on a forward vector for the wheel and have it be uniform across the vessel and over time, then you could just compare the vessel's movement to that vector to determine the signage and apply that to the value you get off the wheelcollider.

Squad's opt-in dialog also has checkboxes checked by default, and google chrome defaults to trying to install McAfee antivirus unless you change the checkboxes

I won't post the logs but Rowsdower PMed me during the conversation because he had been away and lost track of the goings on, he confirmed to me that he has never been instructed to exclusively spotlight Curse Hosted Mods, there was no time at which this was the case. Btw Rowsdower, if you like feel free to post the logs of that. This just confirms your l assertion that most of these problems are simply the result of chronic miscommunication. In this particular case a lot of the argument last night was a non-dispute resulting from the two parties refusing to use the same meanings for the same words, resulting in answers from one party that don't fit the question from the other party but in fact the two are in agreement.

This is at the very lease a creative and skillful attempt to solve a perceived issue. Now, if I'm to understand how this all works, this would block and alert the user to any mods at all that have network code; so it's not really enforcing opt-in as much as it preempts it, and potentially this could make it impossible to run a mod even if you have disabled it's network operation depending on what else runs in that monobehavior. Say the mod has the network accessing code in their Start(). This isn't a complaint, I understand some people would prefer that out come, but you should mention this potentiality in the first post. I'd also recommend as a future feature that you check the offending monobehavior against the 'events' methods, Start(), Active(), Update(), etc(), and if you're disabling potentially mandatory functionality of the mod, just go ahead and disable all, the other monobehaviors in that namespace too to make sure you don't leave some half dismembered code that wasn't properly initialized running.

PART { NODE { name = something transform = NameOfTransformInModel size = 1 method = FIXED_JOINT } } This is PART.NODE, it was introduced in 0.20, and nobody could make it work. Part of this was because it was announced as PART.ATTACH, which doesn't exist. Now, it was figured out that this was wrong and that announcement has been corrected. What PART.NODE is supposed to do is allow you to define an AttachNode on a part via specifying a transform in the .mu 3D asset file, instead of using PART.node_ and specifying a vector with a series of numbers which are frequently difficult to adjust. For instance node_ specifies orientation as the average of 3 one dimensional vectors where the only thing you can impact is the vector's magnitude, not by degrees, but the average of Z=6, Y=0, X=1 composited into a single vector. Unfortunately knowing of NODE is not simply enough. The depths of faults in the code of this node have become reasonably insurmountable. The first problem with it was that NODE.size was ignored, this has been fixed as of 0.24, Thanks to Mu. Following that it was discovered that PART.NODE lacked any code permitting it to define a node to be a part's part.srfAttachNode. This has not been fixed but I have been able to correct it with a plugin which iterates over all the AvailableParts and applies the same logic as the base game to select a node to be the srfAttachNode, if a qualified node exists. DLL: https://github.com/Greys0/Virgin-Kalactic/blob/master/Build/srFix.dll SRC: https://github.com/Greys0/Virgin-Kalactic/blob/master/Source/Virgin_Kalactic/srFix/FixSurfaceNodes.cs License: MIT However, there remains a greater beast. NODE{} definitions are fully exempt from all scale factors applied to the part. PART.scale, PART.rescaleFactor, PART.MODEL.scale; all of it ignored. This can't easily be fixed from the outside because there's no way after the fact to tell if an AttachNode was defined by PART.NODE or PART.node_. The logical thing to do would be to crossreference the AvailablePart pool at PartLoader.Instance.parts against GameDatabase.Instance.GetNodes("PART"), and then apply the rescaleFactor which is stored in the AvailablePart to any matching nodes; But during the loading process all the PART nodes stored in the GameDatabase are striped of string values, or rather, values that are actually supposed to be text instead of numbers, enums, etc. To say that differently, there is no way to determine what part any given instance of PART in the gamedatabase was originally intended to define, all identifying information has been removed. This is a problem I've rammed into several times in trying to fix things which get loaded incorrectly and it's really aggravating because the only other option is to load the files again myself and create my own gamedatabase, which would also mean finding some way to apply ModuleManager patches to my duplicate, and that's getting crazy. As it stands NODE{} is functional, you can define everything about it, there's a fix for the one problem with it; but you Can Not Scale Parts that use NODE{} Glossary PART The structure in a cfg file which KSP uses to define an instance of Part Part The class in the code which is instantiated to define a part part The instance of Part filled with the values from PART PartLoader The class which is responsible for loading parts GameDatabase The repository of confignodes parsed from cfg files AvailablePart An object type used as a precurser to individual instances of Part on vessels; these define the parts as they are shown in the editor before you pick them out of the sidebar AttachNode An object type used to define all 'nodes' on all parts; 'node balls' are based on these and they define part snapping and define some attributes of the joint that is made there

In USA.comcast, they change basically when you vacate the IP for long enough for it to be given to somebody else; so you may have the same IP for months if your network is stable

Majiir is not the only person working on KAS, so things may still turn out in a timely frame of span.

Confirmed, Stage_PRI is ALL_VESSEL but limited to what it considers the current stage to be

NO_FLOW, no flow, ALL_VESSEL, all flow STACK_PRIORITY_FLOW will draw resource from the furthest part which can be accessed via stack joints; or by fuel ducts; fuel duct paths take priority STAGE_PRIORITY_SEARCH is the same, but it's blocked by stack decouplers; the result being that your lifter engines will not burn fuel from your orbiter stage

Sorry to say but everything is in order. Your part is modelled to be 10 units wide, so you had to scale it down by a factor of 10 in Unity, and then it was 1 unit wide, which means it is 0.25m smaller than stock parts. Everything adds up.

Brief update on the overhaul project, Good News, Bad News, Good News, Bad News Good news, I'm nearly done converting all the standard hexcans to NODE{} Bad news, NODE{} has bugs! Good news, I fixed the bugs! Bad news, THERE ARE MORE BUGS! The first bug is that NODE{} is handled by separate code from node_, and that code is incapable of declaring a node to be the surface attach node of a part. I fixed that, here's the fix for anybody else who wants it DLL: https://github.com/Greys0/Virgin-Kalactic/blob/master/Build/srFix.dll Source: https://github.com/Greys0/Virgin-Kalactic/blob/master/Source/Virgin_Kalactic/srFix/FixSurfaceNodes.cs License: MIT The second bug is that it seems PartTools 0.18 is no longer producing valid mus, so I'm going to have to update and hope that fixes it, and if not speak to taniwha about inspecting mu files to see if there's actually something wrong with it, and if not inspect the code to see if there's something wrong with that, and this might just take a while. On the progress front I've reunwrapped the hexcan, so that's good; but I'm changing away from the current design of the label plate, and will instead be appending a secondary mesh onto the parts which will be the label plate, this will look better, have nice lighting effects, and allow me to make use of smaller texture sheets for the hexcan, while simultaneously increasing texel size; which is just good. I hope this will also encourage other modders to make their own appended mesh to increase visual diversity; and maybe add other stuff. There's a big list of things that need to be redone, and I've finished two of them so far, as long as I fix the orientations and the nodes, textures and visual mesh can be changed at any time with minimal impact so this may become an on going project.

I fully agree, don't run things you don't trust. As to the controversy, the first post summarizes it excellently; a large number of loud disrespectful people have been causing a huff because of: Mods that check for new versions Mods that have network-accessing code which is not mandatory Mods that collect anonymous statistics for various goals As far as checking bigger mod's codes; yes it's daunting, but there are only so many ways to make network-accessing code, so you could check via a series of searches, you could even script it. By having a singular mod that is interfaced with via internal... things (ran out of big words), most mods would be able to do away with all of their network-accessing code so that if you ran such a series of scripted searches on the source, they wouldn't ping on the radar. It would be reasonably easy to say with reasonable faith whether a mod accesses the internet or not; saying what it does is more difficult especially in large codebases, but the central mod would not be large, and ideally it would have really good comments explaining everything so even people who don't know C# or .net could look at it, follow the comments, and understand.

I thought that was still hypothetical! Oh well, it's still a defensive measure from modders against "dumb users blaming us for problems they caused", same reason Kethane's install validator exists

The code for a mod to interact with remote systems over the internet looks nothing like the code that will let that mod interact with the version checker mod; so it will be very easy to tell if that mod is doing something suspicious. Ideally mods that don't require network access won't have any at all, so anybody who knows how to learn will be able to check all their mods for misbehavior quickly.

Basically, mods that use Compatability Checker contain a set of versions that the plugin is known to work for, and if you run the plugin on a version of KSP that isn't one of those, it tells you, because there's no way for the modder to know before hand if their plugin built for a previous version will run without flaw on anything newer. It's a warning, it's saying "if you have problems, it's not our fault, you're using a build that isn't intended for this version of KSP"

So I have a suggestion that may quell some of the insecurities about all this; firstly I am only speaking of version checking. What if there were a single mod doing this, that all other mods interfaced with in order to get the feature of version checking. This singular mod would be open source, publicly managed, and offer support for vetted hosting services such as KerbalStuff, Curse if possible, Github Releases, Majiir.net, and any others that come into existence. The key will be that as a service it will only permit given services which the devs/community deem trustworthy. No custom servers. This mod will go out of it's way to be very clear about everything happening and offer opt-directions clearly. It should also be a relatively small codebase, so it'll be easy for users to vet that it's not doing anything suspicious. Other mods will then access the version checker via a standard interface that declares what host to check against and what to look the mod up as. The version checker will then collect these and process the checks all at once at a certain point during starting KSP, and present them to the user in an organized singular dialog. With this singular mod we could then as a community ask mod makers to use the interface instead of handing it themselves, and mods could then advertise using it as a badge similar to the Intel Inside badge commonly found on computer towers. One of the key points is that the version checker mod should not be included in any mod installs, forcing players to opt in by installing it; and no mod should be dependent on it so players can choose not to. This could be achieved by having modders add a certain class to their assemblies which the version checker mod finds, and that class has the information in it, similar how Update() works. If we can get users to trust this one mod, and it prevents the private inquisition from torturing modders, that'd be worth it ya?

There was a bug prior to 0.24 where all PART confignodes in the gamedatabase were stripped of string values, and really any values other than floats, serialized floats, and enums. I haven't tested it myself but I was in contact with Mu and he tells me that's been changed. As a practical example here's some abandoned code I was working on, that is no longer needed in 0.24 https://github.com/Greys0/Virgin-Kalactic/blob/master/Source/Virgin_Kalactic/NodeFix/NodeFix.cs GameDatabase is supposed to be the original confignodes as defined in the cfg file, plus default values where they're not overridden PartLoader.Instance.parts is the pool of 'protoparts' that get cloned when you click on stuff in the VAB/SPH, changing things here will change them for the remainder of the runtime and apply to all newly grabbed parts in the editor. It shouldn't impact existing parts/existing vessels; but there's some indication that certain values are not actually stored on the vessel and get reloaded every time.

So I spent the last eight hours or so working on the HexRB, it's working out pretty well but then I hit a wall with the nodes. Unfortunately HexCans nodes are a pretty big mess and that needs to be fixed but fixing it will break everything. I've been working on a handful of revisions that will break everything. So I'm officially announcing HexCan's first intentionally save-breaking update. #1, All of the attach nodes are being redone using the now functional transform system; I've finished about half of this so far. This will break vessels, they should still load but they'll be assembled incorrectly #2, I'm going to redo the internal and external naming schemes so that they actually make sense and are congruent. This will break saves as the parts the vessels want won't be called that anymore. #3, Several of the mesh and most of the .MU will be revised to correct poor modelling, poor texture styling, and weird orientation conflicts throughout the set, this will break any mods that don't update their textures to match the new UV maps #4, Depricated parts will be eliminated, namely the SAS and ASAS parts will be replaced with Reaction Wheel parts. #5, new parts, but that won't break anything #6, still no career mode, and it doesn't make sense to me for manufacturers to be offering contracts to KSC. This will unfortunately break the alternate texture pack, and science patches as well. No timeline at this point, the HSR-100 is basically good except that it can't attach properly to anything because everything else is broke, and it's not balanced yet.

The truecolor files are very small textures, I quickly extracted the C7 one, it's this It was a very lossy extraction, but you can open this in gimp, presumably photoshop and anything else worth using. Presumably this file is used in the UI where the full size PNG texture is unnecessary. One thing to keep in mind is that the GameDatabase throws away file extensions, so there's no particular need to stick with truecolor either. I'm not aware of any reason to use that file type, but I'm not familiar with it either.

There are a lot of ways to make money irrelevant, I like to do it the easy way, sandbox mode.