dragonfly icon indicating copy to clipboard operation
dragonfly copied to clipboard

Command enum type does not show up

Open andreashgk opened this issue 3 years ago • 4 comments

I am trying to implement a /give command, and I want to have the suffix of the itemType be 'item' so it would look like <itemType: Item> However, no matter what I do it always seems to be string. image

My command looks like this

type Give struct {
	Player []cmd.Target
	Item   Item `cmd:"itemType,Item"`
	Count  cmd.Optional[uint]
	Data   cmd.Optional[int16]
}

and the Item enum type like this

type Item string

func (i Item) Type() string {
	return "Item"
}

func (i Item) Options(source cmd.Source) []string {
	return []string{"apple"}
}

Neither the suffix in the struct field tag nor the one returned in Type() seem to have any effect.

andreashgk avatar Aug 01 '22 23:08 andreashgk

Just to clarify, the suffix doesn't change the parameter type. It allows something like this: /xp <level: int>L, where L is the suffix. That said, this suffix doesn't seem to be showing up, so this is still an issue.

Sandertv avatar Aug 01 '22 23:08 Sandertv

And, as you mentioned, the type from Type() not showing up is also an issue.

Sandertv avatar Aug 01 '22 23:08 Sandertv

After some investigating:

  1. It seems the issue of the enum type showing up as string is because we use soft enums for all enums (these can be changed at runtime). Commands in vanilla that use soft enums also have enums that show up as string. Not sure if and how we can resolve this, given we can't make any assurances the options returned by an enum implementations won't change at runtime.
  2. Parameter suffixes I have not been able to get working either. It seems under some circumstances the client even crashes with a suffix. Maybe the constant we have for this is not correct (anymore)?
  3. Enum collapsing doesn't seem to be working at all anymore. The builtin enum dragonfly has for bool does not get collapsed anymore and instead now shows up as <true|false|1|0>. This enum is not a soft enum, so that cannot be the reason here. Maybe the constant we have for this is not correct anymore?

Sandertv avatar Aug 02 '22 12:08 Sandertv

I think a solution to this would be to make all enums normal enums by default, and only mark them as a dynamic enum if a change was detected. In this case, we could send an AvailableCommands packet to replace the commands in question and change the normal enum to a dynamic enum client-side.

Sandertv avatar Mar 24 '23 09:03 Sandertv