Kerbodyne Plus Development Thread

[Siphonophore]

Quote

This series of lectures might be good for you:

Udemy

Also, https://www.codecademy.com/ is a good resource.

 Like this

• @Bonus Eventus

Thanks! I've tried Codecademy before so I might check the first one out this weekend. Also heres a few suggestions for the NRAX converter;

Those blue pipes on it could glow sky-blue-ish green when the reactor's active, and it could emit a bunch of core heat so players are encouraged to put radiators on ships with NRAX converters without it going into a meltdown and becoming non-functional. Depending on the level skill, an engineer could repair it when holding on to some EVA handrails on it 

 

 

[Bonus Eventus]

 

I think that's enough progress for one evening

[Siphonophore]

Nice! But could you fix the typo at "Thats when Mark Kerman" to a "That's?" not literally though

So any screenshots of the NRAX converter in-game?

 

[Bonus Eventus]

1 hour ago, AJTheMighty said:

Nice! But could you fix the typo at "Thats when Mark Kerman" to a "That's?" not literally though

So any screenshots of the NRAX converter in-game?

 

ha ha, thanks for pointing that out, I'll have to rethink how I strip quotes in the interpreter.

[Siphonophore]

On 2/4/2016 at 8:02 AM, Bonus Eventus said:

ha ha, thanks for pointing that out, I'll have to rethink how I strip quotes in the interpreter.

Your welcome  Btw any progress on the mod itself and Kerbodyne Plus dev release v1.0.6???

 

[Bonus Eventus]

Didn't have much time in the last few weeks to work on the mod. I returned to code this weekend. The interpreter is much better after a slight redesign. Above, is the PHP print of a PART array from the Squad externalCommandSeat.cfg. Basically what I lacked before was well formed data. The data I got from the interpreter was sent to javascript with duplicate keys. Now that's been corrected and each node in the cfg has a unique index. What's really cool about that is, in es6 we have a ton of useful javascript object methods. As a result I can now search for a key (like the unique index) , no matter the arbitrary depth,  and change that objects properties. That means that the html ui (you can see a preview a few posts back) can be assigned click events through jquery and the database representing the Part that came from the interpreter will be immediately validated then updated. This is the theory anyways.

The cfg.js is a javascript framework I'm creating which allows for validation of part.cfg node data, as well as the creation of formatted nodes and modules. It works like this:

cfg.get(obj_name.children).append({
	type : 'MODULE',
	children : {
		name : 'ModuleAnimateGeneric',
		animationName : 'myAnimation',
		isOneShot : false,
		startEventGUIName : 'extend',
		endEventGUIName : 'retract',
		actionGUIName : 'toggle'
		},
  	return : false
	}, callback());

// Obj_name.children is the parent you wish this module to be a child of. Children are always appended to the children array of the parent
// object. Cfg.js has an internal library of cfg data formats (like vector3 or attachRules) which tell it how to validate the datatype of a 
// node. Essentially all that cfg.js does is add valid part data objects to a Part object. 

it's not an accident that the notation above looks a lot like jQuery. I felt that traversing part.cfg data was very similar to traversing the DOM in html. Cfg.js, much like jQuery, adds and deletes nodes as well as iterates over collections and change attributes.  Also, I'm making sure to keep it vanilla javascript, so you can use it's ability to read and modify cfg data for whatever your purposes might be. 

 

For CFGKit the program logic is handled by cfgKit.js and kit.js. Both files work together to handle the data binding and adjusting data views as well as importing and exporting cfg projects and saving a project's metadata as json. 

I know it won't be very exciting to some, but I feel that having an automation tool like this will help me make less mistakes that often happen when hand coding each cfg file. It may be interesting to some of you to know that modeling for me is the fastest and easiest part of creating a new part for Kerbodyne Plus. Importing into Unity comes in second, then texturing, then cfg editing last. Why? Because cfg's are very brittle. They are case sensitive and repetitive. I've struggled getting a part to load correctly for an entire week, just to find out I had an extra comma somewhere. 

Anyways, the hard parts are over now, I just have to craft a massive json file to serve as a module encyclopedia and finish the javascript ui scripting. Keep an eye out, 1.1 is coming soon!

 

