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
1 Like
Updates
-
UI Improvements: Fresher Design, Upscale, Blurred Background, and the editor no longer closes when opening a script.
-
Hierarchy addition: If you don’t want to use
:GetPluginor something, you can useself.Scriptsorself.Pluginsto suit your coding style. -
The SCP demo now uses the most recent version of Yucon, meaning it works again.
-
DataStore2was added to the server plugins by default, as it’s a very popular data storage module. -
WorkshopMapHandlerwas removed as it’s use case is too specific. -
Added
EventHandlerto shared plugins. -
Errors in
StepandRendernow appear in the output.
Thanks to @dthecoolest and @FerbZides for helping with ideas!
3 Likes
a new suggestion @iGottic?
im confused on how to make remote events or remote functions can you add a feature which does this?
function MODULE_NAME:Init()
self:RegisterClientEvent(EVENT_NAME)
self:RegisterEvent(EVENT_NAME)
end
then connect them by this
MODULE_NAME.EVENT_NAME:Connect(function(pars, args)
-- code
end)
another one is a module that fires an event from another module then the event trigger should be like this [YOU CAN DO IT ON YOUR OWN STYLE]
-- client event methods
self:ConnectClientEvent(EVENT_NAME, function(arg)
-- code
end)
-- server events
self:ConnectEvent(EVENT_NAME, function(arg)
-- code
end)
this is what it look from aero
Unfortunately, I going to have to turn down this suggestion.
The system I have right now for remotes is already complicated enough internally, using scrambling methods to increase security. Taking a ton of time to add another method that does the same exact thing with more lines of code is a turnoff for me, unfortunately.
What? More updates already! No way!
- Added
Stepmethod to Client Scripts. - Added
ThreadHandlerto the Shared Plugins. - Deprecated and Removed
FuncManip. Its functions are now included inThreadHandler. - Added documentation to areas missing it, added ASCII art for Yucon.
- A couple other tiny changes.
1 Like
I made a tutorial, as recommended by @HavocOmega.
Did you use Yucon in your game? Lemme know here in the replies, I would love to play it!
3 Likes
So this is basically unity code format.
1 Like
I actually have never coded in Unity, so I would have no clue.
I personally based it on the Love2D engine.
It’s very likely many engines do something like this 
1 Like
Unity also has a function for running every frame, start of code, and after the start of code function.
2 Likes
That’s cool!
Hopefully this framework would then seem more familiar to you in terms of code setup.
This Is The Most Useful Plugin I Have Ever Used. Now I Don’t Need To Spend Hours Making My Code Less Laggy And More Efficient, Great Work!
1 Like
That’s awesome it works for you!
You haven’t run into any issues? (Asking just in case )
Nope Works Just As Intended, Would Recommend To Anyone
1 Like
just a question, when making an fps game, how would I use this for cosmetics? and battle pass? because I don’t it would be needed there, do I just create normal scripts If I don’t want to use this in some places?
If you were to use Yucon Framework, you would use it for everything.
The cosmetics and battle pass would be specific things that would require you to watch a tutorial, and transfer that code type into a yucon script or plugin.
- Over excessive type checking; you only really need to check certain parameters, not instances, especially ones that aren’t from the client. Type checking is useful it replacements of assert, you should use it when trying to prevent functions to return nil values, non-terminating loops, division by 0, adding a string to integers. On the other hand, there’s no real argument that over excessive type is bad. It can detect errors at run-time, it gains efficiency in storage use and execution speed, making it crucial when checking input so that it doesn’t give a wrong result. Contrasting from its advantages, it is very inflexible in terms of readability, when you’re sure that something isn’t going to magically go from an instance to a table somehow, then there isn’t really a reason for checking it. For example, it is a code smell to do this.
local remotesFolder:any = game.ReplicatedStorage:WaitForChild("COMMUNICATION")
WaitForchild will ONLY look for instances
- For people who misread the documentation, while loops aren’t expensive, they’re used incorrectly (…Someone told me about this framework when the topic of while loops came up). The most amateurish uses of it are making an infinite loop with these while loops. While loops are EXTREMELY useful when we have an exit condition dictated by multiple pointers. Although, it is true that the while wait() idiom has no reason for its persistence with amateurs. THIS specific framework addresses this issue, however, I don’t believe that a framework should propose a cure-all method in its replacement. Teaching out different viable options is far better instead. This framework enforces the idea of querying instead of signal-based coding, which is instant upon invocation.
- It wouldn’t be wise to decipher all loops with a singular heartbeat/stepped connection, which will refresh the code after/before every frame, so if your code needs to yield, it wouldn’t work.
- Looks like server-server/client-client communication isn’t supported yet, why? With a framework that focuses on game logic interfacing overarching upper-level services, aka centralising logic, it could prompt quite a few inconveniences when working on a game where your game needs a lot of dependency on other services/controllers.
- Taking a peek on the code, you’re using way too many unchecked coroutines. You can catch errors with coroutines if you didn’t know.
local thread = coroutine.create(func)
local ok, err = coroutine.resume(thread, ...)
if not ok then
warn(debug.traceback(thread), err)
end
- It is a bad idea to loop through your every script, putting them in a heartbeat loop inside a pseudo-thread. Just slap a return inside these step methods. Even though this isn’t really a good practice… Just make a separate connection. And if you’re eager on making it less verbose by binding this to a method. At least make it a utility that returns a newly created connection.
- Remote events, I have no idea what you’ve done, but they don’t seem secure at all. Optimisation wise, you can use string.pack, but obfuscation and security by key is quite frankly not going to work when you publish the framework publicly, I don’t think I need to elaborate there.
- I like its utility modules, they got a few rough edges but nothing worth to note about.
My conclusion, I don’t think you should advertise this to professionals nor people that aspire to be professionals. It is a good library to learn standard practices from, but nothing beyond that when it comes to practical use. Curious to know what other peoples’ experiences on it though.
1 Like
Could you elaborate on this? I am curious on what you mean.
It is, albeit it does need some improving, as you mentioned the remotes are not quite optimized.
I disagree, I do use this in major projects, and so far some improvements have been made. This is partially because of the way the framework is naturally set up, and partially because it truly is optimized.
For example, my game Pistol 1v1 is currently unorganized and, while it does have good code, has bad code. I am remaking the game to Caliber 1v1, with Yucon Framework being the main backend.
Yucon Framework helps the scripts communicate efficiently in a manner that does not eat away at memory. What would have been ugly workarounds before are now built-in for Yucon.
On the same token, your feedback is crucial and I do appreciate it. I will work on an update soon to fix many of the issues you took note of.
Thank you 
1 Like
Are you wondering about why you shouldn’t do what you’re doing, or what you should do?
Could you show me an example of communication between servers?
I’ll rephrase, it is not YET up to par for professional use in my opinion.
If this is a concern, you shouldn’t be loading remotes til its “max capacity”. you should be creating remotes as you need them. I have an old framework I forked from lpgchat. The workflow is very cohesive:
The magic behind the scenes is quite simple, it is just loading/connecting events from the values in set of the ApiSpec module. I have moved on from this framework because it centralises all connections onto one place, which restricts design, but I thought it could be nice for someone wanting to front-load remotes.
1 Like