codepoet
-
Posts
720 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by codepoet
-
-
Thanks for keeping this alive LGG.
As often happens, my life has moved on so I am not able to maintain it, but it is great to see that this mod has been able to move on in its life too.
-
Just a quick note to thank Micha for getting involved with maintaining CLS. I am really pleased to hear people are still interested in it. Micha has my blessing to take it on, and I am happy to be answer any questions if that would be helpful (not likely!).
I have added Micha as a collaborator to the original Github project. Let me know if there is anything else that would help.
Blessing all - CP
-
An ignorant question, I am sure, but why does each launch provider need to have their own spacesuit? By a Beoing suit and a spacex suit and a NASA suit? Can't they just use what is already on the shelf?
-
5 hours ago, Papa_Joe said:
I'm battling two things, the changes made in 1.2 that broke some very old legacy code, and my lack of knowledge on the parts/modules front. I'm learning both, and this is what allowed me to create the module that codepoet was building in code using prefabs into a proper module manager config. It is now properly appearing and persisting in the craft file. Now I just need to clean up the massive quantities of work around code and move it to proper event handlers. This will get rid of the fixedupdate call he was making to keep the modules synced with each other (ModuleDockingNode and his construct ModuleDockingHatch). I think it will be much less complex than it was, so just need to strip out the old and build in the new. If you don't mind, if I have questions related to how parts and module behave I'll ping you via pm. That will save me a lot of digging and learning the hard way
)
Bloody well done.
I remember looking at a module manager approach to the adding the hatches problem, but for some reason was unable to make it work. If you have got it all figured then I expect you will end up with a far more elegant solution,
It is great that you have stuck with it - it would have been a shame if CLS ended up having to be abandoned. Thanks.
-
-
On 24/11/2016 at 3:53 AM, Papa_Joe said:
Still working the issue.
Me thinks I can completely replace the ModuleDockingHatch with extensions to the existing ModuleDockingNode (stock) using Module Manager. Since they are related on a one for one basis, it makes sense to simply fold the hatch functionality into the docking node itself. I'm teaching myself about that as we speak. of course, doing so will break SM and any other mods (are there any?) that use the hatch functionality of CLS. Thinking that one over...
Still at it.
A the time I tried doing it about 3 different ways, until I settled on whatever it was (I can't remember).It was really frustrating as each different approach had an accompanying hard to solve problem related to it. Grrrrr.
I do nit think that the original thread will help to recreate the history much as I think the only post was me saying stuff like "Arrrgghh, I am pulled it all apart and can't make it fit back together again."!!
Good luck.
-
14 hours ago, Papa_Joe said:
I am in fact in the code for CLS now. late changes to KSP 1.2 (like the very last PR build), broke CLS bad. So, I'm trying to refactor the "magic" that was used for so long that no longer works. Maybe a MM config will do it, but not sure. CodePoet was working with Prefabs in the editor and in flight. he was actually modifying these things every fixed update. All this to support hatches.
Stay tooned. I had some RL things interfering with my mod work, but I am working it actively now.
I remember that bit of code was a real pain to get working. If the base game has changed in that area I can be certain that PapaJoe is having to some very heroic work to get it working again!
-
I remember to issue of orientation in SPH when I wrote it originally. It is just the way thing are in the SPH. It must be the way that Jeb set about making rockets go up and planes go sideways.
-
8 hours ago, eddiew said:
I'm sorry, this mod seems to be the cause of a major z-buffer issue causing EVA'd kerbals to render on top of everything else...
Goes away without PWBFB. Returns with. Not sure how to help debug this, but ask me questions and I will try my best to answer
This is not a surprise. PWB-FB does a bunch of funky stuff to do with z-buffers and cameras in order to be able to render the CoM indicator on top of everything else. I believe there are some hard coded z layer numbers in the code based on what else was being used in the game at the time I wrote it. If that has changed then we might need to use a different layer.
However I have not seen the code for over a year so I can;t remember the details.
-
Can a mod please lock this thread now.
-
Thanks so much for putting your time into this Joe. You have been very good to me, and have done a great job keeping mods alive. You have my blessing to take this forward.
-
So I am wondering if second stages get test fired in Texas the same way that the first stages do before they are shipped to the launch site. Much better to have a single f9s2 go pop that loose the whole stack.
-
39 minutes ago, CptRichardson said:
Not really, no. This was an explosion in the PAD, not the launcher. This wasn't a launch failure.
Failure still occurred somewhere in the whole launch system, regardless if it was booster or second stage or pad or operational procedures. If the satellite had been on top of an ariane5 would it have been lost?
Of course the failure could have been caused by the payload, in which case it is not spacex's problem, but at this stage we just do not know.
-
Bottom line is - F9 success stats now suck big time.
-
As with other mods that I wrote, I am not in a position to do justice to PWBfuelbalancer. If anyone else would like to take it on or work it into something else, I would be grateful. Send me a PM.
-
So sorry folks. I promised to get this working, but did nothing.
I have not played kerbal for over a year now. Can someone tell me - does pwbfueldbalancer still work with whatever the latest version of KSP is? Also is there still a demand of need for this mod?
-
2 hours ago, Papa_Joe said:
New Version released:
release v 1.2.3.0
* New: Added support for intercepting Parts selection list during stock Transfer target part selection. A part not in the same space will be unselectable and is highlighted orange like full parts.
* New: Added support for overriding the "Allow unrestricted Crew Transfers"in CLSInterfaces.dll setting via other Mods to prevent "competition" between mods when handling stock crew transfers.
* New: Updated config for Docking Port Jr. Squad now says that a kerbal can squeeze thru.
* New: Refactored code to improve performance, recuce garbage collection, & use Explicit typing.
* Fixed: CLS windows now properly close when changing scenes.
* Fixed: In the Editor, part highlighting does not work correctly when adding new crewable parts.Enjoy.
Good stuff, I am really impressed with these improvements.
Just a shame I never get time to play the game anymore
-
29 minutes ago, Trolllception said:
I've got a question with modifying saves to allow connected living space to recognize a space station as a single connected area. I have been able to modify the nodes for all the parts except the grapple node which was used to connect a USI ball hub to an expandable tube. The connection is linked via a grapple node. Is it possible to allow kerbals to pass through a grapple node into the adjacent structure? This mod really adds another level of excitement to my gameplay. Awesome work!!
I do not know the answer to your question for certain. However I imagine that it has to do the with surface attachment rules. I would have thought that the grapple part has a surface attachment to whatever it has grabbed, and therefore config needs to be set for those part specifically (both the grapple part AND the part it has grappled).
Read the CLS wiki (link in @papa_joe's signature) and pay close attention to the surfaceattachment config options.
-
9 hours ago, Elthy said:
Its clear to see that the charing/soot comes from the reentry-heat, not the entry-burn. That will be an issue with the MCT, since they cant avoid it by using methane. Now they should get us the 4k version from the onboard storage!
If it is caused by re-entry heat then it is not a problem of deposits, as there is nothing to deposit, so they just need to use materials that can withstand the heat.
-
12 hours ago, Nyia said:
I'm having an issue with the BZ-52 Radial Attachment Point. The entirety of my craft is passable in-line, but when I surface attach the BZ-52, which says is also passable, the cupola I attach to it branches off a separate living space, inaccessible from the main body of the craft.
I checked the config code and everything looks right. I even added a surface attach parts passable line just in case, but that didn't work either.
Is there a way to surface attach an extension to the living space?
Thanks in advance!
The part that the BZ-52 is on the side of needs to be configured to allow parts attached to the side of it to be passable. But default they are not. Consider if it is reasonable for Jeb to just hack a hole in the side of a module - for many parts this might not make sense.
If the part that the BZ-52 has "Surface Attached Parts Pass: No" then that is the reason. You can take it up with the author of that part, or just provide you own config to change it. I think there is also a way of changing this in the editor for that part, but I have not played the game for so long now that I am not sure exactly how Papa-Joe made this work.
-
7 hours ago, wumpus said:
A single engine can't be reduced such that TWR<1.0 and they were using at least three times that (three engine burn). It most certainly was a kerbalesque suicide burn, much more than usual (unless you are comparing to only Jeb at the controls. Jeb would have all nine lit at 100%).
I have to wonder how accurate the timing is in cutting the engines. It has to be good enough to cut out just before landing, so presumably you could cut out the side engines just before landing and land on the center engine (without imparting too much torque). I suspect they already checked that and the torque is too high: even a few degrees off would make it easy to miss the barge. Still, cutting two of the engines with a second or two left on the center should make the timing a lot easier.
Another question about the re-entry I had (and probably can only be answered directly from spacex) is the vector of the entry burn. They had a (short) entry burn, it turned on then off. From the numbers given by the announcers, it was roughly ~300 m/s (2.3km/s on screen when MECO was called, announcers claimed 2km/s re-entry speed). I'd be curious if the re-entry burn wasn't quite vertical and the goal was to add *more* horizontal speed. In KSP, low level re-entry is all about having enough atmosphere to slow you down, but KSP has its 1/10th scale planet and other silliness. But maybe letting the vertical speed get cut by making it deal with a higher square velocity in the hypotenuse might carry over into real life.
Here:
Musk confirms that they did indeed cut two of the engines at then end of the landing burn and land on one. Also that the engines can now throttle down to 40%.
So if 40% of one engine is imparting >9.8m/s2 then three at full belt would be capable of giving at least 73.5m/s2. That could really take the edge off your velocity in a hurry.
-
From the chatter on the technical broadcast we can approximate:
Stage 1 is trans-sonic 7:41 (does this mean dropping below Mach 1 due to drag?
Land burn starts: 8:26
Legs deploy: 8:34
Engine cutoff: 8:40 (based on the images, not sound, but image and sound is out of sync as can be seen by the fairing deploy being called before it happens)So that gives a maximum landing burn time of approx 14 seconds, perhaps a bit less (10 seconds?) due to a delay in the pictures compared with the chatter. If it can't hover on one engine, then a single engine is giving it more than 9.8m/s2 so three engines must be giving it more than 29.4m/s2. However, it is subject to acceleration due to gravity, so it is certainly getting more than 19.6m/s2. For ten seconds the landing burn is taking at least 196m/s off the velocity, probably much more, I guess those figures are all in the right ball park.
Is there any other more accurate source of data for the first stage during landing?
Looking at the CRS8 technical yields:
Trans-sonic - 8:00
Landing burn - 8;07
legs - 8:34
MECO - 8:40So for CRS8 that is a landing burn for 33s (29s accounting for a four second picture delay) which is three times the duration of the JCSAT14 3 engine landing burn which is exactly what we would have expected.
I can't explain why the later&harder landing burn results in a longer time from trans-sonic to MECO - you would expect it to be less. Could it be because the JCSAT14 mission has it coming in with more horizontal velocity? I am not sure that makes any sense.
-
56 minutes ago, sevenperforce said:
Which they were.
The one-engine landing burn was 90 seconds; this landing burn was 30 seconds. Assuming the same terminal velocity (which is close to accurate), that's just under 600 m/s of gravity drag saved.
I picked up from here that is was a 6 second landing burn - which would be extraordinary. Is that a typo?
-
11 hours ago, Rakaydos said:
I'm pretty sure you dont have the right crane to do that, in your yard, though.
Crane?
I understood it to be an offer to have the stage land directly in the yard.
I did not realise that this was a landing burn using 3 engine rather than one. Awesome timing on the suicide burn considering how much G that much have been pulling, to get the whole 0 velocity at 0 altitude thing. For me that is the most impressive part of the whole thing.
)
[1.11] Connected Living Spaces (Adopted) 2.0.0.6 (2020-12-29)
in KSP1 Mod Releases
Posted · Edited by codepoet
Yay. Lovely to see old friends!
I just dropped by seeking a moment out of real life. Great to see people still (trying!) to use Connected Living Space, and really thrilled to see that it being used with feature rich mods like Kerbal Health,
I have read the discussion about conflicts with CLSInterfaces.dll with interest. I am sure things have moved on, and I can not remember much from when it was originally introduced, but the purpose of having a separate interfaces dll was to remove some of these sorts or problems by making the interface definition rigid and allowing the implementation and callers to change. It sounds like something has changed in KSP to make life harder for everyone, but it is great to see you all trying to find the best solution. Thanks everyone.