Jump to content

helldiver

Members
  • Posts

    677
  • Joined

  • Last visited

Posts posted by helldiver

  1. I don't think modders need extra cushioning.
    Agreed, if anything you want to be worse. Many (especially younger) modders have no idea how stressful it is being a dev where the company has in-house advertising.

    Neither of you make any sense.

    What cushioning do we need? If we were given any leniency by moderators, in what way does it apply?

    The thread is about abuse against modders. Not modders abusing community members, remember?

    Second, you say "If anything you want to be worse". What does that mean?

    Moderators should be worse with us? Are you serious?

    Is there a growing trend of abusive Modders ranting and yelling at community members?

  2. Well my two cents since KSOS gets its fair share of flak. The most recent being the 32bit vs. 64bit debacle.

    Personally I never really take to heart what folks say on the thread. I've known from the beginning that it wasn't going to make everyone happy. The KSO not really being a parts kit, I knew I was going to take some flak from folks who: "Damnit, such a cool looking model with IVA and it's not a part's kit!". I knew this was going to happen going in to it.

    So I went into it by ignoring those folks completely, and focusing on the others who use the KSO orbiters as they are. Turns out, that the guys who use KSOS "as is" have helped evolve the mod to what it is now (originally it was just going to be the shuttle and a moon lander).

    However, and this is something that took me a while to realize; The people making criticisms of your mod are your fans. The people that have been most critical of KSOS have sparked the most change. At first glance I took most of their rants as just that, rants and complaints. However, the Super 25 incorporated a lot of the things those folks asked for; Better IVA visibility, larger cargo space, improved flight, etcetera. I realized that the reason some of these folks are so critical, is because they enjoy the mod so much, that any blemish will cause them to tell you about it (not always in a diplomatic way).

    This eventually evolved to simply reading the thread and if something seems like a rant or complaint, I make an evaluation:

    -Is it something that can be fixed readily without new resources?

    -Is it a legitimate bug?

    -Is it a quality of life improvement?

    -Can it be incorporated later on at a different phase?

    -Is it in the spirit of the project?

    So pretty much it's gotten to the point where I don't take anything in the thread as a complaint, rant, or troll attempt. This leads to a discussion I had the other day with one of our community members. In it he made a few statements that struck a few chords and my response may have seemed like I was upset at him specifically. In reality the only person that is capable of offending or chasing me away is, Squad. The response really wasn't at him, but was really my frustration with Squad.

    They have claimed and continue to claim "We support modding", evidenced by saying this repeatedly in the twitch stream and just a few posts up someone just repeated it again. I'm not sure what priority Squad has given to modding in their business plan, but so far it is my opinion that it isn't very high, if at all. I've said it in my thread and I'll say it again; Squad does not support modding.

    -Why is there no SDK? With all modules used by the stock game properly defined.

    -Why has an asset manager not been incorporated into the engine without the need of 3rd party plugins such as Active Texture Management?

    -In regards to IVA's only; why are we stuck with placing the IVA texture in the spaces directory next to the internal.cfg? This has become a serious issue for IVA intensive mods such as KSOS. We could save 25% or more on resources if we could point IVA textures to share them without using the idiotic props work around (which is in and of itself inefficient).

    So far the source of any frustration I've had from a thread post has been just that; Something out of our control which is in Squad's court.

  3. The wings only show as shielded in the VAB. On the pad nothing turns up shielded. Did you actually check if they were shielded in flight or only in the VAB?
    Yes someone should that's why I brought it up because I know nothing on how to fix the problem.
    Here Buddy :

    What is the problem exactly?

    and then here with explanation,

    and there here is your fulfilling answer

    However I have fixed this issue if anyone else have it this is a workaround.

    And by the way this is my 1st post Stating my problem, InfiniGlide has been in KSP since KSP has been. Now if KSO was using FAR this wouldn't happen as FAR fixes this bug. And you still have gramma errors with the config(which break stuff) . Check the last post I linked

    @nismobg

    I'm confused with what the problem is.

    Is there a problem with the default KSO Config file?

    I will take a look at the files in question and compare.

    I can't make promises, but I will try and see if we can come up with a FAR config we can add as an alternate install with Phase IV.

    OK remember I told you wings were messed up , I was RIGHT ! Got a fix for you. What happens is wings cause infiniglade with the current configuration .

    And to be more precise the super25surfaceLkso and super25surfaceRkso

    So what i did is change the ModuleControlSurface to :


    MODULE
    {
    name = ModuleControlSurface
    dragCoeff = 0.5
    deflectionLiftCoeff = 0.7
    ctrlSurfaceRange = 20
    ctrlSurfaceArea = 0.95
    }

    and removed from

    mass = 0.08
    dragModelType = override
    maximum_drag = 0.02
    minimum_drag = 0.02
    angularDrag = 2
    crashTolerance = 20
    breakingForce = 25
    breakingTorque = 80
    maxTemp = 3400
    explosionPotential = 0.1
    fuelCrossFeed = True
    // --- winglet parameters ---
    // dragCoeff will override the maximum_drag value
    //dragCoeff = **** REMOVE
    //deflectionLiftCoeff = **** REMOVE


    Now it all works as smooth as a butter on x64. Maybe some of the ModuleControlSurface can be touched a little bit but not much or your will spawn the phantom acceleration again.

    Is this for a default wing installation without FAR/DRE?

  4. helldiver, a few small requests here, if possible:

    - Could you by any chance change the small radial decoupler to use a separate texture instead of one from the orbiter so that it could be used even if all orbiter-related files are removed? Atlasing is an incredibly good thing, but that one particular part is not invariably used with the orbiter parts alone, so it might very well get into a situation where a huge atlas of the orbiter is not available. I doubt it will need more than a tiny 256x256px texture, so one decoupler using a separate texture won't hurt anything.

    -That could be possible in the future. A bit of a strange request on a specific item. I'm not quite sure which radial decoupler you mean. Maybe post a screenshot?

    - If it's possible to do without breaking existing craft definitions, could you rename all the remaining configs, textures and meshes to show clearly which part set and texture atlas they belong to? At the moment, if you want to, for example, temporarily remove small orbiter but leave space station parts, you have to double-check descriptions in part configs against the opened game to know which part is which. The super25_ and ss_ prefixes that are already in place were a good start, it would be nice to see all the other parts and textures to be grouped in the same manner.

    -That is not possible at this point since so many people have prized games going. If you change the config file names you break crafts in saved games (KSP automatically deletes them, how I lost my space station).

    -Changing texture names at this point would be extra work for Nazari, in that he'd have to re-export all *.mu file to point to the new names. Texture names aren't a function of the part or set that uses them, but are named after the internal names I use in my baking/photoshop pipeline. That means that some textures weren't supposed to be specific to say Phase 2. They were supposed to be used by other phases as well. However, way back when I discovered that silly KSP doesn't really like to reuse things such as IVA textures. But by then it was too late. Probably why in Phase 3 and now 4, you see texture names be more specific to that pack.

    -To further help with that, Phase IV will have an installer that will let you pick and choose what pack you wish to install.

    And I'm flattered that you enjoy the KSOS stuff :D

  5. In order for the goo lights to show up correctly in game, in addition to the MU and CFG files, you need the following texture files: kerbin_orbiter_docking_mod.tga, kerbin_orbiter_docking_mod_emis.tga, and kerbin_orbiter_docking_mod_norm_NRM.tga.

    This.

    And I know I've said I wanted to separate them completely from that file. I still am, it's just that things have gotten hectic. I will do my best to get that separated before Phase IV is out.

  6. If you are annoyed by the version warning, a

    Hey Snjo!

    Quick question, you can PM these answers and/or any other detail if you'd like.

    -How do your helicopter modules work?

    -How does the player translate forward, back, left, right? (without rolling/pitching in place).

    -How is collective done? (up, down) is it just throttle up and down?

    -I'm assuming tail rotor controls yaw.

    In the following two screens you note more or less the issue:

    ZBhhiJk.jpg

    jnXrHUY.jpg

    -The main rotor is linked to the rotor head which is linked to the turboshaft. I'm assuming your module would control the main rotor? What is that declared as?

    -In the IVA, as I increase collective (up, down) what happens? How does your module handle that? I need to know so that I can separate out the proper part that'll move. If it's throttle, I need to know so I can declare the collective handles as throttles so they move up and down as the player increases/decreases collective.

    -If so, how is cyclic handled? We can have the cyclic stick controlled like normal (like we do in the KSOs), but does your module which control the main rotor automatically do bladeslip, blade translation and such?

    -So main rotor, which module do we use?

    -Tail rotor, which module do we use?

    -Is the engine a separate thing? (Helicopter's, especially this one, don't really have "thrust").

  7. Vessel Viewer will not be part of the KSOS aircraft by default. Same goes for any other random plugin people think of. If it becomes part of RPM.dll proper then maybe.

    The only changes I plan on incorporating into the KSOS RPM suite are some changes suggested by Luizopiloto (although I do not have artwork changing permissions as such those changes are on hold), fixes suggested in the thread, and bringing it up to speed to the latest version.

    Phase IV Update

    -My apologies for the delays. Asthma has hit me hard this past week and has slowed my productivity.

    -The Kerbostar is an aircraft now like the KSOs. Which means that it requires what seems like about as much attention as a full phase on its own. I've got most of it knocked out, but I'm still brick-n-mortaring the IVA.

    To do

    -Finish Kerbostar IVA

    -Kerbostar colliders are done!

    -Update all testers to latest version of Phase IV (including the kerbostar).

    -Lunar rover kit exterior.

    -Lunar rover kit IVA

    -Final Phase IV Testing

    -Finish updates and fixes to all of KSOS

    -Finish KSOS installer

    -Split KSOS project into component phases.

    -Release KSOS

  8. Yeah, it looks the same. Both Block 7 and 8 are not working. ( I've checked them separately) In super 25 the shuttle flies away, while still connected to the rockets with some grey pipes, and after few seconds everything explodes :cool:

    I've checked cfg files and they look ok, I think that the problem is with some plugin, but I don't know which one so far..

    You're missing Firespitter.

    These are the symptoms typical of Firespitter.dll being missing. Redownload 3.10. You must install all plugins included in the zip by dragging over each folder into your GameData directory

  9. Issue #1:

    I have also posted this on the RPM thread:

    The glitch where the HUD and ADI overlays become super dark is caused by OpenGL rendering.

    This is why it occurs on Linux and Mac.

    I am using Windows 7, and was using the 64-bit version to allow for all my mods. The HUD and ADI was fine during this time.

    The instability, glitches, and enormous memory usage caused me to switch the the 'amazing' openGL switch.

    I can run all my mods with only a 2.6 GB RAM footprint in 32-bit KSP with the -force-opengl command parameter.

    However, this is when they problem occurred with the super dark overlay. I have confirmed this by running the game with no OpenGL switch with the exact same install, and they magically work again with the default DirectX (I have not tried DX11 though).

    As to why this occurs I have no idea whatsoever.

    Also:

    It may be unrelated or not causing the problem, but I also noticed that the files that ARE the ones that become dark have a Y dimension size of 2044 pixels (Instead of say 2048, as in some of the other image files) Could this be the problem? Maybe OpenGL freaks out when an image isn't a power of 2 size? Can you do a check by reworking ladder.png to be a power of 2?

    Issue #2:

    *EDIT*

    I just discovered that the KSO MFD's need electrical power to actually display (Through my perusing of all the RPM configs in KSO) It may be useful to explicitly mention this in the KSO FAQ. It isn't 'exactly' intuitive because the rest of the lights are on. I was testing quickly so just added the cockpits to check. ISSUE#2 is solved, but ISSUE#1 remains at large...

    Interesting!

    Thank you for this, I'll run some tests. I'm stuck with Phase 4 for a bit but I really need to visit the RPM stuff.

  10. What I can do is start working on the plugin needed to do this in a "sterile" Unity environment (i.e. a new Unity project so that I can get things running a lot faster) and then develop it into a state where it can work for KSP.

    The sterile environment will be really helpful since it will give me an idea of how to go about swapping rigged meshes at runtime without major issues. I'll probably start looking at that stuff tomorrow.

    When I get the chance to I'll open up a thread in Addon Development dedicated to this project.

    -You have to try and find out what the bone names are. Not a big deal, but I specifically need to know if I need to include a clavicle or not (left and right shoulder bones).

    -What method did they use for facial animation? Again, if you can somehow find out the bone assignments and it turns out they just added bones in the face, our job is easier. As opposed to morphs.

    -Polygon budget for a single Kerbal? I think they are using a bit more than is traditional. Judging by the silhouette (seems smoother than 1250).

    We'll then run into other issues:

    -RCS location for EVA mode?

    -EVA/IVA mesh swap? Is it a morph or a swap? Making the EVA suit is not an issue for me. But it too need's animations.

    See if you can PM me so we can start moving this off this thread. Also keep in mind I have to finish Phase IV of KSOS before I move on to something else. Although Character models are so much easier and faster for me to do.

  11. Helldiver:

    Also, I noticed in the block crafts for both the Super25 and the KSO that the action groups did not match those outlined in the description of the craft files. Just figured I'd let you know. Otherwise, they both flew great and so far I've had no crashes with the latest 64bit version of ATM.

    That was an oversight in my part.

    I'm slowly transitioning away from the Westi action group standard. It worked well for the KSO. But with the additions of new vehicles such as the cars, trucks, heli and so on, the layout the Super25 uses seems to work a bit better for me in terms of remembering which turns engines on/off trims on/off and so on.

    The Super25 layout goes:

    1: Engine Channel 1 ON/OFF

    2: Engine Channel 2 ON/OFF

    3: Engine Channel 1 Trim ON/OFF

    4: Engine Channel 2 Trim ON/OFF

    5:Special Abilities

    6:Special Abilities

    7:Special Abilities

    8:Animations and Lights

    9:Animations and Lights

    0:Animations and Lights

    I organized them that way in order of most critical system. Although maybe 1,2 should govern engine channel 1, and 3,4 engine channel 2.. hrm...

  12. @Avalon

    Forget "alpha" or "beta" or how good minecraft is - do you understand the concept of "early access"? The alternative is *no game until release* - yes, you are paying for an incomplete, error-ridden, unpolished and untested (to a certain extent) "game", what you get in return is a chance to be part of the development process.

    Please take this discussion to PMs

    It's not helping me at all. I prefer that this space be limited to:

    -Discussion, screenshots, and videos of KSOS usage

    -Bug reports

    -Config file fixes and sharing (such as FAR/DRE configs).

    -General KSOS specific feedback.

    Everything else needs to go to PMs, or its specific thread.

  13. If you (or anyone, for that matter) were to reverse-engineer the kerbal model then I could look into making a plugin to make certain Kerbals use the female model. Just let me know if you ever get to the point where that could be a possibility! :)

    You'd have to elaborate on what you mean by reverse-engineer.

    I can model a 99% replica. Unfortunately I would need their skeleton in order to properly weight it and get the correct assignments.

    The other method would be to redo our own animations as well. At that point we may as well make our own game.

    Squad would have to provide their skeleton files (akin to how Bethesda uses global animation files character meshes with skin modifiers reference)

  14. I think that left one looks a lot truer to the original Kerbal and thus looks better as a whole. The big poofy hairstyle just seems overbearing so if you continue working with those you should use the left one.

    Yeah, if someone did such a plugin or if Squad opened it up, I'd go with the left one.

    Although I'd re-engineer the head to use proper edge flow, working mouth, and correct topology for facial animation.

    Personally I like the big hair (like the majority of female astronauts have long hair). It frames her face better. Unfortunately we'd run into all sorts of clipping issues with the helmets, chairs, and so on. So ultimately we'd have to go with the crew cut or simple pony-tail.

  15. How about this? This image is deliberately drawn to look just like a 3D model.http://forum.kerbalspaceprogram.com/threads/86295-Girlbal

    Uh? What about it?

    I'm not Squad's character artist. And if I were I would go with what's best identifiable as well as usable. Kerbals as they are, are a pain to work with do to their irregular proportions. I do this for a living man. Also, your drawing doesn't read feminine at all. At a distance they'd be indistinguishable from any other Kerbal, insofar that it's just like using Texture Replacer (which we already have).

    Kerbals aren't supposed to look gorgeous. Cute, silly, and funny, but definitely not gorgeous. Imagine drawing a male Kerbal (Admittedly a somewhat masculine face) like a body-builder. Astronauts aren't generally unattractive, male or female, but they're not supermodels.

    They can be what ever I want them to be, this is the Fan Art thread isn't it?

    I'm not making Kerbal character models. I just did Kim since she's part of my project. Just for fun and to practice speed modeling. If eventually someone does a plugin or something that allows us to change the Kerbal's 3D models and such, then I'll take a stab at it. And if I did I'd make sure they read as feminine from the average distances used in game. But until then I have other things to do.

    ...thanks for that. thanks. I just had to fight the huge spider in Skyrim and now i'm pretty skittish when I see one. Now I won't be able to think about female kerbals the same again.

    MUCH better! The OP's pics looked very unrealistic and I didn't really like them personally. But that's just me.

    Problem with those eyes is that they are just too creepy :D

  16. Give you guys an idea:

    dmGelgD.jpg

    Inspired by the images Hayoo did. Not a fan of the strabismus so I took it off the female. I've always felt that Kerbals are wall-eyed to give them that 1970's Buzz Aldrin look.

  17. Well if I was to get serious about an actual female Kerbal, all I'd have to do is a new head. I'd probably go with the design someone posted around here somewhere.

    I'm too tied up with Phase 4 of KSOS to really sit down and do that though. I just did this for fun and to relax.

×
×
  • Create New...