Final teleport
was created for several reasons
-
I needed something more complex than just changing my ped’s coordinates.
-
By default, Final teleport supports mHacking
-
Teleports can be restricted either upon entry or as the end destination
-
multiple exit options (aka elevators)
-
QB version supports also
- lockpicking
- job restriction
- various item restrictions (keys, DNA, any item)
-
There was no modular teleport which would offer easy option to trigger events when needed and
Final teleport does exactly that. This works perfectly in conjunction with my Maploader resource for example.
Menu UI from Kakarot is used and expanded upon, with his permission.
BUY HERE
Commission form
.
Maps
Convention centre
Paleto Bay villa
Demolition derby
Japanese Roads: US to JPN bridge
Japanese Roads: Wangan
Japanese Roads: Akina
Nürburgring Nordschleife Enhancements
Eagle Nest
Casino Rallycross
Daytona inspired freeway
Kagarasan bridge
Kagarasan 2022
Scripts
.
This resource is encrypted by Escrow
Here is a video or written down example teleport from configuration file with explanation:
Also with a proper formatting
["Example Teleport"] = {
-- order of values below doesn't matter, but it's sorted in certain systematic order for clarity sake
----------------------------------------------------------------------------------------------------------------------------
-- required
-- optional -- can be used, but also skipped
-- optional -- is dependent on the first optional above
-- optional -- is dependent on the first optional above
----------------------------------------------------------------------------------------------------------------------------
Coords = vector4(-11262.46, -9643.64, 39.16, 203.03), -- required -- location of the teleport
Exit = "Outside", -- required -- one way via another teleport in config
-- Exit = vector4(-11562.52, -8811.21, 79.84, 203.03), -- alternative: vector4
-- Exit = {"Inside", "Outside"}, -- alternative: table of possible exits to choose from
Label = "~y~Footnote", -- optional -- a footnote visible under teleport's name, can be used with coloring such as ~y~, ~b~, ~s~ etc.
OutdoorDist = 30.0, -- optional -- determines from what distance will be the teleport visible, BUT will be triggered only from 2.5 units anyway (if no value, 2.5 distance is used)
Wait = 3000, -- optional -- how long delay before player is able to see and move around after going through the teleport, in milliseconds (useful for large distances and slow PCs)
ReadyToBeBrokenIn = true, -- REQUIRED, IF you'll decide to use anything related to illegal entry below, if you don't want to have illegal entry option, delete "ReadyToBeBrokenIn" line entirely
BreakInMethod = "mhacking", -- optional -- only "mhacking" for standalone
MhackingSequence = {4,5,6}, -- required for "mhacking", can be either single digit or a table of however long sequence of stages you want
MhackingTime = 60, -- required for "mhacking", in seconds
ClientEvent = { -- optional -- when going trough teleport, this will trigger virtually unlimited amount of client sided events given
["another:resource:client"] = { -- optional -- this can go up to 10 individual values for client sided events, with or without any variables
Variables = {
val1 = "My example value 1",
val2 = "My example value 2",
val3 = "My example value 3"}
},
["other_test:client"],
["LastOne"]
}
ServerEvent = { -- optional -- when going trough teleport, this will trigger virtually unlimited amount of server sided events given
["another:resource:server"] = { -- optional -- this can go up to 10 individual values for server sided events, with or without any variables
Variables = {
val1 = "My example value 1",
val2 = "My example value 2",
val3 = "My example value 3"}
},
["other_test:server"],
["LastOneServer"]
},
TPChosenFromSelection = { -- optional -- used exactly same logic as above with the difference being that this table of information is tied to the EXIT TELEPORT/LOCATION player goes through/into
ReadyToBeBrokenIn = true,
ReadyToBeBrokenIn = true, -- REQUIRED, IF you'll decide to use anything related to illegal entry below, if you don't want to have illegal entry option, delete "ReadyToBeBrokenIn" line entirely
BreakInMethod = "mhacking", -- optional -- only "mhacking" for standalone
MhackingSequence = {4,5,6}, -- required for "mhacking", can be either single digit or a table of however long sequence of stages you want
MhackingTime = 60, -- required for "mhacking", in seconds
ClientEvent = { -- optional -- when going trough teleport, this will trigger virtually unlimited amount of client sided events given
["another:resource:client"] = { -- optional -- this can go up to 10 individual values for client sided events, with or without any variables
Variables = {
val1 = "My example value 1",
val2 = "My example value 2",
val3 = "My example value 3"
}
},
["other_test:client"],
["LastOne"]
},
ServerEvent = { -- optional -- when going trough teleport, this will trigger virtually unlimited amount of server sided events given
["another:resource:server"] = { -- optional -- this can go up to 10 individual values for server sided events, with or without any variables
Variables = {
val1 = "My example value 1",
val2 = "My example value 2",
val3 = "My example value 3"
}
},
["other_test:server"],
["LastOneServer"]
}
}
}
There is something I could consider a bug:
Due to the nature of the script, whenever the resource logic goes through table of items/jobs instead of 1on1 value, it does not notify you, if it’s robbable or not. Simply hit E again, till it will tell you for example “Access restricted” or “You’re missing hacking device”.
I tried my best to iron all bugs I could found out, but if you would be lucky to find some, turn on Debug function /teleports_debug and send me your repro with your client and server sided log. I’m happy to assist, if needed.