EDIT: Made a ton of progress today! However, I underestimated the amount of digging I'd have to do in the c# assemblies to get at the data I needed, sigh. I drilled down in found everything I needed in spite of it being like finding a needle in a haystack. Since this is the first time I've ever poked around in the C# files, it was um, interesting (read really hard). Along the way I updated the wiki's entries for ModuleTestSubject. I have some other useful data to add (concerning the ModuleResourceScanner and ModuleScienceExperiment), but that will have to wait. I'm pooped.

I leave you good people with this, a massive list that this picture does not do justice (around 300 entries). This is all the cfg properties I could find.  There's a chance I might have missed some, but at least I can move on, without anything breaking.

Edited February 15, 2016 by Bonus Eventus
additional info

[Siphonophore]

On 2/13/2016 at 0:35 PM, Bonus Eventus said:

Didn't have much time in the last few weeks to work on the mod. I returned to code this weekend. The interpreter is much better after a slight redesign. Above, is the PHP print of a PART array from the Squad externalCommandSeat.cfg. Basically what I lacked before was well formed data. The data I got from the interpreter was sent to javascript with duplicate keys. Now that's been corrected and each node in the cfg has a unique index. What's really cool about that is, in es6 we have a ton of useful javascript object methods. As a result I can now search for a key (like the unique index) , no matter the arbitrary depth,  and change that objects properties. That means that the html ui (you can see a preview a few posts back) can be assigned click events through jquery and the database representing the Part that came from the interpreter will be immediately validated then updated. This is the theory anyways.

The cfg.js is a javascript framework I'm creating which allows for validation of part.cfg node data, as well as the creation of formatted nodes and modules. It works like this:

cfg.get(obj_name.children).append({
	type : 'MODULE',
	children : {
		name : 'ModuleAnimateGeneric',
		animationName : 'myAnimation',
		isOneShot : false,
		startEventGUIName : 'extend',
		endEventGUIName : 'retract',
		actionGUIName : 'toggle'
		},
  	return : false
	}, callback());

// Obj_name.children is the parent you wish this module to be a child of. Children are always appended to the children array of the parent
// object. Cfg.js has an internal library of cfg data formats (like vector3 or attachRules) which tell it how to validate the datatype of a 
// node. Essentially all that cfg.js does is add valid part data objects to a Part object. 

it's not an accident that the notation above looks a lot like jQuery. I felt that traversing part.cfg data was very similar to traversing the DOM in html. Cfg.js, much like jQuery, adds and deletes nodes as well as iterates over collections and change attributes.  Also, I'm making sure to keep it vanilla javascript, so you can use it's ability to read and modify cfg data for whatever your purposes might be. 

 

For CFGKit the program logic is handled by cfgKit.js and kit.js. Both files work together to handle the data binding and adjusting data views as well as importing and exporting cfg projects and saving a project's metadata as json. 

I know it won't be very exciting to some, but I feel that having an automation tool like this will help me make less mistakes that often happen when hand coding each cfg file. It may be interesting to some of you to know that modeling for me is the fastest and easiest part of creating a new part for Kerbodyne Plus. Importing into Unity comes in second, then texturing, then cfg editing last. Why? Because cfg's are very brittle. They are case sensitive and repetitive. I've struggled getting a part to load correctly for an entire week, just to find out I had an extra comma somewhere. 

Anyways, the hard parts are over now, I just have to craft a massive json file to serve as a module encyclopedia and finish the javascript ui scripting. Keep an eye out, 1.1 is coming soon!

 

EDIT: Made a ton of progress today! However, I underestimated the amount of digging I'd have to do in the c# assemblies to get at the data I needed, sigh. I drilled down in found everything I needed in spite of it being like finding a needle in a haystack. Since this is the first time I've ever poked around in the C# files, it was um, interesting (read really hard). Along the way I updated the wiki's entries for ModuleTestSubject. I have some other useful data to add (concerning the ModuleResourceScanner and ModuleScienceExperiment), but that will have to wait. I'm pooped.

I leave you good people with this, a massive list that this picture does not do justice (around 300 entries). This is all the cfg properties I could find.  There's a chance I might have missed some, but at least I can move on, without anything breaking.

Thats a lot of config and looks like a lot of work; I can't wait for Kerbodyne Plus 1.1

