RJD-1057 (3/5): Remove non-API member functions: EntityManager’s member functions forwarded to EntityBase (1/2) #1473
Conversation
… exceptions were thrown Signed-off-by: Mateusz Palczuk <mateusz.palczuk@robotec.ai>
Signed-off-by: Mateusz Palczuk <mateusz.palczuk@robotec.ai>
Signed-off-by: Mateusz Palczuk <mateusz.palczuk@robotec.ai>
Signed-off-by: Mateusz Palczuk <mateusz.palczuk@robotec.ai>
… API Signed-off-by: Mateusz Palczuk <mateusz.palczuk@robotec.ai>
Signed-off-by: Mateusz Palczuk <mateusz.palczuk@robotec.ai>
Signed-off-by: Mateusz Palczuk <mateusz.palczuk@robotec.ai>
Signed-off-by: Mateusz Palczuk <mateusz.palczuk@robotec.ai>
Signed-off-by: Mateusz Palczuk <mateusz.palczuk@robotec.ai>
Signed-off-by: Mateusz Palczuk <mateusz.palczuk@robotec.ai>
Signed-off-by: Mateusz Palczuk <mateusz.palczuk@robotec.ai>
Signed-off-by: Mateusz Palczuk <mateusz.palczuk@robotec.ai>
Signed-off-by: Mateusz Palczuk <mateusz.palczuk@robotec.ai>
…p-time' into RJD-1057-remove-functions-forwarded-to-entity-base
…d' into RJD-1057-remove-functions-forwarded-to-entity-base
…ntityBase, remove forwarding
…ion to EntityBase, remove forwarding
…sInLanelet, remove forwarding
…tityBase, also some getters, left setVelocityLimit and setBehaviorParameter
…develop templated is() in EntityBase and use it, rename isEgoSpawned to isAnyEgoSpawned, refactor
…ng setBehaviorParameter and setVelocityLimit
…ng request*, move requestLaneChange to EntityBase
…n forwarding, set "waiting" as init action state in behavior_tree
…awned, move checkCollision directly to API
…develop getEgoEntity and dedicated methods in EgoEntity
…o RJD-1057-remove-functions-forwarded-to-entity-base
…y in calc it directly in evaluateTimeHeadway
…le' of https://github.com/tier4/scenario_simulator_v2 into RJD-1057-remove-functions-forwarded-to-entity-base-middle
Checklist for reviewers ☑️All references to "You" in the following text refer to the code reviewer.
|
|
No regressions confirmed here |
…ctions-forwarded-to-entity-base-middle
…ctions-forwarded-to-entity-base-middle
| auto EntityBase::isInPosition(const geometry_msgs::msg::Pose & pose, const double tolerance) const | ||
| -> bool | ||
| { | ||
| return math::geometry::getDistance(getMapPose(), pose) < tolerance; | ||
| } | ||
|
|
||
| auto EntityBase::isInPosition( | ||
| const CanonicalizedLaneletPose & lanelet_pose, const double tolerance) const -> bool | ||
| { | ||
| return isInPosition(static_cast<geometry_msgs::msg::Pose>(lanelet_pose), tolerance); | ||
| } |
There was a problem hiding this comment.
Consider modifying the function name.
This function checks whether a circle exists inside a certain range from the first argument.
There was a problem hiding this comment.
Suggested candidates are isInRange, isInCircle, isNearbyPosition, reachPosition, isReachPosition, etc.
There was a problem hiding this comment.
whether a circle exists inside a certain range from the first argument.
I believe EntityBase::isInPosition(...) method checks if the Entity is in a specific position - with some tolerance. More specifically, it checks if the euclidean distance (3d) between the Entity's map position and the passed map position is smaller than the passed tolerance.
So it's more like checking if a point (passed map position) is inside a sphere of a specified radius (tolerance), which center is located at the reference point (Entity's map position).
While choosing the name of this method, I based it on the name of method IsInLanelet(...) see below - so as to keep it consistent.
About suggested candidates
I believe that the names isInRange and isInCircle do not suit here because they do not refer to what is really being checked. Because, it is simply a comparison of two positions.
In addition, I believe that the word 'reach' in the names reachPosition and isReachPosition does not add anything good, but only adds additional context like an Entity is executing some kind of move - and it doesn't have to be that because it can be a static object.
The only reasonable candidate here is isNearbyPosition however, I cannot find a rationale why the name 'nearby' should be added here. Could you please explain why you think inNearbyPosition is better than isInPosition? Because in my feelings, since we have isInLanelet, isInPosition seems like a good choice.
About tolerance
I would also add that I believe that in isInPosition method tolerance should be optional (as I wrote in the description of PR). It should be handled similarly to how it is in isInLanelet(...).
To be more precise, if we assume that tolerance is std::optional, then if nothing is passed (tolerance is std::nullopt): tolerance should be taken as equal to std::numeric_limits<double>::epsilon().
Thus, the isInPosition(some_position) call will return true if the Entity's map position is the same as passed map position with std::numeric_limits<double>::epsilon() precision.
Please let me know what you think about it 🙇
There was a problem hiding this comment.
From the text is in position I get the impression that it is a function that determines if a specific xyz coordinate is an exact match to an input coordinate.
If it is nearby position, I intuitively understand that there is some tolerance since it means “nearby”.
There was a problem hiding this comment.
Do you mean here a situation such that:
- the method name (
isInNearbyPosition) is supposed to itself provide information to the user that the user can use this method to compare positions with any tolerance
Since, from my point of view, the requirement to pass the tolerance argument provides the same information, I thought that adding this information to the name itself could be redundant.
If you mean this situation, I understand, however, I would like to maintain consistency between the method names IsInLanelet and IsInPosition (since they do the same thing only in a different representation). Because of this, adding 'nearby' to IsInPosition also causes the need to add 'nearby' to IsInLanelet.
In this circumstance, I would like to make two proposals:
1. Nearby
auto isInNearbyPosition(const geometry_msgs::msg::Pose & pose, const double tolerance) const -> bool;
auto isInNearbyPosition(const CanonicalizedLaneletPose & lanelet_pose, const double tolerance) const -> bool;
auto isInLanelet() const -> bool;
auto isInNearbyLanelet(const lanelet::Id lanelet_id, std::optional<double> tolerance = std::nullopt) const -> bool;
2. Optional tolerance
auto isInPosition(const geometry_msgs::msg::Pose & pose, const std::optional<double> tolerance = std::nullopt) const -> bool;
auto isInPosition(const CanonicalizedLaneletPose & lanelet_pose, const std::optional<double> tolerance = std::nullopt) const -> bool;
auto isInLanelet() const -> bool;
auto isInLanelet(const lanelet::Id lanelet_id, const std::optional<double> tolerance = std::nullopt) const -> bool;
The 2. proposal involves the development of what I wrote here:
About tolerance
I would also add that I believe that in isInPosition method tolerance should be optional (as I wrote in the description of PR). It should be handled similarly to how it is in isInLanelet(...).To be more precise, if we assume that tolerance is std::optional, then if nothing is passed (tolerance is std::nullopt): tolerance should be taken as equal to std::numeric_limits::epsilon().
Thus, the isInPosition(some_position) call will return true if the Entity's map position is the same as passed map position with std::numeric_limits::epsilon() precision.
Please let me know which proposal is better in your opinion - then I will implement it. 🙇
...ion/behavior_tree_plugin/include/behavior_tree_plugin/transition_events/transition_event.hpp
Outdated
Show resolved
Hide resolved
| bool despawnEntity(const std::string & name); | ||
|
|
||
| bool entityExists(const std::string & name); | ||
| auto isEntitySpawned(const std::string & name) const -> bool; |
There was a problem hiding this comment.
This renaming makes it difficult to express "has been spawned but now not exists", so please change it back.
There was a problem hiding this comment.
I've changed the name to isEntityExist, please confirm if this is okay for you 🙇
| bool API::checkCollision( | ||
| const std::string & first_entity_name, const std::string & second_entity_name) |
There was a problem hiding this comment.
If possible, it is better to change this function to EntityBase::collidesWith(pointer-to-other-EntityBase) from the viewpoint of uniformity. Please consider whether it is reasonably possible to change it.
There was a problem hiding this comment.
Thank you so much for your valuable insight. 🙇
I've been thinking about this, and looking at the EntityBase, EntityManager and API versions after the final PR 5/5 is merged, it doesn't seem like a good idea to me.
The main problem in developing the EntityBase and API interfaces is the answer to the question “which features should be in the API and which directly in EntityBase”.
We could indeed move all the checkCollision-like features from API to EntityBase::someFeature(pointer-to-other-EntityBase), but I don't think it's a good idea to implement it this way.
Certainly, I don't think that the 'features split ' that occurs in PR 5/5 is ideal, however, looking at EntityBase header (entity_base.hpp) i don't think that adding method collidesWith(pointer-to-other-EntityBase) here would be reasonable. The main reason is the need to pass reference to other Entity.
In my mind, EntityBase should have methods associated with a single entity and its attributes. Creating methods like EntityBase::someFeature(pointer-to-other-EntityBase) will involve passing a large amount of information to EntityBase. If we want to add the collidesWith method, it is good to pass only those elements that are indeed related to collides check.
Therefore, other suggestion as I can propose here is to, for example, create a method
EntityBase::collidesWith(const geometry_msgs::msg::Pose & object_pose, const std::vector<geometry_msgs::msg::Point> object_polygon)
or
EntityBase::collidesWith(const geometry_msgs::msg::Pose & object_pose, const boost_polygon & object_polygon)(see bounding_box.hpp)
However I'm not sure if that makes sense for checkCollision feature.
It seems to me that the option to call API::checkCollision(const std::string & first_entity_name, const std::string & second_entity_name) is from the point of view of the whole architecture obtained in PR 5/5 proper, and at this point I do not see the need to create an additional method EntityBase::collidesWith(...) - please see api.hpp and entity_base.hpp.
I would add that I tried to use common sense in the 'features split' between the API and EntityBase, and it is often subjective. However, if two Entities are explicitly needed for an operation (calculating the distance between them, checking collisions, calculation of time headway), then I would try to keep such features in the API.
Please let me know what you think about it 🙇
| auto getEntityOrNullptr(const std::string & name) const | ||
| -> std::shared_ptr<traffic_simulator::entity::EntityBase>; |
There was a problem hiding this comment.
The name "OrNullptr" is redundant because all functions that return pointers should assume the possibility of a null pointer when used. Change interfaces that return references to getEntity and interfaces that return pointers to getEntityPointer.
There was a problem hiding this comment.
I understand your point of view.
However, I would like to add that there is still the getEntity method:
getEntitythrows an exception now - when the Entity does not exist - is commonly used intraffic_simulator.getEntityOrNullptrdoes not throw exceptions but returnsnullptr- is mainly used bysimulator_core, due to the need to handle cases when the Entity does not exist.
If I will change the name of getEntityOrNullptr to getEntityPointer, then there will be two methods: getEntityPointer and getEntity, both returning a pointer - which I think is more confusing than getEntityOrNullptr+ getEntity.
Please see the source
I would also like to add that in PR 5/5 there are changes developed, in which the getEntityOrNullptr method will be completely removed. In parts of the code where it is now necessary, isEntitySpawned (existEntity) will be used - below I've attached an example.
This change is included in PR 5/5 because in PR 5/5 I focused more on the simulator_core<->api connection itself.
Future example - here getEntityOrNullptr no longer exist
Please let me know what you think about it 🙇
| @@ -65,7 +65,7 @@ class CanonicalizedEntityStatus | |||
| auto getLinearJerk() const noexcept -> double; | |||
| auto setLinearJerk(double) -> void; | |||
|
|
|||
| auto laneMatchingSucceed() const noexcept -> bool; | |||
| auto isInLanelet() const noexcept -> bool; | |||
There was a problem hiding this comment.
Why was laneMatchingSucceed renamed to isInLanelet?
Since successful lane matching and being inside a lanelet polygon have different meanings, I wonder if the renaming was appropriate.
There was a problem hiding this comment.
I've added the isInLanelet() method to EntityBase with the lanelet_id argument because it is often used.
As result, in my feeling, it was a good thing to also change the name from laneMatchingSucceed() to isInLanelet()
Please let me explain 🙇:
I based EntityBase::isInLanelet(...) on the pose::isInLanelet(...) function (from utils).
Method pose::isInLanelet(...) lets us check if canonicalized_lanelet_pose is on the lanelet with the passed lanelet_id:
On the other hand, EntityBase::isInLanelet(...) lets us check if the Entity (its current position) is on the lanelet with the passed lanelet_id (here is the possibility of not passing the tolerance value, since we can use the default value of matching):
scenario_simulator_v2/simulation/traffic_simulator/src/entity/entity_base.cpp
Lines 110 to 119 in 4e0c479
An additional overload of EntityBase::isInLanelet method can be checking if the Entity is on any lanelet (with any lanelet_id) - then we do not pass this argument as well. In this way we get a method that gives the same result as laneMatchingSucceed(). Because if the Entity is on any lanelet, then its EntityStatus attribute canonicalized_lanelet_pose_ always will have a value.
So EntityBase::isInLanelet() without the arguments passed is equivalent to EntityBase::laneMatchingSucceed()
Please let me know what you think about it 🙇
dmoszynski
added
bump major
|
@hakuturu583 I would like to also add that this is not the first PR in which I see this issue - I have no idea how to get rid of it. |
…waiting" -> "none" Co-authored-by: Masaya Kataoka <ms.kataoka@gmail.com>
|
Description
Abstract
This pull request introduces the change of exposing direct access to Entity objects through the API. This change increases flexibility of using the API and removes the need to have many forwarding functions to Entities member functions.
Background
This pull request is one of many that aim to modularize the scenario_simulator_v2.
The main goal of this PR was to remove numerous member functions of
EntityManager(and subsequently some of API too) that forwarded calls to Entities member functions:scenario_simulator_v2/simulation/traffic_simulator/include/traffic_simulator/entity/entity_manager.hpp
Lines 162 to 216 in 0dbf4ec
This has largely been achieved by exposing direct access to Entity and its member functions through the
API::getEntityfunction:scenario_simulator_v2/simulation/traffic_simulator/include/traffic_simulator/api/api.hpp
Line 303 in 8940b3e
The following change was to adjust all cpp mock scenarios to use the new interface.
This is the main reason why this PR is so large - all mock scenarios had to be corrected.
Scenarios using the new interface have been changed similarly to the example below.
Before:
scenario_simulator_v2/mock/cpp_mock_scenarios/src/follow_lane/acquire_position_in_world_frame.cpp
Lines 41 to 64 in 0dbf4ec
After:
scenario_simulator_v2/mock/cpp_mock_scenarios/src/follow_lane/acquire_position_in_world_frame.cpp
Lines 41 to 64 in 8940b3e
Similar changes had to be applied to the whole codebase relying on the API like simulator_core.hpp.
What is more,
EgoEntityhas been modified in such a way, that the functionscenario_simulator_v2/simulation/traffic_simulator/include/traffic_simulator/entity/ego_entity.hpp
Line 68 in 0dbf4ec
has been replaced with a set of other functions below:
scenario_simulator_v2/simulation/traffic_simulator/include/traffic_simulator/entity/ego_entity.hpp
Lines 155 to 164 in 8940b3e
This change simplifies the interface of calling Ego specific actions like
engageorsendCooperateCommand.Details
Below are the detailed interface changes that have been made to
EntityStatus,EntityBase,EntityManagerand theAPI.EntityStatus
laneMatchingSucceedtoisInLanelet:auto laneMatchingSucceed() const noexcept -> bool;->
auto isInLanelet() const noexcept -> bool;EntityBase
Removed forwarded using macro to
EntityStatus:laneMatchingSucceed:laneMatchingSucceedRemoved
asFieldOperatorApplication,reachPositionandrequestClearRoute:auto asFieldOperatorApplication() const -> concealer::FieldOperatorApplication &;bool reachPosition(const geometry_msgs::msg::Pose & target_pose, const double tolerance) const;bool reachPosition(const CanonicalizedLaneletPose & lanelet_pose, const double tolerance) const;bool reachPosition(const std::string & target_name, const double tolerance) const;void requestClearRoute();Added:
isStopped,isInPositionandisInLanelet.Note: Maybe it's a good idea to provide that
toleranceis always of typestd::optional<double>?EgoEntity
Removed
asFieldOperatorApplication:auto asFieldOperatorApplication() const -> concealer::FieldOperatorApplication & override;Added many methods as
asFieldOperatorApplicationreplacements:EntityManager
Removed forwarded using macro to
EntityBase:activateOutOfRangeJob,asFieldOperatorApplication,cancelRequest,get2DPolygon,getBehaviorParameter,getBoundingBox,getCanonicalizedStatusBeforeUpdate,getCurrentAccel,getCurrentTwist,getDefaultMatchingDistanceForLaneletPoseCalculation,getEntityType,getEntityTypename,getLinearJerk,getRouteLanelets,getStandStillDuration,getTraveledDistance,isControlledBySimulator,laneMatchingSucceed,reachPosition,requestAcquirePosition,requestAssignRoute,requestClearRoute,requestFollowTrajectory,requestLaneChange,requestSpeedChange,requestSynchronize,requestWalkStraight,setAcceleration,setAccelerationLimit,setAccelerationRateLimit,setBehaviorParameter,setControlledBySimulator,setDecelerationLimit,setDecelerationRateLimit,setLinearJerk,setLinearVelocity,setMapPose,setTwist,setVelocityLimit:FORWARD_TO_ENTITY(activateOutOfRangeJob);FORWARD_TO_ENTITY(asFieldOperatorApplication);FORWARD_TO_ENTITY(cancelRequest);FORWARD_TO_ENTITY(get2DPolygon);FORWARD_TO_ENTITY(getBehaviorParameter);FORWARD_TO_ENTITY(getBoundingBox);FORWARD_TO_ENTITY(getCanonicalizedStatusBeforeUpdate);FORWARD_TO_ENTITY(getCurrentAccel);FORWARD_TO_ENTITY(getCurrentTwist);FORWARD_TO_ENTITY(getDefaultMatchingDistanceForLaneletPoseCalculation);FORWARD_TO_ENTITY(getEntityType);FORWARD_TO_ENTITY(getEntityTypename);FORWARD_TO_ENTITY(getLinearJerk);FORWARD_TO_ENTITY(getRouteLanelets);FORWARD_TO_ENTITY(getStandStillDuration);FORWARD_TO_ENTITY(getTraveledDistance);FORWARD_TO_ENTITY(isControlledBySimulator);FORWARD_TO_ENTITY(laneMatchingSucceed);FORWARD_TO_ENTITY(reachPosition);FORWARD_TO_ENTITY(requestAcquirePosition);FORWARD_TO_ENTITY(requestAssignRoute);FORWARD_TO_ENTITY(requestClearRoute);FORWARD_TO_ENTITY(requestFollowTrajectory);FORWARD_TO_ENTITY(requestLaneChange);FORWARD_TO_ENTITY(requestSpeedChange);FORWARD_TO_ENTITY(requestSynchronize);FORWARD_TO_ENTITY(requestWalkStraight);FORWARD_TO_ENTITY(setAcceleration);FORWARD_TO_ENTITY(setAccelerationLimit);FORWARD_TO_ENTITY(setAccelerationRateLimit);FORWARD_TO_ENTITY(setBehaviorParameter);FORWARD_TO_ENTITY(setControlledBySimulator);FORWARD_TO_ENTITY(setDecelerationLimit);FORWARD_TO_ENTITY(setDecelerationRateLimit);FORWARD_TO_ENTITY(setLinearJerk);FORWARD_TO_ENTITY(setLinearVelocity);FORWARD_TO_ENTITY(setMapPose);FORWARD_TO_ENTITY(setTwist);FORWARD_TO_ENTITY(setVelocityLimit);Removed
is,isStopping,isInLanelet,checkCollision,getEntityStatus,getCurrentAction:bool is(const std::string & name) const;bool isStopping(const std::string & name) const;bool isInLanelet(const std::string & name, const lanelet::Id lanelet_id, const double tolerance);bool checkCollision(const std::string & first_entity_name, const std::string & second_entity_name);auto getEntityStatus(const std::string & name) const -> const CanonicalizedEntityStatus &;auto getCurrentAction(const std::string & name) const -> std::string;Renamed
entityExiststoisEntitySpawnedauto entityExists(const std::string & name) -> bool;->
auto isEntitySpawned(const std::string & name) -> bool;Renamed
getEntitytogetEntityOrNullptr(which does not throw an exception but returns nullptr)auto getEntity(const std::string & name) const -> std::shared_ptr<entity::EntityBase>;->
auto getEntityOrNullptr(const std::string & name) const -> std::shared_ptr<entity::EntityBase>;Renamed
isEgoSpawnedtoisAnyEgoSpawned:auto isEgoSpawned() const -> bool;->
auto isAnyEgoSpawned() const -> bool;Added
getEntity(which throws an exception).getEgoEntity:API
Removed forwarded using macro to
EntityManager:activateOutOfRangeJob,asFieldOperatorApplication,cancelRequest,checkCollision,entityExists,getBehaviorParameter,getBoundingBox,getCanonicalizedStatusBeforeUpdate,getCurrentAccel,getCurrentAction,getCurrentTwist,getDefaultMatchingDistanceForLaneletPoseCalculation,getEgoName,getEntityNames,getEntityStatus,getLinearJerk,getStandStillDuration,getTraveledDistance,isEgoSpawned,isInLanelet,laneMatchingSucceed,reachPosition,requestAcquirePosition,requestAssignRoute,requestClearRoute,requestFollowTrajectory,requestSpeedChange,requestSynchronize,requestWalkStraight,setAcceleration,setAccelerationLimit,setAccelerationRateLimit,setBehaviorParameter,setDecelerationLimit,setDecelerationRateLimit,setLinearVelocity,setMapPose,setTwist,setVelocityLimit:FORWARD_TO_ENTITY_MANAGER(activateOutOfRangeJob);FORWARD_TO_ENTITY_MANAGER(asFieldOperatorApplication);FORWARD_TO_ENTITY_MANAGER(cancelRequest);FORWARD_TO_ENTITY_MANAGER(checkCollision);FORWARD_TO_ENTITY_MANAGER(entityExists);FORWARD_TO_ENTITY_MANAGER(getBehaviorParameter);FORWARD_TO_ENTITY_MANAGER(getBoundingBox);FORWARD_TO_ENTITY_MANAGER(getCanonicalizedStatusBeforeUpdate);FORWARD_TO_ENTITY_MANAGER(getCurrentAccel);FORWARD_TO_ENTITY_MANAGER(getCurrentAction);FORWARD_TO_ENTITY_MANAGER(getCurrentTwist);FORWARD_TO_ENTITY_MANAGER(getDefaultMatchingDistanceForLaneletPoseCalculation);FORWARD_TO_ENTITY_MANAGER(getEgoName);FORWARD_TO_ENTITY_MANAGER(getEntityNames);FORWARD_TO_ENTITY_MANAGER(getEntityStatus);FORWARD_TO_ENTITY_MANAGER(getLinearJerk);FORWARD_TO_ENTITY_MANAGER(getStandStillDuration);FORWARD_TO_ENTITY_MANAGER(getTraveledDistance);FORWARD_TO_ENTITY_MANAGER(isEgoSpawned);FORWARD_TO_ENTITY_MANAGER(isInLanelet);FORWARD_TO_ENTITY_MANAGER(laneMatchingSucceed);FORWARD_TO_ENTITY_MANAGER(reachPosition);FORWARD_TO_ENTITY_MANAGER(requestAcquirePosition);FORWARD_TO_ENTITY_MANAGER(requestAssignRoute);FORWARD_TO_ENTITY_MANAGER(requestClearRoute);FORWARD_TO_ENTITY_MANAGER(requestFollowTrajectory);FORWARD_TO_ENTITY_MANAGER(requestSpeedChange);FORWARD_TO_ENTITY_MANAGER(requestSynchronize);FORWARD_TO_ENTITY_MANAGER(requestWalkStraight);FORWARD_TO_ENTITY_MANAGER(setAcceleration);FORWARD_TO_ENTITY_MANAGER(setAccelerationLimit);FORWARD_TO_ENTITY_MANAGER(setAccelerationRateLimit);FORWARD_TO_ENTITY_MANAGER(setBehaviorParameter);FORWARD_TO_ENTITY_MANAGER(setDecelerationLimit);FORWARD_TO_ENTITY_MANAGER(setDecelerationRateLimit);FORWARD_TO_ENTITY_MANAGER(setLinearVelocity);FORWARD_TO_ENTITY_MANAGER(setMapPose);FORWARD_TO_ENTITY_MANAGER(setTwist);FORWARD_TO_ENTITY_MANAGER(setVelocityLimit);Removed
setEntityStatus,requestLaneChangeandgetTimeHeadway:auto setEntityStatus(...) -> void;void requestLaneChange(...);std::optional<double> getTimeHeadway(const std::string & from, const std::string & to);Added
checkCollision:EntityManager:isEntitySpawned,isAnyEgoSpawned,getEntityOrNullptr,getEgoEntity:Examples of interface changes
Below are many examples of how to use the interface after the changes.
entityExists->isEntitySpawned->
is<>->
getEntity->getEntityOrNullptr->
reachPosition->isInPosition->
getCurrentAction->
setEntityStatus->setStatus->
asFieldOperatorApplication-> replacements->
->
Others
->
->
References
INTERNAL LINK1
INTERNAL LINK2
Destructive Changes
--
Known Limitations
--