So I’m trying to make a game where each team has their own area, you build a base in your team’s area out of BTools, and invade other teams’ bases.
A couple of problems I ran into is that you can grief other teams’ builds by creating, deleting, and editing parts outside your own area, and you can move parts you create in your own area into another. Here is what the map looks like, and each color block is each team’s area:
I’ve tried different scripting methods, like detecting if a player is touching a part, detecting what team a player is on, and adding and removing items from a player’s inventory. However, I couldn’t quite figure out how to put all of those in one script, because I think that would solve the first problem. I haven’t figured out anything about the second problem, though.
because your not using your own building system it makes it a little trickier but what u are meant to do, is before placing each block/part/model/whatever is check if its within the correct region like the cooridinates are within the building coordinates and if they are then place the block, same goes for deleting when deleting a block check if its within ur bases volume
I’ve edited F3X Tools before, so I know how they work. It works using two scripts. A local script that handles client input and a server script that creates/edits parts. You’ll will need to do a couple things:
You will need to have a method for detecting if a part enters another teams area. Luckily with the release of WorldRoot | Roblox Creator Documentation this can be easily done. You will just have to filter through the results to see if any parts should not be there. If it is, then delete it. Chances are that if the server checks and finds a part, somebody has overridden their clients scripts and/or is hacking/exploiting. a. This should be done on both the server and the client. The server for the absolute preventative measure and the client so that it doesn’t just delete the part. b. When doing this check on the client, you have access to the builders history (the undo and redo actions). When an action is performed on a part, whether it be resizing, repositions, recoloring, ect. that action is stored in an array that holds the builders action history. You should be able to add checks to the code before sending the action to the server or adding the action to the builders history. Before the action is performed, you’ll want to check if the part is in another teams territory. If it is, then you should drop the request and return the part to its original state before the change (the part is being edited locally to provide the visual effects of the change before they are replicated to the server).
You will need a method for detecting what team owns which parts. You may also want to add the option of individual-owned parts (as a togglable option if they didn’t want others messing with their build). This can be accomplished with several methods. You could even use multiple to do the job. These include but are not limited to: CollectionService | Roblox Creator Documentation, Instance Attributes | Roblox Creator Documentation, or detecting what parts are in the teams area. The last one is because no other teams part should be able to be put in another teams area so the only parts that will be in the area are that of the own team. You could also make sure that all parts created by a team are parented to a folder for that specific team in the workspace (or wherever else) and then check if it is a descendant of that teams folder (Instance | Roblox Creator Documentation).
Because I’m too lazy to open studio and find a copy of F3X Tools, you’ll just have to trust my word that in one of the modules there is the code that handles selecting parts (the selection module? Collection? IDK, I haven’t played with it in a while). Then you can add the folders that each teams parts reside inside inside an array for blacklisted parts. If a part is in the array or is a descendant of one of the items in it then you can keep from adding it to the current selection. If you want me too, then I can try and find the specific lines of code for you.
Understanding is key. Before you do anything, you’ll want to familiarize yourself with how the F3X Tools work if you want to do any changes of your own. It may take awhile, but it will be worth it. Besides, it will most likely make you a better programmer in the long run!
