|
| 31 Jan 2015 09:06 PM |
Hi, I'm back with a new suggestion.
Today I'm proposing a new Instance which would allow scripters much more power over their games. With the newly released "blank instance" called a Folder, it got me thinking, what if ROBLOX actually allowed us a blank instance?
So how it works is that Blank would inherit directly from Instance, same properties/methods. Methods, events, and ClassName would no longer be read-only. The metatable would no longer be locked. Name would be Blank by default. There would be some read-only properties, like RobloxLocked or whatever.
Although it directly inherits from Instance, it would have it's own, not overwritable properties. An example of which will be shown later while we handle events.
Of course all of this would have to be sandboxed.
So anyway, essentially Blank can be turned into anything we want it to be. Here's a small bit of example usage I came up with:
local Blank = Instance.new("Blank", workspace)
Blank.ClassName = "MyCustom" Blank.Name = "Custom Name"
Blank.GetChildren = function(t) print(t.Name) end
print(Blank.ClassName) print(Blank.Name) Blank:GetChildren()
--MyCustom --Custom Name --Custom Name
So that's what scripters would mainly have fun with when using this. But then we get into what more intermediate-advanced scripters would like.
local Blank = Instance.new("Blank", workspace)
setmetatable(Blank, { __index = function(t, k) return k end })
print(Blank.yolo)
--yolo
This is just an example, it's not really useful. The only problem with this is you have to sandbox it. Creating a metatable should not (obviously) overwrite your metatable. Just like how you don't store the real global environment in getfenv(0)
Last but not least, we come to events. Events are more complicated, as the scripter can't set them up in a mere few lines, but here's a quick example of what I mean:
local Blank = Instance.new("Blank", workspace)
Blank:BindEvent("Touched")
local connection = Blank.Touched:connect(function(arg) print(arg) end)
for i = 1,10 do Blank.Touched:Fire(i) end
connection:disconnect()
Up until now, none of this is really possible without creating a custom hierarchy, in fact, people are currently working this (eLunate, JarodOfOrbiter) and this would save them tons of hours of work.
I'll start the supports.
Support Ratio; 1:0 |
|
|
| Report Abuse |
|
|
Twistir
|
  |
| Joined: 19 Nov 2009 |
| Total Posts: 12374 |
|
| |
|
| |
|
Coriandr
|
  |
| Joined: 25 Jun 2014 |
| Total Posts: 6850 |
|
|
| 31 Jan 2015 09:44 PM |
Warspy tried explaining this to me. I got about 2/3 of it, then I was lost when he said this would give us the option to create our own instances.
-cough-newbiescripter-cough-
Anyway, seems good by what he explained and I actually got, so, support.
"I just wanted to let you know, the back of yo head is ridiculous." -Daryl, pronounced De-rail |
|
|
| Report Abuse |
|
|
|
| 31 Jan 2015 09:49 PM |
I put together a full list of properties and stuff this would have:
Properties:
Archivable (WRITABLE) ClassName (WRITABLE) Name (WITABLE) Parent (WRITABLE) DataCost (READ-ONLY) RobloxLocked (READ-ONLY)
Functions:
ClearAllChildren (WRITABLE) Clone (WRITABLE) Destroy (WRITABLE) FindFirstChild (WRITABLE) GetChildren (WRITABLE) GetFullName (WRITABLE) IsA (WRITABLE) IsAncestorOf (WRITABLE) IsDescendantOf (WRITABLE) GetDebugId (READ-ONLY) BindEvent (READ-ONLY) UnBindEvent (READ-ONLY)
YieldFunctions:
WaitForChild (WRITABLE)
Events:
AncestryChanged (UNBINDABLE (USING UnBindEvent)) Changed (UNBINDABLE (USING UnBindEvent)) ChildAdded (UNBINDABLE (USING UnBindEvent)) ChildRemoved (UNBINDABLE (USING UnBindEvent)) DescendantAdded (UNBINDABLE (USING UnBindEvent)) DescendantRemoving (UNBINDABLE (USING UnBindEvent))
As for Callbacks, I haven't quit decided on their usage yet. If you have any suggestions feel free to post. |
|
|
| Report Abuse |
|
|
|
| 31 Jan 2015 09:50 PM |
Support Ratio; 3:0
I get the feeling this is gonna get minimum support because little people understand what this means XD |
|
|
| Report Abuse |
|
|
Coriandr
|
  |
