-
-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support ReStock! #1
Comments
It ended up being extremely simple - after I refactored what I call now "MeshEngine", where the mesh handling code is now properly decoupled from the rest of the life cycle of the plugin. ReStock doesn't do anything "fancy" - it merely adds many MODEL sections, each one with the mesh for a part of the part (pun not intended!). So, by example, ReStock can reuse the top and the bottom parts of a fuel tank into another one with the same bulkhead, but taller. |
Implemented on commit 5b06bf3 . I will keep this issue open, as I doubt this task will be finished without some more work. The performance when ReStock is installed is abysmal... |
Something that crossed my mind now… Why only when using ReStock the performance on my rig plummets? Assuming the same conditions of temperature and pressure, there should be no differences between rendering a stock textured part and a ReStock one. Other than the size of the texture, of course, as ReStock are way heavier than Stock on GPUs. But, yet, it should tax the same my GPU when flying the craft, and no only on the Telescope, no? What am I missing here? |
I was wrong! ReStock was only the straw that broke the camel's back - I found a huge performance problem and fixed it, and this made even my rig work fine with DOE and ReStock. This task is concluded. |
Well… It ended up being exaclty this: supporting ReStock is, in essence, properly support Stock! :) So now the task is to support variants, and then procedural parts as Fairings. But this will tacked down in another fight, as I will close this as the task itself is fulfilled! |
ReStock is replacing some StockModules by custom ones, and this is screwing up the MeshEngine. Update it. |
I was wrong. I don't remember anymore what leaded me to believe the problem were the new The history is that even the simplest parts are not being shown when ReStock is installed - salvo some separators, as it appears. This is the test subject, scaled to 5M, using ReStock. This is proof that ReStock is working fine: I launched an "Observatory" vessel and VesselMove'd it to 2.8Km from the LaunchPad, then took the following screenshot without DOE installed: This is the same scenario, Stock only (and TweakScale), and DOE: And, finally, this is the same scenario, but with ReStock (and Plus) installed: This is the whole savegame: test-doe-restock.zip And the KSP.log, MMPatch and ConfigCache: Archive.zip Note: The scaled up aeroequus is prone to explode after reloading the savegame and focusing on it. Just recover whatever survive the ordeal, fix the launch pad and launch the Aeroeruus from the savegame again. |
I redid the test without TweakScale installed - just in case. Had to use something big using StockOnly Parts that can be reasonably seen from ~3KM, fortunately one of the Stock Shuttles, the Dynawing, did the trick. And surprise, surprise!! It's working!!! As it appears, the trouble maker is the TweakScale support!!! |
It's not a surprise I couldn't find the problem before, as I was looking on the wrong place. The thingy that are in need to be updated is the Well… It was a productive day, but it ended. I will need to work on it on another day - but, hey, now I know what to do!! |
This is now a bug, since it's stablished that the Mesh Engine for TweakScale somehow is screwing the ReStock parts. |
This was unexpected… the The DEBUG Log suggests that the MeshEngines are just don't being called at all - this is the reason by nothing being drawn, the Render interface is just not being called. So TweakScale is a trigger for the problem, not the cause… |
Oukey. Carefully reading the
This is happening for all Parts touched by ReStock. Now I need to understand why this is happening when TweakScale is installed. |
AWWWW, KRAP!!! Non scaled parts are being rendered allright - even with the WARNING above. The presence of TweakScale is not a problem, the problem is happening when the part is scaled. The WARNING from the previous post is something to check, but it's not causing the problem. |
Oukey, since we are here. This is the log entrey for
And this is what's on the MM ConfigCache about this part:
|
Obviously, it's not a patching problem. But yet, DistantObject is getting the original model name instead of the ReStock one when querying the GameDatabase… Looking carefully about the subject on the
Check the timestamps: Distant Object is building its internal database before ReStock removes the Stock meshes from memory. And it's doing it using the models before the patching, what suggests I'm doing it too early... |
…t to fectch any changes made to the GameDatabase by Module Manager. This will help solve problems for ReStock, but algo to everybody else that change models. #1
Commit f4f586c solved the problem described in the last two posts. Scaled up parts are still not being shown by DistantObject, but at least I got rid of a annoying problem - that may have a role on this issue - I'm guessing this is a problem with many triggers... |
Now let's try to get rid of these messages:
|
That's odd…. This is the ConfigNode as being fetched by DOE for the
And here, the same but without ReStock:
The thing is missing the |
…. The incredible part is not the stupidity, but how in hell this crap was working for Stock… Fixes #1
…. The incredible part is not the stupidity, but how in hell this crap was working for Stock… Fixes #1
Commit 1fcac3d fixes the WARNING from the last post. Frankly, I don't now why (and I don't remember when right now) I wrote this krappy excuse of code removed by that commit, but it was not only useless (as even KSP 1.3.1 don't give us the I should had paid attention to this the first time an user complained about. Mea culpa, mea maxima culpa. |
More interesting yet, this last commit (and probably the previous too) fixed the ReStock problem. I had said before somewhere in the codebase, Forum or Issue tracking, that supporting ReStock is essentially supporting Stock the right way, and this issue confirms that. Again, mea culpa, mea maxima culpa.. :/ Now I need to swallow my pride and see what else I could had done correctly on this thing before publishing a new release. This issue is closed/fixed. |
As explained here on Forum by the Fellow Kerbonaut Alexsys:
This is not going to be simple, but I don't thing it will that hard neither - I need to understand how ReStock handles the
MODEL
section - and there's a good chance that this is purely Stock behaviour that would end up beneficing everybody!The text was updated successfully, but these errors were encountered: