Poll: is this a good idea?
You do not have permission to vote in this poll.
yes
35.71%
5 35.71%
yes
28.57%
4 28.57%
ice vanish
35.71%
5 35.71%
Total 14 vote(s) 100%
* You voted for this item. [Show Results]

Using Lua to optimize roller levels.
#1
Recently, I spent about an hour and a half making and testing a short lua project of mine involving the block.teleportto lua command. I had been interested in this command ever since needing to use it creating FYR4 sector 12, though this was more related to what I had been doing earlier that day, which was creating a graphing calculator using lua. The code itself is shown below.
Code:
local times = tolua(player.getmetadata("rollerprog", 0))
local rtm = 0
local done = tolua(player.getmetadata("rollergendone", 0))
if done == 0 then
  if times == 0 then
    player.chat("this will take about two minutes. please be patient.")
  end
  if times < 25000 then
    while rtm < 10 do
      rtm = rtm + 1
      local xdist = times + math.random(16) - 8
      local ydist = (times + math.random(16) - 8) * -1
      block.getblock(1,1).teleportto(xdist,ydist, false)
      xdist = times + math.random(12) - 6
      ydist = (times + math.random(12) - 6) * -1
      block.getblock(1,1).teleportto(xdist, ydist, false)
      times = times + 1
    end
  end
  if times > 18745 and times < 18755 then
    player.chat("you are about halfway through the generation.")
  end
  rtm = 0
  local pvtimes = tolua(player.getmetadata("minerollerprog",0))
  if times >= 25000 and pvtimes < 12500 then
    while rtm < 10 do
      rtm = rtm + 1
      local xdist = (2 * pvtimes) + math.random(18) - 9
      local ydist = (-2 * pvtimes) + math.random(18) - 9
      block.getblock(0,1).teleportto(xdist,ydist,false)
      xdist = (2 * pvtimes) + math.random(18) - 9
      ydist = (-2 * pvtimes) + math.random(18) - 9
      block.getblock(0,1).teleportto(xdist,ydist,false)
      times = times + 1
      pvtimes = pvtimes + 1
    end
  end
  if times >= 37496 then
    player.teleportto(5,-5)
    block.getblock(-1,1).teleportto(25000,-25000,true,true)
    player.setmetadata("rollergendone",1)
    player.chat("generation is complete. enjoy your roller!")
  end
  player.setmetadata("rollerprog", times)
  player.setmetadata("minerollerprog", pvtimes)
end

This code takes three blocks set up beneath it like this: 
[Image: 608uB20.png]
and duplicates them, moving the duplicate to a distant location, determined by how far through the generation process it is. The code as it is configured currently creates 50000 vanishes and 25000 bombs, in a roller about 35.3 thousand blocks long (25k blocks tall, 25k blocks wide, diagonal). The lua itself isn't perfect, and due to some limitations, it only generates these blocks locally, and due to the random parts, will be different for everyone.

Despite this, it may be possible to use lua blocks like this to optimize roller levels, before they are sent to the server.


Roller Optimization
Optimizing rollers using this requires certain conditions, and there are some drawbacks to this.

The conditions are:

1. The bombs can be placed in a mathematical way, where nothing about the roller is lost.

This condition prevents using this optimization for "random" sections of rollers, such as vanish sectors. The main purpose of this condition is to minimize player desync.

2. You measured everything properly.

This condition is mostly to keep things normal and possible. If you screw this up, it could be cause issues related to block placement. Thankfully, a few tests with block.teleportto make measurements quite easy to make, and you could always just build around specific measurements.


The drawbacks are:

1. This adds a moment in the match to generate the blocks where they need to go.

Generating the blocks does take a bit. While loops allow the process to move MUCH faster, but it can't be done all at once, as otherwise it would causes extreme lag or even a crash. 20 blocks per frame seems to be good for most people, though it still does cause a crash or significant lag for some. The desktop preloader seems better disposed towards this too.

2. Still some possible desync.

Not everyone will reach the part at the same time, and you can't force people to wait 20 minutes for everyone else to catch up. People that arrive later to the sector will generate some blocks where the first people to get there already passed. This can be solved by generating all the blocks at the start of the level, but this leads to a delay to actually playing the level that may extend to ten minutes or more.


Nonetheless, some examples of roller sectors that could be optimized this way include:

FYR4 sector 3, FYR4 sector 5, FYR4 sector 6, FYR4 sector 7, FYR4 sector 8, FYR3 sector 3, FYR3 sector 2, and FYR3 sector 4.

Using these optimizations in FYR4 could have allowed me to complete the original plan for sector 11 (which was also optimizable), and perhaps tack on a few more sectors after sector 12. After all, this process does save a *lot* of blocks, especially with FYR4 sector 3 and 8.

This process is difficult and requires measurements, which adds a lot to the process of making the roller, but it could allow for significantly longer rollers.

Also, at the time of writing, there are a few things that need to be tested to see how well this would work, namely how bomb explosions would work like this and whether or not it allows for teamwork.
i failed the mario twitter challenge
The Following 1 User Says Thank You to ThePizzaEater1000 For This Useful Post:
  • Northadox
Reply
#2
The testing has gone well, this can be used in rollers.

FYA will be the first roller to see this technology used.
i failed the mario twitter challenge
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)