Rojo question: How to add Touch Event to Part

Help and Feedback Scripting Support
#1

  1. What do you want to achieve?
    I am trying to use Rojo for the first time. I want to use Rojo partially.
    I am trying to create a Part in Workspace, when player touches it, player’s HP turn to 0.

  2. What is the issue?
    In studio, I would add a Script parented to the Part in Workspace, and write touch event in the script.
    For serious Rojo user, what would be the right way?
    To use version control, I probably shouldn’t write logic in Part’s child Script.

  3. What solutions have you tried so far?
    I have searched for Rojo videos and articles. But they are all about setup issue or abstract workflow summary.

Thx for any help!

2 Likes
#2

Nice job trying to learn version control, it’s very powerful and can help you in the long term with your projects and maybe if you decide to go professional and work in a big team.

Anyways, for your question I believe the “typical” would be to create a module script in replicated storage by creating a killbrick.lua script in Rojo “src” which will handle the kill brick logic.

You can handle multiple kill bricks using the CollectionServices workflow of tagging parts with the kill brick tag.

Then using a server script just require the module for the killbrick within a serverscript where you can then execute the kill brick logic for all bricks tagged by the collection service as a function like module.activateAllKillBrickOnTouchEvent() depending on how you set it up:

Refer to module script dev API for using multiple functions or a singular function within a module scrit.

If you want to go a step ahead you can edit the project JSON file to sync server script files, client scripts in Rojo Microsoft visual code to Roblox studio

This is what I did to edit server scripts in visual studio code, then sync using rojo to roblox studio which automatically places the code in a src folder in serverscript service automatically doing the server script stuff.

"ReplicatedStorage": {
      "$className": "ReplicatedStorage",
      "Source": {
        "$path": "src/ReplicatedStorage"
      }
    },
    "ServerStorage": {
      "$className": "ServerStorage",
      "Source": {
        "$path": "src/ServerStorage"
      }
    },
    "ServerScriptService": {
      "$className": "ServerScriptService",
      "Source": {
        "$path": "src/ServerScriptService"
      }
    },
1 Like
#3

Thanks dthecoolest!

I never knew CollectionServices before. This is a wow moment for me. With CollectionServices, there is no need to add killing-logic script to Part.

Can I assume that in the ideal development workflow, we shouldn’t add Script to Part?

If so, I do wonder how to implement following specs: let’s say we have two Parts, one moves from point 1 to point 2, anther Part moves from point 3 to point 4. If I want to make this happen in Rojo, what should I do?

2 Likes
#4

Yeah, it’s not recommended because for an ideal workflow you would want to be able to modify a script as quickly as possible so for a kill brick example it would be fine for 1-5 parts but if you have a large obby with > 1000 kill bricks each with a script inside them then…you wanted to make each kill brick explode on touch becaues it’s cool… yeah don’t do it let the computer do it for you.

Here are some more tutorials on collection services:

Yeah let’s do one more example, so for I Rojo workflow I would do this:

  1. Create a module script in replicated storage or server storage (depends on if you want the script to be available on the client or not, or even both, think ahead for exploiter prevention since they might be able to decompile your byte code I think)
    In Rojo this would be creating MovePart.lua in the src folder to put it in replicated storage according to the default JSON file.

  2. In this module script create a function for doing the specs you mentioned like so in pseudo-code and return this function.

--imagine if this function is 400-600 lines long
function movePart(Part,pointOne,PointTwo)

move part from pointOne to PointTwo

end
  1. Require this function in a server script and execute the specs
--Points to the module in replicated storage then requires it
local MovePartPointer = ReplicatedStorage.MovePartModule
local MovePart = require(MovePartPointer)
--Move part 1 from point 1 to point 2

--execute the function
MovePart(Part1,Point1,Point2)
MovePart(Part2,Point3,Point4)

--Saves a lot of space plus it works
#5

I agree that using CollectionService would be the easiest way to do this, however, I wouldn’t use a ModuleScript, simply a regular server script.

#6

Wow, this is so helpful.

I learn Roblox from Roblox.com’s tutorial and Youtube tutorial. There is some gap between starter’s way and pro’s way.

#7

Yeah that’s a great point for something as simple as an obby kill brick you could just make a server script.

You don’t always need Rojo.

However, keeping this in mind I guess @builder_seller just keep in mind that Rojo is designed around module scripts, but you can also work with server scripts in Rojo as well, what you can do with them is up to you so don’t try and overcomplicate things if necessary.

At the very least you can just use visual studio code to sync scripts to an external Git remote like github and save your version control place online.

#8

Rojo isn’t designed around ModuleScripts, its more just what people who do semi-advanced games on Roblox use, they tend to move into a single script architecture where you do use a lot of ModuleScripts.

#9

But it kinda is at the same time. My source being
the Rojo documentation:

https://rojo.space/docs/0.4.x/sync-details/

Rojo can represent ModuleScript , Script , and LocalScript objects. The default script type is ModuleScript , since most scripts in well-structured Roblox projects will be modules.

Hence, since the default script is a module script, Rojo is actively promoting modular coding which is true to what you say for those type of game architectures.

Imagine if the default script was instead a server script and you would have to write .module.lua to the end of your script text thingy instead that would be real painful for making those types of modular script structure😂.

1 Like