Jump to content

AlphaMensae

Members
  • Posts

    1,619
  • Joined

  • Last visited

Reputation

2,828 Excellent

Contact Methods

Profile Information

  • Location
    Terran Trade Authority

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Tundra's Space Center is the statics, while KSC Extended is a set og .cfgs placing those statics around the KSC.
  2. I had thought about it some years ago, but then Katniss made one for their Katniss's Parts Pack of fictional Saturn MLV parts, and I no longer feel like doing it.
  3. Looks like they're doing 3 week cycles, or "sprints" as it is known in the game dev world. So next patch should be another 3 weeks.
  4. It goes all the back to the early days of KSP, when it was common to do that kind of thing. I think the fuel prioritization UI added in v1.2 greatly reduced the use of asparagus staging.
  5. I hate it, I want the PAWs back in all of their KSP1 style. The Part Commader has its uses, but it should be an option, not something that you're forced to use. When I can see the part I want to adjust, it's far simpler to just right click on it. Also, PAWs allows multiple parts to be viewed at once, like engines and tanks to see fuel flow, or seeing drag (using the Aero GUI) during flight. The Part Commander is just one of those ideas that sounds better in theory than in practice, and is anoher example of Intercept changing things that already worked well just for the sake of changing them.
  6. If you look at the PAW for the new bases, you'll see the "Clamp Parts" switch. This turns off the launch clamp bits (the stretchy columns and footings) som they are not in the way. For these new bases, and then for all the launch bases and stands that don't use the clamp parts as the structure, I'm making the clamp bits very tiny and adding the switch to turn them off. They have to be present in the .mu or the launch clamp function won't work, so I'm using B9PS to turn them off afterwards.
  7. Uh, are those the panels from Making History? I don't have that. MLP does nothing to affect stock parts, as Cheesecake said.
  8. After a long break, I finally felt like doing the new Medium General Launch Base. I also added a 9th color to the GeneralBases texture series: the yellow-beige I used for the Ariane-style flat slab mast. Now the new Small Base, the new Medium Base and eventually all the General parts can be that color. Medium base has 4m and 6m exhaust hole widths, width an alternate style for 6m short variant...it sort of happened from the way I set up the punch-out deck sections. New Medium Base is now on the master branch of the Github.
  9. There is going to be an in-game mod manager, so that will do all the loading. For parts, I'm thinking you'd package all your assets from Unity and the JSON .cfg into a bundle, and the mod manager will take it from there.
  10. They are bundled in the sharedassets files under KSP2_x64_Data folder. Not accessible without some kind of Unity asset viewer. This is not like KSP1 at all.
  11. Oh, I didn't do it myself, I'm just reporting the findings of numerous others who have. The game code is being dissected left and right by a lot of experienced coders, who are NOT impressed with what they see. Official "modding support" means when the devs finish and turn on the in-game mod-loader/manager. I suspected long ago that KSP2 would use Unity asset bundles and an in-game mod manager/loader, like most other modern games today. The method Squad used for KSP1 (separate .mu and .cfg files for each part) was done when Unity was a lot different than today and asset bundles were behind a paywall, and Squad was either unwilling to pay the fee or unable to, being a tiny company.
  12. All the stock assets are in the sharedassets.assets files under the KSP2_x64_Data folder. Can't look at them without a Unity asset viewer.
  13. To put it simply, .dlls will use an assembly loader, while part assets will be assetbundles and be combined with JSON .cfg files. There's the framework at least for an in-game modloader present, and it appears it will use a GameData folder to load mods from.
  14. The coders started decompiling the game and lookng at the backend and assets immediately after downloading it, which wasn't hard to do, plenty of tools available for that. Lots of details have been revealed, enough to have an ad-hoc modloader made. Basically, .dlls have to use and assembly loader, while part assets are in assetbundles and are combined with the .cfgs, which are in JSON. There is also at least the framework for an in-game modloader present. It appears that it will use a GameData folder.
  15. Modding KSP2 won't be as simple as KSP1. There aren't any standalone meshes, .dlls and .cfgs that the game simply loads. It's all Unity Asset Bundles/Shared Assets now as far I can tell. We'll either have to wait for the official in-game mod loader (the framework for one is already there) or the coding types to make one themselves or another way to load mods.
×
×
  • Create New...