User:Butternutbamboo

From MinecraftOnline
Jump to navigation Jump to search
User butternutbamboo
getplayerhead.sh?butternutbamboo&128.png
About
Known as butternut / butter / bamboo
Gender nonbinary
In Freedonia
First joined 5 September 2020
First building Blue Hill mayor's house
Staff member Moderator
Support level **** Supporter IV
Kit level **** Gold
View profile and statistics

Hi, welcome to my user page! Feel free to leave a message on my talk page :)

I'm named after the butternut squash and the lucky bamboo plant (dracaena sanderiana). At the time, butternut squash was my favorite vegetable and lucky bamboo was my favorite plant.

Projects

Name Type Started Note
Blue Hill Category:Towns 2020-09-20
Misc. wiki contributions 2023-07-10
Primrose Category:Cities 2023-08-05
Item farms Category:Howto 2023-09-15 Directory of public farms and guides on how to build your own
MCO Case Book Category:Rules 2023-10-12 Review of scenarios of uncertain legality
Freedonia Public Library Network Category:Organisations 2023-11-28
Primrose-Elysium Flower Farms Category:Agricultural 2023 or 2024?

I like to build things at a small / realistic scale, i.e. one story = 3 blocks. It doesn't leave a lot of room for detail, but I find that it makes builds more immersive to walk through :)

I love doing interior decorating of builds also!

Player homes

# Location Coordinates / Map link Contribution
1 Blue Hill 4352, -14622 Built, along with the surrounding town
2 Shackcity 15693, -9695 Built
3 Computia -18569, -2851 Furnished (built by getplayerhead.sh?Headmate&16.png Headmate)
4 Sandy Shades 14455, -2843 Built
5 Georgetown -2404, -2997 Empty
6 Newport Tower apartment 29 (floor 11) -10688, 18905 Furnished (built by getplayerhead.sh?Darkerfly&16.png Darkerfly)
7 Obsidian Town Butternut Ranch 8199, 15697 Built
8 Elysium 5268, -15648 Furnished (built by getplayerhead.sh?1melinoe1&16.png 1melinoe1)
9 Art Studio -472, -843 (End) Built (designed by getplayerhead.sh?1melinoe1&16.png 1melinoe1)
10 Spawn 25, 274 Built
11 Primrose 4725, -14914 Built
12 Sleeptopia v2 -7949, 9218 Built

There is a convenient mailbox in front of my spawn house if you want to drop me any items!

Interesting links / places

  • A cute + peaceful little fountain area built by getplayerhead.sh?RainBd&16.png RainBd in the North Borderlands, at 4658, -18137.
  • Floracliffs: Super cute and peaceful town with lots of cliffs and tons of flowers! One of my favorite places to walk around and explore on the server. Really easy to get lost in a good way. :)
  • Bad Apple Cinema: Really neat use of Craftbook! A theater that plays an animated film with sound.
  • Yannapurna National Park, or more generally, builds by getplayerhead.sh?YugRekooh&16.png YugRekooh: Super interesting builds that play with scale and gravity.
  • The very tall chunk by getplayerhead.sh?Berselius33&16.png Berselius33 in the Mosaic Mansion is super interesting to explore! It really feels like an adventure to start at ground level and work your way up through all the different areas and builds within - I haven't experienced anything similar on the server. You'll need a kit with at least /thru or a lot of ender pearls.
  • NECROPOLIS: Immersive and consistent horror build with lots of lore hidden around.
  • Milva

Research

Impact of early gifts for new player survival / activity

Background: The impact of giving gifts such as iron or diamond tools or armor to new players has been debated, with some arguing that early assistance can help ease players into the server while others argue that doing so disincentivizes further play. However, knowledge has been limited to anecdotal evidence and no formal analysis has been carried out to research the impacts of early assistance.

Research questions:

  • How do different gifts given to new players affect their relationship with the server and its community?
  • Do different gifts have different impacts?

Hypothesis: In general, early gifts will not have an impact on player survival or citizenship, as these will mostly be driven by external factors upstream of character and personality, or by mentorship from more experienced players.

Data: Chat logs were obtained for one year covering September 1st, 2022 to September 1st, 2023.

Timestamps of advancements were extracted from these chat logs; advancements were detected by searching for advancement messages such as "[player] has made the advancement Cover Me With Diamonds" chatted by McObot. Specifically, the following three advancements were searched for:

  • Suit Up (iron armor)
  • Isn't It Iron Pick (iron pickaxe)
  • Cover Me With Diamonds (diamond armor)

Among users with at least one of these advancements, timestamps of first and last seen and time played as of December 6, 2023 were obtained from the server's Web Scripts.

