of     1   

RegularTetragon
#183259475Tuesday, February 09, 2016 5:32 AM GMT

Is there any in existence already? If not, I call dibs. It's delightful, It's delicious, It's delovely!
cntkillme
#183259738Tuesday, February 09, 2016 5:41 AM GMT

It's been done but it'd be a pretty fun project to do again.
OzzyFin
#183259801Tuesday, February 09, 2016 5:42 AM GMT

there are some guis meant for exploits which have both no clue about their names though, you can probably find them by googling also yea it'd be fun to re-do ... yes i did that stupid stuff 2 years ago but it taught me a lot
RegularTetragon
#183260326Tuesday, February 09, 2016 6:02 AM GMT

This all came about because I wanted to be able to edit IntValues to test different gameplay conditions without having to republish my game or use the command line which takes more time than I would like. I've already got a working UI and basic property editing functionality which I made in a couple hours in 123 lines of code I'm pretty happy with. I still need to set up a bunch of things. Right now it's all done client side which only edits things locally, so I'll need to create a proxy system via RemoteFunctions which, now that I think about it, sounds like a right mess because arguments to remote functions that don't exist to the receiving end are nil when you they get them, combined with the fact that things tend to share the same name (I'll probably use some kind of ID table which will update with DescendantAdded and DescendantRemoving, ew) The biggest issue is property visibility. Because the metatables of instances aren't visible it relies on what's basically a dictionary attack using every property name in ROBLOX from what's admittedly an outdated list as seen on this forum: http://forum.roblox.com/Forum/ShowPost.aspx?PostID=56655319 I also need to make the explorer tree collapsible, because right now even a small game has way too much in the way of clutter (currently looking at a ScrollingFrame with a canvas height of 11060px in my game UpGrade which contains a small level and a few developer things in ServerStorage. The endgame here is that you'll be able to access every single instance running on the server, because why stop at IntValues. I'll have special editors for things like CFrames, Vectors, UDims, and Colors with stuff like color pickers, etc, because I'm pretty much all in at this point. If you've got any recommendations or issues with how I'm implementing this I'll gladly take suggestions, but that's the current idea. It's delightful, It's delicious, It's delovely!
CrustyCitation5
#183260412Tuesday, February 09, 2016 6:06 AM GMT

Who's down to recreate Roblox within Roblox? Let's go
RegularTetragon
#183260443Tuesday, February 09, 2016 6:07 AM GMT

Just so I can keep myself on some kind of schedule: I'll make a release once it has server side functionality and you can collapse the UI. Give it a week if I manage to work on it consistently. It's delightful, It's delicious, It's delovely!
AlphaPineapple
#183262552Tuesday, February 09, 2016 10:13 AM GMT

Anaminus already did this.
RegularTetragon
#183312866Wednesday, February 10, 2016 6:29 AM GMT

