TiktaalikDreaming

I struggled a bit with having parts reference non-baked in textures. Turns out a simple issue of me exporting without an image assigned to the flag transform was stopping it working. So, re-building the magazines can continue apace. At a pace I'm capable of while working a full time job that takes a bit over an hour to get to or from. While working on other mods. n stuff. But those early parts are just embarrassing. I was working through the nexus to re-texture and clean up the meshes with "lessons learnt" from the last year or so, but now that I look at the "Orion bits" I realize these parts need a revamp much much more. So, after I actually apply a texture to the 86foot parts, I'm going to re-do the Orion Bits pretty much from scratch (except probably the 7m mission section, cos that was a poodle). In particular, that control centre is just so bad. Thoughts? I am seriously thinking of consolidating parts. EG the escape vehicle would become the crew area as a single piece. A fuel tank. And an engine piece. The lower spine would still need to be modular, ditto for the mission section. But the rather annoying fiddly bits of putting together the escape vehicle, especially those solid boosters, needs to go away. IMHO.

You sir, get the cake (or cigar if you prefer that colloquialism). Added a copy of the same 32x32 transparent image I'd been using as a placeholder to the flag transform, and it all works just fine. If I hadn't thought "hey, I could add a little flag to these and partly ruin people's frame rate" then I wouldn't have gone through this rather frustrating, but educational experience. So, that's an image assigned to the flag transform in unity and exported with the model, even though it too gets overwritten. SOLVED! PS: the items are different sizes because one thing I was testing was messing with the various scale options.

The issue you're seeing with the original is what I was seeing originally as well. I'm not 100% sure what causes it yet. As for steam based rcs, I'm not sure what the ISP should be, but probably around that of peroxide. Plus minus for concentration of peroxide vs energy dumped into the steam

As @HebaruSan says, there's a spacedock page to download. There's actually a choice, two versions. The TD Edition is more detailed, has more parts etc, but due to that, it's less suitable for slow computers. The original models are included in this simpler version https://spacedock.info/mod/73/USAF Orion Mod Both mods use the same plugin, and there's a cap on how many types of magazine is supported by the plugin, so you cannot have both versions installed, or the engines won't work. For both versions, inside the zip there's a GameData folder. Copy everything in the zip's GameData folder to ksp's GameData folder.

Yup.

Um... Like a flag transform? I'll have to try switching it. I'm not at my pc for about twelve hours, but I'll check then. And pack up an example.

Looks like I have a choice of "Texture load error" on the placeholder, or "exception during compilation" on PartLoader. The part loads when it can't load the placeholder because it seems to skip trying to replace textures due to missing the texture it would replace; PartCompiler: Cannot replace texture as cannot find texture 'baselabel' to replace I'm going to try weird silly ideas next.

OK, fixed that error, now I'm back to the parts not loading, and popping out the following error during part loading (no errors now on texture or model loading); PartLoader: Encountered exception during compilation. System.NullReferenceException: Object reference not set to an instance of an object at PartLoader.ReplaceTextures (UnityEngine.GameObject model, System.Collections.Generic.List`1 textureNames, System.Collections.Generic.List`1 newTextures) [0x00000] in <filename unknown>:0 at PartLoader.CompileModel (.UrlConfig cfg, .ConfigNode partCfg, Single scaleFactor, .AvailablePart partInfo) [0x00000] in <filename unknown>:0 at PartLoader.ParsePart (.UrlConfig urlConfig, .ConfigNode node) [0x00000] in <filename unknown>:0 at PartLoader+<CompileParts>c__Iterator65.MoveNext () [0x00000] in <filename unknown>:0 Going to try a blank placeholder

Yep, all the textures load in, even the ones not in use... but... My placeholder is misbehaving. Which is odd, seeing as when I comment out the texture line, it shows just fine; Texture load error in 'C:\Steam\steamapps\common\Kerbal Space Program\GameData\USAFOrionTD\Parts\Orion\Magazines\USAFStackable\baselabel.dds' I'll see what I can do to tidy that up.

@MeCripp you do make a good point about the PART module though. When I spotted what you meant there (read it on mobile and just didn't read it properly) I had sudden high hopes. That config has been like that forever. Presumably that was a 0.25- style config style or something. But it's been working, and I never even noticed until you pointed it out. I fixed it up (the MODEL section with model= and texture= etc is a "recent" config thing after all) and got exactly the same behaviour as before. :-( But, I will fix up the part configs. Because there's a reasonable chance the answer is this PLUS something else. eg; PART { name = USAFOrionMag012kt920kN module = Part author = WinchellChung MODEL { model = USAFOrionTD/Parts/Orion/Magazines/USAFStackable/Magazine scale = 1.0,1.0,1.0 texture = baselabel, USAFOrionTD/Labels/r1ktlabels } ------ USUAL PART VARIABLES ----- MODULE { name = OrionMagazine ------etc ----- PS: Your spoiler section has eaten the rest of your post. I find all sorts of craziness goes on with quotes/spoilers/code section when using mobile, so presumably some browsers hate it.

Not aiming at changing the textures in the VAB. Just setting the texture for the part. I know I'd need a module (usually firespitter of b9) to have it switchable.

Thanks, that makes me feel less deranged. I found some old threads on this you'd commented on, and wondered if you ever got it working. I have plenty mods using this, and copying their config with the names changed to protect the innocent got me no-where as well. I feel it's something simple that I just can't see because I'm too close to it. This query is pretty much me giving up trying everything I can think of. Because I've got through everything I can think of. It's still cycling through my head, but I'm not going to waste lots of time trying things I've already tried. I know when I'm beat (for now).

You're a bit late to the party. It's up and running again. The offer is appreciated though. The source code is at https://github.com/cerebrate/USAFOrion And being Git, you can check out what needed changing. There was a fair bit of work put in by @FreeThinker to 1.2ify it, which helped greatly (the UI worked for the first time since ksp v0.25 or something) but the engine still wouldn't function, and the second commit from @HebaruSan brought that back alive by figuring out it was missing staging info.

Also not the length of the path.

I'm trying to be clever with asset use (trying to be clever is how most issues start). I have a set of parts that all use the same mesh, and mostly the same texture, so I'm trying to use all the same model, except for different versions, apply a different transparent texture as a label. This should be stock behaviour when using the MODEL{model=, texture=} mesh references. And for the life of me, I cannot spot why it's not working for me. Example part snippet; PART { name = USAFOrionMag012kt920kN module = OrionMagazine author = WinchellChung MODEL { model = USAFOrionTD/Parts/Orion/Magazines/USAFStackable/Magazine scale = 1.0,1.0,1.0 texture = baselabel, USAFOrionTD/Parts/Orion/Magazines/Labels/r1ktlabels } The intention being that I change the texture = line to point at a new label for each new edition of the part. So far I'm just messing with two of them. Dir listings; Directory of G:\NothaSteam\Kerbal Space Program\GameData\USAFOrionTD\Parts\Orion\Magazines\USAFStackable 2017-03-18 11:33 AM <DIR> . 2017-03-18 11:33 AM <DIR> .. 2017-03-18 11:33 AM 16,512 baselabel.dds 2017-03-18 11:30 AM 42,598 Magazine.mu 2017-03-18 11:15 AM 1,398,256 NewMagazine.dds 2017-03-18 11:15 AM 1,398,256 NewMagazineNRML_NRM.dds 2017-03-18 11:41 AM 5,466 part.cfg 5 File(s) 2,861,088 bytes 2 Dir(s) 447,172,456,448 bytes free Directory of G:\NothaSteam\Kerbal Space Program\GameData\USAFOrionTD\Parts\Orion\Magazines\Labels 2017-03-18 11:46 AM <DIR> . 2017-03-18 11:46 AM <DIR> .. 2017-03-18 11:46 AM 87,486 r09ktlabels.tga 2017-03-18 10:55 AM 87,568 r1ktlabels.dds 2 File(s) 175,054 bytes 2 Dir(s) 447,172,456,448 bytes free I've copy/pasted the paths, switching \ for /, copy pasted file names without extensions. I've moved the replacement textures to a different folder, converted their names to all lower-case, starting with a letter, tried square textures (it started as 512x128), tried dds vs tga vs png. If the place-holder texture is dds, game loads, no errors in the output_log. But the part just has a blank texture where the replacement should be; If the placeholder isn't dds, then I get errors about null references; PartLoader: Compiling Part 'USAFOrionTD/Parts/Orion/Magazines/USAFStackable/part/USAFOrionMag012kt920kN' (Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42) PartLoader: Encountered exception during compilation. System.NullReferenceException: Object reference not set to an instance of an object at PartLoader.ReplaceTextures (UnityEngine.GameObject model, System.Collections.Generic.List`1 textureNames, System.Collections.Generic.List`1 newTextures) [0x00000] in <filename unknown>:0 at PartLoader.CompileModel (.UrlConfig cfg, .ConfigNode partCfg, Single scaleFactor, .AvailablePart partInfo) [0x00000] in <filename unknown>:0 at PartLoader.ParsePart (.UrlConfig urlConfig, .ConfigNode node) [0x00000] in <filename unknown>:0 at PartLoader+<CompileParts>c__Iterator65.MoveNext () [0x00000] in <filename unknown>:0 (Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42) PartCompiler: Cannot compile part And the part doesn't load (Cannot compile part seems fairly clear on that). If I skip the texture = (or comment it out) then the part loads with the placeholder texture. If I apply one of the label textures in unity and compile the mu that way, it also loads fine. Or just substitute the placeholder with one of the actual textures, it also loads fine. So, what I know is it's definitely reading the texture = line, and doing something with the named texture. That bit is working. It just never seems to find the replacement texture. Which suggests there's something wrong in the paths. But I've checked that so many times I can't see there being any typos or what have you there. I'm at the "try stupid things" stage. One thing I do like to do for sticky issues, is write a big long post about the issue so I have to get it clear in my head, on the hope that the process of explaining it, solves the issue. And so far that hasn't helped, except I ran a few extra tests to get the post more complete, but with no greater success than my other attempts. So, gonna step away from the 'puter for a bit. Clean my head with a wee bit of dilute WWII German rocket fuel, and come back to this later.

Quick test with 1.2.9 shows that a simple recompile is all that's needed to keep the old boom boom going. OK, and if anyone desperately needs orions in their pre-release 1.2.9, the current recompiled dll is here https://www.dropbox.com/s/rym45sre6j2uvej/USAFOrion_v1.2.9.zip?dl=0 Just replace the USAFOrion.dll in your mod where-ever it happens to be (usually GameData/modname/libraries). It may need further updating if the linked KSP libraries change during pre-release.

The core components changed, so all the mods with code (aka, not just parts, resources, tech tree) will break until they're recompiled. Most won't require much beyond the mod author loading up the code, checking links to libraries, and hitting compile. But many mod authors will be keeping those updates to themselves until 1.3 as well. Don't expect official mod updates until after 1.3.

I'd have to check. There's quite a bit of tweaking that would have to be done for scaling. The main engine pieces would be mostly, roughly OK to scale I think. And I guess if I just scale the number of pulse units on the magazines without scaling each unit's effectiveness I can ignore my other concerns. My plan was basically a Kerbal scaled (aka 64%) and MM config for RSS+RO to scale up to real world values. But for the kerbal scaled, make the parts fit in with existing sizes. So, Kerbal/RSS sizes would be 1.875m/3m, 5m/7m, 2.5m/3.2m, 6.4m/10m. But also, eventually there should be a (nominal) 10m, 20m, and 86f. And Orion's don't scale in all directions. As they get larger, they don't need to have a longer suspension stroke, so they get wide and squat. That turned into some weird rambling. TL;DR; I'll look at it, but not making any promises. I am working on re-doing a lot of parts. I didn't do a lot of remeshing on the main engine, but I have re-UVed it, and will have a much saner texture soon (lines that meet up, and other crazy things) Also, as I realized when I rescaled things, I didn't rescale the pulse unit impulse values, I started some long overdue rebuild of the magazines and am looking at combining an update of fixing values, and putting all the magazine assets in one folder with shared model and overlays for the labeling. And I might end up with equivalents of USAF and NASA pulse unit magazines.

It's been working better than google for me. I do get my home internets via some badly tensioned pieces of string, so sometimes it's hard to tell if there's any of this magical slowness, but it does seem fine to me. And I've done a fair bit of uploading this week as well.

OK, updating the Orion Bits mod as I type. I've gone through and rescaled all the parts to 64% to match what I did with the orion drive. But, I'd like to pick some KSP sizes for future versions. Although the two different sizes for the upper and lower spine are going to annoy me. I'm currently thinking Size 2 and size 1.5 (1.875m, which has been used by other mods from time to time). I'd just round the 7m mission control areas to size 4 (5m) etc. I mention this as, having gone back and looked at the parts, some of them are plain awful. One is just a cylinder with basically crayon marks on it. Jeebus. And there's way too many. That escape vehicle engine is a serious pain in the gluteus maximus. It could be one part with an engine fairing and two modes. So, also expect some changes in the next few months (although, I may wait until after the imminent 1.3 pre-release before worrying too much about that). And my amazingly fast, surely better than dialup, upload has finished.

Updating to fix the fairing now. Updated the original Nyrath edition as well, as I know a lot of people prefer that one. It's still 10m.

Arg, that'll be me not paying attention. I'll fix up in a bit. I can't remember what stage the Michael was up to. I think I stumbled on some issues, and then the plugin stopped. There's definitely issues with things of any sort attached to the pusherplate. I'm sure I can fudge something for that though.

OK, I think I have a grasp of what was stopping me getting the original parts working. It's a combination of the plugin hating multiple copies of the BombXferWindow.cfg file it uses as a temp storage for some settings, AND simply maxing out magazine types. I already knew about the second, but had cleverly forgotten. Anyway, I'll be repacking the TD edition AND the Nyrath edition soon. The existing TD edition manages two copies of the BombXferWindow.cfg file. And it worked when I first used it, but wouldn't work after I'd exited and come back in.

It seems unlikely that an update where the best they hype it up about is localization will break many mods. Unless it breaks all mods. I do expect there to be a way of adding multi-lingual descriptions for parts at least. But I'd like to think they found a way of adding that sideways without breaking every existing parts mod. And, um, the 16th isn't so far away as a "few days" anymore. But I'll grant that a deadline of the 16th, might very well still be a few days away. ;-)

That's on the agenda as well. Possibly a fuel switch for the loader floors and magazines, but at least shoving all the same model versions in the same folder and then using overlaid textures for captions/labels/signs. But that'll take a bit longer than deleting some files. Also, specular maps. I'd like shiny pistons without shiny everything else.