Closed Rhahi closed 1 week ago
This makes me think that the supposed "limitation on number of objects" might be the reason why I had to restart the KRPC every launch to not get those "mismatched" errors.
I was doubting whether if this is a bug in KRPC.jl or just kRPC in general, so I tested a similar code with the same spacecraft using the python client, so it is probably a KRPC.jl bug.
import krpc
conn = krpc.connect("Test", "10.0.0.51")
sc = conn.space_center
ves = sc.active_vessel
for p in ves.parts.all:
for m in p.modules:
print(m.name)
this code worked for me.
I found the fix. PR coming in soon.
Hello,
I have been working with engine cluster configurations, and then found out that KRPC gives up after numerous calls fetching module names. I was trying to cache some modules for re-use later, and to do that I needed to match their string name.
I don't know what's wrong here, other than not doing too many calls, so I need your help to fix the problem.
As usual, I start with importing common modules, and setting up vessels object.
Note that these tests are performed with Realism Overhaul, so I think in vanilla it will last a bit longer (due to less modules per parts)
The error appers when I query for
Name
call several times across several parts.Interestingly, doing this on fewer parts does not cause any problem.
Note that in this case the script broke during the 4th part, but I don't think there is anything magical about number 4; during my cluster engine test I failed while parsing the 5th engine, (after naming 120-ish modules).
So I am assuming that there might be some kind of total number of "unique" object count or total amount of memory that KRPC.jl can track?
I almost forgot to show the stacktrace. Here are two examples.
Updates
This is probably an integeroverflow issue.
calling engine (but doing some other calling in between) several times will cause a crash when the ID reaches 128!