f3xteam / rbx-building-tools Goto Github PK

I think it would be beneficial to builders if there were a way to enter custom fields to the new part tool. The part created when this option is used would be taken from the current selection, and would only work if there was only one part selected (or perhaps used the most recently selected part instead). This could be accomplished by creating a model in ReplicatedStorage in which clones of the player's custom entries are stored. Also, I think the text color should be different on custom options, to tell them apart from preset ones.

http://s3.postimg.org/aikstgcwz/img.png

An gui in which you can change various parts of how the tools work, including default sizes & surface types, whether or not the Color tool immediately colors a part when you select it, whether or not to show menu items like Materials and Surfaces in all caps, etc. Perhaps it could be saved via the HttpInterface, and then automatically retrieved from the tools using the userId of the player. In the plugin, there could be a box in the Settings menu in which you input your userId, so your settings are synced.

Parts that are accidentally cloned and forgotten inside other parts should be highlighted to prevent duplicates.

When using the tools in-game, and the tools break, you can just hit backspace and pick them back up, which reloads all the LocalScripts in the tool. What we need to be able to do is reload the plugin in some way, so that when a fatal error occurs, we don't need to go through and save it to roblox, then close it and open it again, then be able to build more, especially when you're forgetful like me and do things like #38.

The current process to build the tool during development consists of copying the code of each changed script file into its corresponding script object in Studio, for both the tool and the plugin models.

Ideally this would be automated somehow, such that the code in the script files is copied to the script objects automatically instead of having to be done by hand.

So in Studio when there's a window along the bottom of the viewport like Output or Basic Objects, the plugin's Guis show up about halfway down in the studio window, regardless of if the bottom part is visible. The bottom part of each gui ends up below the bottom of the viewport. I'm probably not making any sense, so here's a screenshot to show what I mean. I figured it's because the offset is being used in the Udim2 positions of the guis, as when the vertical dimensions of the viewport change, the gui stays the same distance from the top. This results in dropdowns not being entirely visible, the bottom row of BrickColors missing in the color tool, ect. Having to drag each and every tool's gui each and every time I use studio is annoying. I propose that instead of (for example) the position being Udim2.new(0, 50, 0, 200), the position be (once again, an example) (0, 50, 1, -500), so the Y axis is determined by the bottom of the viewport rather than the top. The offset property of the Position would be the full height of the specific gui with dropdowns extended and all that jazz, plus a bit of a buffer, negative. This would solve the problem. I would code it if I knew how the dropdowns worked, but I don't. Thanks for your time.

Visual cues would eliminate the need to read each label and visualize the ideal material or surface type.

Perhaps:
a) The background of each option button could be a texture of the material or surface type it represents, or
b) A small image of the material or surface type could appear at the start or end of each option button?

This is because of the NetworkServer it creates to be able to send HTTP requests.

I don't know about the other tools, but when using the move tool and holding the mouse down on a handle, then cloning the part, the tools break, giving this error:

09:31:11.965 - Plugin_144950355.Building Tools by F3X: Plugin.Building Too:600: attempt to index field '?' (a nil value)
09:31:11.965 - Stack Begin
09:31:11.965 - Script 'Plugin_144950355.Building Tools by F3X: Plugin.Building Too', Line 600
09:31:11.966 - Stack End

I'm using the studio plugin. Things like this is why we need #39.

• Ctrl-C, Ctrl-V to copy/paste selection
• Ctrl and Shift instead of just Shift

Just sayin', it'd be nice if there was a hotkey or something for that. I have all the hotkeys for the tools memorized, and it's getting in the way.

This is due to the plugins requiring HttpService, which in turn requires a NetworkServer to be available. When in solo mode, the plugin should not create the NetworkServer, otherwise solo mode breaks. However, there is no reliable way of knowing whether Studio is in solo mode.

Currently, the plugins check for the existence of Game.Visit. This works for checking if solo mode is enabled, but it's also created when the place was opened through an Edit button.

This can be fixed by listening to UserInputService instead of the Mouse object.

The ideal dragging feature should:

• Snap edges to edges, faces to faces, and corners to corners depending on what the user wants
• Move by the set increment
• Have the classic dragging feature where the surface of the part being dragged that is closest to the surface behind that part is oriented towards the latter surface and dragged relative to it.

When the increment field is selected, the first keystroke entered is ignored, and instead acts as it normally does. For example, pressing 1 as the first keystroke when entering the increment results in tool 1 being selected instead. If "." is the first keystroke being entered, it turns the camera view rather than entering it.

Right now, tools have certain of their events hooked up to as callbacks under Tool.Listeners.EventName. This is a pretty strange setup though. They should just be signals, to be able to connect to signal Tool.Equipped, for example, instead of setting Tool.Listeners.Equipped to a callback function.

Will fix this by replacing it with HttpInterface:WaitForChild('Test'), along with anything else that might lead to the same error.

This sometimes causes Studio to conflict with BT's actions and lead to deleting everything by hitting Ctrl + Z instead of Shift + Z.

A feature allowing you to use handles regularly, but offering to enter an exact amount by which to perform the operation, before performing the change.

Ideal experience

1. Use handles in Move Tool to drag X studs in a certain direction,
2. Upon letting go of the mouse button, if the Ctrl key is being held, an autofocused textbox appears near the mouse, containing the number of studs dragged,
3. Type a different number (as soon as first number is typed, original number fades), or leave the one displayed,
   Note: If number is optionally prefixed by = symbol, it's interpreted as the target amount, such that the actual delta is automatically calculated to result in the vector component being the number after =.
   For example, =5 while resizing a part in a direction where it's 4 studs, would result in a change of 1 stud.
4. Pressing Enter completes the movement, and the textbox disappears. Clicking anywhere on the screen outside the textbox, or pressing Esc, cancels the movement and the textbox disappears.

This is a better, cleaner alternative to the current implementation where each item must be individually added by a call to Selection:add(Item).

This would allow for the safe pulling/merging of built .rbxm files.