Lisias

Where did you find the documentation for it? I looked in every IVA on Stock + DLC and none use it. I'm hunting down 3rd parties, but until the moment, your repo is the only one I found using it and I assumed it was a custom module, as the INTERNAL I found in your repo was using a custom InternalModule.

There's a somewhat interesting discussion about how to build IVAs using Blender and the mu plugin here: I think we should move the discussion here. Until there, may I suggest @ColdJ to take a look on that post and comment here what you think?

Yep. But a better solution is: @PART[31-37AD,37-50AD]:FOR[NeistAir] { -MODULE[TweakScale],* { } %MODULE[TweakScale] { %defaultScale = 3.750 %type = stack } } This will: Clean up any rogue TweakScale patches, preventing duplicates - and so you know for sure exactly what patch will be in effect at a given time. Will create the TweakScale while processing NestAir, allowing 3rd parties to apply other patches in a previsible way using ":AFTER" With @kerbmario using ":AFTER" himself, you have a race condition later where the one with the up hand on the ascii ordering will win the match. Check the Module Manager's Patch Cycle for further details.

Yep, I completely misunderstood the advice. Initially, I though you was suggesting merging the props on the IVA itself, as it was done with the Mk2CrewCabinInternal. Well, as I said, this wastes memory because the same objects (as the seats) are copied over and over, instead of having a single copy "stamped" multiple times. And we have the re-usability factor. But this is not what you was talking about, somehow I missed you were specifically talking about the CFG - but on a feature I'm not aware of. To everybody around be on the same page, this is what I'm doing when I put a seat on a Cabin: INTERNAL { <yada yada yada> MODULE { name = InternalSeat seatTransformName = Seat1 allowCrewHelmet = false displayseatName = #autoLoc_6002197 //#autoLoc_6002197 = Seat <<1>> displayseatIndex = 1 } PROP { name = Seat_Passenger position = -0.1875, -0.41250, 0.00875 rotation = 0,0.707,0,0.707 scale = 1,1,1 } } There's a vertex on the mesh called Seat1, and it's where the Kerbal is put while sitting. And the PROP thingy tells KSP to draw a Seat_Passenger on the same spot, so the Kerbal don't "float" in the IVA. I'm doing this way because it's how the MK1 crewed parts are defined in KSP (checked on 1.12.5, still the same), and I didn't even thought about existing another, more convenient way. By plain (lack of) luck, I checked the MK2_CrewCab_Int and there I found the seats (and other props) "hardcoded" into the mesh, and this prompted my initial response about being inefficient (not to mention copying ipsi literis copyrighted martial into the work, preventing me from distributing the thing later when I finish the job - if ever). However, after working hours I kept digging, and found the GenericSpace1 where things appears to be like @JonnyOThan says: INTERNAL { name = GenericSpace1 MODULE { name = InternalSeat seatTransformName = CenterSeat allowCrewHelmet = false displayseatName = #autoLoc_6002191 //#autoLoc_6002191 = Center Seat } } But, still, it's not what he's talking about - the GenericSpace1 also have the props "hardcoded" on the mesh. Unfortunate, to say the least. I kept digging, and found Mobile_Processing_Lab_Int . This one hadn't any seat prop hardcoded in the mesh, neither a PROP section on its config file. Digging on the mesh, I found that the seats are not vertices, but Collections (using a blender lingo). Unlinking one seat's collection reverts it to be a single vertice, as I'm using my Mk1 parts. I didn't really understand how the cube mesh turns into a seat on KSP, I didn't found any metadata hinting me what prop this cube is representing. But, and again, this doesn't looks like what he said above the same. What he's saying is something like this (I think): INTERNAL { <yada yada yada> PROP { name = Seat_Passenger position = -0.1875, -0.41250, 0.00875 rotation = 0,0.707,0,0.707 scale = 1,1,1 MODULE { name = InternalSeat seatTransformName = Seat1 allowCrewHelmet = false displayseatName = #autoLoc_6002197 //#autoLoc_6002197 = Seat <<1>> displayseatIndex = 1 } } } Problem: I didn't found a single IVA on Stock doing it. I will need to dig into 3rd parties to see exactly how to use it. What I would really would like to be able to do is to set a transformName into the PROP, so I could use Seat1 on it too (instead of copying and paste Blender's data into the position and rotation). That would make me happy right now. -- -- ANOTHER POST EDIT -- -- I'm grinding some github search in order to get samples about how to use things this way. https://github.com/search?q="INTERNAL"+KSP+path%3A*.cfg+PROP+internalseat&type=code However, until this moment, I didn't found anyone doing it this way but yourself - however, using a custom Internal Module. So I don't have a comfortably diverse usage on the wild to rely on this stunt - it may work, or it may not, I would need to study FreeIVA's source code to understand what it's doing, and then try to figure out how the Stock Internal Modules are behaving. For now, I will keep things as they are, and I suggest @kerbmario to do the same. A good compromise would move the PROPs below their respective MODULEs, making easier to eye ball who belongs to who. The idea of using a MODULE inside the PROP is not bad, however. It just won't make my life easier enough to lure me into trying a somewhat unproven technique on the wild without some testings - something I'm not willing to do now, as I want to use my currently scarce free time to do something that I can use on the game now.

That's the shady reality of what I was meaning: unless they managed to do things minimally right (what includes a EULA compliant way to load add'ons), the current (and probably future) IP owner will be the lesser of the beneficiaries. You see, it's some years since this Scene accepted EULA infringing works to be published around here - and things escalated to people charging for closed source add'ons "out there". All of this creates a huge precedence that will escalate sooner or later to something like what happened with Falcon 3.0 from Spectrum Holobyte - someone else will make money at the IP's owner expenses, just like that. I'm not implying that every single author that is turning their back to the EULA is ill intentioned - besides considering incredibly shady that a few of them is (at least last time I checked) currently employed by the competition and, worst, their boss is suing people for doing what this dude is doing here (it's not about what they are doing with the reverse engineering - as it's not a crime, but they are being sued by doing "direct" reverse engineering trying a stunt on Copyrights). What's exactly what Bungie is doing, by the way.*** Electronic Arts too, but incredibly enough, EA is trying the "right way", instead of vilifying something that was considered in the recent past a customer's right - the right to do whatever they wants with something loaded in their computer's memory. [But Dura Lex Sed Lex - good people don't need laws, we create laws due the bad people.] Bungie manages to accomplish what they want, things are going to get very hairy around here. Whoever is considering buying this IP (if someone) is also calculating how much they will need to expend on legal actions to take control back, lowering the perceived value of the IP and, so, devaluating it [in practice]. And the cheaper the IP gets, more probable it could be acquired by someone willing to use it on pachinkos or farming games on Facebook, and by then it would be their best interest to just shut down the whole modding scene and prosecuting anyone that made some bucks at their expense as a preemptive measure to prevent people from making money without paying them something, as this will be their business model. TL;DR: we, gamers and modders, will be screwed. *** Disclaimer: I had misplaced the paragraph about Bungie, giving the impression I'm implying Bungie is willing to buy KSP2. What I was meaning (and idiotically placed the statement in the wrong place) is that Bungie is activelly working to screw the modding scene as a way to solve another problem they have somewhere else. I moved these 3 paragraphs to where they are now, correctly passing the message I intended. But even if they don't, someone else will manage to make some bucks at their expenses - it's already happening for some time, we have precedence. Once there's no one actively watching the IP, you will see very "interesting" things being made with the IP. I don't rule out some videos being published on... "interesting sites" and not only on Youtube anymore. They opened a can of worms.

"Pray to God, but row towards shore" . Let whoever end up buying the thing later to decide if it worthed. You see, there will be some benefits if they manage to deliver something minimally playable under the name KSP2; mods and assets reuse. There're tons of things that can be done once the anger goes away and cool heads start to think properly again. Some games only realy kick in after EoL. Keep Launching.

Not unheard on this Industry - or any other. Sometimes Real Life© just run over us. Perhaps on wishful thinking, I wondered that perhaps they got themselves on a dead end on the code, decided to throw the whole crapload into the trash bin and restart from scratch (I did it once on a big budget project - the manager wanted to kill me, but the rest of the team concluded I was right and backed me... Interesting times... ). And then the Pandemonium happened, and everything got belly up for months. I take a month or two away from TweakScale, and not rarely I need to toy with the thing for a week or two to remember why and how I did some things (did I implemented that feature already? Funny things happens when I didn't but assume I did), what to say on a huge project like that? The "Game Over" for me was when I (as usual) got a argument with someone that looked like a developer, and knew enough from the code to make plausible they was a KSP2 dev. It was when I learnt that the whole heat system on KSP2 was based on the stunt implemented on the KSP¹'s ISRU in parallel with the CoreHeat (is this the real name?) that implements Convection, Conduction and Radiation. I got liquided by learning it, because this dumbed down the most interesting and challenging problems on space faring... But, whatever, as I said before, they just had lost me as a customer - what probably would make some people around here pretty happy. (like Val, that would not be barbecued again!) However, what worried me is that the dude didn't knew about the CoreHeat, so they didn't knew how parts behaved on reentry, while getting heated by atmosphere friction, you name it!!! And with this happening late 2023, at least a month after the For Science! update, this would mean that they could dumbed down the game into a corner because they just didn't planed how to implement some very significant challenges on a space simulator. And by now, it's too late to another rewrite if they really got themselves on that corner.

Yep... Fixed on the post. They are not mutually exclusive situations. In truth, it's almost a mutually inclusive situation. But PD/IG/KSP would not had been sacked NOW if GTA VI had not being delayed, causing the devaluation on the stocks and prompting the CEO to take harsh measures to prevent the shareholders getting (too much) burnt in the process. Again, liability. From the Oxford Languages: We are risking a dictionary war here - I'm pretty sure I used the term "liability" correctly.

You completely missed the point. I'm not implying that GTA VI will fail. Did you ever wondered why the Cut Throat Fest started to happen only after the last Quarterly Earnings Conference Call? Hint: Well... As well: Not to mention: And since the thing was delayed on May 22th: And, finally: So, yeah. P.D. (and KSP2) was sacked because they lost more than 2B USD in stock value early this year due GTA VI being delayed until late 2025. Dude, if this is not a liability, I don't know what would be. (and one must be living in Narnia to believe these events are unrelated, I need to say)

Yes, it can. Limitations from the engine can't be overcome, but programming bugs and silly mistakes (approximately 80% of all grievances we have on KSP¹ since 1.4.0) can. In fact, they already was in some 3rs parties add'ons. You get these fixes that already exist and apply them on the codebase and launch 1.12.6, and a lot of problems will just vanish. The proper way. No software can be guaranteed 100% bug free, but we can get near it. You know, these are two mutually inclusive requirements: in order to be able to affirm if something can or not be fixed, someone needs to know the damned thing, and at least managed to fix some of them. Some of us did exactly that. It's absolutely impressive how the less someone know about software development, the more he's prone to complain about people fighting about how to better develop software. You can't fix what you don't know it's broken - or believe it can't be.

Krap. He does it, I will end up funding 50% of KSP2 myself!!!!

Yes, it is. You are the one claiming KSP can't be fixed.

From the business point of view, GTV VI is a huge liability. It's terribly worrisome to have your entire company relying on the success of a single tittle. It's like opening a shop and having just one client: they literally own your shop, you only pay the taxes. KSP2, the Project, it's probably dead on arrival already. KSP, the Program, it's not. Yet. But I agree it may happen if nothing is done by the current IP owners.

It's easy, but somewhat worksome without Unity. Using Blender, you need to setup a vertex for each Kerbal seat (this is the vertex that will be used by the InternalSeat module in the internal cfg - do not misunderstand it with with the Seat_Passenger prop!). It's easier to do that using an already known Part as basis. Check what I'm doing here: https://github.com/net-lisias-ksp/mkext/tree/dev/Mk1/Spaces/mk1CabinInternal (in special, the blend and the cfg file for the mk1CabinEconomicInternal). It's not that hard, besides I'm currently having my cheeks being mercilessly bashed by the internal cameras (that are also set on vertices in the mu model, but by some reason they are screwed in my model besides I'm trying to mimicking the original).

Worst, they do it blatantly ignoring evidences, real life evidences (almost proves) that they are wrong.

For sure. But he have the will? This dude is not stupid - he have a plan, a long term plan, on everything he does. How footing the money for KSP2 development would fit on it? Elon is not only a dreamer, he's a maker (an incredibly rare combination). He makes things happen (at least, some of them - and it's incredibly entertaining while he fails his way into success!! most of the time, at least). But he does that with a purpose. I suggest a thought experiment: let's pretend we are like traveling salesman, and we just knocked Elon's door trying to selling him encyclopaedias KSP2. Incredibly surprising, he attended the door and is listening. How we should try to sell him this thing?

There're alternatives, field proven and demonstrably effective. And, perhaps, their best shot at this point. Disclaimer: I'm not implying it will be easy, neither that it doesn't have it's share of risks - Open Source is a development model, not a panacea that will fix all the illness in the World.

Speaking frankly... None of the alleged problems was a deal breaker for me, no matter how bad they looked. I'm a seasoned software developer, and more than once I did things similar - delivered alpha versions of the software absolutely terribly looking, but with things done right under the bonnet (at that time, I was still believing they are coding everything from scratch), and then adding the bells and whistles at the last moment on the last beta, when only small visual glitches would be needed to be fixed because the internal mechanics were ironed out already. The only real red alert was the pricing: this is not how you do Early Access, this is not how you reward your user base for doing free work for you (beta testing and development feedback). This was the deal breaker for me: if it looks as a scam, smells like a scam and behaves like a scam, it should be a scam - or at least, something pretty near one. Things slowly and gradually starting to fall in their place as the patches were applied only reassured me I was initially right: the thing was rushed into the wild by a management decision - what hinted the project was risking getting doomed (or already being) by mismanagement. The game being dumbed down was a show stopper for me for sure, but it didn't meant that the game would be a failure - it only meant I would not buy it. There're good things on KSP2, there're real improvements over the sequel - they could had succeed under a saner environment (even if by delivering a game I would not like - I would not be their only customer, after all).

