Purple Explorer - A secondary explorer's plugin

Resources Community Resources
,
#1

Hello developers! Today I’ll show my new plugin: Purple Explorer

imagem_2022-12-17_160446808

Here is the link to get the plugin: https://create.roblox.com/marketplace/asset/10535211702

Why should I use this?

  • Personal game’s explorer for each developer (compartible with Team Create);
  • Reorganize your project’s main and recorrent objects (such scripts and related objects) without changing the original Parent of those;
  • Bigger size and customizable colors theme;
  • Instantiate scripts and folder easily;
  • Similar use than the default Roblox Studio’s Explorer window.

This plugin was been created to provide a new way of the developer (specifically a programmer) organize your own game’s explorer, without really affecting it, because in large projects, the amount of objects in Explorer can affect the visibility of some important objects which are recorrent, like Script’s, ModuleScript’s and LocalScript’s

Main Features:

Adding objects

Select the explorer object(s) which you want to add and click on the plus button (+) in the top:

Dragging objects

You can drag objects inside Purple Explorer, like the default Explorer, but without changing the real parent of the objects:

Opening and instantiating new Scripts

You can add scripts with the top buttons and open with Right Click in the object:

Refreshing and Saving

The Refresh Button destroy any elements which the real object (explorer object) was been destroyed too. Save Button saves the current explorer in a folder with the developer’s UserId:

Theme Color Editor

imagem_2022-12-17_194721758

This is a menu of the plugin that allows customize the explorer’s appearance. To change a color of an element, click on the mini-display example on the left side in somewhere to change the color of the choosen element.

Saving Addendum

When the plugin save the explorer, it creates a folder with one ObjectValue for each object you have added in the plugin, and because this, it’s strongly recommended to use fewer amount of objects as possible. The Color Editor doesn’t suffer this problem, because it uses the setting methods of plugin library (:SetSetting() and :GetSetting()).

Conclusion

I really hope this plugin can help someone to handle easier with some scripts in their games, and I would like to read some suggestions to improve the plugin performance and quality overall. Please report in this post any bug related with this plugin ^^

Known issues:

  • Objects grabbing can bug and block the normal use of the plugin. If you notice this, please report with the maximum of details and restart the plugin (disable and enable by Plugin Manager);
  • Saving method, looking for a better way to do this.
5 Likes
#3

I downloaded this plugin way before this post was created lol. Anyways, looks nice :+1:!

#4

What is the point off this? I really don’t see any benefit of using this plugin.

1 Like
#5

No offense but I dont see the point of this at all. The default one fits all my needs well and the point of another one that takes up place in my already filled up plugin slots just seems useless.

1 Like
#6

@LifeDigger @TheH0meLands

For me, the above quote is the biggest selling factor for this. Particularly for teams involving builders/modelers + programmers, this is a big win here. Seeing as you both seem to be programmers, I would just give the example of having a certain programming organization scheme that does not align with the organizational scheme of your builders/modelers.

Here’s an example: a builder wants to put all related parts in the same model. This includes a door (which will have a proximity prompt added to it on game start-up via code), an invisible collision part (which is initialized via code on start-up), and a few other things that are programmatically modified or set-up. This makes sense for the builder, because if they need to move the model, everything moves along with it. This is challenging for the programmer, because it requires parsing through the whole workspace to get these parts. The programmer might prefer an alternative scheme, such as putting all the invisible proximity prompt parts in a shared folder, all the collision parts in a separate folder, etc.

This plugin (from what I understand) allows both approaches to happen simulatenously. The programmer can set the actual parents to be something that makes sense from the programming standpoint (ex: folders in different places) and the builder can use the plugin to adjust the view so that everything appears on their end to be within the same parent - and then make easy adjustments.

Sorry, the example got a little long-winded, but this to me is the key “why use this” feature that I thought was worth highlighting.

1 Like
#7

Exactly, I forgot reinforce this point in my post, because this plugin is originally intended for programmers, especially in large projects.