Jump to content

FusTek Station Parts Dev Thread (continuation of fusty's original work)


sumghai

Recommended Posts

Again, thanks for the kudos, everyone!

Just wanted to chip in my appreciation for the continuing work on this, its amazing! I've always rather enjoyed the atmospherics of having a station as an actual "place" for the Kerbals to be.

http://i.imgur.com/4nh7W7F.png

http://i.imgur.com/dsC32WU.png

http://i.imgur.com/OivfUs2.png

http://i.imgur.com/JC9L418.png

GLORIOUS, MOST GLORIOUS.

Qapla'!

Does the "click me" in the latest dev version not work on most windows or am I just clicking the wrong thing?

It's a bug on my part, due to my inexperience with using JSIActionGroupSwitch. Otherwise, you are clicking in the right spots.

Link to comment
Share on other sites

(Lack Of) Progress Report, 14 October 2014

I've been migrating my add-on development over to KSP 0.25, and one thing I've noted is the improved ModuleAnimateGeneric, which allows animations to be toggled/tweaked* while in the VAB/SPH editor scene.

For SDHI Service Module System, this meant I could drop Firespitter as a dependency entirely; FusTek would still require Firespitter for texture switching, but the IACBM docking ports and Warehouse/Payload Bay animations have been migrated over to the new stock system.

That being said, I've noticed that adding/manipulating/removing Payload Bay parts in the VAB/SPH causes the game to freeze for several seconds - I'll need to fix that. I'll also need to invert the hatch retrofit animation I added for the IACBMs.

Link to comment
Share on other sites

Development on this add-on has been paused until late November 2014, as I am in the final months of completing my Master's Degree. I'll resume work on R0.04a when I come back.

Thanks for your understanding.

Psht, way to make a college drop-out feel good about themselves. :rolleyes:

Best of luck finishing up "dat masters degree"!

Link to comment
Share on other sites

Good luck on the masters! Love the fustek parts, and love the idea that they'll live on.

When you get back to this, a suggestion. My one complaint is that the eva handles are too yellow. The real ISS eva handles are more of a dark gold/orange. For reference here are some photos of ISS EVA handles in bright sunlight. I know we're not exactly going for realism here, and others may disagree, but that yellow has always struck me as being too cartoony.

Just a thought.

Edited by wreckreation
update photo url
Link to comment
Share on other sites

  • 2 weeks later...
My one complaint is that the eva handles are too yellow. The real ISS eva handles are more of a dark gold/orange. For reference here are some photos of ISS EVA handles in bright sunlight. I know we're not exactly going for realism here, and others may disagree, but that yellow has always struck me as being too cartoony.

Personally, I'm tempted to agree with you. They're currently cartoony yellow for two reasons:

- It's a homage to the original FusTek aesthetic

- I haven't yet figured out a good way to do the dark gold-ish texture without it looking too brown / photorealistic. Remember, KSP shaders tend to be twice as bright as standard Unity shaders.

Perhaps in the future someone could make an alternative texture pack with better EVA handle colors.


(A Surprise) Progress Report, 28 October 2014

I had a couple of days of respite, and decided to deal with another low-lying fruit (since resuming work on IVAs in earnest would have been too much).

I've been looking at rebalancing part prices for 0.25.x/0.90.x, and after a number of discussions on GitHub (Issue #31), I've put together a spreadsheet of preliminary price changes:

https://drive.google.com/open?id=1O4F2ws5sF8Xv1t9SDwLH5QW6Wsq4gga20W_V9wlGWTI&authuser=0

Rationale

- The basic structural framework of most (but not all) FusTek modules are built from one of two common form factors: the standard full-length module and the half-length module. It is only the internal fittings and viewports that differentiates, say, a Habitation module from a Science module - this makes more sense than pricing each variant individually based on the number of typical occupants (in the psuedo-real-world of the Kerbal universe, it's physically possible for six Kerbals to gather in the nominally 2-crew utilities or the 4-crew habitat modules to take a group photo or something.

- I've settled on the notion that Life Support is implied in the stock game, so prices have been set accordingly. If a user chooses to install a life support plugin like TAC-LS, the cost is already covered.

- After looking at the current results, I've decided that an additional premium won't be necessary, since FusTek parts are intended to be high-quality but expensive parts.

- Some of the existing parts will get resource / feature buffs (e.g. increased ElectricCharge capacity)

Could you guys please look over these proposed values, so that I can push this to GitHub and cross this one off my TODO list? Thanks in advance.

Link to comment
Share on other sites

hmm great news sumghai :cool:b

although why is it i am getting the feeling that at some point that there will be a plugin made that will work along side Kas by having utilizing the storage function of Kas to affect IVAs via the coding of specific props to appear and disappear in the IVA whenever a flexrack is present in the container/inventory which of course would affect the resource value of the part...

of course i don't make/know how to make plugins so i am not sure if this makes sense/would work

Link to comment
Share on other sites

(A Quickie) Progress Report, 31 October 2014

Having received no dissenting (or indeed, any) feedback regarding the proposed part costs, I've gone ahead and pushed the changes to GitHub.

I have some spare time this weekend, which I'll use to try to fix the laggy / broken Payload Bay modules.

Link to comment
Share on other sites

Having received no dissenting (or indeed, any) feedback regarding the proposed part costs, I've gone ahead and pushed the changes to GitHub.

Hey, just in case I'm ever not clear. My silence is never that I'm not interested. Rather, the opposite. I think you know what you're doing and I trust that it'll all work out in the end. :) Cheers.

Link to comment
Share on other sites

Well, personally, I looked over the spreadsheet and thought it made sense, but I didn't want to disturb your Masters work, so I didn't post anything. But don't worry, there are plenty of us out here who are very eagerly (if quietly) awaiting updates on this!

Link to comment
Share on other sites

Progress Report, 7 November 2014

Apparently, this brief respite is a bit longer than I expected, so I made good use of this by dealing with more low-lying fruit.

KSP Freezing when Payload Bay modules are manipulated in the editor - SOLVED

While migrating most of the FusTek part animations to the updated ModuleAnimateGeneric in KSP 0.25, I encountered a strange problem with the FusTek Payload Bays - when I added / manipulated / removed a Payload Bay module in the VAB/SPH editor scene, the game would freeze or turn into a slideshow. Error logs didn't suggest anything out of the ordinary.

After days of investigating (including rebuilding the parts from scratch), I determined that the problem was due to an incompatibility with Ferram Aerospace Research (FAR):

- Generally speaking, FAR considers any part with the keyword "payload" in its title to be an aerodynamic payload shroud / fairing, and does some funky calculations to determine its aerodynamic properties.

- The problem is that the FusTek Payload Bays are A) not supposed be considered as payload fairings and B) contain high-poly meshes for the EVA handrails; both factors causes FAR to struggle with on-the-fly calculations, hence the editor lag/freeze.