I'm happy to announce that all the backend is done and it works with Filtering Enabled. Right now you can only edit ints and strings, but that's because I want to have special editors for everything else. I managed to get around the whole "properties are invisible" by looking to Anaminus's JSON ApiDump which is retrieved from here http://anaminus.github.io/rbx/json/api/latest.json with httpService (there is a fallback version, which is still massive but runs the risk of becoming outdated). This is then processed into a tree structure which looks kind of like this class superclass properties property type readonly property type readonly class superclass properties property type readonly and so on. The API Dump is then disposed of because it's a massive waste of memory, most of which I probably won't end up using. Deprecated and hidden properties aren't included. There's a method which you use to travel up the tree structure via super classes, so that way you get all the properties of an object, not just the ones specific to it. There's an ignore list to avoid indexing ROBLOX Locked objects and itself (otherwise you'd run into recursion issues), as well as a folder in Workspace called "Effects" and anything called tetraignore, which is where you shove all the intensive/temporary stuff that doesn't need indexing to reduce the overhead (in the game I'm working with it would reach 10% processor usage without it, now it generally peaks around 1%) It now works with filtering enabled. Right now my next tasks are making it update regularly, adding editors for Vector3s, CFrames, Color3s, BrickColor, Enums, UDim2's, and ObjectValues (almost certainly forgetting something here) and making the tree structure in the explorer collapsable. I might also expose methods at some point, as well as allow the user to switch from server to client view, but those are stretch goals and might need some refactoring. This is definitely one of the more complicated things I've done, and I've learned some about ROBLOX's internals. Here's a video https://www.youtube.com/watch?v=6qqilQXId2U&feature=youtu.be It's delightful, It's delicious, It's delovely!
RegularTetragon
#183568136Sunday, February 14, 2016 5:41 AM GMT

The tree explorer is collapsible now and updates both parents and names in as close to real time as I can reasonably get it. Properties don't update regularly, which I'll call a design decision. It's annoying to have something you're changing replaced, and I'm doing all I can to reduce overhead, so if I do add something like that it'll be an alternative mode and won't work on focused boxes. From here I've got to build editors for userdata types, and possibly some kind of generic editor in case I haven't built a specific one for that particular class. How that will work I'm not sure. It's possible I'll need to create lists of constructor methods from the API Dump. At that point it enters beta. I've also got an issue of being unable to give the player the GUI from the server when FE is on (which is the whole point of making this, really.) I didn't want to give all players initial access to the GUI, but I might have to just in case. Even if someone manages to get a hold of it, players are verified per-command (GetHierarchalData, GetPropertiesFromId, GetProperty, SetProperty), so it wouldn't be totally awful, just not ideal. Once I have these editor types done, I'll make a release: Vector3 CFrame BrickColor3 Color3 Instance Enum Boolean (embedded into properties) string, int, float, double, number, and content are all the "Easy Types" which just use a textbox. I'd make the others use a text box, but I don't really feel like parsing a string into arguments for a constructor. It gets super ambiguous especially with CFrames who have, like, two hundred thousand constructors, so I'll make an editor system which cascades. Like, with the CFrame editor, the constructor CFrame CFrame.new(Vector3 Origin, Vector3 Towards) will have two buttons, each will open a Vector3 editor window. I also want to have Instantiate, Clone, and Destroy in the released version, which should be EZPZ (I'll have a special cache designed specifically for Instantiate and Clone which isn't indexed) Overall, I'm very happy with how this has turned out so far. If I work hard I should be able to finish it by Monday night (thank you dead presidents) I didn't use any while or until loops, just for loops, events, and a lot of super tasty closure. Are you proud of me yet, ma? Here's a video https://www.youtube.com/watch?v=CnEm5XZditg&feature=youtu.be It's delightful, It's delicious, It's delovely!
TickerOfTime
#183617588Sunday, February 14, 2016 10:05 PM GMT

Many have done this. Myself included.
RegularTetragon
#183743562Tuesday, February 16, 2016 7:01 AM GMT

@TickerOfTime, yeah I figured. Went ahead with it anyway because it seemed like fun. --- I said I'd have it out on monday if I worked on it consistently, and, well, it's Tuesday (albeit early Tuesday) and I don't have it out yet because I was watching youtube videos all day. However, I did get it to the point I said I would in the last post minus the ability to edit properties of the instance type which'll be done through the explorer and will have to involve an annoyingly large if statement and some less-than-generic code. Now that I'm behind though I want to add the ability to set the parent by dragging for a proper release, and possibly work on some GUI optimization. If anybody has any ideas on how to organize properties, I'm all ears. Editors for complex types such as Vector3s, CoordinateFrames, BrickColors, and Color3s are held as functions in a module (not the GUIs for them though, I'm a firm believer in Prefabrication whenever possible). This module allows for things like using two Vector3 editors to create a Coordinate Frame from position and rotation, and breaks up the code a bit into more manageable pieces. Each Editor basically acts like a YieldFunction which always returns the type of its name (by design, of course, there's no way to ensure strict typing. Also these are held under a table to prevent namespace conflicts that might be involved when redefining "Vector3"). By clicking the X it returns the original value, by clicking Accept it returns the new value. This has some unintended behaviour of making it revert to its previous value, regardless of whether or not it has been changed more recently than the server received the getProperty request. They aren't closed automatically when you select another property (yet) When you click on an Enum, you'll get a dropdown menu of all possible values. I'll need to make a way to allow users to click off of it (expected behaviour of a context menu). Booleans are just TextButtons, when you click them they change between true and false in an admittedly roundabout way. They basically get the current value from the server, invert it, and send it back to the server. I could just check if TextBox.Text == "true" but that could run into some issues of the client and server are desynced. I've been working quite a lot with closure which is now probably my favorite thing about Lua and what makes this project so fun. For example, the Enum selection line is in an anon function inside an event inside a loop inside an anon function inside an event inside of an anon function inside of an event inside of a function called makeButton. Naturally, this bit of code references an upvalue two events above it. It's what I would call both good code and an encapsulation nightmare, but you know, it works pretty well. Not so sure about performance, the Script Performance window doesn't seem to complain but I can't measure memory usage. Although I think I opened that pandora's box when I started making this. This all works without errors when on ROBLOX's servers, as expected. Anyway, I've got another preview up, check it out if you like: https://www.youtube.com/watch?v=RRyAVWvdm7U&feature=youtu.be (Please ignore the disgusting corruption noise at the beginning) It's delightful, It's delicious, It's delovely!
RegularTetragon
#183743887Tuesday, February 16, 2016 7:11 AM GMT

(now with completely inappropriate music) It's delightful, It's delicious, It's delovely!
cntkillme
#183744108Tuesday, February 16, 2016 7:19 AM GMT

That looks pretty good, mine was utter crap

    of     1