No. They are "torts" (civil wrongs). They are the things you are accused when you crash your car into another, for example. If you prove that you wasn't negligent, incompetent or imprudent on the crash (for example, someone else hit you, made you lose the control, and then you crashed into another car), you will walk. Except that it's not a product, it's a service. Check the EULA. You can't have it both ways. They advertised a Service, not a Product (again, check the EULA). In a way or another, I explicitly mentioned FTC for the Customers as I already had stated that the share holders would be the ones with a (somewhat) solid case in a lawsuit, not the customers. FTC is the way to go by the customers. The FTC's mission is to protect "the public from deceptive or unfair business practices and from unfair methods of competition through law enforcement, advocacy, research, and education." . Launching a terrible, unfinished service (remember the EULA) to earn some extra bucks besides knowing the service is unfit to use may be a good cause for a lawsuit by the FTC. Again, winning it it's another history.

The best thing I can say from KSP2 is also the worst. The launch. Boy, they got a huge amount of interest, the Steam Charts skyrocketed. Had the launch be successful, they would had eclipsed the prequel easily. They proved there was a demand for the game.

Not necessarily. There're three Civil Responsibilities you can get sued on a Court of Law for failing them: Imprudence Negligence Inexperience Incompetence And we have evidences that TT2 was responsible for Negligence by failing look out PD, and PD was responsible for Inexperience Incompetence or Imprudence while carrying on their duties. But these faults are towards the share holders, not the customers. From the Customer's point of view, they may be liable by the FTC if they fails to deliver something until the end of the month that could reasonably fulfill the promises they openly made about the product. On Europe, they surely are liable for failing to deliver a reasonably working product that would match the expectations generated by the Marketing- it's the reason Steam is granting refunds to the Europeans, they think it's cheaper to refund than risking a class suit in Europe. There're grounds for trying a lawsuit for sure. Winning it, on USA are least, it's a completely different problem.

Boeing 767X . They literally took a 747, inverted the X axis and replaced the wings and engines. Mostly Kerbal.

[snip] There're are years of fixes and workarounds made by 3rd parties, most of the fixes due absolutely silly mistakes that were made on code that, frankly, only survived for so many years because there was absolutely no due process to properly handle regressions, with the people responsible dismissing them alegging exactly what you are alleging. There's no point to hunt bugs if they are not fixed because the idiot that called the shots just dismisses the bug reports as "there's no fixing KSP". And once the bugs pile up, things start to get hairy because you build new code over bad code, and fixing the bad code will break the new code. And then, finally, you get near the point in which fixing things became expensive. I'm following (and even working around) these pesky silly mistakes that played havoc on the game for years already, and I had tracked them down to the KSP release they were introduced in all cases. And I affirm without the slightest doubt that the bugs that rendered KSP "unfixable" (please note the quotes) were introduced by the very people that claimed KSP were unfixable. This is a fact. That are being double checked as people decide to play older versions of KSP and suddenly realises they have less bugs than the newer. [snip]

Oh, now I see. Unfortunately, both sections are part of the same Forum - they stop moderating the KSP2 subforum, whatever happens will affect the KSP¹ subforum the same. Think on an airplane where by some reason beyound imagination the crew decide to stop serving the the last rows of passengers - the uproar will be felt in the whole airplane, not only on the affected section. We have only one Forum. For the best and for the worst. But... I would like to have the KSP¹ section restored to its former glory. Posts on the KSP2 one will be essentially rants, interrelated by one or two support requests that will not be answered - all the action is happening on KSP¹ nowadays, and I really think this is not going to change soon. Wondering if I should go back to mod Orbiter, as I was doing before knowing KSP.

What's not happening. People are ditching KSP2, not KSP¹. Steam's concurrent players are rising, the online users on this Forum are stable at worst (long time user, we have way less people around in the past and yet we are still here). Whatever is happening (and it's happening), it's affecting only KSP2. Destroying what's still working is not a constructive way to protest about what's not. TL;DR: Scorched Earth tactics negate food and resources for everybody, and not only to the enemy - it's only used on the motherland by an army as a last and desperate measure. We are not fighting an enemy (if we had one, he already fled). We are fighting for survival.