[1.3.1, 1.4, 1.5, 1.6, 1.7] Procedural Parts - Tidal Stream Branch

[whale_2]

3 minutes ago, steddyj said:

Yup, this appears to work when resizing.  The misplaced node issue on reload is still there in 1.7.2, but again that existed before you did anything.  I did notice that it did change the behavior of that issue slightly, however.  Previously when you reloaded the craft and the nodes were shifted, both went to the same side of the part.  With your latest update they go to opposite ends.  Likely nothing, but curious.

Can you share the .craft file that has misplaces nodes on reloading? Want to replicate this as well.

[steddyj]

Just now, whale_2 said:

Can you share the .craft file that has misplaces nodes on reloading? Want to replicate this as well.

Honestly the bug is so prolific that it would take longer to create and upload a craft file than to just type out the replication steps.

Launch game in 1.7.1+.  Open Sandbox, VAB.  Select HECS as root probe.  Add procedural liquid tank.  Adjust length (diam does not always cause the issue).  Exit VAB, save changes.  Open VAB.  Lift procedural tank off probe core, note the misposition of nodes, and how it will only seem to surface attach now.

There may or may not be a visible gap when the craft reloads.  Sometimes it seems the node is placed outside of the part's mesh, but most often (at least when following the above) it was shooting the nodes out to the edge of the top/bottom faces.  If you have Node Helper installed on your game (https://github.com/linuxgurugamer/NodeHelper) you can look at the nodes and see the reason that you can't connect to them is that they've rotated their orientation as well as shifting to the edge of the part.  They point towards the center of the face, so it surface attaches before you can connect to another node.  

[whale_2]

1 hour ago, steddyj said:

Honestly the bug is so prolific that it would take longer to create and upload a craft file than to just type out the replication steps.

...

Ok, see now. It will take some time...

[AG-cs]

On 7/12/2019 at 11:38 PM, Nightside said:

Those look great!

Thank you! The full package, which contains more than 50 textures, is about to be completed and ready to be released. Endings and TAC, Electronic Components. Rather, he is approaching such easy art sci-fis themes.
 

Edited June 12, 2020 by AG-cs

[Emirhan]

I have the bug that makes nodes go crazy as you guys mentioned earlier but I have another weird bug that makes the game literally unplayable. Changing the texture and type of the fuel tanks works fine and cause no problems at all but whenever I resize a fuel tank in my vessel by any means (diameter, lenght and making it conical etc.), it causes massive amounts of aerodynamic drag that i can't make any of my logically realistic vessels go faster than 250 m/s. It either explodes because of the g-force or simply cant make into space. I tried this with a solid booster and when separated it from the main vessel, it didn't crash landed, instead it slowly fell to the ground at 20 m/s and survived without any parachutes or extra equipment. I don't know if this bug is known but it's worth noting.

Edit: I think the problem is caused by Procedural Parts mod because this occurred (maybe i spotted it late) when i downloaded this mod. But I will ask about this problem on the forum anyway. Maybe there is something else behind this. 

Edited July 19, 2019 by Emirhan

[vossiewulf]

6 hours ago, Emirhan said:

I have the bug that makes nodes go crazy as you guys mentioned earlier but I have another weird bug that makes the game literally unplayable. Changing the texture and type of the fuel tanks works fine and cause no problems at all but whenever I resize a fuel tank in my vessel by any means (diameter, lenght and making it conical etc.), it causes massive amounts of aerodynamic drag that i can't make any of my logically realistic vessels go faster than 250 m/s. It either explodes because of the g-force or simply cant make into space. I tried this with a solid booster and when separated it from the main vessel, it didn't crash landed, instead it slowly fell to the ground at 20 m/s and survived without any parachutes or extra equipment. I don't know if this bug is known but it's worth noting.

Edit: I think the problem is caused by Procedural Parts mod because this occurred (maybe i spotted it late) when i downloaded this mod. But I will ask about this problem on the forum anyway. Maybe there is something else behind this. 

