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

Ports extensions from Nebula #9059

Draft
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

Atermonera
Copy link
Contributor

First pass at porting extensions, as on tin. Provided without verification but with warranty.

  • Grabs what appears to be the basic underlying things.
  • Updates hand labeler to use the label extension, tries to tie it into other places but this is probably incomplete and will most likely require further effort on my part.
  • Swipes, but does not tick, some extensions that I'm particular interested in trying to use.
    • /eye and /on_click are unticked.
  • Makes extensions a thing that exists, such that the lack of extensions outright is no longer a non-starter for a number of other potential ports.

@Atermonera Atermonera added the Port [PR] This is code or assets from another codebase. label Mar 14, 2023
@@ -29,43 +29,53 @@
if(length(A.name) + length(label) > 64)
to_chat(user, SPAN_WARNING("\The [src]'s label too big."))
return
if(istype(A, /mob/living/silicon/robot/platform))
Copy link
Contributor

Choose a reason for hiding this comment

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

This block is separate to the label system generally, it renames the mob.

Copy link
Contributor

Choose a reason for hiding this comment

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

Disregard, just saw the proc.

@MistakeNot4892
Copy link
Contributor

MistakeNot4892 commented Mar 14, 2023

I'm not sure if this is a good idea. Components and extensions have a ton of overlap in functionality even if the DSC pattern bars you from using components from extension-like functions. Having both systems in parallel feels like a complexity and maintenance issue.

Snips unused code
@Atermonera
Copy link
Contributor Author

I agree that the two-implementation solution is messy (See: nanoui v. tgui, among probably numerous other examples), but there actually isn't that much that uses components right now.
I much more often see shiny things that we could have, but for lacking extensions, than I do shiny things that we're getting because we have components.

@Spookerton Spookerton added the Stale [PR] This requires additional work and appears abandoned. label Aug 23, 2023
@Spookerton Spookerton marked this pull request as draft August 23, 2023 15:25
@Spookerton
Copy link
Member

I would want this to come with a commitment to transition existing component use to extensions, which I think defeats the "I much more often see shiny things that we could have" sentiment which, I assume, carries the caveat of still wanting the shiny things from components without the effort of translation. I agree with MistakeNot4892 - both is a recipe for overhead, interoperability issues, and dev headaches.

I'm biased in favor of extensions because they're what I use already elsewhere. I've found DSC a tad less approachable, largely due to the rote use of its own signals system creating a lot of async funnies and signal comprehension instead of direct calls.

Buuuut it is what currently exists. Translating extensions to it is just as possible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Port [PR] This is code or assets from another codebase. Stale [PR] This requires additional work and appears abandoned.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants