You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The ue4-dev branch has accumulated a significant number of bug fixes, feature additions, and improvements over the past several releases that have not been ported to ue5-dev. Since ue5-dev is the future of the project, these gaps leave users on the newer branch without fixes and features that are already available in ue4-dev.
Rather than cherry-picking commits (which often fail due to the UE4→UE5 structural differences), I propose implementing equivalent functionality as new code targeting ue5-dev directly, submitted as a series of focused, independently reviewable PRs.
Proposed PR series
The changes are organized into 21 PRs across 9 categories. Each PR is self-contained and can be reviewed and merged independently.
Category 1: Bug fixes (small PRs, ready for immediate merge)
PR
Title
Changes
Reference commits (ue4-dev)
#0a
fix(LibCarla): core bug fixes
RPC deadlock (atomic_bool), assert removal, OpenDrive lane width, GeoReferenceParser crash, TM NaN error, yield→sleep_for, assert relaxation
The Week 1 PRs are intentionally the smallest and most straightforward — pure bug fixes that should be uncontroversial and quick to review. This establishes the pattern and builds momentum for the larger PRs.
Approach
For each PR, I am implementing equivalent functionality as new code targeting ue5-dev rather than cherry-picking from ue4-dev. The reference commits listed above are used to understand what needs to change, but the actual implementation accounts for UE5.5 API differences and the current state of ue5-dev.
Questions for maintainers
Granularity: Are 21 PRs too many, or is this level of granularity helpful for review? I can split or merge PRs based on your preference.
Priority: Are there specific categories you'd like to see first? I've ordered by estimated ease-of-merge, but if there are particular pain points on ue5-dev, I can reprioritize.
I'm happy to adjust the plan based on feedback. Looking forward to your thoughts.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Motivation
The
ue4-devbranch has accumulated a significant number of bug fixes, feature additions, and improvements over the past several releases that have not been ported toue5-dev. Sinceue5-devis the future of the project, these gaps leave users on the newer branch without fixes and features that are already available inue4-dev.Rather than cherry-picking commits (which often fail due to the UE4→UE5 structural differences), I propose implementing equivalent functionality as new code targeting
ue5-devdirectly, submitted as a series of focused, independently reviewable PRs.Proposed PR series
The changes are organized into 21 PRs across 9 categories. Each PR is self-contained and can be reviewed and merged independently.
Category 1: Bug fixes (small PRs, ready for immediate merge)
fix(LibCarla): core bug fixes0c477d65c,7b2ef1d94,3b3b890ae,280c71c42,488fd42a4,4c49a741d,5161fb09efix(streaming): restore ROS 2 sensor data flow6bf5e3d94fix(sensors): camera fx, semantic tags, pedestrian bbox86ebadcee,40ac1f19e,ff009c8a3,ccc86c6b4,742113a92,86a1ec101,a095219c7fix(LibCarla): eliminate compiler warningsd179041f4Category 2: ROS 2 enhancements
feat(ros2): transformation fix and refactora46b2690b,cd3d640f3,201d375d3,a6f6ed03dfeat(ros2): geometry data types and multistream support590d54f02,3b938d718feat(ros2): V2X sensor and serializer8f33324d9,1146277a7feat(ros2): fine-grained server synchronizationaa9c92b21Category 3: Recorder and replay
feat(recorder): weather recording and simultaneous record/replaydf0161e87,be60694b7,5ab7c76ea,70bee19db,fd6c4e0bffix(recorder): replay compatibility fixesc9f2e3ab6,7b0707548,969f9ce20Category 4: TrafficManager
feat(tm): improved large vehicles and PID tuning4fdea38a5,c8dfee97e,fb5f61269,e7e076f1b,141fc20aeCategory 5: Vehicle, physics, and control API
feat(vehicle): wheel rotation API and telemetrya14b2d943,03e71c251,01b1ede51,3647beaf0,fda970b88,e7e3987f7,bd6860437feat(api): new force/impulse and actor component functions60fdd57e0,0b13c72d6,5d6862c3d,3eb9a7626,00ff27ac3,5ca6323f4,842f44294Category 6: New sensors
feat(sensor): fisheye camera (Kannala-Brandt model)390aa0b8e,8f6e2b348feat(sensor): hybrid solid-state LiDARa4eca2e4dfeat(sensor): IMU gravity parameter and geolocationcaca5f02e,39f7741b7,9ce853e99Category 7: Segmentation
feat(segmentation): masked materials and instance segmentation fixes8b79b708e,9c620141f,e8947a47c,d859cd9d2,f45dd6943,4da825b42Category 8: Left-hand traffic
feat(map): left-hand traffic support77894abcdCategory 9: Other improvements
feat(opendrive): lane marking and waypoint fixes86fcfe5e8,e41ffa03c,4d4dd1d11,4ca87e818,6cb77140c,58c870ae3feat(traffic): traffic light and sign improvementsf856729ee,e06993189,c1ba7342c,2fed7136e,363da3d78feat(python): agent improvements and InvertedAI9a59963ca,4da0c7415,29af5dc89,b60034be6,694ad122a,aeeff9907Submission order
All PRs within each week are independent and can be reviewed in parallel.
The Week 1 PRs are intentionally the smallest and most straightforward — pure bug fixes that should be uncontroversial and quick to review. This establishes the pattern and builds momentum for the larger PRs.
Approach
For each PR, I am implementing equivalent functionality as new code targeting
ue5-devrather than cherry-picking fromue4-dev. The reference commits listed above are used to understand what needs to change, but the actual implementation accounts for UE5.5 API differences and the current state ofue5-dev.Questions for maintainers
ue5-dev, I can reprioritize.I'm happy to adjust the plan based on feedback. Looking forward to your thoughts.
All reactions