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

Perhaps items should graphically default to their copy-from parent? #22498

Closed
ShadowDragon8685 opened this Issue Nov 26, 2017 · 3 comments

Comments

Projects
None yet
4 participants
@ShadowDragon8685

ShadowDragon8685 commented Nov 26, 2017

This is something I've noticed that really limits modding items in if you're playing with/modding for a tileset install (such as MShock,) because of the way the game expects the graphic set to specify where each individual item ID comes instead of the item's block specifying where in the graphics it is found.

For example, supposing I wanted to mod in a skill book which took the form of a samurai novel; I could copy-from it from the existing samurai novel and change only the read time and change it from a just-for-fun to a skill book and leave it the same, and it would thus have the same weight, volume, and yield the same amount of paper, etc, as the standard samurai novel.

But in world, it would appear as a gargantuan ? sign, which is jarring in an otherwise graphically-realized game. I am proposing thus that alphanumerics would be resorted to only if absolutely necessary; either, or perhaps both, of the following should be implemented:

1] If an item has no unique graphics assigned to its specific ID, but it has a copy-from tag assigned, it would be treated graphically as if it were its copy-from parent, using the graphic thereof.
2] Allow items to specify a tag (perhaps "show-as": "[item_id]") which it treats the item as graphically.

This would make item-content packs a lot simpler, by allowing modders to easily reuse graphics that fit the part, rather than setting the bar so high as to either fork a graphics pack to go with their item content packs (and the inevitable cluster that would bring when multiple item packs collide,) or to require that they get the attention of the maintainers of the popular graphics packs to set the item tags.

@kevingranade

This comment has been minimized.

Show comment
Hide comment
@kevingranade

kevingranade Nov 28, 2017

Member

The second option has promise, map entities can have a graphical attribute seperate from their id, which defaults to the id, the difference being that several entities can share a graphical id. It's also a superset of the other option, because the graphical id would be just another attribute for copy-from to act on.

Shorter term though, we could have tilesets use sym as a fallback tileset id.

Member

kevingranade commented Nov 28, 2017

The second option has promise, map entities can have a graphical attribute seperate from their id, which defaults to the id, the difference being that several entities can share a graphical id. It's also a superset of the other option, because the graphical id would be just another attribute for copy-from to act on.

Shorter term though, we could have tilesets use sym as a fallback tileset id.

@BevapDin

This comment has been minimized.

Show comment
Hide comment
@BevapDin

BevapDin Nov 28, 2017

Contributor

we could have tilesets use sym as a fallback tileset id.

This is already implemented, but it requires the tileset to have an ASCII fallback defined (the characters are not rendered via SDLs font rendering, but as normal tiles from the tilesets png file).

Some tilesets (e.g. Hoder, Tsu, Deon) don't have this ASCII fallback defined.

Contributor

BevapDin commented Nov 28, 2017

we could have tilesets use sym as a fallback tileset id.

This is already implemented, but it requires the tileset to have an ASCII fallback defined (the characters are not rendered via SDLs font rendering, but as normal tiles from the tilesets png file).

Some tilesets (e.g. Hoder, Tsu, Deon) don't have this ASCII fallback defined.

@Night-Pryanik

This comment has been minimized.

Show comment
Hide comment
@Night-Pryanik

Night-Pryanik Jul 22, 2018

Member

Closing as per lack of discussion.

Member

Night-Pryanik commented Jul 22, 2018

Closing as per lack of discussion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment