[BETA] Fork3X - An open-source, complete, and patched fork of the F3X building tools!

Resources Community Resources
, ,
41

So, are you enjoying v3.1.0 (apart from the Private Area bug)? Well, I am already thinking about v3.2.0 behind the scenes. I am currently working on another (open-source) resource, and had the idea to add something that you might love, mostly to deal with the new Studio UI update that might impact some: bridges.

Hold on, what’s a bridge?

A way to respect other creators’ works with updates, all by integrating them in the building tools. I mean, are you interested in using stravant’s Gapfill with F3X with a fresher interface? A bridge allows you to do so: it will use another plugin’s files and use them as a functionality for the Building Tools.

As I don’t think I will update this a lot (expect the next update to come soon, but then it will be slower), bridges could allow the building tools to be useful to enhance a plugin. Do not expect this to be here at v3.1.1, but I think it’s a good idea to have an all-in-one plugin.

What do you think of this concept?

Are you interested in bridges?
  • The idea is fantastic and I would like to use them.
  • The idea seems good on the paper, but I won’t use them.
  • I don’t see the point in such a feature.
0 voters

Thanks for voting! Fork3X’s goal is to be useful of course. :+1:

1 Like
42

I noticed there isn’t much info about how you are going to approach Unions, I was personally working on a Fork of my own a while back but never fully finished it, you need to keep track and save the original parts and union them when they are pasted back in.

Granted you can only track unions created via the tool since it needs to store the data.

Is this something you are looking to add in the future?
From what I noticed it doesn’t save or load unions, if it does then must be bugged for me?

And also an import button inside of the tool itself is useful.

I personally scrapped the short code idea and just assigned the codes to the player’s ID with their chosen “save name”. They can save a build to a set name so they will never get overwritten in the Datastore unless they are doing the same build with the same name.
Low odds, but it still happens with the short codes.
Also added a way to have the whole build as a sterilized string that you can export and copy then import. Possible ideas I suppose.

I love the UI Design, it’s amazing. Perfect job with that, it is very clean.

2 Likes
43

Thanks for the comments! I appreciate this!

I will maybe make a documentation about this since it’s a question many developers asked me.

This is normal, and sadly, supporting this is extremely painful.

Theorically, you cannot take any union and get any detail about its composition. It was planned that I make UnionDatas, which would be modules that gets those informations that would allow unions to be separated and also saved.

The only problem is that I think this can maybe be pretty heavy to save: you are somewhat saving a great bunch of parts for this, and sometimes the GeometryService can simply not give the same result… : /

But saying this, I am not saying it’s not coming. It just needs to be done thoughtfully.

Fun fact: There used to be an import button. Another fun fact: the F3X servers often got the builds erased with inappropriate stuff in them.

You know what? I should maybe think about it again. I heard a bit about the Buildverse servers (that are now accidentally the default export servers) that doesn’t suffer from those erasure issues. So maybe I can bring it back and add something to get both servers (by typing BV:abcd or F3X:abcd in function of which server).

Thank you! I put a lot of effort on it.

2 Likes
44

I noticed that moving a grouped model with collisions enabled makes the parts non-collidable on the client side until you delete it and undo. I hope this gets fixed soon! Great job on it so far, it’s really cool to see. :+1:

3 Likes
45

I maintain my own fork of F3X which is designed to work in the 2021 version of Rōblox.

I’ll definitely add your patches in:

1 Like
46

Yes! I saw your fork on the F3X repository. Just make sure that some of the new methods might not be avalaible in that Roblox version.

Good luck. :+1:

2 Likes
47

Inside the move module on line 582, instead of

for _, Model in ipairs(Selection.Models) do
	for _, Part in Model:GetChildren() do
		if Part:IsA("BasePart") then
			SetUpPart(Part)
		end
	end
end

I swapped the

if Part:IsA("BasePart") then

with

if Part:IsA("BasePart") and not InitialPartStates[Part] then

So far it’s worked for me

2 Likes
48

You can even remove this line since I don’t use Selection.Models for BulkMoveTo(). I forgot to do it I don’t know why, but yeah, thanks for pointing out!

This line will indeed capture the part state twice, once with the correct collision initial state, and a second time when they’re disabled, explaining why this happens.

2 Likes
49

I know this has been pretty silent for now. This is normal since I am working on some other project and have to do other crucial changes for the building tools for a smooth future.

I have been noticing that profiles are kind of painful to set up; you need to use 2 attributes that are easy to confuse. However, I have some good new. I am currently replacing Roact to React-lua for better performances (in some scenarios, the explorer could create lag on a whole server with Roact).

And guess what? Roblox gave me a hand by releasing a really helpful update you can find here. UI styling will create real performance improvements (profiles are extremely laggy due to every methods that have to be used behind the scenes) and more ease to make them.

Alongside, another wonderful update found here will let me access most APIs via secrets. This means many that burdens that appeared with the F3X servers’ slow death will disappear in the next update, including Decal to Image (without fast load), MeshPart to Mesh/Texture, marketplace results and meshpart searching, etc…

I also keep working on a transformation tool update that should allow separation and more control on unioning, and so the longly awaited union saving. This with some other bug fixes and requested features.

The list looks big, right? But sure it’s worth the wait. This should be coming in a few weeks (without bridges sadly), and I’m sure you’re not going to regret it.

4 Likes
50

This is what I was waiting for, this is one of the best forks for f3x so far. coming with only one issue, I am fearful of implementing this and handing it to anyone in any of my games due to the export feature as people can use this tool as a method to steal maps, is there any way to set a permissions or maybe run a game:getalldescendants to add a attribute that makes everything unsavable?

1 Like
51

You can disable export manually easily by changing the CoreCustomFunctions setting to:

	CustomCoreFunctions = {
		ExportSelection = {function()
			print("This shouldn't export if done correctly.") -- You can remove this tho.
		end}
	};

You can even copy the ExportSelection() function in the Core module, put it as I did above, and modify things so it doesn’t export forbidden things.

1 Like
52

oh yeah thanks that’ll be great, i’ll be using this from now on and maybe I’ll be able to make it so you can only export stuff that YOU own

53

god this is so p eak i love this thing

i used to build with f3x in a old scene maker game or something

THIS IS SO PEAK. 10/10

1 Like
54

Will you add support for Intersections?

55

You mean collisions while moving? I shall remind this requires some extra operations that can be extremely laggy in-game, and aren’t often used.

56

No, I mean the IntersectionOperation for transformation tool.

57

Ah, yes! Coming with the good new for you: it has been added in v3.1.1 that will release in a few weeks. I’m having a break for now so I can work back on my other projects efficiently.

According to me, I think the intersection tool in Studio is… strange. That’s one of the main points I made this resource (that I first made personally) which was to make building in studio less of a struggle. Hope you’ll enjoy it when v3.1.1 will release!

EDIT: Did you notice something? In the building tools’ original files, the version is v3.1.0. So why are we still at v3.1.0? Well, Fork3X was actually built over v3.0.0, hence why it was slightly off on a first time.

58

Thanks! I will update my version of Fork3X when that comes! :smiley:

59

Wait, can you also do ColorSequence support too for ParticleEmitters?

60

I noticed that the code you have on GitHub is very different from what I see in the demo place file, &c. Just sent a pull request to fix that.