[1.0.X - Experimental] [On Hold] FusTek Station Parts (WIPs on GitHub)

[sumghai]

@Space Coyote

Your initial bug report was rather ambiguous, but I finally found out what you were talking about.

Turns out you were referring the GUI element representing the slots, not their volume. I've changed slotSize to the KIS default of 50.

[Insanitic]

Umm, just a quick question. Are the windows supposed to completely transparent? Because mine is, and because it is, I think it's cutting my FPS to about half because the interior view is so detailed that it too is being loaded in full.

[sumghai]

Umm, just a quick question. Are the windows supposed to completely transparent? Because mine is, and because it is, I think it's cutting my FPS to about half because the interior view is so detailed that it too is being loaded in full.

Yes, the windows are meant to be almost fully transparent.

As for lag due to JSITransparentPod - it's regrettable, but see-through interiors are one of the core features of the eventual V1.0 release.

[Insanitic]

Alright, thanks for confirming. I guess I can handle the lag, for the awesome looks of your models!

[SpaceMonkeyExile]

This mod is amazing. I just put my first space station up and it looks awesome! Keep up the good work!

[Space_Coyote]

@Space Coyote

Your initial bug report was rather ambiguous, but I finally found out what you were talking about.

Turns out you were referring the GUI element representing the slots, not their volume. I've changed slotSize to the KIS default of 50.

So at this ipoint at least we got that figured out even though I didn't know what i was looking for..

So does this mean I need to do a uninstall/reinstall on thi sone? or should I jsut wait?

Space_Coyote

[sumghai]

So at this ipoint at least we got that figured out even though I didn't know what i was looking for..

So does this mean I need to do a uninstall/reinstall on thi sone? or should I jsut wait?

Uninstall FusTek, re-download from GitHub, re-install.

Please note that since this is a WIP developmental build, I push updates automatically to GitHub many times a week, so you may want to redownload once every couple of weeks.

[J.Random]

Yes, the windows are meant to be almost fully transparent.

As for lag due to JSITransparentPod - it's regrettable, but see-through interiors are one of the core features of the eventual V1.0 release.

Just for those who tries not to use transparent pod mods because of how weird they may behave (especially together), can you add a "fallback" of some sorts? Pretty please?

[sumghai]

Just for those who tries not to use transparent pod mods because of how weird they may behave (especially together), can you add a "fallback" of some sorts? Pretty please?

I think it's better to solve the underlying problem at hand, than simply not using a certain feature and sweeping it under the carpet.

If the problem is with transparent pods in general, speak to MOARdV, as he's maintaining the JSI RPM plugin that provides this functionality.

If, however, the problem is with my specific implementation of transparent pods in FusTek, please provide details, error logs, screenshots, videos, clear reproductions steps, all on a separate KSP install with as few other mods as possible required to replicate the problem.

[J.Random]