Btw is the XEMT, Data Server and NRAX converter gonna be in the next release?

EDIT:

How about these suggestions:

T404 deployable heatshield

XL parachutes

T404 battery bank

T202 crew module (more ISS style)

T404 cargo bay with two doors on top and bottom

T404 hollow docking port

T202 airlock

 

Edited February 15, 2016 by AJTheMighty
added suggestions for new parts

[Bonus Eventus]

 

Started whiteboarding for the new Behemoth system. I went back and forth with this a bit. In the end I decided to make it a modular system more in keeping with the stock game. The behemoth booster will now become a system similar to the falcon 9 modular system. The system parts will look like this:

 

• B-1 Engine
• Behemoth Cluster (9 B-1 Engines mounted to a size 6 Bulkhead)
• 30m LFO tank
• Decoupler (size 6 Bulkhead)
• XL Radial Decoupler

 

Edited February 20, 2016 by Bonus Eventus

[Bonus Eventus]

Here's a look at the new Behemoth Tank compared to the old version. I feel like the texture is close to giving the impression of scale I'm going for. This kind of texture is always a bit difficult to make. I try to keep my textures to 1024 at the largest ( who am I kidding. All these parts are huge!). So, to make a large part like this new tank (which is stretching the meaning of large, seeing as it's 30m high :0 ), the texture has to repeat. But, if the texture is too repetitive then believability is broken. I'm not suggesting that the texture has to look real. If the model is supposed to look toy-ish, than the user should believe that it's toy-ish, and not a bad attempt at a realistism that ended up looking toy-ish. It's a subtle but important difference that's fundamental to visual design. And it's darn hard to achieve at times, honestly. Anyways, for this new tank texture, I tried to be extra clever, by tactically splitting up the geometry so that uvs would repeat. That geometry was also mirrored or rotated in places to break up the repetitive patterns. Some repetition is ok though because steel welded tanks like these are made of modular steel panels which are similar and repeat. If you look closely at the first stage of the falcon 9, you can sometimes make out the seams where the panels meet under the paint. If I wanted to recreate that effect here I would just use normal maps. But, I've noticed performance his in KSP from using large normal maps, so I tend to avoid it. So far I think this choice has been a good one. I think the textures look more unified and cleaner because of it. 

Throughout the process of making Kerbodyne Plus, I've changed my approach multiple times as I learned more about this kind of stylization. Most of the model making I've done up to this point has been for extremely realistic applications. This is the first time I've really done anything approaching stylization in a 3d model. It was a bit of a learning curve coming from texture painting at 8k+ resolution, and near infinite polycounts. However, I've learned a lot through several experiments, and failed attempts. The style guide of Kerbodyne Plus is finally beginning to emerge. I think (hope) that style changes won't be happening as much any more, rendering these redesigns unnecessary. My rule of thumb is, if it's not right, it's not right, so change it. Which is why I'll completely abandon designs that seemingly have nothing wrong with them. If you stand back and take a look at that "cool" part, like the old NRAX converter for instance, within the context of all the other parts and the parts yet to be made you'll see the problems and inconsistencies.  In the case of the old NRAX converter, it was kind of plain looking for one, it had a large polycount at 10k+ but also it was a little to realistic and or complicated. When I placed other complex parts next to it, those complex parts started to look simple by comparison.  With my second attempt, NRAX v2, I had the opposite problem, I whent to simple. Also the T404 profile hadn't been invented yet. It makes sense to me that the NRAX should work like a module on the ISS.  

So, back to modeling now. I've got engines to make!

[Siphonophore]

On 2/20/2016 at 9:45 AM, Bonus Eventus said:

Here's a look at the new Behemoth Tank compared to the old version. I feel like the texture is close to giving the impression of scale I'm going for. This kind of texture is always a bit difficult to make. I try to keep my textures to 1024 at the largest ( who am I kidding. All these parts are huge!). So, to make a large part like this new tank (which is stretching the meaning of large, seeing as it's 30m high :0 ), the texture has to repeat. But, if the texture is too repetitive then believability is broken. I'm not suggesting that the texture has to look real. If the model is supposed to look toy-ish, than the user should believe that it's toy-ish, and not a bad attempt at a realistism that ended up looking toy-ish. It's a subtle but important difference that's fundamental to visual design. And it's darn hard to achieve at times, honestly. Anyways, for this new tank texture, I tried to be extra clever, by tactically splitting up the geometry so that uvs would repeat. That geometry was also mirrored or rotated in places to break up the repetitive patterns. Some repetition is ok though because steel welded tanks like these are made of modular steel panels which are similar and repeat. If you look closely at the first stage of the falcon 9, you can sometimes make out the seams where the panels meet under the paint. If I wanted to recreate that effect here I would just use normal maps. But, I've noticed performance his in KSP from using large normal maps, so I tend to avoid it. So far I think this choice has been a good one. I think the textures look more unified and cleaner because of it. 

Throughout the process of making Kerbodyne Plus, I've changed my approach multiple times as I learned more about this kind of stylization. Most of the model making I've done up to this point has been for extremely realistic applications. This is the first time I've really done anything approaching stylization in a 3d model. It was a bit of a learning curve coming from texture painting at 8k+ resolution, and near infinite polycounts. However, I've learned a lot through several experiments, and failed attempts. The style guide of Kerbodyne Plus is finally beginning to emerge. I think (hope) that style changes won't be happening as much any more, rendering these redesigns unnecessary. My rule of thumb is, if it's not right, it's not right, so change it. Which is why I'll completely abandon designs that seemingly have nothing wrong with them. If you stand back and take a look at that "cool" part, like the old NRAX converter for instance, within the context of all the other parts and the parts yet to be made you'll see the problems and inconsistencies.  In the case of the old NRAX converter, it was kind of plain looking for one, it had a large polycount at 10k+ but also it was a little to realistic and or complicated. When I placed other complex parts next to it, those complex parts started to look simple by comparison.  With my second attempt, NRAX v2, I had the opposite problem, I whent to simple. Also the T404 profile hadn't been invented yet. It makes sense to me that the NRAX should work like a module on the ISS.  

So, back to modeling now. I've got engines to make!

AMASING

Thought of making the Leviathan Solar Wing bigger? Like much, much taller, maybe 60m when unfurled?

[Bonus Eventus]

On 2/21/2016 at 1:47 PM, AJTheMighty said:

AMASING

Thought of making the Leviathan Solar Wing bigger? Like much, much taller, maybe 60m when unfurled?

Glad you like the idea. As far as the Leviathan Solar Wing being bigger, I have no plans to do that. Isn't it big enough?

 

 

Almost finished with the engine cluster. Will start texturing it soon.

EDIT: After listening to several Iggy Pop albums this is where I got with the texture.

Edited February 24, 2016 by Bonus Eventus

[Bonus Eventus]

 

Still balancing isp and tweaking the particle effects. Right now the thrust at sea level is 26000 kn. Trying to work out an annoying bug where the engines stick to the launch pad. I think it may have something to do with my collider setup. Anyways, look forward to the next dev build (most likely tomorrow some time);.

[Siphonophore]

10 hours ago, Bonus Eventus said:

 

Still balancing isp and tweaking the particle effects. Right now the thrust at sea level is 26000 kn. Trying to work out an annoying bug where the engines stick to the launch pad. I think it may have something to do with my collider setup. Anyways, look forward to the next dev build (most likely tomorrow some time);.

It's so big...

Can't wait for the next dev release, I hope it'll have the NRAX converter.

Also, could you show a WIP of the new XEMT engine model?

[Bonus Eventus]

Just now, AJTheMighty said:

It's so big...

Can't wait for the next dev release, I hope it'll have the NRAX converter.

Also, could you show a WIP of the new XEMT engine model?

sorry bud, I haven't made it yet  

[davidy12]

On February 4, 2016 at 10:38 PM, AJTheMighty said:

Naw, I meant a tutorial on how to program like how you did it almost from scratch

Also, how's the foldable centrifuge coming along? By centrifuge, I mean this; http://imgur.com/gallery/tbUIPCL

You've been working on it, haven't you?

I vote for THE CENTRIFUGE!!!!

[Siphonophore]

1 hour ago, davidy12 said:

I vote for THE CENTRIFUGE!!!!

MAKE IT HAPPEN @Bonus Eventus

[Bonus Eventus]

2 hours ago, davidy12 said:

I vote for THE CENTRIFUGE!!!!

 

57 minutes ago, AJTheMighty said:

MAKE IT HAPPEN @Bonus Eventus

Haha, you dudes are persistent. I still haven't been given a good reason to do that though  Yes, AJ has been very vocal about the fact that AJ would like a centrifuge, however why? The habitat pack has exactly what you're looking for. So does the Hermes pack. Convince me. I'm open minded about it, but give me a logical reason.

[davidy12]

4 minutes ago, Bonus Eventus said:

 

Haha, you dudes are persistent. I still haven't been given a good reason to do that though  Yes, AJ has been very vocal about the fact that AJ would like a centrifuge, however why? The habitat pack has exactly what you're looking for. So does the Hermes pack. Convince me. I'm open minded about it, but give me a logical reason.

First of all, its taking forever for porkjet to release it (new version). Second, on flights to Jool, my kerbals will feel weak. Third, the Porkjet one is small. Also, all Centrifuges that are reasonable have no IVAs. ESSENTIAL for immersive experience. Maybe you could work with @Badsector's designs to create a larger and one with IVAs. ( @Badsector: Your centrifuge is awesome)

[Siphonophore]

8 minutes ago, davidy12 said:

First of all, its taking forever for porkjet to release it (new version). Second, on flights to Jool, my kerbals will feel weak. Third, the Porkjet one is small. Also, all Centrifuges that are reasonable have no IVAs. ESSENTIAL for immersive experience. Maybe you could work with @Badsector's designs to create a larger and one with IVAs. ( @Badsector: Your centrifuge is awesome)

@davidy12 

I already sketched an IVA for the centrifuge's two sections in the concept; but it does not have windows.

 @Bonus Eventus when you're working with the centrifuge, try and think of the Hermes' centrifuge, but without windows; it's hard to make the ship rotate in IVA behind you w/ windows...

 

[Bonus Eventus]

On 12/17/2015 at 3:55 PM, Bonus Eventus said:

So, as for these suggestions (and for anyone who might give part suggestions in the future), I always appreciate feedback, but I have to balance those suggestions against the other 2000 or so users of this mod.
To that end there's a few basic things I'm looking for: 

1. A good argument for why the part should be added (ex, it would allow designs that make for better gameplay experiences).
2. There isn't another mod that has made it (and made it awesome!)
3. The idea behind the part adds to the enjoyment of the other users of this mod as a whole, rather than the needs of a specific individual.
4. It's in keeping with the spirit of the mod in general (aesthetically and gameplay-wise).

 

Inflatable centrifuge - I think MKS already has this. I know some of the other TAC and Life Support mods do. (See point #2 above)

 

17 minutes ago, davidy12 said:

First of all, its taking forever for porkjet to release it (new version). Second, on flights to Jool, my kerbals will feel weak. Third, the Porkjet one is small. Also, all Centrifuges that are reasonable have no IVAs. ESSENTIAL for immersive experience. Maybe you could work with @Badsector's designs to create a larger and one with IVAs. ( @Badsector: Your centrifuge is awesome)

Those are decent points, but the concerns I have are that: 

1. I'd have to use the firespitter plugin which isn't supported by the original mod author (as far as i'm aware) 
2. Those mods you mentioned are planning on finishing the IVAs, and it's not like I'd get it done any faster
3. There's no artificial gravity in the stock game and I don't plan to support TAC or other life support mods directly. How does something spinning add to gameplay? The work it would require to make this is non-trivial. IVA's are hard. Plugin writing is hard. So, for me to want to do it, there has to be a large enough benefit to the users and for myself to allocate resources to creating it in the first place.

 

1 minute ago, AJTheMighty said:

@davidy12 

I already sketched an IVA for the centrifuge's two sections in the concept; but it does not have windows.

 @Bonus Eventus when you're working with the centrifuge, try and think of the Hermes' centrifuge, but without windows; it's hard to make the ship rotate in IVA behind you w/ windows...

 

Hey AJ, when did I agree to make a centrifuge.

[davidy12]

Just now, Bonus Eventus said:

 

Those are decent points, but the concerns I have are that: 

1. I'd have to use the firespitter plugin which isn't supported by the original mod author (as far as i'm aware) 
2. Those mods you mentioned are planning on finishing the IVAs, and it's not like I'd get it done any faster

 

Hey AJ, when did I agree to make a centrifuge.

No, @Badsector may take a while, and he doesn't use firespitter

[Bonus Eventus]

4 minutes ago, davidy12 said:

No, @Badsector may take a while, and he doesn't use firespitter

Well, there's no way to do that in the stock game, so regardless, I'd have to use firespitter or make my own plugin as @Badsector presumably did. I imagine, considering I've done zero plugin authoring, he'd get it done faster. Make sense?

Edited February 28, 2016 by Bonus Eventus
spelling :(

[Badsector]

1 hour ago, Bonus Eventus said:

Well, there's no way to do that in the stock game, so regardless, I'd have to use firespitter or make my own plugin as @Badsector presumably did. I imagine, considering I've done zero plugin authoring, he'd get it done faster. Make sense?

Is not need use firespitter plugin, you can do that with ModuleAnimateGeneric you have only to add the layer of animation

first animation

	name = ModuleAnimateGeneric
	layer = 0

second animation

	name = ModuleAnimateGeneric
	layer = 1

 

[Bonus Eventus]

Kerbodyne Plus Dev 1.06 - 02/27/2016

If you want a release candidate check for stable releases here link

This is not a release candidate. It will break future saves!

Notes:

• Replaced the Behemoth booster with the Behemoth Launch System (size 6 9x engine cluster with custom particle and sound effects).
• Added new part S6 B-1x9 "Behemoth" Liquid Fuel Engine.
• Added new part Kerbodyne ADTP-3-6 (adapter fuel tank).
• Added new part Kerbodyne S6-94640 Tank (giant size 6 30m tank).
• Added new part K404 E-2 Radial LFO Fuel Tank.
• Added new part Kerbodyne PFR-6 Stack Decoupler.

Downloads

Source code (zip)
Source code (tar.gz)

[Bonus Eventus]

4 hours ago, Badsector said:

Is not need use firespitter plugin, you can do that with ModuleAnimateGeneric you have only to add the layer of animation

first animation

	name = ModuleAnimateGeneric
	layer = 0

second animation

	name = ModuleAnimateGeneric
	layer = 1

 

I had no idea that ModuleAnimateGeneric had been updated in 1.05, that's so awesome! My life just got a whole lot easier

As to the whole centrifuge discussion, I feel I should at least concede that a centrifuge is a practical, necessary technology for interplanetary space travel, and is something we could even build today. So, I can see how a mod like mine, that claims to be for end-game parts and focuses on near future technology (as well as large scale design) would seemingly be a good fit for a centrifuge system. However, the only reason why NASA and other space related organizations need or want a centrifuge is for human health concerns as well as ease of mobility while in space. However, KSP does not have mechanisms which degrade skeletons over time or ways for Kerbals to even move in IVA. It makes more sense for life support mods to address this or incorporate them.

My position from the start has been to be mod agnostic. I don't want to support mods, it's too much work and it can cause installation conflicts. B9 for example, had like 4 or 5 dependencies which often broke whenever KSP was updated. As a user that's annoying. As a mod maker it's also annoying to have to wait on other mods to update. Adding a centrifuge would be setting a weird precedence where people might wrongfully expect that KP is a life support mod. It's not. I expect I'd get a lot of people nagging me to make KP TAC compatible. I can just imagine people asking for greenhouses  

Also, plugin development is something I'm trying actively to avoid, so in the case of a centrifuge with a spinning IVA, I'm suspicious as to whether or not that could ever be done stock. As I understand it, the internal space for @Badsector 's centrifuge are located in the center column and not in the spinning hub portion. I would think it would be the hardest part about making a centrifuge, so it's no surprise to me that he hasn't finished yet. However I don't know this for a fact so maybe @Badsector can enlighten me. 

I honestly don't see anyway around these issues. I envision that other mods will make parts that fill these gaps in gameplay, and then users pick and choose what mods they want to depend on for that gameplay. The responsible thing to do as a mod maker, I feel, is to facilitate that so as to not make it hard for other mods to be installed with theirs and not force dependencies on users. Kerbodyne Plus is focused on station parts and motherships.

I do appreciate the feedback though peeps! I'm glad you guys care about and support KP