- I couldn't reduce the polys on the EVA handrails, since this would make them inconsistent with those on other modules.

- I also couldn't simply rename the Payload Bays, since that was the most sensible name for the part's given purpose.

After consulting with ferram, I figured out a way to override the default payload shroud behaviour on the FusTek Payload Bays by manually generating a FARBasicDragModel and including it in the part definitions. FAR will see the custom definition and will thus no longer try to do on-the-fly calculations, resolving the editor lag/freeze issue.

(ASIDE: You may be wondering why I'm deliberately nerfing the shielding behavior from the Payload Bays / Warehouse modules. This is because like all other station modules, these need to be protected with payload shrouds from *other* part packs - I mean, when was the last time you saw an ISS module strapped to a lifter rocket exposed to the elements anyway?)

Karmony Viewport size reduction

I shrunk the dimensions of the round portholes on the Karmony modules by 80%, because the corresponding internal prop at the original size was clipping into internal bulkheads. Kerbals are still going to have decent views of the cosmos despite this nerf, however.

(WIP) Prohibiting surface attachment on portions of Warehouse / Payload Bay modules

lo-fi recently made an interesting discovery with regards to the new stock cargo bays, in that surface attachment is disabled only for the cargo bay door mesh. The trick is to label the associated colliders with a tag called NoAttach in Unity. This makes perfect sense, given that any parts attached to any animated door won't move in sync with said doors (unless InfernalRobotics is involved).

Needless to say, I would like to implement this cool little feature on my Warehouse / Payload Bay modules as well, so I'll need to do some clever jiggery-pokey with extra collider meshes.

IVAs

Patience, you must have my young padawan. I'm still working on them, but the effort required to finish them properly doesn't make them low-lying fruit.

Link to comment
Share on other sites

Progress Report, 8 November 2014

NoAttach has been applied to the Warehouse and Payload Bay doors, preventing surface attachment on those submeshes.

I also added a couple of dummy, non-convex colliders to the inner surface of the Payload Bay module ends. This forces docking ports to be stack-attached rather than surface attached, which will make it easier for users to turn Payload Bays into garages for mini-tugs.

Fig 80 - (WIP) FusTek Karmony Warehouse / Payload Bay - Model refinement and NoAttach surfaces test

Link to comment
Share on other sites

  • 1 month later...

Hey Sumghai, I downloaded the last published FusTek file and I have a few things to comment on:

  • I'm experiencing lag generated by the IACBM docking collars in both the VAB and in orbit. I made a 155 part station in the VAB that had approximately 34 docking collars. Lag became a huge issue that was not seen after swapping them out with the stock clamp-o-trons. The debug window had nothing to say about it, though I'll need to find time to try to replicate it on a stock install. Personally, I think you could do without the docking fin animations as they serve no purpose outside of roleplay.
  • Similar lag on the same station was seen with the payload and warehouse bays, though I think you fixed it in the last commit.
  • IVA looking pretty good so far, and I'm glad you reduced the viewing ports.

I'll do more play testing in the following weeks.

Link to comment
Share on other sites

Hey Sumghai, I downloaded the last published FusTek file and I have a few things to comment on:

  • I'm experiencing lag generated by the IACBM docking collars in both the VAB and in orbit. I made a 155 part station in the VAB that had approximately 34 docking collars. Lag became a huge issue that was not seen after swapping them out with the stock clamp-o-trons. The debug window had nothing to say about it, though I'll need to find time to try to replicate it on a stock install. Personally, I think you could do without the docking fin animations as they serve no purpose outside of roleplay.
  • Similar lag on the same station was seen with the payload and warehouse bays, though I think you fixed it in the last commit.
  • IVA looking pretty good so far, and I'm glad you reduced the viewing ports.

I'll do more play testing in the following weeks.

Do you have FAR installed? The Payload Bay lag in the VAB/SPH was due to an unforeseen interaction with FAR, which I fixed a while back.

I'm not sure about the IACBMs, since I've never experienced any lag caused by the docking fin animation module.

Link to comment
Share on other sites

Oh, sorry, I wasn't pointing to the animation as a cause of lag. Just that the animation serves no ingame purpose. I don't know what might be causing the lag though. And I Uninstaller FAR, and all problems with the warehouse and payload bay disappeared, as you earlier noted.

Link to comment
Share on other sites

Oh, sorry, I wasn't pointing to the animation as a cause of lag. Just that the animation serves no ingame purpose.

I'm keeping the animation, in case SQUAD or someone someday expands on ModuleDockingNode to make guidance fins functional.

I don't know what might be causing the lag though. And I Uninstaller FAR, and all problems with the warehouse and payload bay disappeared, as you earlier noted.

Actually, try re-installing FAR now.

The commit that contains the fix for FAR and the payload bay module essentially requires the player to clear out / reset their CustomFARClassification file. Perhaps that was all that was needed in your case

Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...