I've never seen that, and I use PP with lots of mods, like 200. That sounds more like something is conflicting with PP, you should look in the ksp.log to see what is happening.

[TheBeesSteeze]

On 7/13/2019 at 8:26 AM, whale_2 said:

Ok, see now. It will take some time...

On 7/13/2019 at 7:24 AM, steddyj said:

Honestly the bug is so prolific that it would take longer to create and upload a craft file than to just type out the replication steps.

Launch game in 1.7.1+.  Open Sandbox, VAB.  Select HECS as root probe.  Add procedural liquid tank.  Adjust length (diam does not always cause the issue).  Exit VAB, save changes.  Open VAB.  Lift procedural tank off probe core, note the misposition of nodes, and how it will only seem to surface attach now.

There may or may not be a visible gap when the craft reloads.  Sometimes it seems the node is placed outside of the part's mesh, but most often (at least when following the above) it was shooting the nodes out to the edge of the top/bottom faces.  If you have Node Helper installed on your game (https://github.com/linuxgurugamer/NodeHelper) you can look at the nodes and see the reason that you can't connect to them is that they've rotated their orientation as well as shifting to the edge of the part.  They point towards the center of the face, so it surface attaches before you can connect to another node.  

I'm just going to put a +1 on wanting to see this fixed and I'm happy to help in any way I can. I have the same bug. I can't reliably load any spacecraft to edit with procedural parts on it, so I just finding myself never using procedural parts, which is sad because I really like the mod otherwise.

[Crixomix]

I'm having some issues, wondering if anyone can help.

I just installed a fresh install of KSP, with a garden variety of mods. If I change the tank type a few types, I get this going on https://imgur.com/a/IIvihrI

 

[steddyj]

On 7/27/2019 at 12:56 PM, Crixomix said:

I'm having some issues, wondering if anyone can help.

I just installed a fresh install of KSP, with a garden variety of mods. If I change the tank type a few types, I get this going on https://imgur.com/a/IIvihrI

 

Rightclick somewhere out of the display to close the menu, then open it again.  You should find just the last tank set on it.  This is not an issue with PP as far as I can tell, it's a graphical glitch with the tank switch module.  It updates the menu with the new tank set but doesn't clear off the old one.  

[Crixomix]

20 hours ago, steddyj said:

Rightclick somewhere out of the display to close the menu, then open it again.  You should find just the last tank set on it.  This is not an issue with PP as far as I can tell, it's a graphical glitch with the tank switch module.  It updates the menu with the new tank set but doesn't clear off the old one.  

Thanks. However, I've discovered I can't use procedural parts until the node craziness is fixed.

[ozraven]

I have some good news and some bad news.

Good news: Below is a link to an updated ProceduralParts.dll compiled for 1.7.3 with the node issue "fixed" and resource duplication on the action menu fixed.

Bad news: The "fix" for the node issue is a hack because I can't explain why it works. Comparing a resized and a non-resized tank craft loading, it comes down to the resized tank failing some sort of bounds check and the non-resized tank passing the check. I removed this check and it works - but I am afraid there may be unintended side affects of this change because the logic was there for a reason.

So, back to the good news: In testing, I've found this seems to work.  Multiple tanks, resized, reshaped, etc. all load fine in the editor and on the pad. Node attachments, surface attachments - it all seems to work as expected. (You may need to fix some older .craft files by restacking parts connected to procedural tanks if they initially load incorrectly. It seems in some cases the node problem would be saved incorrectly and now loads incorrectly. Restack, save, load and it should now be corrected.) So, I wanted to let everyone try it out and see what problems could be found.

If you have problems, please make your .craft file available (PM me if needed) and describe what you expected vs. the actual result.

Procedural Parts Community Patch 2 for KSP 1.7.3 - Unzip to GameData, this just includes the new ProceduralParts.dll so you need the latest Procedural Parts release installed as normal, first.

Procedural Parts Community Patch 2 for KSP 1.7.3 Source Diff - For anyone who wants to continue this effort or just see the changes I made, apply this patch to your working copy.

I'm hesitant to make a pull request for this change since it is a definite hack, but if requested, I will do so as-is.

 

NOTE: This is an unofficial release, please do not contact @Tidal Stream for support. I make no claim to the Procedural Parts mod and all changes are released under the mod's original license terms.

UPDATE: Please see this post for more details on a newer patch.

Edited July 31, 2019 by ozraven
Updated links to latest patch.

[steddyj]

15 minutes ago, ozraven said:

Bad news: The "fix" for the node issue is a hack because I can't explain why it works. Comparing a resized and a non-resized tank craft loading, it comes down to the resized tank failing some sort of bounds check and the non-resized tank passing the check. I removed this check and it works - but I am afraid there may be unintended side affects of this change because the logic was there for a reason.

Yeah.... I looked at your diff file and... yes.  This is a hack. I mean this with no disrespect, just a caution to anyone who may not be willing or able to look at the diff file to see what you did.  For the layman, there's a seatbelt in the Procedural Parts car that was getting stuck.  So Ozraven took it out.  100% guarantee of no problem.  (100% guarantee is void if vehicle is involved in an accident.)  In fairness this is exactly what he said he did, but I'm fond of colorful metaphors that people seem to find relatable.  Also in fairness, this seatbelt may do nothing more than keep your big gulp firmly in the cupholder, I don't know.

To get a bit more nerdy about the issue

if (Mathf.Abs(Mathf.Abs(position.y) - 0.5f) < 1e-5f)

So my C# is very rusty and I haven't done any Unity programming at all. If I'm reading this correctly : We're working on an attachment node (if I understand correctly what an Attachment object is) This returns true of the Absolute value of (The absolute value of ( attachment node's position on the y axis) - .5 ) is less than .00005).  the only way for this to return true is if position.y = [+/-.49995-.50005]. This jives with the preceding comment, "This is easy, just get the UV and location correctly and force an update. as the position might be after some rotation and translation, it might not be exactly +/- 0.5" So the math is just to give some wiggle room, we're looking to see if the y offset of the attachment node is pretty close to .5 or -.5.  I just don't understand why this position needs to be close to +/-.5.  It looks like if the condition is true it positions the node to the top or bottom, otherwise it's attached to the side. 

I *think* the intention here is to sort between a node on the top/bottom versus a node on the side of a part.  However, I don't know of any procedural parts that have side nodes, nor do I understand why this breaks after 1.7.0.  Were nodes changed in 1.7.1?  Why is this looking at the y offset of the node, and then adjusting the X and Z offsets by .5?  When and why is AddAttachmentNormalized called?

 

[ozraven]

28 minutes ago, steddyj said:

Yeah.... I looked at your diff file and... yes.  This is a hack. I mean this with no disrespect, just a caution to anyone who may not be willing or able to look at the diff file to see what you did.

No worries, it's a hack through and through.

29 minutes ago, steddyj said:

To get a bit more nerdy about the issue

if (Mathf.Abs(Mathf.Abs(position.y) - 0.5f) < 1e-5f)

So my C# is very rusty and I haven't done any Unity programming at all. If I'm reading this correctly : We're working on an attachment node (if I understand correctly what an Attachment object is) This returns true of the Absolute value of (The absolute value of ( attachment node's position on the y axis) - .5 ) is less than .00005).  the only way for this to return true is if position.y = [+/-.49995-.50005]. This jives with the preceding comment, "This is easy, just get the UV and location correctly and force an update. as the position might be after some rotation and translation, it might not be exactly +/- 0.5" So the math is just to give some wiggle room, we're looking to see if the y offset of the attachment node is pretty close to .5 or -.5.  I just don't understand why this position needs to be close to +/-.5.  It looks like if the condition is true it positions the node to the top or bottom, otherwise it's attached to the side. 

I think the tolerance is included to account for possible rounding issues when (if) any rot/trans calculations are needed. But, this check passes if the part isn't resized and fails in pretty much every other case. I couldn't come up with reasoning for fudging the math to make it work, so removing it entirely seemed like the least bad way.

33 minutes ago, steddyj said:

I *think* the intention here is to sort between a node on the top/bottom versus a node on the side of a part.  However, I don't know of any procedural parts that have side nodes, nor do I understand why this breaks after 1.7.0.  Were nodes changed in 1.7.1?  Why is this looking at the y offset of the node, and then adjusting the X and Z offsets by .5?  When and why is AddAttachmentNormalized called?

Hmm, maybe it is there in case someone defines a procedural part that does have side nodes. Interesting thought. And your questions are much like mine, and I haven't yet had the time to wrap my head around the larger picture of the process. I'm hoping yours and others observations of this area of code will lead us all to a satisfactory fix.

So, everyone, this is experimental and you should definitely only use this with test saves and test files. Keep backups. Moar struts. Fly safe. Wear seat belts at all times.

[Bloodbunny]

Hack solution or no, thanks for taking the time to look into this. You've saved a 'must have' mod for the time being.

[ozraven]

Issue: When switching procedural tank shape the action menu loses the Procedural Parts tweakables.

Workaround: Saving and reloading the craft restores the menu and the part has the selected shape.

I will try to fix this problem in the next few hours and post a new build.

[vossiewulf]

1 hour ago, ozraven said:

I will try to fix this problem in the next few hours and post a new build.

I will definitely download this once you guys think you have something fully stable and working, this has been a major headache for me also as I frequently use PP. Very much appreciate the time you and others have spent looking into a fix.

[ozraven]

I believe the fix to the shape change issue is another hack - this time I just don't have time right now to look further in to the problem, but after some testing, I don't see any adverse effects of the change. Please find the latest patch below, and for those interested, the diff files with the changes I've made. As before, this is an experimental patch for the community. Please use test files and make backups. Do not report issues to @Tidal Stream. These changes are donated to the community and released under the same license as Procedural Parts. See this post for more information on this series of hackery fixes.

Procedural Parts Community Patch 2 for KSP 1.7.3 - Unzip to GameData, this just includes the new ProceduralParts.dll so you need the latest Procedural Parts release installed as normal, first.

Procedural Parts Community Patch 2 for KSP 1.7.3 Source Diff - For anyone who wants to continue this effort or just see the changes I made, apply this patch to your working copy.

Edited July 31, 2019 by ozraven

[Tyko]

On 7/30/2019 at 8:55 PM, ozraven said:

I believe the fix to the shape change issue is another hack - this time I just don't have time right now to look further in to the problem, but after some testing, I don't see any adverse effects of the change. Please find the latest patch below, and for those interested, the diff files with the changes I've made. As before, this is an experimental patch for the community. Please use test files and make backups. Do not report issues to @Tidal Stream. These changes are donated to the community and released under the same license as Procedural Parts. See this post for more information on this series of hackery fixes.

Procedural Parts Community Patch 2 for KSP 1.7.3 - Unzip to GameData, this just includes the new ProceduralParts.dll so you need the latest Procedural Parts release installed as normal, first.

Procedural Parts Community Patch 2 for KSP 1.7.3 Source Diff - For anyone who wants to continue this effort or just see the changes I made, apply this patch to your working copy.

Thanks for doing this work! Just a question....When @Tidal Stream gets around to a permanent fix would you expect your patch to break any in flight craft? I know it's never a 100% sure thing, just trying to decide if I should proceed with your patch or just wait.

thanks again

[ozraven]

4 hours ago, Tyko said:

Thanks for doing this work! Just a question....When @Tidal Stream gets around to a permanent fix would you expect your patch to break any in flight craft? I know it's never a 100% sure thing, just trying to decide if I should proceed with your patch or just wait.

thanks again

I am using these changes with my career save, which I started with KSP 1.7.0 when Procedural Parts was working normal. The vessels in flight have all loaded normally for me, so I think it should be fine. However, I keep backups from each play session and am completely comfortable repairing my save files if needed. Your mileage may vary, but know that I have not found any breaking issues so far. I don't think a permanent fix will cause any issues either. One of the things I reviewed was to make sure the data in the save file was correct and made sense. The changes I have made don't change how the data is stored and loaded. I feel confident that although my changes are likely a temporary solution, any crafts made or in flight won't be affected by a permanent fix.

[steddyj]

@Tyko (and everyone):  @Tidal Stream is not expected to make any permanent fix for this or any other issues.  He mentioned a few weeks ago that he is no longer playing KSP nor is he actively maintaining this mod.  He might push a new release if someone submits a pull request, but he's either not chiming in here because either this isn't (as of yet) a permanent fix or he's no longer following the forum.  All in all, this mod needs a new maintainer.

@ozraven - I would venture that the new bug may be caused by the chunk of code you removed earlier to fix the issue with the tanks remaining in the menu.  I frankly didn't look that closely at that part as I was focused more on the node issue, is that what you've added back (in whole or part) in this new patch?  As to your earlier comment I do understand the tolerance, just not why it's looking at that coordinate at all.  Why would a top/bottom node be +/-.5 on Y, and apparently ONLY on Y because the actions taken if true is to offset X and Z by the same?  Also, why is it important to have all of those coordinates offset?  

[ozraven]

1 hour ago, steddyj said:

...  All in all, this mod needs a new maintainer.

I'm happy to contribute and try to understand more in pursuit of a proper fix for the issues, but I cycle between other games too frequently to take on PP. I further lack enough understanding of its operation to be comfortable maintaining the code. Lastly, if I were to return to maintaining mods, I have my own that is already being cared for by someone else!

1 hour ago, steddyj said:

@ozraven - I would venture that the new bug may be caused by the chunk of code you removed earlier to fix the issue with the tanks remaining in the menu.  I frankly didn't look that closely at that part as I was focused more on the node issue, is that what you've added back (in whole or part) in this new patch?  

No, the new bug was caused by the existing code not being compatible with whatever changes were made to nodes. When the shape changes, all attach nodes on the part are "processed" - this would seem to allow nodes to be relocated and if another part is attached, it is repositioned according to the new geometry. However, in the changes to nodes, for some reason, the top node is processed twice but appears invalid on the second pass. (See ProceduralAbstractSoRShape.cs:498 for my change and comments.) The fix was to check for null and skip processing if it's an invalid attachment. This is another hack because it works and I didn't have time to follow the logic and see what is the underlying cause.

2 hours ago, steddyj said:

As to your earlier comment I do understand the tolerance, just not why it's looking at that coordinate at all.  Why would a top/bottom node be +/-.5 on Y, and apparently ONLY on Y because the actions taken if true is to offset X and Z by the same?  Also, why is it important to have all of those coordinates offset?  

And more questions I've thought now put to words - unfortunately I haven't had time to revisit the logic to improve my understanding. Now that PP works, I'm drawn back in to playing.

 

[Tyko]

@steddyj sad news about @Tidal Stream  

i hope he takes the time to announce that he’s winding down and ask for help. It would be sad if this mod languished in its broken state 

[Tidal Stream]

Hello! I am glad that the Procedural Parts community is still active. As I wrote before, I don't have time for KSP any more. I will merge whale2's pull request so this should fix rerooting problems. ozraven's patch looks hacky so I am unsure about that one yet. Realism Overhaul (RP-0 at least) is still relying on Procedural Parts so they can take over if needed. And if someone has the time for full-time fixing of Procedural Parts, go ahead but make sure it doesn't break things, especially for RO.

[The-Doctor]

@Tidal Stream  Hi, I'd like to first start by saying awesome mod, and definitely if you don't have time for ksp you should focus on real life. I'd like to know if procedural parts has procedural pods incorporated or something so.

[RailgunRemix]

Hi @Tidal Stream,

I'm getting a recurring issue with Parts/Tanks/4SRB where it takes an infinite amount of time to load.

I'm running RO and a couple other mods but replaced its version of Procedural Parts with your branch. Crash logs aren't a thing because, well, it doesn't crash. It just decides not to load.

Screenshot: https://imgur.com/a/3nJXi7M (all errors are unrelated)

 

Please do try fixing it if you have time.

Regards.