Ever seen vehicle wheels bump over invisible terrain on runway without tipping vehicle over? Well, if you have both USI Tools (?) and RPM installed, you may also start seeing another vehicle internals clipping through your vehicle internals in kerbal portrait view roughly at the same spot. Or IVA hanging at funny angle in mid air in main view. Another example is that vehicle internal lighting, seen outside, may change depending on EVA kerbal orientation. I don't blame anyone and I'm not saying "OMG BROKEN FIX NAO". I think it's just how the whole "transparent pods" thing is done. It's a hack of Unity render layers (which also aren't great, to my understanding). Glitches like that can be considered minor, they don't leave errors in logs, and they can't be triggered reliably. They're PITA to debug. That's why, instead of pestering mod developers with bugs they surely know about anyway, I'm simply trying to not use said plugins. And all I'm asking is an option for that, if it's not too much of excess work for you.

[sumghai]

Ever seen vehicle wheels bump over invisible terrain on runway without tipping vehicle over? Well, if you have both USI Tools (?) and RPM installed, you may also start seeing another vehicle internals clipping through your vehicle internals in kerbal portrait view roughly at the same spot. Or IVA hanging at funny angle in mid air in main view. Another example is that vehicle internal lighting, seen outside, may change depending on EVA kerbal orientation. I don't blame anyone and I'm not saying "OMG BROKEN FIX NAO". I think it's just how the whole "transparent pods" thing is done. It's a hack of Unity render layers (which also aren't great, to my understanding). Glitches like that can be considered minor, they don't leave errors in logs, and they can't be triggered reliably. They're PITA to debug. That's why, instead of pestering mod developers with bugs they surely know about anyway, I'm simply trying to not use said plugins. And all I'm asking is an option for that, if it's not too much of excess work for you.

I'm afraid you'll just have to take this up with RoverDude, Mihara and MOARdV, or simply not use FusTek Station Parts.

JSI RPM is considered a core dependency for FusTek - besides the pretty transparent windows, it is also used for various prop texture shifting / animations.

[Space_Coyote]

Okay Just updated the Fustek and the GUI size for iS is fine except for one thing.. If you are trying tin put into the storage units an item that can be used to have multiples of (e.g. Lights explosives, and Handholds for example) then these are not being multiplied, (Soyou can only put 1 hand hold into a slot raarther than 20 or 50 or however many.. (Things likee wrenches screwdrivers, and eva tankes are okay. as they are only designed for one inventory slot.)

(Just some of the observations I am making..

(Oh and if these have bene fixed, I'll go download and reteest in 1.0.4 as the KIS/KAS system has been updated for such.._

Space_Coyote.

[Z3R0_0NL1N3]

I'm using this mod (installed properly), but I'm having some trouble with the transparent windows. The internals of the pod are viewable when clipping the camera inside the part. Does this affect memory, campared to a standard IVA? Secondly, some parts' windows seem to just have holes, but I assume that those internals are just not complete.

And I don't mean to be Mr-Complainy-Pants, because I always use this mod for my ISS-like stations, but... I honestly don't like the transparent windows. I love the internals and the work that's gone into them, but I just wish that the internals were IVA-only, and not viewable from outside the spacecraft. It's a cool effect, but it just feels out of place with everything else thal doesn't use it. I'm not saying you have to make this change, (it could just be an option!) but is there something in the config I could change to display like normal, or is it more complicated than that to change?

And secondly, for a second, simpler request, could you make the parts have the mission flags (on a similar position to the ISS)?

I read your red-text on the first post, so I'm just asking a question of inquiry, if it's not too much work.

[McPoisoned]

Can't wait for the release! I love your design and the mod itself. But I'm kinda afraid that the transparent windows will make it insanly laggy when building large space stations.

[Z3R0_0NL1N3]

Can't wait for the release! I love your design and the mod itself. But I'm kinda afraid that the transparent windows will make it insanly laggy when building large space stations.

Yeah, that's my worry too. As much as I love the designs, I think they'd be better IVAs.

[sumghai]

I'm already aware of the transparent window issue. No need to keep posting repeated reports.

[Wolf Baginski]

Yes, the windows are meant to be almost fully transparent.

As for lag due to JSITransparentPod - it's regrettable, but see-through interiors are one of the core features of the eventual V1.0 release.

"Regrettable", but it may be a killer for my system. It's a questionable design decision, maybe good for a cupola, doesn't seem that sensible for the small round windows on the various Fustek modules. Are such small windows worth the lag?

It's all up to you, but if there isn't an alternative provided, I'm afraid it will all seem rather pointless to me.

[AOA1]

These are immensely useful parts. Besides a few of the modules having a "click to test lights" block inside of them, I haven't found any issues related to the parts themselves, and that one thing is just a test object.

Edited July 19, 2015 by AOA1

[Wolf Baginski]

I can't tell whether it is the transparent windows or the complex interiors, but lag in the latest version has skyrocketed. Comparing Mission Elapsed Time with real-world time, it's running as slow as 30 sec realtime to 1 sec MET. A rendezvous with a large space station, about 1/3 FusTek by part count has become incredibly sluggish. The computer is running at about 50% of CPU power, which suggests an overload of the GPU, possibly exacerbated by getting close to the RAM limit. The GPU is an Nvidia GTX 650 which handles some heavy-duty games without problems.

My experiences today have come despite removing some un-used Mod sections from large Part collections. I do have some command pods which use the same RPM function to provide transparency, and have never triggered this problem.

Differences: the Parts appear to be modelled with just the one transparent component. Checking the part.cfg for the FusTek parts, a cylinder with six small transparent portholes has six references to a view port model, of this form:

MODEL

{

model = FusTek/Station Parts/Parts/modelKarmonyViewport

position = 1.26393, -1.1, 0.0

rotation = 0.0, 0.0, -90

scale = 1.0, 1.0, 1.0

}

There are some differences in the position and rotation values.

Now, I do have some practical experience of 3D modelling and CGI, and have manually hacked files. Something such as the Wavefront .obj format is a huge mass of ASCII text, partly the sort of info that is in a part.cfg, partly the 3D coordinates of every vertex in a theoretically human-readable form. Which leads to all sorts of extra work for the computer, converting the ASCII to 32-bit integers, probably signed integers. The .mu files used by Unity are of that sort, not ASCII. Is that going to mess up things so much?

I don't know. But those six components might end up being treated, by JSITransparentPod, as six distinct parts. The Kupola model doesn't do that, all the glass is in the same model.mu as the rest of the structure.

Back in the old days, I worked with programs in interpreted BASIC, and I really hope Unity isn't that bad, but finding six small components by reading an ASCII file is going to be slow. I found ways to replace several lines of BASIC with a dozen bytes of machine code, and the speed difference is incredible.

This new behaviour of the FusTek parts feels like a reversal of that change.

And do you need to reference all the different components in the part.cfg?

Hell, no! It doesn't need Blender, it's essentially a merging and positioning of the components, made as distinct files and saved as a single file (I used Wings3D and I know Blender can do the same). A key term-of-art here is "Material". You can have the same material defined for all the component meshes, the same label, and that label will be in the end product, much easier for JSITransparentPod.

I can think of several things I can do. There's a tool to get an .mu file back into Blender. But then I have to deal with the IVAs. One thing is obvious, just from the filesizes: even with the efficient use of the same .dds files for so many different parts, they're big files. And I find that one of them is a whole set of barcode labels for different things They're big enough to distinguish the line patterns. When you're in the IVA, everything looks incredibly sharp, much sharper than the IVA in a Squad component.

Even with the efficient re-use of each texture, they're just too good. You could halve the dimensions of every file, and likely still be better than what Squad uses, and there would be a quarter of the data for the graphics chipset to be handling.

Of course, a common trick is to make a high-res model and generate things such as normal maps from that model. Things such as ambient occlusion are "baked" into the texture after being generated from the high-detail model. If that's what Sumghai plans, where has he said so?

On what I have seen, in terms of performance and looking closely at the data being used, the current test releases have become deeply flawed.

[Starwaster]

Wolf, there's a number of things wrong there in your speculations.

First the config files. All of of that is parsed one time only: when the game starts up. It's already parsed and serialized and Unity models and textures loaded before the game gets to the main menu.

Second, your GPU: I've run quite a few tests here over the past couple of days and have been corresponding back and forth with Sumghai and trying different things out and I am really not finding that my GPU is being challenged at all. (it's a 650 too). Just to give you the benefit of the doubt, I just went through and butchered the crap out of those texture files. I cut them all to 25% (never mind halving them). It had zero impact on performance issues.

I do find that the CPU is being worked pretty hard but that's going to be more of an issue with whatever work the plugin is doing every update than with the graphics card.

[Ford6]

The game is run on unity engine. Unity is CPU driven. . . . GPU mostly idles with unity programs. Also, the current version of unity used by KSP (Unity Version 5+ uses multi-thread / core, and KSP is being converted to it.) only uses one thread / core. So 50% usage one a duel core is full usage.

[Wolf Baginski]

The game is run on unity engine. Unity is CPU driven. . . . GPU mostly idles with unity programs. Also, the current version of unity used by KSP (Unity Version 5+ uses multi-thread / core, and KSP is being converted to it.) only uses one thread / core. So 50% usage one a duel core is full usage.

I have tools which report usage per core. All cores are showing fluctuations, but are running at about the same level. None are even close to a sustained 100% usage. The CPU usage is not choking the game when using Sumghai's latest version.

[AOA1]

To follow up on my previous post from before:

Comparing stations with stock parts to those with these parts, it seems that some parts in this mod cause memory issues, as the stations with these parts are far laggier, even if they have 1/5 the parts.

From tests in the SPH, it appears that, when two IACBMs are connected, there is a memory leak that causes the game to lag. Apologies if this has been posted in the past.

EDIT: Should this be posted in the development thread instead? Sorry, I'm new to forums.

Edited July 21, 2015 by AOA1

[Starwaster]

To follow up on my previous post from before:

Comparing stations with stock parts to those with these parts, it seems that some parts in this mod cause memory issues, as the stations with these parts are far laggier, even if they have 1/5 the parts.

From tests in the SPH, it appears that, when two IACBMs are connected, there is a memory leak that causes the game to lag. Apologies if this has been posted in the past.

EDIT: Should this be posted in the development thread instead? Sorry, I'm new to forums.

Why do you think it's a memory leak?

[Wolf Baginski]

I'm not sure where you should post it.

The IACBM has been in use for a long time, and I don't see any recent signs of changes. That's something that makes a memory leak unlikely. It's got a particular look. but it isn't vital that you use it. Since a lot of in-line docking ports, such as are used in spaceplanes, use the Clamp-O-Tron stock docking port, there is an argument for sticking with the stock docking port at 1.25m size.

There are other 1.25m docking ports. Unless somebody makes an in-line which just has the attachment node, and has the actual docking port as a separate part, if you want to use a spaceplane you have to stick with the Clamp-O-Tron.