I recently used this for one of my projects!
Looks pretty cool, but one thing I don’t like is the discrepancies between the code styles. Some functions use completely different code styles than others. The base functions are in the pascal case style. The CodePlus module is a mix between camel case and snake case. And the other modules are also varying. You should uniform the code style.
I think it would help alot if you provide code example for the functions on the documentation. I feel like theres something missing from the documentation, principally on the client / server communication. Other than that it’s a neat framework!
I will definitely have to fix this. Thanks!
I may provide a tutorial soon
Updates (under testing, will apply in the next day or two):
- Plugins now have access to remotes
- Plugins cannot cross-reference each other anymore.
- Minor optimization
In addition, I have released a small demo that uses Yucon: SCP Launcher - Roblox
Can you release the source code for the Yucon demo? I thought this would be an example of how to use it.
Sure
You should find that it’s open-source now.
I would just like to ask why you think spawn brings down the leftover memory for other scripts, and would like to ask what you would use instead.
spawn
runs on a separate thread priority in the Lua enviroment. Yucon takes advantage of coroutine
to deliver a more reliable experience.
But that still doesn’t answer the question of why you think it brings down the left over memory, is there any evidence to support this claim?
After doing some research, I can’t actually find the specifics. It’s likely I confused spawn
with some other method.
The topic will be edited to change that information
However, spawn
is a bad practice, and I recommend using coroutine
for many cases.
It’s been quite a bit since the last update! Don’t worry, I got your back!
- Removed LuaU’s
=>
symbol, and replaced it with:
. Sorry if your framework broke in the meantime, it is now fixed! - Optimized the code a bit more.
- Included
type array
andtype dictionary
in all default plugins and scripts. - Fixed method names; they are all now
PascalCase
, rather than some that and somecamelCase
. Thanks to @Dysche for the idea.
Very interesting way to organize Server-side scripts and local scripts to execute module scripts. Moreover, the GUI for the plugin is easy to use. I’ll be using it in my inverse kinematics project and I’ll make sure to credit you when I publish a working version of my project with the plugin in the main branch of my GitHub.
Edit:
I have encountered some things which may make newer users have difficulties with the framework at the beginning which I summarized below:
TL;DR
-
Example use cases for Preload and Start (Step is self-explanatory and self testable)
-
Errors in step don’t output onto the command bar
-
The SCP launcher example is bugged and shows a black screen
I’ll work on it. Thanks for the feedback!
nice framework i tried it and it worked well the only thing that i was expecting is your own framework datastore module like aero till then ill just wait for it
my recommended is that:
access modules with self.FOLDER_NAME.MODULE_NAME
like something from aero
a good module datastore
make the gui better
Thanks!
Sure thing! Expect that soon, and thanks for that feedback.
I’ll keep the self:GetPlugin() system, but I may do a hierarchy system. Do you have more information on this that you think would fit Yucon?
I was thinking the same thing! In your opinion, what does the GUI lack the most?
Thanks for your feedback, I will be sure to work on it as soon as possible.
the gui lacks only the size accessing the modules with self like aero would do something like metatables
Ok. Would you like me to stretch it vertically, horizontally, or both?
Currently, Yucon already uses metatables.
both
paths like this something from aero
self.Services.MODULE_NAME