ConstructionGL2 Part 1: ECSification, events and steps. (#5017)
- Completely rewrited the `ConstructionComponent` logic to be ECS, *without* looking too much at the original implementation.
- The original implementation was dirty and unmaintainable, whereas this new implementation is much cleaner, well-organized and maintainable. I've made sure to leave many comments around, explaining what everything does.
- Construction now has a framework for handling events other than `InteractUsing`.
- This means that you can now have CGL steps for things other than inserting items, using tools...
- Construction no longer uses `async` everywhere for `DoAfter`s. Instead it uses events.
- Construction event handling occurs in the `ConstructionSystem` update tick, instead of on event handlers.
- This ensures we can delete/modify entities without worrying about "collection modified while enumerating" exceptions.
- This also means the construction update tick is where all the fun happens, meaning it'll show up on our metrics and give us an idea of how expensive it is/how much tick time is spent in construction.
- `IGraphCondition` and `IGraphAction` have been refactored to take in `EntityUid`, `IEntityManager`, and to not be async.
- Removes nested steps, as they made maintainability significantly worse, and nothing used them yet.
- This fixes #4892 and fixes #4857
Please note, this leaves many things unchanged, as my idea is to split this into multiple PRs. Some unchanged things:
- Initial construction code is the same. In the future, it'll probably use dummy entities.
- Client-side guided steps are the same. In the future, the server will generate the guided steps and send them to clients as needed, caching these in both the server and client to save cycles and bandwidth.
- No new construction graph steps... Yet! :eyes:
2021-10-26 16:38:03 +02:00
|
|
|
using Content.Server.Construction.Components;
|
2022-10-17 05:43:33 +13:00
|
|
|
using Content.Server.Containers;
|
ConstructionGL2 Part 1: ECSification, events and steps. (#5017)
- Completely rewrited the `ConstructionComponent` logic to be ECS, *without* looking too much at the original implementation.
- The original implementation was dirty and unmaintainable, whereas this new implementation is much cleaner, well-organized and maintainable. I've made sure to leave many comments around, explaining what everything does.
- Construction now has a framework for handling events other than `InteractUsing`.
- This means that you can now have CGL steps for things other than inserting items, using tools...
- Construction no longer uses `async` everywhere for `DoAfter`s. Instead it uses events.
- Construction event handling occurs in the `ConstructionSystem` update tick, instead of on event handlers.
- This ensures we can delete/modify entities without worrying about "collection modified while enumerating" exceptions.
- This also means the construction update tick is where all the fun happens, meaning it'll show up on our metrics and give us an idea of how expensive it is/how much tick time is spent in construction.
- `IGraphCondition` and `IGraphAction` have been refactored to take in `EntityUid`, `IEntityManager`, and to not be async.
- Removes nested steps, as they made maintainability significantly worse, and nothing used them yet.
- This fixes #4892 and fixes #4857
Please note, this leaves many things unchanged, as my idea is to split this into multiple PRs. Some unchanged things:
- Initial construction code is the same. In the future, it'll probably use dummy entities.
- Client-side guided steps are the same. In the future, the server will generate the guided steps and send them to clients as needed, caching these in both the server and client to save cycles and bandwidth.
- No new construction graph steps... Yet! :eyes:
2021-10-26 16:38:03 +02:00
|
|
|
using Content.Shared.Construction;
|
|
|
|
|
using Content.Shared.Construction.Prototypes;
|
|
|
|
|
using Content.Shared.Construction.Steps;
|
2023-03-24 22:00:29 +13:00
|
|
|
using Content.Shared.Containers;
|
2022-11-16 12:10:27 +01:00
|
|
|
using Content.Shared.Database;
|
ConstructionGL2 Part 1: ECSification, events and steps. (#5017)
- Completely rewrited the `ConstructionComponent` logic to be ECS, *without* looking too much at the original implementation.
- The original implementation was dirty and unmaintainable, whereas this new implementation is much cleaner, well-organized and maintainable. I've made sure to leave many comments around, explaining what everything does.
- Construction now has a framework for handling events other than `InteractUsing`.
- This means that you can now have CGL steps for things other than inserting items, using tools...
- Construction no longer uses `async` everywhere for `DoAfter`s. Instead it uses events.
- Construction event handling occurs in the `ConstructionSystem` update tick, instead of on event handlers.
- This ensures we can delete/modify entities without worrying about "collection modified while enumerating" exceptions.
- This also means the construction update tick is where all the fun happens, meaning it'll show up on our metrics and give us an idea of how expensive it is/how much tick time is spent in construction.
- `IGraphCondition` and `IGraphAction` have been refactored to take in `EntityUid`, `IEntityManager`, and to not be async.
- Removes nested steps, as they made maintainability significantly worse, and nothing used them yet.
- This fixes #4892 and fixes #4857
Please note, this leaves many things unchanged, as my idea is to split this into multiple PRs. Some unchanged things:
- Initial construction code is the same. In the future, it'll probably use dummy entities.
- Client-side guided steps are the same. In the future, the server will generate the guided steps and send them to clients as needed, caching these in both the server and client to save cycles and bandwidth.
- No new construction graph steps... Yet! :eyes:
2021-10-26 16:38:03 +02:00
|
|
|
using Robust.Server.Containers;
|
|
|
|
|
using Robust.Shared.Containers;
|
|
|
|
|
using Robust.Shared.Prototypes;
|
|
|
|
|
|
|
|
|
|
namespace Content.Server.Construction
|
|
|
|
|
{
|
2022-02-16 00:23:23 -07:00
|
|
|
public sealed partial class ConstructionSystem
|
ConstructionGL2 Part 1: ECSification, events and steps. (#5017)
- Completely rewrited the `ConstructionComponent` logic to be ECS, *without* looking too much at the original implementation.
- The original implementation was dirty and unmaintainable, whereas this new implementation is much cleaner, well-organized and maintainable. I've made sure to leave many comments around, explaining what everything does.
- Construction now has a framework for handling events other than `InteractUsing`.
- This means that you can now have CGL steps for things other than inserting items, using tools...
- Construction no longer uses `async` everywhere for `DoAfter`s. Instead it uses events.
- Construction event handling occurs in the `ConstructionSystem` update tick, instead of on event handlers.
- This ensures we can delete/modify entities without worrying about "collection modified while enumerating" exceptions.
- This also means the construction update tick is where all the fun happens, meaning it'll show up on our metrics and give us an idea of how expensive it is/how much tick time is spent in construction.
- `IGraphCondition` and `IGraphAction` have been refactored to take in `EntityUid`, `IEntityManager`, and to not be async.
- Removes nested steps, as they made maintainability significantly worse, and nothing used them yet.
- This fixes #4892 and fixes #4857
Please note, this leaves many things unchanged, as my idea is to split this into multiple PRs. Some unchanged things:
- Initial construction code is the same. In the future, it'll probably use dummy entities.
- Client-side guided steps are the same. In the future, the server will generate the guided steps and send them to clients as needed, caching these in both the server and client to save cycles and bandwidth.
- No new construction graph steps... Yet! :eyes:
2021-10-26 16:38:03 +02:00
|
|
|
{
|
|
|
|
|
private void InitializeGraphs()
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
2022-03-25 05:00:39 +01:00
|
|
|
/// <summary>
|
|
|
|
|
/// Sets a container on an entity as being handled by Construction. This essentially means that it will
|
|
|
|
|
/// be transferred if the entity prototype changes. <seealso cref="ChangeEntity"/>
|
|
|
|
|
/// </summary>
|
|
|
|
|
/// <param name="uid">The target entity.</param>
|
|
|
|
|
/// <param name="container">The container identifier. This method does not check whether the container exists.</param>
|
|
|
|
|
/// <param name="construction">The construction component of the target entity. Will be resolved if null.</param>
|
|
|
|
|
/// <returns>Whether we could set the container as being handled by construction or not. Also returns false if
|
|
|
|
|
/// the entity does not have a <see cref="ConstructionComponent"/>.</returns>
|
ConstructionGL2 Part 1: ECSification, events and steps. (#5017)
- Completely rewrited the `ConstructionComponent` logic to be ECS, *without* looking too much at the original implementation.
- The original implementation was dirty and unmaintainable, whereas this new implementation is much cleaner, well-organized and maintainable. I've made sure to leave many comments around, explaining what everything does.
- Construction now has a framework for handling events other than `InteractUsing`.
- This means that you can now have CGL steps for things other than inserting items, using tools...
- Construction no longer uses `async` everywhere for `DoAfter`s. Instead it uses events.
- Construction event handling occurs in the `ConstructionSystem` update tick, instead of on event handlers.
- This ensures we can delete/modify entities without worrying about "collection modified while enumerating" exceptions.
- This also means the construction update tick is where all the fun happens, meaning it'll show up on our metrics and give us an idea of how expensive it is/how much tick time is spent in construction.
- `IGraphCondition` and `IGraphAction` have been refactored to take in `EntityUid`, `IEntityManager`, and to not be async.
- Removes nested steps, as they made maintainability significantly worse, and nothing used them yet.
- This fixes #4892 and fixes #4857
Please note, this leaves many things unchanged, as my idea is to split this into multiple PRs. Some unchanged things:
- Initial construction code is the same. In the future, it'll probably use dummy entities.
- Client-side guided steps are the same. In the future, the server will generate the guided steps and send them to clients as needed, caching these in both the server and client to save cycles and bandwidth.
- No new construction graph steps... Yet! :eyes:
2021-10-26 16:38:03 +02:00
|
|
|
public bool AddContainer(EntityUid uid, string container, ConstructionComponent? construction = null)
|
|
|
|
|
{
|
|
|
|
|
if (!Resolve(uid, ref construction))
|
|
|
|
|
return false;
|
|
|
|
|
|
|
|
|
|
return construction.Containers.Add(container);
|
|
|
|
|
}
|
|
|
|
|
|
2022-03-25 05:00:39 +01:00
|
|
|
/// <summary>
|
|
|
|
|
/// Gets the current construction graph of an entity, or null.
|
|
|
|
|
/// </summary>
|
|
|
|
|
/// <param name="uid">The target entity.</param>
|
|
|
|
|
/// <param name="construction">The construction component of the target entity. Will be resolved if null.</param>
|
|
|
|
|
/// <returns>The current construction graph of an entity or null if invalid. Also returns null if the entity
|
|
|
|
|
/// does not have a <see cref="ConstructionComponent"/>.</returns>
|
|
|
|
|
/// <remarks>An entity with a valid construction state will always have a valid graph.</remarks>
|
ConstructionGL2 Part 1: ECSification, events and steps. (#5017)
- Completely rewrited the `ConstructionComponent` logic to be ECS, *without* looking too much at the original implementation.
- The original implementation was dirty and unmaintainable, whereas this new implementation is much cleaner, well-organized and maintainable. I've made sure to leave many comments around, explaining what everything does.
- Construction now has a framework for handling events other than `InteractUsing`.
- This means that you can now have CGL steps for things other than inserting items, using tools...
- Construction no longer uses `async` everywhere for `DoAfter`s. Instead it uses events.
- Construction event handling occurs in the `ConstructionSystem` update tick, instead of on event handlers.
- This ensures we can delete/modify entities without worrying about "collection modified while enumerating" exceptions.
- This also means the construction update tick is where all the fun happens, meaning it'll show up on our metrics and give us an idea of how expensive it is/how much tick time is spent in construction.
- `IGraphCondition` and `IGraphAction` have been refactored to take in `EntityUid`, `IEntityManager`, and to not be async.
- Removes nested steps, as they made maintainability significantly worse, and nothing used them yet.
- This fixes #4892 and fixes #4857
Please note, this leaves many things unchanged, as my idea is to split this into multiple PRs. Some unchanged things:
- Initial construction code is the same. In the future, it'll probably use dummy entities.
- Client-side guided steps are the same. In the future, the server will generate the guided steps and send them to clients as needed, caching these in both the server and client to save cycles and bandwidth.
- No new construction graph steps... Yet! :eyes:
2021-10-26 16:38:03 +02:00
|
|
|
public ConstructionGraphPrototype? GetCurrentGraph(EntityUid uid, ConstructionComponent? construction = null)
|
|
|
|
|
{
|
|
|
|
|
if (!Resolve(uid, ref construction, false))
|
|
|
|
|
return null;
|
|
|
|
|
|
2022-03-25 05:00:39 +01:00
|
|
|
// If the set graph prototype does not exist, also return null. This could be due to admemes changing values
|
|
|
|
|
// in ViewVariables, so even though the construction state is invalid, just return null.
|
ConstructionGL2 Part 1: ECSification, events and steps. (#5017)
- Completely rewrited the `ConstructionComponent` logic to be ECS, *without* looking too much at the original implementation.
- The original implementation was dirty and unmaintainable, whereas this new implementation is much cleaner, well-organized and maintainable. I've made sure to leave many comments around, explaining what everything does.
- Construction now has a framework for handling events other than `InteractUsing`.
- This means that you can now have CGL steps for things other than inserting items, using tools...
- Construction no longer uses `async` everywhere for `DoAfter`s. Instead it uses events.
- Construction event handling occurs in the `ConstructionSystem` update tick, instead of on event handlers.
- This ensures we can delete/modify entities without worrying about "collection modified while enumerating" exceptions.
- This also means the construction update tick is where all the fun happens, meaning it'll show up on our metrics and give us an idea of how expensive it is/how much tick time is spent in construction.
- `IGraphCondition` and `IGraphAction` have been refactored to take in `EntityUid`, `IEntityManager`, and to not be async.
- Removes nested steps, as they made maintainability significantly worse, and nothing used them yet.
- This fixes #4892 and fixes #4857
Please note, this leaves many things unchanged, as my idea is to split this into multiple PRs. Some unchanged things:
- Initial construction code is the same. In the future, it'll probably use dummy entities.
- Client-side guided steps are the same. In the future, the server will generate the guided steps and send them to clients as needed, caching these in both the server and client to save cycles and bandwidth.
- No new construction graph steps... Yet! :eyes:
2021-10-26 16:38:03 +02:00
|
|
|
return _prototypeManager.TryIndex(construction.Graph, out ConstructionGraphPrototype? graph) ? graph : null;
|
|
|
|
|
}
|
|
|
|
|
|
2022-03-25 05:00:39 +01:00
|
|
|
/// <summary>
|
|
|
|
|
/// Gets the construction graph node the entity is currently at, or null.
|
|
|
|
|
/// </summary>
|
|
|
|
|
/// <param name="uid">The target entity.</param>
|
|
|
|
|
/// <param name="construction">The construction component of the target entity. Will be resolved if null.</param>
|
|
|
|
|
/// <returns>The current construction graph node the entity is currently at, or null if invalid. Also returns
|
|
|
|
|
/// null if the entity does not have a <see cref="ConstructionComponent"/>.</returns>
|
|
|
|
|
/// <remarks>An entity with a valid construction state will always be at a valid node.</remarks>
|
ConstructionGL2 Part 1: ECSification, events and steps. (#5017)
- Completely rewrited the `ConstructionComponent` logic to be ECS, *without* looking too much at the original implementation.
- The original implementation was dirty and unmaintainable, whereas this new implementation is much cleaner, well-organized and maintainable. I've made sure to leave many comments around, explaining what everything does.
- Construction now has a framework for handling events other than `InteractUsing`.
- This means that you can now have CGL steps for things other than inserting items, using tools...
- Construction no longer uses `async` everywhere for `DoAfter`s. Instead it uses events.
- Construction event handling occurs in the `ConstructionSystem` update tick, instead of on event handlers.
- This ensures we can delete/modify entities without worrying about "collection modified while enumerating" exceptions.
- This also means the construction update tick is where all the fun happens, meaning it'll show up on our metrics and give us an idea of how expensive it is/how much tick time is spent in construction.
- `IGraphCondition` and `IGraphAction` have been refactored to take in `EntityUid`, `IEntityManager`, and to not be async.
- Removes nested steps, as they made maintainability significantly worse, and nothing used them yet.
- This fixes #4892 and fixes #4857
Please note, this leaves many things unchanged, as my idea is to split this into multiple PRs. Some unchanged things:
- Initial construction code is the same. In the future, it'll probably use dummy entities.
- Client-side guided steps are the same. In the future, the server will generate the guided steps and send them to clients as needed, caching these in both the server and client to save cycles and bandwidth.
- No new construction graph steps... Yet! :eyes:
2021-10-26 16:38:03 +02:00
|
|
|
public ConstructionGraphNode? GetCurrentNode(EntityUid uid, ConstructionComponent? construction = null)
|
|
|
|
|
{
|
|
|
|
|
if (!Resolve(uid, ref construction, false))
|
|
|
|
|
return null;
|
|
|
|
|
|
|
|
|
|
if (construction.Node is not {} nodeIdentifier)
|
|
|
|
|
return null;
|
|
|
|
|
|
|
|
|
|
return GetCurrentGraph(uid, construction) is not {} graph ? null : GetNodeFromGraph(graph, nodeIdentifier);
|
|
|
|
|
}
|
|
|
|
|
|
2022-03-25 05:00:39 +01:00
|
|
|
/// <summary>
|
|
|
|
|
/// Gets the construction graph edge the entity is currently at, or null.
|
|
|
|
|
/// </summary>
|
|
|
|
|
/// <param name="uid">The target entity.</param>
|
|
|
|
|
/// <param name="construction">The construction component of the target entity. Will be resolved if null.</param>
|
|
|
|
|
/// <returns>The construction graph edge the entity is currently at, if any. Also returns null if the entity
|
|
|
|
|
/// does not have a <see cref="ConstructionComponent"/>.</returns>
|
|
|
|
|
/// <remarks>An entity with a valid construction state might not always be at an edge.</remarks>
|
ConstructionGL2 Part 1: ECSification, events and steps. (#5017)
- Completely rewrited the `ConstructionComponent` logic to be ECS, *without* looking too much at the original implementation.
- The original implementation was dirty and unmaintainable, whereas this new implementation is much cleaner, well-organized and maintainable. I've made sure to leave many comments around, explaining what everything does.
- Construction now has a framework for handling events other than `InteractUsing`.
- This means that you can now have CGL steps for things other than inserting items, using tools...
- Construction no longer uses `async` everywhere for `DoAfter`s. Instead it uses events.
- Construction event handling occurs in the `ConstructionSystem` update tick, instead of on event handlers.
- This ensures we can delete/modify entities without worrying about "collection modified while enumerating" exceptions.
- This also means the construction update tick is where all the fun happens, meaning it'll show up on our metrics and give us an idea of how expensive it is/how much tick time is spent in construction.
- `IGraphCondition` and `IGraphAction` have been refactored to take in `EntityUid`, `IEntityManager`, and to not be async.
- Removes nested steps, as they made maintainability significantly worse, and nothing used them yet.
- This fixes #4892 and fixes #4857
Please note, this leaves many things unchanged, as my idea is to split this into multiple PRs. Some unchanged things:
- Initial construction code is the same. In the future, it'll probably use dummy entities.
- Client-side guided steps are the same. In the future, the server will generate the guided steps and send them to clients as needed, caching these in both the server and client to save cycles and bandwidth.
- No new construction graph steps... Yet! :eyes:
2021-10-26 16:38:03 +02:00
|
|
|
public ConstructionGraphEdge? GetCurrentEdge(EntityUid uid, ConstructionComponent? construction = null)
|
|
|
|
|
{
|
|
|
|
|
if (!Resolve(uid, ref construction, false))
|
|
|
|
|
return null;
|
|
|
|
|
|
|
|
|
|
if (construction.EdgeIndex is not {} edgeIndex)
|
|
|
|
|
return null;
|
|
|
|
|
|
|
|
|
|
return GetCurrentNode(uid, construction) is not {} node ? null : GetEdgeFromNode(node, edgeIndex);
|
|
|
|
|
}
|
|
|
|
|
|
2023-04-30 09:04:31 +12:00
|
|
|
/// <summary>
|
|
|
|
|
/// Variant of <see cref="GetCurrentEdge"/> that returns both the node and edge.
|
|
|
|
|
/// </summary>
|
|
|
|
|
public (ConstructionGraphNode?, ConstructionGraphEdge?) GetCurrentNodeAndEdge(EntityUid uid, ConstructionComponent? construction = null)
|
|
|
|
|
{
|
|
|
|
|
if (!Resolve(uid, ref construction, false))
|
|
|
|
|
return (null, null);
|
|
|
|
|
|
|
|
|
|
if (GetCurrentNode(uid, construction) is not { } node)
|
|
|
|
|
return (null, null);
|
|
|
|
|
|
|
|
|
|
if (construction.EdgeIndex is not {} edgeIndex)
|
|
|
|
|
return (node, null);
|
|
|
|
|
|
|
|
|
|
return (node, GetEdgeFromNode(node, edgeIndex));
|
|
|
|
|
}
|
|
|
|
|
|
2022-03-25 05:00:39 +01:00
|
|
|
/// <summary>
|
|
|
|
|
/// Gets the construction graph step the entity is currently at, or null.
|
|
|
|
|
/// </summary>
|
|
|
|
|
/// <param name="uid">The target entity.</param>
|
|
|
|
|
/// <param name="construction">The construction component of the target entity. Will be resolved if null.</param>
|
|
|
|
|
/// <returns>The construction graph step the entity is currently at, if any. Also returns null if the entity
|
|
|
|
|
/// does not have a <see cref="ConstructionComponent"/>.</returns>
|
|
|
|
|
/// <remarks>An entity with a valid construction state might not always be at a step or an edge.</remarks>
|
ConstructionGL2 Part 1: ECSification, events and steps. (#5017)
- Completely rewrited the `ConstructionComponent` logic to be ECS, *without* looking too much at the original implementation.
- The original implementation was dirty and unmaintainable, whereas this new implementation is much cleaner, well-organized and maintainable. I've made sure to leave many comments around, explaining what everything does.
- Construction now has a framework for handling events other than `InteractUsing`.
- This means that you can now have CGL steps for things other than inserting items, using tools...
- Construction no longer uses `async` everywhere for `DoAfter`s. Instead it uses events.
- Construction event handling occurs in the `ConstructionSystem` update tick, instead of on event handlers.
- This ensures we can delete/modify entities without worrying about "collection modified while enumerating" exceptions.
- This also means the construction update tick is where all the fun happens, meaning it'll show up on our metrics and give us an idea of how expensive it is/how much tick time is spent in construction.
- `IGraphCondition` and `IGraphAction` have been refactored to take in `EntityUid`, `IEntityManager`, and to not be async.
- Removes nested steps, as they made maintainability significantly worse, and nothing used them yet.
- This fixes #4892 and fixes #4857
Please note, this leaves many things unchanged, as my idea is to split this into multiple PRs. Some unchanged things:
- Initial construction code is the same. In the future, it'll probably use dummy entities.
- Client-side guided steps are the same. In the future, the server will generate the guided steps and send them to clients as needed, caching these in both the server and client to save cycles and bandwidth.
- No new construction graph steps... Yet! :eyes:
2021-10-26 16:38:03 +02:00
|
|
|
public ConstructionGraphStep? GetCurrentStep(EntityUid uid, ConstructionComponent? construction = null)
|
|
|
|
|
{
|
|
|
|
|
if (!Resolve(uid, ref construction, false))
|
|
|
|
|
return null;
|
|
|
|
|
|
|
|
|
|
if (GetCurrentEdge(uid, construction) is not {} edge)
|
|
|
|
|
return null;
|
|
|
|
|
|
|
|
|
|
return GetStepFromEdge(edge, construction.StepIndex);
|
|
|
|
|
}
|
|
|
|
|
|
2022-03-25 05:00:39 +01:00
|
|
|
/// <summary>
|
|
|
|
|
/// Gets the construction graph node the entity's construction pathfinding is currently targeting, if any.
|
|
|
|
|
/// </summary>
|
|
|
|
|
/// <param name="uid">The target entity.</param>
|
|
|
|
|
/// <param name="construction">The construction component of the target entity. Will be resolved if null.</param>
|
|
|
|
|
/// <returns>The construction graph node the entity's construction pathfinding is currently targeting, or null
|
|
|
|
|
/// if it's not currently targeting any node. Also returns null if the entity does not have a
|
|
|
|
|
/// <see cref="ConstructionComponent"/>.</returns>
|
|
|
|
|
/// <remarks>Target nodes are entirely optional and only used for pathfinding purposes.</remarks>
|
ConstructionGL2 Part 1: ECSification, events and steps. (#5017)
- Completely rewrited the `ConstructionComponent` logic to be ECS, *without* looking too much at the original implementation.
- The original implementation was dirty and unmaintainable, whereas this new implementation is much cleaner, well-organized and maintainable. I've made sure to leave many comments around, explaining what everything does.
- Construction now has a framework for handling events other than `InteractUsing`.
- This means that you can now have CGL steps for things other than inserting items, using tools...
- Construction no longer uses `async` everywhere for `DoAfter`s. Instead it uses events.
- Construction event handling occurs in the `ConstructionSystem` update tick, instead of on event handlers.
- This ensures we can delete/modify entities without worrying about "collection modified while enumerating" exceptions.
- This also means the construction update tick is where all the fun happens, meaning it'll show up on our metrics and give us an idea of how expensive it is/how much tick time is spent in construction.
- `IGraphCondition` and `IGraphAction` have been refactored to take in `EntityUid`, `IEntityManager`, and to not be async.
- Removes nested steps, as they made maintainability significantly worse, and nothing used them yet.
- This fixes #4892 and fixes #4857
Please note, this leaves many things unchanged, as my idea is to split this into multiple PRs. Some unchanged things:
- Initial construction code is the same. In the future, it'll probably use dummy entities.
- Client-side guided steps are the same. In the future, the server will generate the guided steps and send them to clients as needed, caching these in both the server and client to save cycles and bandwidth.
- No new construction graph steps... Yet! :eyes:
2021-10-26 16:38:03 +02:00
|
|
|
public ConstructionGraphNode? GetTargetNode(EntityUid uid, ConstructionComponent? construction)
|
|
|
|
|
{
|
|
|
|
|
if (!Resolve(uid, ref construction))
|
|
|
|
|
return null;
|
|
|
|
|
|
|
|
|
|
if (construction.TargetNode is not {} targetNodeId)
|
|
|
|
|
return null;
|
|
|
|
|
|
|
|
|
|
if (GetCurrentGraph(uid, construction) is not {} graph)
|
|
|
|
|
return null;
|
|
|
|
|
|
|
|
|
|
return GetNodeFromGraph(graph, targetNodeId);
|
|
|
|
|
}
|
|
|
|
|
|
2022-03-25 05:00:39 +01:00
|
|
|
/// <summary>
|
|
|
|
|
/// Gets the construction graph edge the entity's construction pathfinding is currently targeting, if any.
|
|
|
|
|
/// </summary>
|
|
|
|
|
/// <param name="uid">The target entity.</param>
|
|
|
|
|
/// <param name="construction">The construction component of the target entity. Will be resolved if null.</param>
|
|
|
|
|
/// <returns>The construction graph edge the entity's construction pathfinding is currently targeting, or null
|
|
|
|
|
/// if it's not currently targeting any edge. Also returns null if the entity does not have a
|
|
|
|
|
/// <see cref="ConstructionComponent"/>.</returns>
|
|
|
|
|
/// <remarks>Target edges are entirely optional and only used for pathfinding purposes. The targeted edge will
|
|
|
|
|
/// be an edge on the current construction node the entity is at.</remarks>
|
ConstructionGL2 Part 1: ECSification, events and steps. (#5017)
- Completely rewrited the `ConstructionComponent` logic to be ECS, *without* looking too much at the original implementation.
- The original implementation was dirty and unmaintainable, whereas this new implementation is much cleaner, well-organized and maintainable. I've made sure to leave many comments around, explaining what everything does.
- Construction now has a framework for handling events other than `InteractUsing`.
- This means that you can now have CGL steps for things other than inserting items, using tools...
- Construction no longer uses `async` everywhere for `DoAfter`s. Instead it uses events.
- Construction event handling occurs in the `ConstructionSystem` update tick, instead of on event handlers.
- This ensures we can delete/modify entities without worrying about "collection modified while enumerating" exceptions.
- This also means the construction update tick is where all the fun happens, meaning it'll show up on our metrics and give us an idea of how expensive it is/how much tick time is spent in construction.
- `IGraphCondition` and `IGraphAction` have been refactored to take in `EntityUid`, `IEntityManager`, and to not be async.
- Removes nested steps, as they made maintainability significantly worse, and nothing used them yet.
- This fixes #4892 and fixes #4857
Please note, this leaves many things unchanged, as my idea is to split this into multiple PRs. Some unchanged things:
- Initial construction code is the same. In the future, it'll probably use dummy entities.
- Client-side guided steps are the same. In the future, the server will generate the guided steps and send them to clients as needed, caching these in both the server and client to save cycles and bandwidth.
- No new construction graph steps... Yet! :eyes:
2021-10-26 16:38:03 +02:00
|
|
|
public ConstructionGraphEdge? GetTargetEdge(EntityUid uid, ConstructionComponent? construction)
|
|
|
|
|
{
|
|
|
|
|
if (!Resolve(uid, ref construction))
|
|
|
|
|
return null;
|
|
|
|
|
|
|
|
|
|
if (construction.TargetEdgeIndex is not {} targetEdgeIndex)
|
|
|
|
|
return null;
|
|
|
|
|
|
|
|
|
|
if (GetCurrentNode(uid, construction) is not {} node)
|
|
|
|
|
return null;
|
|
|
|
|
|
|
|
|
|
return GetEdgeFromNode(node, targetEdgeIndex);
|
|
|
|
|
}
|
|
|
|
|
|
2022-03-25 05:00:39 +01:00
|
|
|
/// <summary>
|
|
|
|
|
/// Gets both the construction edge and step the entity is currently at, if any.
|
|
|
|
|
/// </summary>
|
|
|
|
|
/// <param name="uid">The target entity.</param>
|
|
|
|
|
/// <param name="construction">The construction component of the target entity. Will be resolved if null.</param>
|
|
|
|
|
/// <returns>A tuple containing the current edge and step the entity's construction state is at.</returns>
|
|
|
|
|
/// <remarks>The edge, step or both could be null. A valid construction state does not necessarily need them.</remarks>
|
ConstructionGL2 Part 1: ECSification, events and steps. (#5017)
- Completely rewrited the `ConstructionComponent` logic to be ECS, *without* looking too much at the original implementation.
- The original implementation was dirty and unmaintainable, whereas this new implementation is much cleaner, well-organized and maintainable. I've made sure to leave many comments around, explaining what everything does.
- Construction now has a framework for handling events other than `InteractUsing`.
- This means that you can now have CGL steps for things other than inserting items, using tools...
- Construction no longer uses `async` everywhere for `DoAfter`s. Instead it uses events.
- Construction event handling occurs in the `ConstructionSystem` update tick, instead of on event handlers.
- This ensures we can delete/modify entities without worrying about "collection modified while enumerating" exceptions.
- This also means the construction update tick is where all the fun happens, meaning it'll show up on our metrics and give us an idea of how expensive it is/how much tick time is spent in construction.
- `IGraphCondition` and `IGraphAction` have been refactored to take in `EntityUid`, `IEntityManager`, and to not be async.
- Removes nested steps, as they made maintainability significantly worse, and nothing used them yet.
- This fixes #4892 and fixes #4857
Please note, this leaves many things unchanged, as my idea is to split this into multiple PRs. Some unchanged things:
- Initial construction code is the same. In the future, it'll probably use dummy entities.
- Client-side guided steps are the same. In the future, the server will generate the guided steps and send them to clients as needed, caching these in both the server and client to save cycles and bandwidth.
- No new construction graph steps... Yet! :eyes:
2021-10-26 16:38:03 +02:00
|
|
|
public (ConstructionGraphEdge? edge, ConstructionGraphStep? step) GetCurrentEdgeAndStep(EntityUid uid,
|
|
|
|
|
ConstructionComponent? construction = null)
|
|
|
|
|
{
|
|
|
|
|
if (!Resolve(uid, ref construction, false))
|
|
|
|
|
return default;
|
|
|
|
|
|
|
|
|
|
var edge = GetCurrentEdge(uid, construction);
|
|
|
|
|
|
|
|
|
|
if (edge == null)
|
|
|
|
|
return default;
|
|
|
|
|
|
|
|
|
|
var step = GetStepFromEdge(edge, construction.StepIndex);
|
|
|
|
|
|
|
|
|
|
return (edge, step);
|
|
|
|
|
}
|
|
|
|
|
|
2022-03-25 05:00:39 +01:00
|
|
|
/// <summary>
|
|
|
|
|
/// Gets a node from a construction graph given its identifier.
|
|
|
|
|
/// </summary>
|
|
|
|
|
/// <param name="graph">The construction graph where to get the node.</param>
|
|
|
|
|
/// <param name="id">The identifier that corresponds to the node.</param>
|
|
|
|
|
/// <returns>The node that corresponds to the identifier, or null if it doesn't exist.</returns>
|
ConstructionGL2 Part 1: ECSification, events and steps. (#5017)
- Completely rewrited the `ConstructionComponent` logic to be ECS, *without* looking too much at the original implementation.
- The original implementation was dirty and unmaintainable, whereas this new implementation is much cleaner, well-organized and maintainable. I've made sure to leave many comments around, explaining what everything does.
- Construction now has a framework for handling events other than `InteractUsing`.
- This means that you can now have CGL steps for things other than inserting items, using tools...
- Construction no longer uses `async` everywhere for `DoAfter`s. Instead it uses events.
- Construction event handling occurs in the `ConstructionSystem` update tick, instead of on event handlers.
- This ensures we can delete/modify entities without worrying about "collection modified while enumerating" exceptions.
- This also means the construction update tick is where all the fun happens, meaning it'll show up on our metrics and give us an idea of how expensive it is/how much tick time is spent in construction.
- `IGraphCondition` and `IGraphAction` have been refactored to take in `EntityUid`, `IEntityManager`, and to not be async.
- Removes nested steps, as they made maintainability significantly worse, and nothing used them yet.
- This fixes #4892 and fixes #4857
Please note, this leaves many things unchanged, as my idea is to split this into multiple PRs. Some unchanged things:
- Initial construction code is the same. In the future, it'll probably use dummy entities.
- Client-side guided steps are the same. In the future, the server will generate the guided steps and send them to clients as needed, caching these in both the server and client to save cycles and bandwidth.
- No new construction graph steps... Yet! :eyes:
2021-10-26 16:38:03 +02:00
|
|
|
public ConstructionGraphNode? GetNodeFromGraph(ConstructionGraphPrototype graph, string id)
|
|
|
|
|
{
|
|
|
|
|
return graph.Nodes.TryGetValue(id, out var node) ? node : null;
|
|
|
|
|
}
|
|
|
|
|
|
2022-03-25 05:00:39 +01:00
|
|
|
/// <summary>
|
|
|
|
|
/// Gets an edge from a construction node given its index.
|
|
|
|
|
/// </summary>
|
|
|
|
|
/// <param name="node">The construction node where to get the edge.</param>
|
|
|
|
|
/// <param name="index">The index or position of the edge on the node.</param>
|
|
|
|
|
/// <returns>The edge on that index in the construction node, or null if none.</returns>
|
ConstructionGL2 Part 1: ECSification, events and steps. (#5017)
- Completely rewrited the `ConstructionComponent` logic to be ECS, *without* looking too much at the original implementation.
- The original implementation was dirty and unmaintainable, whereas this new implementation is much cleaner, well-organized and maintainable. I've made sure to leave many comments around, explaining what everything does.
- Construction now has a framework for handling events other than `InteractUsing`.
- This means that you can now have CGL steps for things other than inserting items, using tools...
- Construction no longer uses `async` everywhere for `DoAfter`s. Instead it uses events.
- Construction event handling occurs in the `ConstructionSystem` update tick, instead of on event handlers.
- This ensures we can delete/modify entities without worrying about "collection modified while enumerating" exceptions.
- This also means the construction update tick is where all the fun happens, meaning it'll show up on our metrics and give us an idea of how expensive it is/how much tick time is spent in construction.
- `IGraphCondition` and `IGraphAction` have been refactored to take in `EntityUid`, `IEntityManager`, and to not be async.
- Removes nested steps, as they made maintainability significantly worse, and nothing used them yet.
- This fixes #4892 and fixes #4857
Please note, this leaves many things unchanged, as my idea is to split this into multiple PRs. Some unchanged things:
- Initial construction code is the same. In the future, it'll probably use dummy entities.
- Client-side guided steps are the same. In the future, the server will generate the guided steps and send them to clients as needed, caching these in both the server and client to save cycles and bandwidth.
- No new construction graph steps... Yet! :eyes:
2021-10-26 16:38:03 +02:00
|
|
|
public ConstructionGraphEdge? GetEdgeFromNode(ConstructionGraphNode node, int index)
|
|
|
|
|
{
|
|
|
|
|
return node.Edges.Count > index ? node.Edges[index] : null;
|
|
|
|
|
}
|
|
|
|
|
|
2022-03-25 05:00:39 +01:00
|
|
|
/// <summary>
|
|
|
|
|
/// Gets a step from a construction edge given its index.
|
|
|
|
|
/// </summary>
|
|
|
|
|
/// <param name="edge">The construction edge where to get the step.</param>
|
|
|
|
|
/// <param name="index">The index or position of the step on the edge.</param>
|
|
|
|
|
/// <returns>The edge on that index in the construction edge, or null if none.</returns>
|
ConstructionGL2 Part 1: ECSification, events and steps. (#5017)
- Completely rewrited the `ConstructionComponent` logic to be ECS, *without* looking too much at the original implementation.
- The original implementation was dirty and unmaintainable, whereas this new implementation is much cleaner, well-organized and maintainable. I've made sure to leave many comments around, explaining what everything does.
- Construction now has a framework for handling events other than `InteractUsing`.
- This means that you can now have CGL steps for things other than inserting items, using tools...
- Construction no longer uses `async` everywhere for `DoAfter`s. Instead it uses events.
- Construction event handling occurs in the `ConstructionSystem` update tick, instead of on event handlers.
- This ensures we can delete/modify entities without worrying about "collection modified while enumerating" exceptions.
- This also means the construction update tick is where all the fun happens, meaning it'll show up on our metrics and give us an idea of how expensive it is/how much tick time is spent in construction.
- `IGraphCondition` and `IGraphAction` have been refactored to take in `EntityUid`, `IEntityManager`, and to not be async.
- Removes nested steps, as they made maintainability significantly worse, and nothing used them yet.
- This fixes #4892 and fixes #4857
Please note, this leaves many things unchanged, as my idea is to split this into multiple PRs. Some unchanged things:
- Initial construction code is the same. In the future, it'll probably use dummy entities.
- Client-side guided steps are the same. In the future, the server will generate the guided steps and send them to clients as needed, caching these in both the server and client to save cycles and bandwidth.
- No new construction graph steps... Yet! :eyes:
2021-10-26 16:38:03 +02:00
|
|
|
public ConstructionGraphStep? GetStepFromEdge(ConstructionGraphEdge edge, int index)
|
|
|
|
|
{
|
|
|
|
|
return edge.Steps.Count > index ? edge.Steps[index] : null;
|
|
|
|
|
}
|
|
|
|
|
|
2022-03-25 05:00:39 +01:00
|
|
|
/// <summary>
|
|
|
|
|
/// Performs a node change on a construction entity, optionally performing the actions for the new node.
|
|
|
|
|
/// </summary>
|
|
|
|
|
/// <param name="uid">The target entity.</param>
|
|
|
|
|
/// <param name="userUid">An optional user entity, for actions.</param>
|
|
|
|
|
/// <param name="id">The identifier of the node to change to.</param>
|
|
|
|
|
/// <param name="performActions">Whether the actions for the new node will be performed or not.</param>
|
|
|
|
|
/// <param name="construction">The construction component of the target entity. Will be resolved if null.</param>
|
|
|
|
|
/// <returns>Whether the node change succeeded or not. Also returns false if the entity does not have a <see cref="ConstructionComponent"/>.</returns>
|
|
|
|
|
/// <remarks>This method also updates the construction pathfinding automatically, if the node change succeeds.</remarks>
|
ConstructionGL2 Part 1: ECSification, events and steps. (#5017)
- Completely rewrited the `ConstructionComponent` logic to be ECS, *without* looking too much at the original implementation.
- The original implementation was dirty and unmaintainable, whereas this new implementation is much cleaner, well-organized and maintainable. I've made sure to leave many comments around, explaining what everything does.
- Construction now has a framework for handling events other than `InteractUsing`.
- This means that you can now have CGL steps for things other than inserting items, using tools...
- Construction no longer uses `async` everywhere for `DoAfter`s. Instead it uses events.
- Construction event handling occurs in the `ConstructionSystem` update tick, instead of on event handlers.
- This ensures we can delete/modify entities without worrying about "collection modified while enumerating" exceptions.
- This also means the construction update tick is where all the fun happens, meaning it'll show up on our metrics and give us an idea of how expensive it is/how much tick time is spent in construction.
- `IGraphCondition` and `IGraphAction` have been refactored to take in `EntityUid`, `IEntityManager`, and to not be async.
- Removes nested steps, as they made maintainability significantly worse, and nothing used them yet.
- This fixes #4892 and fixes #4857
Please note, this leaves many things unchanged, as my idea is to split this into multiple PRs. Some unchanged things:
- Initial construction code is the same. In the future, it'll probably use dummy entities.
- Client-side guided steps are the same. In the future, the server will generate the guided steps and send them to clients as needed, caching these in both the server and client to save cycles and bandwidth.
- No new construction graph steps... Yet! :eyes:
2021-10-26 16:38:03 +02:00
|
|
|
public bool ChangeNode(EntityUid uid, EntityUid? userUid, string id, bool performActions = true, ConstructionComponent? construction = null)
|
|
|
|
|
{
|
|
|
|
|
if (!Resolve(uid, ref construction))
|
|
|
|
|
return false;
|
|
|
|
|
|
|
|
|
|
if (GetCurrentGraph(uid, construction) is not {} graph
|
|
|
|
|
|| GetNodeFromGraph(graph, id) is not {} node)
|
|
|
|
|
return false;
|
|
|
|
|
|
2022-11-16 12:10:27 +01:00
|
|
|
var oldNode = construction.Node;
|
ConstructionGL2 Part 1: ECSification, events and steps. (#5017)
- Completely rewrited the `ConstructionComponent` logic to be ECS, *without* looking too much at the original implementation.
- The original implementation was dirty and unmaintainable, whereas this new implementation is much cleaner, well-organized and maintainable. I've made sure to leave many comments around, explaining what everything does.
- Construction now has a framework for handling events other than `InteractUsing`.
- This means that you can now have CGL steps for things other than inserting items, using tools...
- Construction no longer uses `async` everywhere for `DoAfter`s. Instead it uses events.
- Construction event handling occurs in the `ConstructionSystem` update tick, instead of on event handlers.
- This ensures we can delete/modify entities without worrying about "collection modified while enumerating" exceptions.
- This also means the construction update tick is where all the fun happens, meaning it'll show up on our metrics and give us an idea of how expensive it is/how much tick time is spent in construction.
- `IGraphCondition` and `IGraphAction` have been refactored to take in `EntityUid`, `IEntityManager`, and to not be async.
- Removes nested steps, as they made maintainability significantly worse, and nothing used them yet.
- This fixes #4892 and fixes #4857
Please note, this leaves many things unchanged, as my idea is to split this into multiple PRs. Some unchanged things:
- Initial construction code is the same. In the future, it'll probably use dummy entities.
- Client-side guided steps are the same. In the future, the server will generate the guided steps and send them to clients as needed, caching these in both the server and client to save cycles and bandwidth.
- No new construction graph steps... Yet! :eyes:
2021-10-26 16:38:03 +02:00
|
|
|
construction.Node = id;
|
|
|
|
|
|
2022-11-16 12:10:27 +01:00
|
|
|
if (userUid != null)
|
|
|
|
|
_adminLogger.Add(LogType.Construction, LogImpact.Low,
|
|
|
|
|
$"{ToPrettyString(userUid.Value):player} changed {ToPrettyString(uid):entity}'s node from \"{oldNode}\" to \"{id}\"");
|
|
|
|
|
|
2022-09-11 10:56:03 +02:00
|
|
|
// ChangeEntity will handle the pathfinding update.
|
2023-07-13 12:23:52 +02:00
|
|
|
if (node.Entity.GetId(uid, userUid, new(EntityManager)) is {} newEntity
|
|
|
|
|
&& ChangeEntity(uid, userUid, newEntity, construction) != null)
|
2022-09-11 10:56:03 +02:00
|
|
|
return true;
|
|
|
|
|
|
ConstructionGL2 Part 1: ECSification, events and steps. (#5017)
- Completely rewrited the `ConstructionComponent` logic to be ECS, *without* looking too much at the original implementation.
- The original implementation was dirty and unmaintainable, whereas this new implementation is much cleaner, well-organized and maintainable. I've made sure to leave many comments around, explaining what everything does.
- Construction now has a framework for handling events other than `InteractUsing`.
- This means that you can now have CGL steps for things other than inserting items, using tools...
- Construction no longer uses `async` everywhere for `DoAfter`s. Instead it uses events.
- Construction event handling occurs in the `ConstructionSystem` update tick, instead of on event handlers.
- This ensures we can delete/modify entities without worrying about "collection modified while enumerating" exceptions.
- This also means the construction update tick is where all the fun happens, meaning it'll show up on our metrics and give us an idea of how expensive it is/how much tick time is spent in construction.
- `IGraphCondition` and `IGraphAction` have been refactored to take in `EntityUid`, `IEntityManager`, and to not be async.
- Removes nested steps, as they made maintainability significantly worse, and nothing used them yet.
- This fixes #4892 and fixes #4857
Please note, this leaves many things unchanged, as my idea is to split this into multiple PRs. Some unchanged things:
- Initial construction code is the same. In the future, it'll probably use dummy entities.
- Client-side guided steps are the same. In the future, the server will generate the guided steps and send them to clients as needed, caching these in both the server and client to save cycles and bandwidth.
- No new construction graph steps... Yet! :eyes:
2021-10-26 16:38:03 +02:00
|
|
|
if(performActions)
|
|
|
|
|
PerformActions(uid, userUid, node.Actions);
|
|
|
|
|
|
2022-03-05 10:58:30 +01:00
|
|
|
// An action might have deleted the entity... Account for this.
|
|
|
|
|
if (!Exists(uid))
|
|
|
|
|
return false;
|
|
|
|
|
|
ConstructionGL2 Part 1: ECSification, events and steps. (#5017)
- Completely rewrited the `ConstructionComponent` logic to be ECS, *without* looking too much at the original implementation.
- The original implementation was dirty and unmaintainable, whereas this new implementation is much cleaner, well-organized and maintainable. I've made sure to leave many comments around, explaining what everything does.
- Construction now has a framework for handling events other than `InteractUsing`.
- This means that you can now have CGL steps for things other than inserting items, using tools...
- Construction no longer uses `async` everywhere for `DoAfter`s. Instead it uses events.
- Construction event handling occurs in the `ConstructionSystem` update tick, instead of on event handlers.
- This ensures we can delete/modify entities without worrying about "collection modified while enumerating" exceptions.
- This also means the construction update tick is where all the fun happens, meaning it'll show up on our metrics and give us an idea of how expensive it is/how much tick time is spent in construction.
- `IGraphCondition` and `IGraphAction` have been refactored to take in `EntityUid`, `IEntityManager`, and to not be async.
- Removes nested steps, as they made maintainability significantly worse, and nothing used them yet.
- This fixes #4892 and fixes #4857
Please note, this leaves many things unchanged, as my idea is to split this into multiple PRs. Some unchanged things:
- Initial construction code is the same. In the future, it'll probably use dummy entities.
- Client-side guided steps are the same. In the future, the server will generate the guided steps and send them to clients as needed, caching these in both the server and client to save cycles and bandwidth.
- No new construction graph steps... Yet! :eyes:
2021-10-26 16:38:03 +02:00
|
|
|
UpdatePathfinding(uid, construction);
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
2022-03-25 05:00:39 +01:00
|
|
|
/// <summary>
|
|
|
|
|
/// Performs an entity prototype change on a construction entity.
|
|
|
|
|
/// The old entity will be removed, and a new one will be spawned in its place. Some values will be kept,
|
|
|
|
|
/// and any containers handled by construction will be transferred to the new entity as well.
|
|
|
|
|
/// </summary>
|
|
|
|
|
/// <param name="uid">The target entity.</param>
|
|
|
|
|
/// <param name="userUid">An optional user entity, for actions.</param>
|
|
|
|
|
/// <param name="newEntity">The entity prototype identifier for the new entity.</param>
|
|
|
|
|
/// <param name="construction">The construction component of the target entity. Will be resolved if null.</param>
|
|
|
|
|
/// <param name="metaData">The metadata component of the target entity. Will be resolved if null.</param>
|
|
|
|
|
/// <param name="transform">The transform component of the target entity. Will be resolved if null.</param>
|
|
|
|
|
/// <param name="containerManager">The container manager component of the target entity. Will be resolved if null,
|
|
|
|
|
/// but it is an optional component and not required for the method to work.</param>
|
|
|
|
|
/// <returns>The new entity, or null if the method did not succeed.</returns>
|
ConstructionGL2 Part 1: ECSification, events and steps. (#5017)
- Completely rewrited the `ConstructionComponent` logic to be ECS, *without* looking too much at the original implementation.
- The original implementation was dirty and unmaintainable, whereas this new implementation is much cleaner, well-organized and maintainable. I've made sure to leave many comments around, explaining what everything does.
- Construction now has a framework for handling events other than `InteractUsing`.
- This means that you can now have CGL steps for things other than inserting items, using tools...
- Construction no longer uses `async` everywhere for `DoAfter`s. Instead it uses events.
- Construction event handling occurs in the `ConstructionSystem` update tick, instead of on event handlers.
- This ensures we can delete/modify entities without worrying about "collection modified while enumerating" exceptions.
- This also means the construction update tick is where all the fun happens, meaning it'll show up on our metrics and give us an idea of how expensive it is/how much tick time is spent in construction.
- `IGraphCondition` and `IGraphAction` have been refactored to take in `EntityUid`, `IEntityManager`, and to not be async.
- Removes nested steps, as they made maintainability significantly worse, and nothing used them yet.
- This fixes #4892 and fixes #4857
Please note, this leaves many things unchanged, as my idea is to split this into multiple PRs. Some unchanged things:
- Initial construction code is the same. In the future, it'll probably use dummy entities.
- Client-side guided steps are the same. In the future, the server will generate the guided steps and send them to clients as needed, caching these in both the server and client to save cycles and bandwidth.
- No new construction graph steps... Yet! :eyes:
2021-10-26 16:38:03 +02:00
|
|
|
private EntityUid? ChangeEntity(EntityUid uid, EntityUid? userUid, string newEntity,
|
|
|
|
|
ConstructionComponent? construction = null,
|
|
|
|
|
MetaDataComponent? metaData = null,
|
2021-11-08 12:37:32 +01:00
|
|
|
TransformComponent? transform = null,
|
ConstructionGL2 Part 1: ECSification, events and steps. (#5017)
- Completely rewrited the `ConstructionComponent` logic to be ECS, *without* looking too much at the original implementation.
- The original implementation was dirty and unmaintainable, whereas this new implementation is much cleaner, well-organized and maintainable. I've made sure to leave many comments around, explaining what everything does.
- Construction now has a framework for handling events other than `InteractUsing`.
- This means that you can now have CGL steps for things other than inserting items, using tools...
- Construction no longer uses `async` everywhere for `DoAfter`s. Instead it uses events.
- Construction event handling occurs in the `ConstructionSystem` update tick, instead of on event handlers.
- This ensures we can delete/modify entities without worrying about "collection modified while enumerating" exceptions.
- This also means the construction update tick is where all the fun happens, meaning it'll show up on our metrics and give us an idea of how expensive it is/how much tick time is spent in construction.
- `IGraphCondition` and `IGraphAction` have been refactored to take in `EntityUid`, `IEntityManager`, and to not be async.
- Removes nested steps, as they made maintainability significantly worse, and nothing used them yet.
- This fixes #4892 and fixes #4857
Please note, this leaves many things unchanged, as my idea is to split this into multiple PRs. Some unchanged things:
- Initial construction code is the same. In the future, it'll probably use dummy entities.
- Client-side guided steps are the same. In the future, the server will generate the guided steps and send them to clients as needed, caching these in both the server and client to save cycles and bandwidth.
- No new construction graph steps... Yet! :eyes:
2021-10-26 16:38:03 +02:00
|
|
|
ContainerManagerComponent? containerManager = null)
|
|
|
|
|
{
|
|
|
|
|
if (!Resolve(uid, ref construction, ref metaData, ref transform))
|
2022-10-17 04:58:07 +13:00
|
|
|
{
|
|
|
|
|
// Failed resolve logs an error, but we want to actually log information about the failed construction
|
|
|
|
|
// graph. So lets let the UpdateInteractions() try-catch log that info for us.
|
|
|
|
|
throw new Exception("Missing construction components");
|
|
|
|
|
}
|
ConstructionGL2 Part 1: ECSification, events and steps. (#5017)
- Completely rewrited the `ConstructionComponent` logic to be ECS, *without* looking too much at the original implementation.
- The original implementation was dirty and unmaintainable, whereas this new implementation is much cleaner, well-organized and maintainable. I've made sure to leave many comments around, explaining what everything does.
- Construction now has a framework for handling events other than `InteractUsing`.
- This means that you can now have CGL steps for things other than inserting items, using tools...
- Construction no longer uses `async` everywhere for `DoAfter`s. Instead it uses events.
- Construction event handling occurs in the `ConstructionSystem` update tick, instead of on event handlers.
- This ensures we can delete/modify entities without worrying about "collection modified while enumerating" exceptions.
- This also means the construction update tick is where all the fun happens, meaning it'll show up on our metrics and give us an idea of how expensive it is/how much tick time is spent in construction.
- `IGraphCondition` and `IGraphAction` have been refactored to take in `EntityUid`, `IEntityManager`, and to not be async.
- Removes nested steps, as they made maintainability significantly worse, and nothing used them yet.
- This fixes #4892 and fixes #4857
Please note, this leaves many things unchanged, as my idea is to split this into multiple PRs. Some unchanged things:
- Initial construction code is the same. In the future, it'll probably use dummy entities.
- Client-side guided steps are the same. In the future, the server will generate the guided steps and send them to clients as needed, caching these in both the server and client to save cycles and bandwidth.
- No new construction graph steps... Yet! :eyes:
2021-10-26 16:38:03 +02:00
|
|
|
|
|
|
|
|
if (newEntity == metaData.EntityPrototype?.ID || !_prototypeManager.HasIndex<EntityPrototype>(newEntity))
|
|
|
|
|
return null;
|
|
|
|
|
|
|
|
|
|
// Optional resolves.
|
|
|
|
|
Resolve(uid, ref containerManager, false);
|
|
|
|
|
|
|
|
|
|
// We create the new entity.
|
2022-10-17 05:43:33 +13:00
|
|
|
var newUid = EntityManager.CreateEntityUninitialized(newEntity, transform.Coordinates);
|
ConstructionGL2 Part 1: ECSification, events and steps. (#5017)
- Completely rewrited the `ConstructionComponent` logic to be ECS, *without* looking too much at the original implementation.
- The original implementation was dirty and unmaintainable, whereas this new implementation is much cleaner, well-organized and maintainable. I've made sure to leave many comments around, explaining what everything does.
- Construction now has a framework for handling events other than `InteractUsing`.
- This means that you can now have CGL steps for things other than inserting items, using tools...
- Construction no longer uses `async` everywhere for `DoAfter`s. Instead it uses events.
- Construction event handling occurs in the `ConstructionSystem` update tick, instead of on event handlers.
- This ensures we can delete/modify entities without worrying about "collection modified while enumerating" exceptions.
- This also means the construction update tick is where all the fun happens, meaning it'll show up on our metrics and give us an idea of how expensive it is/how much tick time is spent in construction.
- `IGraphCondition` and `IGraphAction` have been refactored to take in `EntityUid`, `IEntityManager`, and to not be async.
- Removes nested steps, as they made maintainability significantly worse, and nothing used them yet.
- This fixes #4892 and fixes #4857
Please note, this leaves many things unchanged, as my idea is to split this into multiple PRs. Some unchanged things:
- Initial construction code is the same. In the future, it'll probably use dummy entities.
- Client-side guided steps are the same. In the future, the server will generate the guided steps and send them to clients as needed, caching these in both the server and client to save cycles and bandwidth.
- No new construction graph steps... Yet! :eyes:
2021-10-26 16:38:03 +02:00
|
|
|
|
|
|
|
|
// Construction transferring.
|
|
|
|
|
var newConstruction = EntityManager.EnsureComponent<ConstructionComponent>(newUid);
|
|
|
|
|
|
2022-10-17 05:43:33 +13:00
|
|
|
// Transfer all construction-owned containers.
|
|
|
|
|
newConstruction.Containers.UnionWith(construction.Containers);
|
|
|
|
|
|
|
|
|
|
// Prevent MapInitEvent spawned entities from spawning into the containers.
|
|
|
|
|
// Containers created by ChangeNode() actions do not exist until after this function is complete,
|
|
|
|
|
// but this should be fine, as long as the target entity properly declared its managed containers.
|
|
|
|
|
if (TryComp(newUid, out ContainerFillComponent? containerFill) && containerFill.IgnoreConstructionSpawn)
|
|
|
|
|
{
|
|
|
|
|
foreach (var id in newConstruction.Containers)
|
|
|
|
|
{
|
|
|
|
|
containerFill.Containers.Remove(id);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// We set the graph and node accordingly.
|
ConstructionGL2 Part 1: ECSification, events and steps. (#5017)
- Completely rewrited the `ConstructionComponent` logic to be ECS, *without* looking too much at the original implementation.
- The original implementation was dirty and unmaintainable, whereas this new implementation is much cleaner, well-organized and maintainable. I've made sure to leave many comments around, explaining what everything does.
- Construction now has a framework for handling events other than `InteractUsing`.
- This means that you can now have CGL steps for things other than inserting items, using tools...
- Construction no longer uses `async` everywhere for `DoAfter`s. Instead it uses events.
- Construction event handling occurs in the `ConstructionSystem` update tick, instead of on event handlers.
- This ensures we can delete/modify entities without worrying about "collection modified while enumerating" exceptions.
- This also means the construction update tick is where all the fun happens, meaning it'll show up on our metrics and give us an idea of how expensive it is/how much tick time is spent in construction.
- `IGraphCondition` and `IGraphAction` have been refactored to take in `EntityUid`, `IEntityManager`, and to not be async.
- Removes nested steps, as they made maintainability significantly worse, and nothing used them yet.
- This fixes #4892 and fixes #4857
Please note, this leaves many things unchanged, as my idea is to split this into multiple PRs. Some unchanged things:
- Initial construction code is the same. In the future, it'll probably use dummy entities.
- Client-side guided steps are the same. In the future, the server will generate the guided steps and send them to clients as needed, caching these in both the server and client to save cycles and bandwidth.
- No new construction graph steps... Yet! :eyes:
2021-10-26 16:38:03 +02:00
|
|
|
ChangeGraph(newUid, userUid, construction.Graph, construction.Node, false, newConstruction);
|
|
|
|
|
|
|
|
|
|
if (construction.TargetNode is {} targetNode)
|
|
|
|
|
SetPathfindingTarget(newUid, targetNode, newConstruction);
|
|
|
|
|
|
|
|
|
|
// Transfer all pending interaction events too.
|
|
|
|
|
while (construction.InteractionQueue.TryDequeue(out var ev))
|
|
|
|
|
{
|
|
|
|
|
newConstruction.InteractionQueue.Enqueue(ev);
|
|
|
|
|
}
|
|
|
|
|
|
2023-02-26 06:14:26 +13:00
|
|
|
if (newConstruction.InteractionQueue.Count > 0 && _queuedUpdates.Add(newUid))
|
|
|
|
|
_constructionUpdateQueue.Enqueue(newUid);
|
|
|
|
|
|
ConstructionGL2 Part 1: ECSification, events and steps. (#5017)
- Completely rewrited the `ConstructionComponent` logic to be ECS, *without* looking too much at the original implementation.
- The original implementation was dirty and unmaintainable, whereas this new implementation is much cleaner, well-organized and maintainable. I've made sure to leave many comments around, explaining what everything does.
- Construction now has a framework for handling events other than `InteractUsing`.
- This means that you can now have CGL steps for things other than inserting items, using tools...
- Construction no longer uses `async` everywhere for `DoAfter`s. Instead it uses events.
- Construction event handling occurs in the `ConstructionSystem` update tick, instead of on event handlers.
- This ensures we can delete/modify entities without worrying about "collection modified while enumerating" exceptions.
- This also means the construction update tick is where all the fun happens, meaning it'll show up on our metrics and give us an idea of how expensive it is/how much tick time is spent in construction.
- `IGraphCondition` and `IGraphAction` have been refactored to take in `EntityUid`, `IEntityManager`, and to not be async.
- Removes nested steps, as they made maintainability significantly worse, and nothing used them yet.
- This fixes #4892 and fixes #4857
Please note, this leaves many things unchanged, as my idea is to split this into multiple PRs. Some unchanged things:
- Initial construction code is the same. In the future, it'll probably use dummy entities.
- Client-side guided steps are the same. In the future, the server will generate the guided steps and send them to clients as needed, caching these in both the server and client to save cycles and bandwidth.
- No new construction graph steps... Yet! :eyes:
2021-10-26 16:38:03 +02:00
|
|
|
// Transform transferring.
|
2022-03-25 05:00:39 +01:00
|
|
|
var newTransform = Transform(newUid);
|
2023-05-04 11:03:45 -08:00
|
|
|
newTransform.AttachToGridOrMap(); // in case in hands or a container
|
ConstructionGL2 Part 1: ECSification, events and steps. (#5017)
- Completely rewrited the `ConstructionComponent` logic to be ECS, *without* looking too much at the original implementation.
- The original implementation was dirty and unmaintainable, whereas this new implementation is much cleaner, well-organized and maintainable. I've made sure to leave many comments around, explaining what everything does.
- Construction now has a framework for handling events other than `InteractUsing`.
- This means that you can now have CGL steps for things other than inserting items, using tools...
- Construction no longer uses `async` everywhere for `DoAfter`s. Instead it uses events.
- Construction event handling occurs in the `ConstructionSystem` update tick, instead of on event handlers.
- This ensures we can delete/modify entities without worrying about "collection modified while enumerating" exceptions.
- This also means the construction update tick is where all the fun happens, meaning it'll show up on our metrics and give us an idea of how expensive it is/how much tick time is spent in construction.
- `IGraphCondition` and `IGraphAction` have been refactored to take in `EntityUid`, `IEntityManager`, and to not be async.
- Removes nested steps, as they made maintainability significantly worse, and nothing used them yet.
- This fixes #4892 and fixes #4857
Please note, this leaves many things unchanged, as my idea is to split this into multiple PRs. Some unchanged things:
- Initial construction code is the same. In the future, it'll probably use dummy entities.
- Client-side guided steps are the same. In the future, the server will generate the guided steps and send them to clients as needed, caching these in both the server and client to save cycles and bandwidth.
- No new construction graph steps... Yet! :eyes:
2021-10-26 16:38:03 +02:00
|
|
|
newTransform.LocalRotation = transform.LocalRotation;
|
|
|
|
|
newTransform.Anchored = transform.Anchored;
|
|
|
|
|
|
|
|
|
|
// Container transferring.
|
|
|
|
|
if (containerManager != null)
|
|
|
|
|
{
|
|
|
|
|
// Ensure the new entity has a container manager. Also for resolve goodness.
|
|
|
|
|
var newContainerManager = EntityManager.EnsureComponent<ContainerManagerComponent>(newUid);
|
|
|
|
|
|
|
|
|
|
// Transfer all construction-owned containers from the old entity to the new one.
|
|
|
|
|
foreach (var container in construction.Containers)
|
|
|
|
|
{
|
2022-10-30 02:48:53 -04:00
|
|
|
if (!_container.TryGetContainer(uid, container, out var ourContainer, containerManager))
|
ConstructionGL2 Part 1: ECSification, events and steps. (#5017)
- Completely rewrited the `ConstructionComponent` logic to be ECS, *without* looking too much at the original implementation.
- The original implementation was dirty and unmaintainable, whereas this new implementation is much cleaner, well-organized and maintainable. I've made sure to leave many comments around, explaining what everything does.
- Construction now has a framework for handling events other than `InteractUsing`.
- This means that you can now have CGL steps for things other than inserting items, using tools...
- Construction no longer uses `async` everywhere for `DoAfter`s. Instead it uses events.
- Construction event handling occurs in the `ConstructionSystem` update tick, instead of on event handlers.
- This ensures we can delete/modify entities without worrying about "collection modified while enumerating" exceptions.
- This also means the construction update tick is where all the fun happens, meaning it'll show up on our metrics and give us an idea of how expensive it is/how much tick time is spent in construction.
- `IGraphCondition` and `IGraphAction` have been refactored to take in `EntityUid`, `IEntityManager`, and to not be async.
- Removes nested steps, as they made maintainability significantly worse, and nothing used them yet.
- This fixes #4892 and fixes #4857
Please note, this leaves many things unchanged, as my idea is to split this into multiple PRs. Some unchanged things:
- Initial construction code is the same. In the future, it'll probably use dummy entities.
- Client-side guided steps are the same. In the future, the server will generate the guided steps and send them to clients as needed, caching these in both the server and client to save cycles and bandwidth.
- No new construction graph steps... Yet! :eyes:
2021-10-26 16:38:03 +02:00
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
// NOTE: Only Container is supported by Construction!
|
2022-10-30 02:48:53 -04:00
|
|
|
var otherContainer = _container.EnsureContainer<Container>(newUid, container, newContainerManager);
|
ConstructionGL2 Part 1: ECSification, events and steps. (#5017)
- Completely rewrited the `ConstructionComponent` logic to be ECS, *without* looking too much at the original implementation.
- The original implementation was dirty and unmaintainable, whereas this new implementation is much cleaner, well-organized and maintainable. I've made sure to leave many comments around, explaining what everything does.
- Construction now has a framework for handling events other than `InteractUsing`.
- This means that you can now have CGL steps for things other than inserting items, using tools...
- Construction no longer uses `async` everywhere for `DoAfter`s. Instead it uses events.
- Construction event handling occurs in the `ConstructionSystem` update tick, instead of on event handlers.
- This ensures we can delete/modify entities without worrying about "collection modified while enumerating" exceptions.
- This also means the construction update tick is where all the fun happens, meaning it'll show up on our metrics and give us an idea of how expensive it is/how much tick time is spent in construction.
- `IGraphCondition` and `IGraphAction` have been refactored to take in `EntityUid`, `IEntityManager`, and to not be async.
- Removes nested steps, as they made maintainability significantly worse, and nothing used them yet.
- This fixes #4892 and fixes #4857
Please note, this leaves many things unchanged, as my idea is to split this into multiple PRs. Some unchanged things:
- Initial construction code is the same. In the future, it'll probably use dummy entities.
- Client-side guided steps are the same. In the future, the server will generate the guided steps and send them to clients as needed, caching these in both the server and client to save cycles and bandwidth.
- No new construction graph steps... Yet! :eyes:
2021-10-26 16:38:03 +02:00
|
|
|
|
2021-10-27 01:28:38 +02:00
|
|
|
for (var i = ourContainer.ContainedEntities.Count - 1; i >= 0; i--)
|
ConstructionGL2 Part 1: ECSification, events and steps. (#5017)
- Completely rewrited the `ConstructionComponent` logic to be ECS, *without* looking too much at the original implementation.
- The original implementation was dirty and unmaintainable, whereas this new implementation is much cleaner, well-organized and maintainable. I've made sure to leave many comments around, explaining what everything does.
- Construction now has a framework for handling events other than `InteractUsing`.
- This means that you can now have CGL steps for things other than inserting items, using tools...
- Construction no longer uses `async` everywhere for `DoAfter`s. Instead it uses events.
- Construction event handling occurs in the `ConstructionSystem` update tick, instead of on event handlers.
- This ensures we can delete/modify entities without worrying about "collection modified while enumerating" exceptions.
- This also means the construction update tick is where all the fun happens, meaning it'll show up on our metrics and give us an idea of how expensive it is/how much tick time is spent in construction.
- `IGraphCondition` and `IGraphAction` have been refactored to take in `EntityUid`, `IEntityManager`, and to not be async.
- Removes nested steps, as they made maintainability significantly worse, and nothing used them yet.
- This fixes #4892 and fixes #4857
Please note, this leaves many things unchanged, as my idea is to split this into multiple PRs. Some unchanged things:
- Initial construction code is the same. In the future, it'll probably use dummy entities.
- Client-side guided steps are the same. In the future, the server will generate the guided steps and send them to clients as needed, caching these in both the server and client to save cycles and bandwidth.
- No new construction graph steps... Yet! :eyes:
2021-10-26 16:38:03 +02:00
|
|
|
{
|
2021-10-27 01:28:38 +02:00
|
|
|
var entity = ourContainer.ContainedEntities[i];
|
ConstructionGL2 Part 1: ECSification, events and steps. (#5017)
- Completely rewrited the `ConstructionComponent` logic to be ECS, *without* looking too much at the original implementation.
- The original implementation was dirty and unmaintainable, whereas this new implementation is much cleaner, well-organized and maintainable. I've made sure to leave many comments around, explaining what everything does.
- Construction now has a framework for handling events other than `InteractUsing`.
- This means that you can now have CGL steps for things other than inserting items, using tools...
- Construction no longer uses `async` everywhere for `DoAfter`s. Instead it uses events.
- Construction event handling occurs in the `ConstructionSystem` update tick, instead of on event handlers.
- This ensures we can delete/modify entities without worrying about "collection modified while enumerating" exceptions.
- This also means the construction update tick is where all the fun happens, meaning it'll show up on our metrics and give us an idea of how expensive it is/how much tick time is spent in construction.
- `IGraphCondition` and `IGraphAction` have been refactored to take in `EntityUid`, `IEntityManager`, and to not be async.
- Removes nested steps, as they made maintainability significantly worse, and nothing used them yet.
- This fixes #4892 and fixes #4857
Please note, this leaves many things unchanged, as my idea is to split this into multiple PRs. Some unchanged things:
- Initial construction code is the same. In the future, it'll probably use dummy entities.
- Client-side guided steps are the same. In the future, the server will generate the guided steps and send them to clients as needed, caching these in both the server and client to save cycles and bandwidth.
- No new construction graph steps... Yet! :eyes:
2021-10-26 16:38:03 +02:00
|
|
|
ourContainer.ForceRemove(entity);
|
|
|
|
|
otherContainer.Insert(entity);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2023-04-15 07:41:25 +12:00
|
|
|
var entChangeEv = new ConstructionChangeEntityEvent(newUid, uid);
|
|
|
|
|
RaiseLocalEvent(uid, entChangeEv);
|
|
|
|
|
RaiseLocalEvent(newUid, entChangeEv, broadcast: true);
|
|
|
|
|
|
2023-07-13 12:23:52 +02:00
|
|
|
foreach (var logic in GetCurrentNode(newUid, newConstruction)!.TransformLogic)
|
|
|
|
|
{
|
|
|
|
|
logic.Transform(uid, newUid, userUid, new(EntityManager));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
EntityManager.InitializeAndStartEntity(newUid);
|
|
|
|
|
|
2022-03-25 05:00:39 +01:00
|
|
|
QueueDel(uid);
|
ConstructionGL2 Part 1: ECSification, events and steps. (#5017)
- Completely rewrited the `ConstructionComponent` logic to be ECS, *without* looking too much at the original implementation.
- The original implementation was dirty and unmaintainable, whereas this new implementation is much cleaner, well-organized and maintainable. I've made sure to leave many comments around, explaining what everything does.
- Construction now has a framework for handling events other than `InteractUsing`.
- This means that you can now have CGL steps for things other than inserting items, using tools...
- Construction no longer uses `async` everywhere for `DoAfter`s. Instead it uses events.
- Construction event handling occurs in the `ConstructionSystem` update tick, instead of on event handlers.
- This ensures we can delete/modify entities without worrying about "collection modified while enumerating" exceptions.
- This also means the construction update tick is where all the fun happens, meaning it'll show up on our metrics and give us an idea of how expensive it is/how much tick time is spent in construction.
- `IGraphCondition` and `IGraphAction` have been refactored to take in `EntityUid`, `IEntityManager`, and to not be async.
- Removes nested steps, as they made maintainability significantly worse, and nothing used them yet.
- This fixes #4892 and fixes #4857
Please note, this leaves many things unchanged, as my idea is to split this into multiple PRs. Some unchanged things:
- Initial construction code is the same. In the future, it'll probably use dummy entities.
- Client-side guided steps are the same. In the future, the server will generate the guided steps and send them to clients as needed, caching these in both the server and client to save cycles and bandwidth.
- No new construction graph steps... Yet! :eyes:
2021-10-26 16:38:03 +02:00
|
|
|
|
|
|
|
|
return newUid;
|
|
|
|
|
}
|
|
|
|
|
|
2022-03-25 05:00:39 +01:00
|
|
|
/// <summary>
|
|
|
|
|
/// Performs a construction graph change on a construction entity, also changing the node to a valid one on
|
|
|
|
|
/// the new graph.
|
|
|
|
|
/// </summary>
|
|
|
|
|
/// <param name="uid">The target entity.</param>
|
|
|
|
|
/// <param name="userUid">An optional user entity, for actions.</param>
|
|
|
|
|
/// <param name="graphId">The identifier for the construction graph to switch to.</param>
|
|
|
|
|
/// <param name="nodeId">The identifier for a node on the new construction graph to switch to.</param>
|
|
|
|
|
/// <param name="performActions">Whether actions on the new node will be performed or not.</param>
|
|
|
|
|
/// <param name="construction">The construction component of the target entity. Will be resolved if null.</param>
|
|
|
|
|
/// <returns>Whether the construction graph change succeeded or not. Returns false if the entity does not have
|
|
|
|
|
/// a <see cref="ConstructionComponent"/>.</returns>
|
ConstructionGL2 Part 1: ECSification, events and steps. (#5017)
- Completely rewrited the `ConstructionComponent` logic to be ECS, *without* looking too much at the original implementation.
- The original implementation was dirty and unmaintainable, whereas this new implementation is much cleaner, well-organized and maintainable. I've made sure to leave many comments around, explaining what everything does.
- Construction now has a framework for handling events other than `InteractUsing`.
- This means that you can now have CGL steps for things other than inserting items, using tools...
- Construction no longer uses `async` everywhere for `DoAfter`s. Instead it uses events.
- Construction event handling occurs in the `ConstructionSystem` update tick, instead of on event handlers.
- This ensures we can delete/modify entities without worrying about "collection modified while enumerating" exceptions.
- This also means the construction update tick is where all the fun happens, meaning it'll show up on our metrics and give us an idea of how expensive it is/how much tick time is spent in construction.
- `IGraphCondition` and `IGraphAction` have been refactored to take in `EntityUid`, `IEntityManager`, and to not be async.
- Removes nested steps, as they made maintainability significantly worse, and nothing used them yet.
- This fixes #4892 and fixes #4857
Please note, this leaves many things unchanged, as my idea is to split this into multiple PRs. Some unchanged things:
- Initial construction code is the same. In the future, it'll probably use dummy entities.
- Client-side guided steps are the same. In the future, the server will generate the guided steps and send them to clients as needed, caching these in both the server and client to save cycles and bandwidth.
- No new construction graph steps... Yet! :eyes:
2021-10-26 16:38:03 +02:00
|
|
|
public bool ChangeGraph(EntityUid uid, EntityUid? userUid, string graphId, string nodeId, bool performActions = true, ConstructionComponent? construction = null)
|
|
|
|
|
{
|
|
|
|
|
if (!Resolve(uid, ref construction))
|
|
|
|
|
return false;
|
|
|
|
|
|
|
|
|
|
if (!_prototypeManager.TryIndex<ConstructionGraphPrototype>(graphId, out var graph))
|
|
|
|
|
return false;
|
|
|
|
|
|
2022-03-25 05:00:39 +01:00
|
|
|
if(GetNodeFromGraph(graph, nodeId) is not {})
|
ConstructionGL2 Part 1: ECSification, events and steps. (#5017)
- Completely rewrited the `ConstructionComponent` logic to be ECS, *without* looking too much at the original implementation.
- The original implementation was dirty and unmaintainable, whereas this new implementation is much cleaner, well-organized and maintainable. I've made sure to leave many comments around, explaining what everything does.
- Construction now has a framework for handling events other than `InteractUsing`.
- This means that you can now have CGL steps for things other than inserting items, using tools...
- Construction no longer uses `async` everywhere for `DoAfter`s. Instead it uses events.
- Construction event handling occurs in the `ConstructionSystem` update tick, instead of on event handlers.
- This ensures we can delete/modify entities without worrying about "collection modified while enumerating" exceptions.
- This also means the construction update tick is where all the fun happens, meaning it'll show up on our metrics and give us an idea of how expensive it is/how much tick time is spent in construction.
- `IGraphCondition` and `IGraphAction` have been refactored to take in `EntityUid`, `IEntityManager`, and to not be async.
- Removes nested steps, as they made maintainability significantly worse, and nothing used them yet.
- This fixes #4892 and fixes #4857
Please note, this leaves many things unchanged, as my idea is to split this into multiple PRs. Some unchanged things:
- Initial construction code is the same. In the future, it'll probably use dummy entities.
- Client-side guided steps are the same. In the future, the server will generate the guided steps and send them to clients as needed, caching these in both the server and client to save cycles and bandwidth.
- No new construction graph steps... Yet! :eyes:
2021-10-26 16:38:03 +02:00
|
|
|
return false;
|
|
|
|
|
|
|
|
|
|
construction.Graph = graphId;
|
|
|
|
|
return ChangeNode(uid, userUid, nodeId, performActions, construction);
|
|
|
|
|
}
|
|
|
|
|
}
|
2023-04-15 07:41:25 +12:00
|
|
|
|
|
|
|
|
/// <summary>
|
|
|
|
|
/// This event gets raised when an entity changes prototype / uid during construction. The event is raised
|
|
|
|
|
/// directed both at the old and new entity.
|
|
|
|
|
/// </summary>
|
|
|
|
|
public sealed class ConstructionChangeEntityEvent : EntityEventArgs
|
|
|
|
|
{
|
|
|
|
|
public readonly EntityUid New;
|
|
|
|
|
public readonly EntityUid Old;
|
|
|
|
|
|
|
|
|
|
public ConstructionChangeEntityEvent(EntityUid newUid, EntityUid oldUid)
|
|
|
|
|
{
|
|
|
|
|
New = newUid;
|
|
|
|
|
Old = oldUid;
|
|
|
|
|
}
|
|
|
|
|
}
|
ConstructionGL2 Part 1: ECSification, events and steps. (#5017)
- Completely rewrited the `ConstructionComponent` logic to be ECS, *without* looking too much at the original implementation.
- The original implementation was dirty and unmaintainable, whereas this new implementation is much cleaner, well-organized and maintainable. I've made sure to leave many comments around, explaining what everything does.
- Construction now has a framework for handling events other than `InteractUsing`.
- This means that you can now have CGL steps for things other than inserting items, using tools...
- Construction no longer uses `async` everywhere for `DoAfter`s. Instead it uses events.
- Construction event handling occurs in the `ConstructionSystem` update tick, instead of on event handlers.
- This ensures we can delete/modify entities without worrying about "collection modified while enumerating" exceptions.
- This also means the construction update tick is where all the fun happens, meaning it'll show up on our metrics and give us an idea of how expensive it is/how much tick time is spent in construction.
- `IGraphCondition` and `IGraphAction` have been refactored to take in `EntityUid`, `IEntityManager`, and to not be async.
- Removes nested steps, as they made maintainability significantly worse, and nothing used them yet.
- This fixes #4892 and fixes #4857
Please note, this leaves many things unchanged, as my idea is to split this into multiple PRs. Some unchanged things:
- Initial construction code is the same. In the future, it'll probably use dummy entities.
- Client-side guided steps are the same. In the future, the server will generate the guided steps and send them to clients as needed, caching these in both the server and client to save cycles and bandwidth.
- No new construction graph steps... Yet! :eyes:
2021-10-26 16:38:03 +02:00
|
|
|
}
|