Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added feature to help resolve mocks based off same type search. #417

Merged
merged 11 commits into from
Jan 1, 2024

Conversation

OrianaVenture
Copy link
Contributor

  • Accepts new mock format JVLmock_PrefabName__ChildName.
  • Finds an object that matches the type of the mock from the specified child of the prefab in the new format.
  • Cleans name of any object Mesh with " Instance" on the end of the name for finding mock replacement.

Since there are many unnamed Mesh objects used the current mocking system can not replace them. This is the required changes to get a functioning mesh mocking system, but should work for other types too.

Examples of usage:

  1. Create a mocked mesh called JVLmock_Pickable_Thistle__default, this will find the first Mesh on the Pickable_Thistle prefab under the child "default" for a replacement.
  2. Create a mocked mesh named JVLmock_TrollCave02__dirtfloor (11), this will find the first Mesh on the TrollCave02 prefab under the child "dirtfloor (11)" for a replacement.

…ially useful for Mesh mocking.

* Accepts new mock format JVLmock_PrefabName__ChildName.
* Finds an object that matches the type of the mock from the specified child of the prefab in the new format.
* Cleans name of any object Mesh with " Instance" on the end of the name for finding mock replacement.
@MSchmoecker
Copy link
Member

Thanks, it looks really good. Especially using the ClassMember to find fields on the child, which makes it much more generic.
Using __ as a separator instead of a single underscore is also a good idea to keep the names intact and feels natural to use.

While testing with the VikingShip, a child name can be ambiguous, e.g. mast is used for both the mesh and the interactive child. The interactive child is nested shallower and therefore found first. Intermediate children could be a solution, so maybe JVLmock_VikingShip__ship__mast to match the ship child first and then the mast child.

With more complex matching, the warnings should also be more specific. For example, if a child wasn't found should print a different warning than if the type on the child wasn't found. If you don't want to worry about this, I can also do this later.

There are a few minor comments I will make on the code but this won't be a blocker.

JotunnLib/Managers/MockSystem/MockManager.cs Outdated Show resolved Hide resolved
JotunnLib/Managers/MockSystem/MockManager.cs Outdated Show resolved Hide resolved
JotunnLib/Managers/MockSystem/MockManager.cs Outdated Show resolved Hide resolved
JotunnLib/Managers/MockSystem/MockManager.cs Outdated Show resolved Hide resolved
@OrianaVenture
Copy link
Contributor Author

Current minor suggestions have been implemented. I will look into making the pathing more dynamic to accept more nesting for cases like: JVLmock_VikingShip__ship__mast and work on better error logging for that case.

* Supports format JVLMock_PrefabName__ChildName__ChildName2__ChildName3 etc
* Improved name cleaning calls for GetRealPrefabFromMock
* Added new field to MockResolveException for children path
@OrianaVenture
Copy link
Contributor Author

Testing this on my current mocked locations the startup time is significantly slower than my stand alone solution which had caching. Next improvement will be to add in the ability to cache all instances with the longer path finding names after finding them once.

@MSchmoecker MSchmoecker merged commit af2f28b into Valheim-Modding:dev Jan 1, 2024
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants