Page 1 of 1

Checkpoints (Dynamically Changing a Teleporter's Output)

PostPosted: Sun Nov 30, 2014 2:13 am
by sky_lark
Hi everyone,

As far as scripts go, I'm pretty clueless. But I found a neat little script in Bobdaduck's map, The Emperor's Revenge (a remix of Arctic's original classic) and adapted it to solve a really big problem in one of my levels. The way it works is it reconfigures a teleporter's output as soon as a player crosses over a trigger. With multiple triggers placed I was able to create a series of checkpoints that would actively adjust the teleporter path as players progressed!

  Code:
--Levelgen script adapted from The Emperor's Revenge by bobdaduck

function changeTeleportDest(teleporterId, dest)
   local teleporter = levelgen:findObjectById(teleporterId)

   if(teleporter ~= nil) then -- if the teleporter exists
      teleporter:clearDests()
      teleporter:addDest(dest)
   end
end

function onShipEnteredZone(ship, zone, zoneType, zoneId)
   if(zoneId == 1) then
      local x = 2
      local y = 2
      changeTeleportDest(50, point.new(x, y))
   elseif(zoneId == 2) then
      local x = 3
      local y = 4
      changeTeleportDest(50, point.new(x, y))
   elseif(zoneId == 3) then
      local x = -6
      local y = -6
      changeTeleportDest(50, point.new(x, y))
   end
end

function main()   
   subscribe(Event.ShipEnteredZone)
end

How to use script: First, go into your level and place a teleporter. Click on it and press Shift-3 (the # key) to enter an ID. You can use whatever number you'd like, but be sure it corresponds to TeleportDest in the level editor. In the above code the ID is 50.

Set the teleporter's output to its starting location. Then, place RepairItems at the locations of where you want new teleporter outputs to be. Go into the level file and find the matching RepairItem. It will look something like this:

  Code:
RepairItem 2 2 5

The first two numbers represent the X and the Y coordinates. These are the numbers you'll need. Disregard the third number which is the delay time for how long the repair item takes to respawn after use and irrelevant for our use.

In fact, we just need the RepairItem for its coordinates. You can delete the RepairItem now. You can achieve the same thing by placing your cursor over the desired spot in the level editor and looking at the bottom left corner for a reading, but I've found the RepairItem method to be more exact.

Once you have the X and Y coordinates of a desired teleporter output location, enter those into the lines "local x" and "local y". Do this for just the first block of code. Then repeat the steps to enter in another output for the second block of code. You can add more code blocks if you need more teleporter outputs or remove some if you need less.

Once the teleporter outputs are all configured, you'll need to place triggers. These utilize the Levelgen Zone, which is marked by a gray box in the lower section of the toolbar on the right side of your screen. Drag a Zone onto the level and place it where you want. When players cross over that Zone, it will trigger the teleporter output to change location. Don't worry, the Zones are invisible in-game and only visible to the level editor.

Before you finish be sure to change the order of the triggers by clicking a Zone and entering Shift-3 (the # key) to change its ID. Match the ID of each zone to the corresponding "zoneId" text in each code block. Make the IDs something easy like 1, 2, 3 which can be easily matched to the Zones in the level editor. After doing all this test the level to ensure everything's working and in the right order!

Re: Checkpoints (Dynamically Changing a Teleporter's Output)

PostPosted: Sun Nov 30, 2014 5:51 am
by Quartz
Yes, I rather appreciated this simple but clever script myself. bobdaduck makes good dungeons in his sleep then calls them "bad."

I attempted to assimilate this script at one point and failed spectacularly. Thanks for the guide, bookmarking.

Re: Checkpoints (Dynamically Changing a Teleporter's Output)

PostPosted: Fri Dec 05, 2014 10:45 am
by amgine
could it be done wihout the repair item markers?

Re: Checkpoints (Dynamically Changing a Teleporter's Output)

PostPosted: Fri Dec 05, 2014 12:37 pm
by sky_lark
Yes. You can place a cursor to the exact spot and look at the number output in the bottom left corner. If you can figure out Bitfighter's numbering you can also just write the numbers manually, but it appears to be more complicated than just 1 square = 1, 2 squares = 2, that sort of thing.

Re: Checkpoints (Dynamically Changing a Teleporter's Output)

PostPosted: Tue Dec 09, 2014 7:18 pm
by amgine
Maybe ill look into figuring out how far 1 square is my guess is 225 pixels

Re: Checkpoints (Dynamically Changing a Teleporter's Output)

PostPosted: Tue Dec 09, 2014 8:05 pm
by raptor
One grid square in the editor was traditionally 255 grid units and was coupled with the server level grid size. After we decoupled and deprecated the GridSize parameter in the level files (in 019 I think), you can now adjust the editor gridsize without affecting the levels with the INI option 'EditorGridSize'.

Re: Checkpoints (Dynamically Changing a Teleporter's Output)

PostPosted: Fri Dec 12, 2014 9:55 am
by amgine
ah so 1 grid square could be 4 grid units?

This gave me a idea for another feature request ill post on another thread.

Re: Checkpoints (Dynamically Changing a Teleporter's Output)

PostPosted: Tue Dec 23, 2014 10:20 pm
by watusimoto
1 big square might be 255 "units". (No bitfighter or code where I'm at so I can't check for sure.)

Re: Checkpoints (Dynamically Changing a Teleporter's Output)

PostPosted: Wed Dec 24, 2014 1:57 am
by sky_lark
Can we change the unit format to more usable numbers? So instead of 1 big square equalling 255 units, it equals 10 units. And 1 small square would equal 1 unit. This would be quite helpful for levelgens that require coordinates to be determined manually, like in this tutorial.

Re: Checkpoints (Dynamically Changing a Teleporter's Output)

PostPosted: Wed Dec 24, 2014 9:29 am
by watusimoto
That might be possible, but would have two side-effects. Either:

1) Units in the editor would differ from units in the level file; or

2) Units in the level file would have to be rescaled such that "1" is no longer the base unit (if we scale from 256 to 100, the smallest unit would be 100/256, which would be awkward).

Probably #2 would be the better answer; older levels would need to be rescaled, but this could be done automatically. That said, there are some of us who think 256 is a very logical size for a big square in the editor. Most players here should be accustomed to thinking in bizarre units with no logical relationship to one another.

Re: Checkpoints (Dynamically Changing a Teleporter's Output)

PostPosted: Wed Dec 24, 2014 9:39 am
by raptor
I think how we have it now in 019 is probably the best way so far:

1. 1 game unit is small and is the same everywhere. e.g. a standard barrier in the editor is 50 units wide (width: 50) and when hosting, it is 50 units wide in the server and sent that way to levelgen scripts. (It was different in 018 and earlier, using a ratio to 255 as the unit, and was quite confusing).
2. You can adjust the editor grid size in the INI. We should make this available in the UI, however. It defaults to 255 because that is tradition, not for any other reason.

Re: Checkpoints (Dynamically Changing a Teleporter's Output)

PostPosted: Wed Dec 24, 2014 1:20 pm
by amgine
would 1 square is 32 units be better? (8:1)

Re: Checkpoints (Dynamically Changing a Teleporter's Output)

PostPosted: Wed Dec 24, 2014 2:24 pm
by sky_lark
As long as you guys have thought about it I'm on board. I don't use cursor positioning all that much so it's not a huge deal either way!

Re: Checkpoints (Dynamically Changing a Teleporter's Output)

PostPosted: Wed Dec 24, 2014 2:25 pm
by raptor
You can make it whatever you want with 'EditorGridSize' in the INI. The point is that it is consistent on the server.

Re: Checkpoints (Dynamically Changing a Teleporter's Output)

PostPosted: Wed Dec 24, 2014 10:05 pm
by watusimoto
One thing I do want to try is to subdivide the big square into 12 little squares instead of 10. That way you could easily go 1/2, 1/3, 1/4, and 1/6 of the the size of a big square. 10 just isn't that nicely divisible.

Re: Checkpoints (Dynamically Changing a Teleporter's Output)

PostPosted: Thu Dec 25, 2014 7:19 pm
by amgine
sounds good.

but why have grid size if its not even enforced on maps ?

Re: Checkpoints (Dynamically Changing a Teleporter's Output)

PostPosted: Thu Dec 25, 2014 10:12 pm
by watusimoto
The grid size you seen in the editor is really not related to anything on the game map. 1 "unit" (not one square) in the map equals one unit in the game. That we draw big squares at 255 pixels high, and smaller ones at a 10th of that is just a convention that the editor has always held to. At one point it actually did (sort of) mean something, but it no longer does. We could change the squares in the editor to anything and it would change nothing outside of the editor. (And I think there is an INI setting to do just that.)

Re: Checkpoints (Dynamically Changing a Teleporter's Output)

PostPosted: Fri Dec 26, 2014 1:38 pm
by amgine
Two things I think are important here are.

1. The UI should default to 256 not 255.

2. Grid sqares should be doubled.

extremely often I find myself needing to place objects at 1/2 of 1 small square and although you can do non grid snapping placement it is very impercice and can make level creation difficult.

Re: Checkpoints (Dynamically Changing a Teleporter's Output)

PostPosted: Fri Dec 26, 2014 10:04 pm
by Fordcars
Not to sound know-it-all-y, but it is 255 because the number 255 fits nicely into one byte, while 256 doesn't. This is obviously confusing, but, one byte is 8-bits. If we fill those 8 bits, it will do 11111111 in binary, which is 255. 256 would be 100000000 :)

But yeah, the user doesn't care if it fits in a byte or not, so maybe it should be a prettier number like 100?

Re: Checkpoints (Dynamically Changing a Teleporter's Output)

PostPosted: Sat Dec 27, 2014 11:18 am
by sky_lark
amgine wrote:extremely often I find myself needing to place objects at 1/2 of 1 small square and although you can do non grid snapping placement it is very impercice and can make level creation difficult.

I run into this a lot, and while it's not a perfect solution, I have a workaround. Take a wall that is one small square in length. Select it, hit ctrl+shift+x to resize it down to .50. This will cut it in half leaving a point halfway in the square. Then drag your other walls or objects you need at that point to that trimmed wall's endpoint. You can get lots of other smaller points by varying the length of wall and resize metric too!

Re: Checkpoints (Dynamically Changing a Teleporter's Output)

PostPosted: Sun Dec 28, 2014 10:04 pm
by watusimoto
Just to be clear, there are 256 possible values for a byte, usually represented as 0-255. I believe that the big squares actually do represent 256 values (but I really don't care enough to argue about it or verify it), but for reasons having no direct relation to bits and bytes. Most likely because programmers just like the number 256, so when you need to think of a number in the 100-300 range, that's what you tend to get.

Re: Checkpoints (Dynamically Changing a Teleporter's Output)

PostPosted: Mon Dec 29, 2014 1:34 pm
by Fordcars
watusimoto wrote:Just to be clear, there are 256 possible values for a byte, usually represented as 0-255. I believe that the big squares actually do represent 256 values (but I really don't care enough to argue about it or verify it), but for reasons having no direct relation to bits and bytes. Most likely because programmers just like the number 256, so when you need to think of a number in the 100-300 range, that's what you tend to get.


Oh ok :P

Re: Checkpoints (Dynamically Changing a Teleporter's Output)

PostPosted: Fri Jan 02, 2015 7:40 pm
by amgine
can we have a smaller grid for easier placment ?

and thanks it helps!