| Joined: 25 Jun 2014 |
| Total Posts: 6850 |
|
|
| 31 Jan 2015 09:52 PM |
Probably.
"I just wanted to let you know, the back of yo head is ridiculous." -Daryl, pronounced De-rail |
|
|
| Report Abuse |
|
|
|
| 31 Jan 2015 09:55 PM |
| Talk Thread: http://www.roblox.com/Forum/ShowPost.aspx?PostID=155072773 |
|
|
| Report Abuse |
|
|
SkyScythe
|
  |
| Joined: 04 May 2013 |
| Total Posts: 18 |
|
| |
|
128GB
|
  |
| Joined: 17 Apr 2014 |
| Total Posts: 8056 |
|
|
| 31 Jan 2015 10:02 PM |
| No support there is no reason to make our own instances. |
|
|
| Report Abuse |
|
|
|
| 31 Jan 2015 10:09 PM |
Support Ratio; 4:0
@128 Please,mod tell, why not?
Event cntkillme (sorta) said this was a good idea. So please, enlighten me, why is this a bad idea? |
|
|
| Report Abuse |
|
|
| |
|
128GB
|
  |
| Joined: 17 Apr 2014 |
| Total Posts: 8056 |
|
|
| 31 Jan 2015 10:12 PM |
| I already did, because there is no reason for it |
|
|
| Report Abuse |
|
|
|
| 31 Jan 2015 10:18 PM |
@128
Creating our own services Creating our own special types of objects and releasing them
We don't have any reason for StarterPlayer yet we have that...
Continue this in the talk thread please. |
|
|
| Report Abuse |
|
|
Tenako
|
  |
| Joined: 08 Nov 2013 |
| Total Posts: 25046 |
|
| |
|
128GB
|
  |
| Joined: 17 Apr 2014 |
| Total Posts: 8056 |
|
|
| 31 Jan 2015 10:22 PM |
Actually there is a reason for starter player, so we can easily and efficiently set default values for a player and (So I've heard) put local scripts in it that will not reset when the player respawns (One day, not yet)
Making our own instances and services is completely pointless and does not make anything more efficient or easy to use or add any benefit at all. |
|
|
| Report Abuse |
|
|
cntkillme
|
  |
| Joined: 07 Apr 2008 |
| Total Posts: 44956 |
|
|
| 31 Jan 2015 10:51 PM |
'Just like how you don't store the real global environment in getfenv(0)' uwot? it does hold reference to the real global environment though... |
|
|
| Report Abuse |
|
|
| |
|
eLunate
|
  |
| Joined: 29 Jul 2014 |
| Total Posts: 13268 |
|
|
| 01 Feb 2015 03:21 AM |
This would be hard to implement on Roblox's current DataModel and I personally see little use for it.
Roblox needs to spend time fixing the stuff that is actually broken before thinking about how to implement custom behaviours into a C class from the Lua side and then how to tell the network model those behaviours. |
|
|
| Report Abuse |
|
|
| |
|
|
| 01 Feb 2015 03:26 AM |
| This thread must die. It did happen. |
|
|
| Report Abuse |
|
|
|
| 01 Feb 2015 03:27 AM |
| Btw folder instance is for organization. |
|
|
| Report Abuse |
|
|
nandym
|
  |
| Joined: 09 Sep 2011 |
| Total Posts: 22 |
|
| |
|
|
| 01 Feb 2015 04:31 AM |
Let this thread die. Support |
|
|
| Report Abuse |
|
|
|
| 01 Feb 2015 06:21 AM |
Support Ratio; 9:1
Please save all discussion for the talk thread, and no this has not already been possible.
@eLuanate, on the talk thread, please explain how this is useless, it's exactly what YOU and Jarod are trying to do (well almost, at least that's what's in Jarod's blurb) |
|
|
| Report Abuse |
|
|