- Fixed deadlock when loading ghost nodes from collision solids and
have non-identity scale applied.
Signed-off-by: deflected <deflected@users.noreply.github.com>
This happens only when the system Python has the module built-in (eg. on Ubuntu where most modules are builtin) but deploy-ng doesn't.
Regression was introduced by 94b5fa1e90Fixes#264
This will help us catch cases wherein we inadvertently create a circular dependency between component libraries. Right now it only checks inheritance and typedefs, but this can be expanded in the future.
Also, sorts the module initialization by dependency topology. This isn't very important right now, but having this guarantee might help when refactoring module initialization in the future.
Typedefs are evidently always considered "fully defined", so we need to add another condition to the database merging code to prefer the type that is marked "global" when merging two types.
Again, all this does is affect the 4-years-disused OTP system, leaving
the CMU system entirely untouched.
This changes the packet formatting in several of distributed's helper
classes.
I imagine very few Panda3D users depend on the message numbers having
particular values. The ones removed belonged to Disney's OTP system,
which hasn't been used by anybody in over 4 years.
At any rate, old code should continue to work, just at the cost of
compatibility between clients and servers running different P3D versions.
This new loop is better in two ways:
1) It reads straight into the Datagram's internal buffer,
saving the trouble of allocating an intermediate buffer
and wasting CPU time to copy out of it.
2) It's more cautious in the face of large (>4MB) lengths,
which are more likely to be due to corruption than the
datagram *actually* being that large.
It was an incomplete experiment for distributing rendering pipelines over
a LAN of computers all working in concert.
Who knows, it may return someday. Until then, it's best not to keep it
around.
This just starts with PandaNode, and uses DCAST_INTO_R instead of DCAST
to catch bad bams. BamWriter should never produce bam output that will
trigger this; I found this with a fuzzer.
I'm unsure about the tradeoff between bam loading performance and
robustness in the face of bad bams. It certainly makes a lot of sense
in debug builds, but we might want to consider a compile flag that
forces bam-related asserts always on even in release builds.
Found this by fuzzing; not concerned about updating the writer as
the writer itself should never do this. This is just to protect
against segfaults in the face of corrupt or malicious bams.
This should also be a slight performance boost since breaking out
of the loop upon discovering an incomplete child object means we don't
bother resolving everything else just to discard it all.
Sam Edwards
rdb
deflected
Mitchell Stokes