Jump to content

Electrocutor

Members
 View Profile  See their activity

  • Posts

    699

  • Joined

  • Last visited

 Content Type 

Everything posted by Electrocutor

  1. Electrocutor
    @bcink Thanks for the effort, but it appears that someone else has already accomplished this.
  2. Electrocutor
    Since I only see the porkjet models, did you run into the same issue as myself when trying to allow multiple engine models? Such that having stock, porkjet, and prokjet_boattail all together made the fairings unable to hide?
  3. Electrocutor
    I had completed the external SSPXR most recently.
  4. Electrocutor
    Okay. I'll work on a first pass then get back to you if there are specific things that really need addressed to look right. I do remember that the enormous dishes looked pretty sweet when metallic.
  5. Electrocutor
    I can. I've actually attempted KSPIE a couple of times, but it appears that models within had come from a great many different sources, with few of them being consistent. Basically, that means that I cannot make an overall patch that spreads across many parts, but instead need to define specific criteria for each part and each of its meshes (like stock parts not made by Porkjet). This means it will take a lot more time. Do you remember where you got all the models from originally that they may have updated versions? The optimal solution is a complete model/texture setup with diffuse+specular and normal textures with meshes separating things that need to be different, such as glass. I will continue making patches and asking the mod authors (just like FreeThinker here) if they wish to include compatibility, but for those that do not, you'll need to ask me instead of just having them openly available. I don't mind handing out my configs to requests, especially when I think they make the mod look far better than with the original shaders, such as with SSPXR. Such amazing artwork and TU really brings it out. Any author who explicitly does not wish for me to distribute a TU patch, thought, I will not.
  6. Electrocutor
    If you remove the engine part from the boattail model and only put the bottail mesh into the original engine model (covering up most of the bell), would it work? If it's truly not doable, then simply making the fairing mesh uniquely named would be able to at least make it work: f.e. porkjet_fairing for main and porkjet_fairing_boattail for the bottailed version.
  7. Electrocutor
    No... Here is what we have: Engine Model A: "fairing" is separate mesh Engine Model A Boattail: "fairing" is separate mesh, boattail is built-in What I want: Engine Model A: "fairing" mesh renamed to "porkjet_fairing", and boattail separated into its own mesh named "porkjet_boattail" Thus, we combine two .mu models into one and the fairings and boattails meshes have a unique name per artist. This way, we could also have ven_fairing and ven_boattail and be able to combine it all into a single part with variants.
  8. Electrocutor
    Necro is open to supporting TU, so likely you will see this included in the actual mods when finished, just like Nils' feline rover.
  9. Electrocutor
    Greetings, I'm looking for someone familiar with modeling to modify Porkjet's PartOverhauls models. The source models are in .fbx format. http://kerbalspaceprogram.com/files/PartOverhauls.zip Scope Create KSP model files (.mu) for each engine that has shroud/fairing renamed to porkjet_fairing and boattail separated into its own mesh named porkjet_boattail.
  10. Electrocutor
    I've got the mk1pod and fuel tanks working fine, but as yet have been unable to make ModuleJettison work. It appears that it will only ever hide a single mesh with the given name. Since the fairing in both stock and porkjet's are named "fairing" it only hides the stock one and porkjet's is always visible. I am trying to find a workaround.
  11. Electrocutor
    I'll re-add the link. It was still linked from the tech support thread. I will be re-adding a full stock config sometime soon that utilizes PartVariants as well. The Porkjet Stock currently there was the only one I had updated to the new TU syntax. It's not dead. I can build configs pretty easily and send them to you if you like. The normal way mods do compatibility is to include a patch within their mod if they want their mod to support it. So you could ask those mod authors if they are interested in having TU compatibility if you want it to permanently be available. Technically, yes. There is no legal reason I cannot make MM patches available for download, but it's consider in poor taste to do so against the wishes of the mod authors.
  12. Electrocutor
    Could you not stretch the header slightly wider so as to fit? dV should never exceed 6 characters and twr 3. Well, I guess there is also the mouse-over tooltip if need be: maybe that would be an even better idea, just leave the stock 1-line and show dV and TWR on mouse-over. I've also thought about the same for precision maneuver nodes. Consider the small control buttons you have for SAS on the side of the navball: have a similar thing when you create a maneuver. One button for 'Circularize' that pushes prograde until matching altitude, one button for 'Intercept' that pushes all 3 axes until your orbit intersects with your current target (or SOI of target) with as close to parallel orbit as possible, and one button to toggle 'Precise', which changes the amount that pulling on the 3 nodes will change your dV for the maneuver to being much, much less. Instead of being a robust mod that gives you all sorts of options, it would instead enhance the stock interface to only provide things that are sorely missing.
  13. Electrocutor
    .
  14. Electrocutor
    .
  15. Electrocutor
    I haven't updated any but PorkjetStock to the new syntax yet. You can read about Shadow's changes and update it yourself though, it's not too tough.
  16. Electrocutor
    Okay. I guess my only thought would then be whether or not enabling it actually has any non-negligible performance hit. From what I've read, many people love this precisely because it doesn't affect their fps at all, even when using built-in Intel GPU. There is, unfortunately, a bad vibe from the word 'reflections' due to the poor-performance implementation of it left over from TextureReplacer.
  17. Electrocutor
    .
  18. Electrocutor
    That's just it, I either have to wait for MM to support spaces or for this mod to not use spaces in directory structure.
  19. Electrocutor
    @Shadowmage So after having been stupid a number of times, it occurs to me... why not just default to enabled = true? This entire mod does not work at all unless this is true to begin with. In fact, if any other mod happens to include a TU config, but forgets to set enabled=true it will instead turn the textures black.
  20. Electrocutor
    @blspblackdeath Is there any chance I could get you to re-organize this mod to use a more standardized directory structure that does not contain any spaces? Currently, you have 'Kerbal Historical Institute' and 'IWNO' kind of mashed in the middle that causes issues with ModuleManager patches. I am working on making a patch as to allow all the old models/textures as PartVariants to the current ones.
  21. Electrocutor
    If all you were doing is changing textures, then it would be ok, but in the case where you need to show and hide different models or meshes, you need a bunch more syntax. For each new model variant, you must hide that model in all other variants. Also, my bad on incorrectly assessing: having the 'only add if not exist' would indeed work if you are only making a texture variant. Scenario: Mod 1 adds a model variant Mod 2 adds a model variant Mod 3 (yours) adds a texture variant Since yours happens to be processed last and does not maintain the existing baseVariant hidden model properties, that means that your variant would show 3 models simultaneously and then change the main texture on all their meshes. If instead, yours were loaded first, then MM patch such as I posted in the guide would maintain and add hidden model properties into your variant so it would work properly.
  22. Electrocutor
    As per my guide... if you have multiple ModulePartVariants, you cannot have the same nodes set in more than one of them. In your example, TEXTURE of the second partmodule would override TEXTURE of the first. You can, of course, have a single ModulePartVariants with many VARIANT within, but that would require a different MM patch than what you have listed.
  23. Electrocutor
    This screenshot looks like you have AA disabled. In version 1.4, PrivateDivision/Squad has made AA required to be on for a number of visual things to work right.
  24. Electrocutor
    @DMagic Have you ever considered making a light-weight version of deltaV such that it integrates seamlessly into the existing stage GUI, is simplified to only showing dV and TWR, and has no other components? Effectively a stock dV/TWR implementation. My thought is to extend each stage node header (orange bar) to be two lines instead of 1 when an engine or decouple is within that stage. The first line would stay as-is, but the second would show the dV and TWR. No other options or configurations, no extra toolbars, windows, or other GUI stuff.
  25. Electrocutor
    @XLjedi Check out my PartVariant Guide thread. That will tell you the difference between name, displayName, and themeName. As for large cfg patches, it depends what you are applying it to. If you built models using pbr flow, such that each material type was its own mesh and standardized naming schema, then you could share a handful of textures across all parts, and just create a small program or script to copy/paste everything, only changing the [partname]. The downside to doing this is that we don't have detail diff or bump, so any major structure has to be modeled instead of bumped. As far as your example above goes, it would work fine so long as your mod was the only one installed that made variants, but it would not work with other variant mods.
×
×
  • Create New...