Additionally, the following cutoff points were used to create indicator variables:

  • Early gift: If a player received an advancement within 45 minutes of joining (polled from ingame chat)
  • Left server: If a player was last seen more than 30 days ago

Methods: A conceptual framework is shown below. The causal path of interest is shown in green and is biased by confounding paths in red through who is online, reflecting who can provide gifts or help in general, and personal characteristics. It is hypothesized that how friendly a new user is may affect the propensity of other players to give gifts or help, though this requires further study.

The following methods are used to investigate the relationship of interest:

  • Crude analysis: In the crude, unadjusted analysis, a robust Poisson model was fit to estimate probability of having left the server due to having received an early gift.
    • Model: 
      glm(left_server ~ early_gift, data = merged, family = quasipoisson(link = "log"))
  • Cluster analysis (Canceled): In the cluster analysis, players were matched to each other by clustering based on similarity of online player lists at the time of joining the server. The cluster IDs were then included as dummy variables in the same robust Poisson model.

Results: A total of 775 player joins were detected over the study period. The table below shows the characteristics of these players relevant to the study. The accompanying figure also shows the relationship between time-to-first-gear vs. overall time played among the different gear types.

Characteristics of players
Variable Median (IQR) or Count (%)
Banned 4 (0.52%)
Received an early gift 135 (17.42%)
Left the server 456 (58.84%)
Time played (hours) 0.34 (1.20)
Time since last seen (days) 444 (45)
First gear = iron armor 52 (6.71%)
First gear = iron pick 40 (5.16%)
First gear = diamond armor 43 (5.55%)
First gear = none 640 (82.58%)
Time-to-first-gear, if any (hours) 0.5 (2.4)

Results from the regression modeling are shown below. A significant relationship between early gift and left server over the time period could not be found, either across the whole sample or within strata of gift type.

Modeling results showing point estimates and 95% confidence intervals, using robust covariance matrices via sandwich.
Coefficient Whole-sample (n = 124) Iron armor (n = 48) Iron pickaxe (n = 37) Diamond armor (n = 39)
Intercept 0.96 (0.91, 1.00) 0.88 (0.72, 1.01) 1.00 (1.00, 1.00) 1.00 (1.00, 1.00)
Early gift 0.98 (0.90, 1.04); p = 0.61 1.07 (0.86, 1.26); p = 0.47 0.95 (0.85, 1.03); p = 0.34 0.95 (0.85, 1.03); p = 0.32

Analyses did not proceed to the cluster analysis due to very low power likely precluding meaningful results.

Discussion: The crude analysis confirms our hypothesis that receiving an early gift does not affect a player's propensity to stay or leave the server. However, the sample used for the analysis was very small: n = 124 in the whole-sample model, where the variables for both early gift and left server were not missing (i.e. join, first gear, and last seen timings). Further research is needed to provide more evidence for this.

The following are potential areas that this study could be improved upon:

  • An opportunity to close the second biasing path through personal characteristics may be available by using sentiment analyses or mixed methods to quantify and adjust for personal characteristics.
  • Early gifts have been identified using a simple cutoff value which is prone to misclassification. Future work can review the chat logs before each advancement to determine manually if it was an early gift or not.
  • Left server has been identified using a simple cutoff of 30 days. It's possible that people could rejoin the server again after this time.

Factors affecting propensity to donate

Background: WIP

Research questions: WIP

Hypothesis: WIP

Data: WIP

Methods: Several features were engineered from the sample data, shown below:

  • Year joined
  • Time played and kits
  • Velocity of time played
  • Season, using periodic terms for day-of-the-year
  • Number and overall sentiment of chat messages sent and times mentioned in chat
  • Wiki activity (presence of user page; number of edits)
  • Achievements earned (iron pick, diamond armor, etc.)

These features were then used to train an XGBoost machine learner with hyperparameters optimized via Bayesian optimization, using 10-fold cross validation. Shapley values were used to assess importance of individual features for the overall model fit and the impact that each feature had on model predictions.

Results: WIP

Discussion: WIP

Time series of Emerald Mall prices

Ongoing project! Using Rifts to build a time series of the prices of items at Emerald Mall.

Spaghetti plot of price movements from 2022 to 2026.
Histogram of price movements from 2022 to 2026. Note log X axis.

For more information and the full data: Emerald Mall Prices#Historical prices and price movement

A Monte Carlo simulation for nether wart farm optimization

Background: The City of Primrose is planned to have a fully automatic, passive nether wart farm installed under the port area. There are two different ways to design such a farm:

  1. . Based on MCZ205 Automatic Block Detector, configured to detect block 115:3 (fully-grown planted nether warts), or
  2. . Using a tick-based timer.

We ended up choosing the MCZ205-based design. We then aimed to find what was the optimal number of block detectors to use to maximize the harvest rate of the farm. There are two competing factors:

  1. The harvest efficiency, i.e. the proportion of nether warts fully grown at the time of each harvest cycle, and
  2. The time between each harvest cycle.

Both of these factors increase with an increasing number of block detectors, implying an ideal number of block detectors at which the farm output is maximized.

Research question: What is the ideal number of block detector ICs to use to maximize nether wart farm efficiency?

Hypothesis: There will be some ideal number of block detector ICs before and after which farm efficiency will decrease.

Methods: A Monte Carlo simulation was written to simulate nether wart growth and farm performance for different numbers of block detectors. This simulation was parameterized with the following information:

The last parameter will not affect the shape of the resulting curves but will affect the magnitude of the harvest rate.

The R code for this simulation is available below (click on "Expand" to show). 

#!/usr/bin/env Rscript
# Monte Carlo simulation for Primrose nether wart farm

library(ggplot2)
library(parallel)
library(pbapply)

# BlockDetector-based -----------------------------------------------------

# n_sampled = Number of nether warts to check for full growth before harvest
# n_warts = Total number of nether warts planted in the harvestable area
sim_detectors <- function(n_sampled = 1, n_warts = 11 * 30) {
  warts <- rep(0, n_warts)
  i <- 1
  while (TRUE) { # Each random tick
    warts <- warts + as.numeric(runif(n_warts) > 0.9)
    if (all(warts[1:n_sampled] >= 3)) {
      break
    }
    i <- i + 1
  }
  return(data.frame(
    i = i,
    p_grown = sum(warts >= 3) / n_warts * 100,
    n_grown = sum(warts >= 3)
  ))
}

result_detectors <- data.frame(n_sampled = as.integer(rep(1:10, times = 10000)))

cluster <- makeCluster(8)
result_detectors <- cbind(
  result_detectors,
  do.call(rbind, pblapply(result_detectors$n_sampled, sim_detectors, cl = cluster))
)
stopCluster(cluster)

## Harvest efficiency ----

ggplot(result_detectors) +
  aes(x = n_sampled, y = p_grown) +
  geom_smooth(method = "gam") +
  labs(
    title = "Percent of nether warts fully grown at time of harvest",
    x = "Number of sampled nether warts",
    y = "Percent of nether warts fully grown"
  ) +
  scale_x_continuous(breaks = unique(result_detectors$n_sampled)) +
  theme_minimal() +
  theme(panel.grid.minor = element_blank())

ggsave("sim-nether-warts-p-grown-v-n-sampled.png", width = 6, height = 4)

(table_proportion <- aggregate(
  p_grown ~ n_sampled,
  result_detectors,
  function(x) sprintf("%0.2f%%", round(mean(x), 2))
))

## Harvest rate ----

result_detectors$rate_per_hour <- (
  result_detectors$n_grown / result_detectors$i / # Rate per random tick
    47.3 * 60 * 60 # Conversion to hours
)

ggplot(result_detectors) +
  aes(x = n_sampled, y = rate_per_hour) +
  geom_smooth(method = "gam") +
  labs(
    title = "Nether wart harvest rate vs sample size",
    x = "Number of sampled nether warts",
    y = "Harvest rate per hour"
  ) +
  scale_x_continuous(breaks = unique(result_detectors$n_sampled)) +
  theme_minimal() +
  theme(panel.grid.minor = element_blank())

ggsave("sim-nether-warts-harvest-rate-v-n-sampled.png", width = 6, height = 4)

(table_harvest <- aggregate(
  rate_per_hour ~ n_sampled,
  result_detectors,
  function(x) round(mean(x))
))
# Ideal: 3

merge(table_proportion, table_harvest, by = "n_sampled")

Results: The tables and figures below show simulation results for 10,000 iterations, 1,000 for each number of nether warts sampled from 1 to 10.

Results of a 10,000 iteration Monte Carlo simulation for an 11x30 nether wart farm
Number of sampled nether warts Proportion fully grown at time of harvest Nether warts harvested per hour
1 51.43% 403
2 67.46% 446
3 75.97% 448
4 81.00% 443
5 84.06% 436
6 86.80% 426
7 88.14% 421
8 89.39% 415
9 90.68% 407
10 91.48% 402

Discussion: From the above results: 3 is the ideal number of block detectors to use.

A Monte Carlo simulation for sugar cane farm optimization

Background: In addition to nether warts, the City of Primrose is planned to have a fully automatic, passive sugarcane farm installed under the port area. As with the nether warts, there are two different ways to design this farm:

  1. Based on MCZ205 Automatic Block Detector, configured to detect block 338 (sugarcane), or
  2. Using a tick-based clock.

Harvesting sugarcane early with pistons has no penalty, so we chose to use a tick-based timer in order to pack the sugarcane more densely. This is because MCZ205-based sugarcane farms must accommodate both the block detector and the lever output in order to drive the pistons. An optimal 2-row sugarcane farm requires a width of 5 blocks to accommodate the machinery, while a similar tick-based farm requires only 3 blocks.

As with the nether wart farm, we have two competing factors:

  • Clock speed / lag: We would like to avoid the lag that would be incurred by running a fast harvest clock. Additionally, setting the clock as fast as possible can actually decrease the production rate of a sugarcane farm. With a fast clock, there is a higher probability that the space above the sugarcane will be filled with a solid block, preventing harvest.
  • Harvest efficiency: To simplify the build process and prevent lag that would be caused by a more densely-packed design, we chose to allow for the sugarcane to grow 3 blocks tall instead of the usual 2 found at automatic farms. Compared to a typical farm that harvests 2-block-tall sugarcane using pistons with a 2/4=50% vertical space efficiency, the 3-block-tall design has a 3/5=60% vertical space efficiency (the additional 2 blocks of height in each design are one for the substrate / water and one for the block holding up the water). Additionally, leaving 2 blocks of space allows for a buffer period where late harvesting does not slow down the farm until at least half of the sugarcane have fully grown, at which point growth attempts will result in more failures than successes.

Research question: At what point does the harvest efficiency start to decrease as the harvest clock period keeps increasing?

Methods: A Monte Carlo simulation was written to simulate sugarcane growth and farm output as a function of harvest clock period. This simulation was parameterized with the following information:

As with the nether wart farm: last parameter will not affect the shape of the resulting curves but will affect the magnitude of the harvest rate.

The R code for this simulation is available below (click on "Expand" to show). 

#!/usr/bin/env Rscript
# Monte Carlo simulation for Primrose sugarcane farm

library(ggplot2)
library(mgcv)
library(parallel)
library(pbapply)

# harvest_clock = Number of ticks between harvests harvest
# n_sugarcane = Total number of sugarcane planted
# max_height = Maximum height that the sugarcane is allowed to grow
sim <- function(harvest_clock = 1000, n_sugarcane = 10 * 12, max_height = 3) {
  growths <- rbinom(n_sugarcane, harvest_clock, 3/4096)
  harvest <- sapply(floor(growths / 16), min, max_height - 1)
  return(sum(harvest))
}

result <- data.frame(harvest_clock = as.integer(rep(
  round(seq(1e3, 1e5, length.out = 100)),
  times = 1000
)))

cluster <- makeCluster(8)
result$sugarcane <- pbsapply(result$harvest_clock, sim, cl = cluster)
stopCluster(cluster)

ggplot(result) +
  aes(x = harvest_clock, y = sugarcane) +
  geom_smooth(method = "gam") +
  labs(
    title = "Sugarcane harvested vs game ticks between harvests",
    x = "Game ticks",
    y = "Sugarcane harvested"
  ) +
  theme_minimal() +
  theme(panel.grid.minor = element_blank())

ggsave("sim-sugarcane-harvest-vs-clock.png", width = 6, height = 4)

result$rate_per_hour <- (
  result$sugarcane / result$harvest_clock * # Rate per game tick
    12 * 60 * 60 # Conversion to hours assuming 12 TPS
)

## Optimization ----

model <- gam(rate_per_hour ~ s(harvest_clock), data = result)

predicted <- data.frame(harvest_clock = min(result$harvest_clock):max(result$harvest_clock))
predicted$predicted_rate_per_hour <- predict(model, newdata = predicted)

(max_output <- subset(predicted, predicted_rate_per_hour == max(predicted_rate_per_hour)))

ggplot(result) +
  aes(x = harvest_clock, y = rate_per_hour) +
  geom_smooth(method = "gam") +
  geom_vline(xintercept = max_output$harvest_clock) +
  labs(
    title = "Harvest rate vs harvest clock",
    subtitle = sprintf(
      "Maximum output at %s-tick clock (%s sugarcane per hour)",
      max_output$harvest_clock,
      floor(max_output$predicted_rate_per_hour)
    ),
    x = "Harvest clock (ticks)",
    y = "Harvest rate per hour"
  ) +
  theme_minimal() +
  theme(panel.grid.minor = element_blank())

ggsave("sim-sugarcane-harvest-rate-vs-clock.png", width = 6, height = 4)

Results: The tables and figures below show simulation results for 10,000 iterations, 1,000 each for 100 harvest clock tick rates evenly spaced between 1,000 and 100,000 ticks.

Discussion: From the above results: the ideal length of the harvest clock period is about 50,000 ticks.

Retrieved from "https://minecraftonline.com/w/index.php?title=User:Butternutbamboo&oldid=144195"