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

feat!: Force user to delete regions by name; introduce +all specifier #28

Merged
merged 2 commits into from
Jun 30, 2024

Conversation

Restioson
Copy link
Contributor

@Restioson Restioson commented Jun 11, 2024

  • Force the user to specify which regions they want to remove with /map region remove here <name>. This is a breaking change with regard to the command syntax, as <name> is a required parameter.
  • Allow most local regions to be specified by +all which includes all that the player is inside of. This is a breaking change as now region markers beginning with + are invalid.

@haykam821: this is similar to what we discussed, but instead of using @all (@ is not allowed in word string args), it uses +all, and then makes +all a reserved region name. Unfortunately I had to reintroduce this as siblings would be very messy and don't compose well at all.

Partially addresses #21

Copy link
Contributor

@haykam821 haykam821 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To clarify what I discussed with you previously on Discord, we can still introduce new functionality here without removing the ability to use a certain region name. For example:

/map region remove here all
/map region remove here "all"

Using a literal and a string argument would allow simple unquoted cases to be executed under the literal node, while quoted cases would be considered under the argument node. The same principle could be applied to the custom RegionSelectorArgumentType introduced here.

Note that if we go with a design that includes reserved names, they would still be usable within map templates; they would simply not be editable with this mod.

I've left a few other considerations and smaller notes in this review.

}
}

private record RegionSelector(Either<String, SpecialRegionSelector> inner) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does the behavior of RegionSelector overlap with RegionPredicate?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's a bit more specific than RegionPredicate - perhaps it could be a subclass/instance of RegionPredicate though

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

RegionPredicate is now 🦀

}
}

private record RegionSelector(Either<String, SpecialRegionSelector> inner) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it make sense for RegionSelector to have multiple implementations (perhaps using a sealed interface) rather than using an Either record component?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps if it is considered to be better style - I wrote it as such as there can only be two region selector types (special or named)

Copy link
Contributor Author

@Restioson Restioson Jun 13, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If RegionSelector were made a subclass of RegionPredicate then perhaps each instance could be a different subclass? What do you think?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok, so now that RegionPredicate is gone, how do we feel about this?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could the region selector implementation be moved to a different package? The MapMetadataCommand class is getting a bit long.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That might be a good idea yes

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's a bit shorter now; any new thoughts? I could also extract all the static methods, but this is the only class they are used in

Comment on lines 75 to 78
public static final DynamicCommandExceptionType INVALID_REGION_SELECTOR = new DynamicCommandExceptionType(
arg -> Text.stringifiedTranslatable("text.nucleoid_creator_tools.map.region.reserved_name", arg)
);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could this field be named something along the lines of RESERVED_REGION_NAME to better fit the translation key (or vice versa, renaming the translation key to fit the field name and translation)?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would go the other way and rename the key to text.nucleoid_creator_tools.map.region.selector.invalid, as it does not actually have anything to do with reserved names, but yes, they are misaligned at present.

@Restioson
Copy link
Contributor Author

To clarify what I discussed with you previously on Discord, we can still introduce new functionality here without removing the ability to use a certain region name.

Don't worry - the current changeset does not add any reserved words

Copy link
Member

@Gegy Gegy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mostly nits, but haykam's comment about Vanilla client compatibility definitely needs a look 🙂

@@ -79,25 +166,25 @@ public static void register(CommandDispatcher<ServerCommandSource> dispatcher) {
)))))
.then(literal("rename")
.then(literal("all")
.then(argument("old", StringArgumentType.word()).suggests(regionSuggestions())
.then(argument("new", StringArgumentType.word())
.then(regionMarkerArg("old")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the 'exact' marker is extracted, it might help to rename this to 'region selector'/'region predicate' kind of thing

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't quite follow unfortunately - perhaps the attached diff is wrong though

@Restioson Restioson force-pushed the feat/delete-by-name branch 2 times, most recently from 15a1ce2 to 6ab4886 Compare June 16, 2024 14:39
@Restioson Restioson requested a review from Gegy June 16, 2024 14:40
Copy link
Member

@Gegy Gegy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great, awesome work! Will merge as-is and we can follow-up moving the argument handling out later if we want :)

return argument(name, StringArgumentType.word()).suggests(suggestions);
}

@SuppressWarnings("SameParameterValue") // We want to keep this general
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: I believe putting this as a public helper in another class would disable that inspection - might generally be nice to have in separate classes as we are doing in Plasmid

@Gegy Gegy merged commit abec0b2 into NucleoidMC:1.20.4 Jun 30, 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.

3 participants