MCPI and MCPI-reborn

[mitu]

@bulleribokk said in MCPI and MCPI-reborn:

@mitu thanks for the reply :) It is just short for minecraft-pi, no it is not an official minecraft client [...]

Ok, so it's an clone with some extra features (learning programming being one of them).

The solution you mentioned for when desktop environment is needed - could you please elaborate a bit? I'd rather not install the entire desktop, so I hope that's not what you meant. My target retropie machine is rpi3, which is not really powerful enough for desktop AND a game.[...]

There not much to elaborate. Just start the desktop and then open the game like normal. I don't think the desktop environment itself is so heavyweight that impacts the performace of a game. FWIW, starting the desktop means:

• starts the X server - that's what takes the most CPU/RAM
• start openbox - the window manger
• start lxpanel - the panel that provides the start menu and the taskbar. There may be some optional applets (audio/WiFi) which are incorporated here, but I they're not impacting the performance in any way.

If you want to automate that (similar to your scripts below), then you can copy an existing port's script and create a new port. In the the new port, start your application as a 'desktop app', just likeminecraft-pi is started right now. Using the XINIT-WM prefix will take care of starting the Window Manager + Xorg before your port/game is started.

In the latest update on retropie github now I see there's a change.

You need to elaborate which change are you thinking about. Are you referring to the XINIT-WM prefix addition that would enable launching a minimal windows manager for X based ports/applications ?

Not that I understand what the difference between old and new way is, but I'm wondering if some solution like that is needed for running MCPI-reborn as well. I'm for some reason unable to run the game directly from files extracted from AppImage. Clearly, the best way to run it is running the AppImage file, as intended. Does newest version retropie support AppImages?

Launching from the front-end (EmulationStation) on a Pi, no. On a desktop installation (i.e. on a PC), then they should probably work as simple Ports.

I haven't updated to the newest retropie yet, read that there was a new release on pi-day, but maybe I should just do a test install on a separate SD card to see if the newest retropie runs AppImage files. If it does, then perhaps it could work with something like

No, there was not a release on Pi day, not this year anyway.

[bulleribokk]

@mitu said in MCPI and MCPI-reborn:

No, there was not a release on Pi day, not this year anyway.

I may have mixed up with rpiOS release. Anyway thanks for your suggestions, but yes I did state that running rpiOS AND the game on rpi3 is jerky because it does take a lot of resources to run the entire desktop environment in rpiOS. Maybe in retropie the desktop environment is different, anything that might work is worth a shot :)

[bulleribokk]

@mitu said in MCPI and MCPI-reborn:

FWIW, starting the desktop means:

starts the X server - that's what takes the most CPU/RAM
start openbox - the window manger
start lxpanel - the panel that provides the start menu and the taskbar.

I've made sure I got the latest retropie and did the update and upgrade commands and all should be good, so then after your explanation about desktop here^ I tried to make a script to put in the ports folder like so:

#!/bin/bash
startx
openbox
lxpanel

Problem is, I kinda didn't get that very last thing you described, i.e. I get no start menu or task bar or anything, just the blank screen with a mouse pointer to move around :\
Have you got a tip for how I should do it the correct way? to get an actual useable desktop?

[mitu]

@bulleribokk said in MCPI and MCPI-reborn:

I've made sure I got the latest retropie and did the update and upgrade commands and all should be good, so then after your explanation about desktop here^ I tried to make a script to put in the ports folder like so:
...

Maybe I wasn't clear enough, but my explanation of 'what's in a X session' was meant to exemplify what programs are running in an X session and why I don't think starting a desktop env is that 'heavy'. It wasn't meant to be put in a start script and that was not my intention.

What I meant was to

• install the desktop from Retropie-Setup (see the docs) then you can start the desktop from the Ports system and then subsequently start mcpi. No script involved, just clicks.

OR

• create your own scriptmodule similar to the minecraft.sh (this one, which should live in $HOME/RetroPie-Setup/scriptmodules/ports in your system) file. You can copy the file and rename it to mcpi.sh and then replace any occurences of minecraft with mcpi. Make sure the path to the executable is correct, then use RetroPie-Setup to install the new port. The newly added port entry would automatically start a minimal desktop and - within it - the MCPI game/client, just like the current Minecraft.

[bulleribokk]

@mitu said in MCPI and MCPI-reborn:

install the desktop from Retropie-Setup (see the docs) then you can start the desktop from the Ports system and then subsequently start mcpi. No script involved, just clicks.

Success on that, got desktop to click on in "ports" and after loading up desktop I could open terminal and run the MCPI-reborn AppImage :) Good to know that works, but I kinda want to make it run like the old minecraft-pi like to avoid entire desktop

OR

create your own scriptmodule similar to the minecraft.sh (this one, which should live in $HOME/RetroPie-Setup/scriptmodules/ports in your system) file. You can copy the file and rename it to mcpi.sh and then replace any occurences of minecraft with mcpi. Make sure the path to the executable is correct, then use RetroPie-Setup to install the new port. The newly added port entry would automatically start a minimal desktop and - within it - the MCPI game/client, just like the current Minecraft.

I tried to follow that advice, copied the minecraft.sh to mcpi.sh and the next part is a bit confusing.. anyway, here's what I put in the file:

#!/usr/bin/env bash
rp_module_id="mcpi"
rp_module_desc="mcpi-reborn"
rp_module_licence="PROP"
rp_module_section="exp"
rp_module_flags="!all videocore"

function depends_minecraft() {
    getDepends xorg matchbox-window-manager
}

function install_bin_minecraft() {
    [[ -f "$md_inst/mcpi" ]] && rm -rf "$md_inst/"*
    aptInstall mcpi
}

function remove_minecraft() {
    aptRemove mcpi
}

function configure_minecraft() {
    addPort "$md_id" "mcpi" "mcpi" "XINIT-WM:/home/pi/mcpi.AppImage"
}

so it is basically same but changed to mcpi.. and the path there is correct since I have the file mcpi.AppImage in /home/pi/

Impressively, this does show up as "mcpi" at the same place as "minecraft-pi" when I run the Retropie-Setup, however it wont let me install anything.. also I started suspecting that it can't work anyway since function install_bin_minecraft() says aptInstall.. and mcpi-reborn isn't possible to install with apt :\ I have the appimage file and it runs fine in desktop, so how can I make it run like old minecraft-pi?

[mitu]

@bulleribokk said in MCPI and MCPI-reborn:

also I started suspecting that it can't work anyway since function install_bin_minecraft() says aptInstall.. and mcpi-reborn isn't possible to install with apt

Replace mcpi-reborn with a small, but unrelated package that the install_bin procedure can install through apt and would not throw an error.

[bulleribokk]

@mitu well I suppose the old minecraft-pi fits that description, so I tried to change my script to

#!/usr/bin/env bash
rp_module_id="mcpi"
rp_module_desc="mcpi-reborn"
rp_module_licence="PROP"
rp_module_section="exp"
rp_module_flags="!all videocore"

function depends_mcpi() {
    getDepends xorg matchbox-window-manager
}

function install_bin_mcpi() {
    [[ -f "$md_inst/minecraft-pi" ]] && rm -rf "$md_inst/"*
    aptInstall minecraft-pi
}

function remove_mcpi() {
    aptRemove minecraft-pi


function configure_mcpi() {
    addPort "$md_id" "mcpi" "mcpi" "XINIT-WM:/home/pi/mcpi.AppImage"
}

So this time when I ran it, it seemed to execute the function install_bin_mcpi() at least, made me guess that this is actually executed by the retropie setup script which just parse this file and get code to run from prefix instal_bin_* is this right?

Seems it did not run the function configure_mcpi() so I did not get an mcpi item to click on in ports :\

[mitu]

@bulleribokk said in MCPI and MCPI-reborn:

Seems it did not run the function configure_mcpi() so I did not get an mcpi item to click on in ports :\

Then run it manually

cd $HOME/RetroPie-Setup
sudo ./retropie_packages.sh mcpi configure

[bulleribokk]

@mitu I found that I was missing a bracket } and that's why my script didn't work, and you were absolutely correct that it had to be added with the line sudo ./retropie_packages.sh mcpi configure, no reason to actually install anything, just the configure line :) I guess if the functions above are needed then no problem.

Anyway.. The result was amazing! It has been some time since I tried to run mcpi-reborn on rpi3 with full desktop, it was just too jerky to enjoy, but this way was quite smooth actually :) Loaded up a new world now, could see little baby pigs running around there with smooth movements, and not very noticeable lag when moving the mouse around to look or when walking :) Thank you so much for the help! :D

This was clumsy and slow for me to make work, but with your help mitu, it is definitely solved! Now others can also enjoy mcpi-reborn on retropie even on the slow rpi3 unit!

There's AppImage for whatever target architecture you need for your retropie on the github page for mcpi-reborn, so just grab the right one and save in homedir or where you want.
Here's the (repaired) script if others need it, put it in $HOME/RetroPie-Setup/scriptmodules/ports in your system and just make sure you've got the game AppImage file location and path correct at the bottom of the script before running:

#!/usr/bin/env bash
rp_module_id="mcpi"
rp_module_desc="mcpi-reborn"
rp_module_licence="PROP"
rp_module_section="exp"
rp_module_flags="!all videocore"
 
function depends_mcpi() {
    getDepends xorg matchbox-window-manager
}
 
function install_bin_mcpi() {
    [[ -f "$md_inst/minecraft-pi" ]] && rm -rf "$md_inst/"*
    aptInstall minecraft-pi
}
 
function remove_mcpi() {
    aptRemove minecraft-pi
}
 
function configure_mcpi() {
    addPort "$md_id" "mcpi" "mcpi" "XINIT-WMC:/home/pi/mcpi.AppImage"
}

Then run the configure function manually like so:

cd $HOME/RetroPie-Setup
sudo ./retropie_packages.sh mcpi configure

This I did over SSH ofc, so after having run this script, on the retropie you need to restart emulationstation, and "mcpi" will be added in ports :)

The game has a few GTK zenity dialogue boxes that pop up first and gave me no mouse pointer so I had to use tab for moving about and get past those, it was annoying, but fine. I bet it is possible after first run, to do a change in the configure script to add --default, which will skip those dialogue boxes

[bulleribokk]

@mitu I figured perhaps there's some way to add mouse already prior to actual game load, and in the runcommand.sh line 957 there is something that looks like you can use as param for this purpose, is that right? How do I add the cursor the proper way, would you have some advice on that?

[mitu]

Not a parameter, but you can replace the launch prefix from XINIT-WM with XINIT-WMC to not clear the mouse cursor, though I'd have expected that any game that runs fullscreen would use their own mouse handling and not rely on thw window manager/compositor to show the mouse.

[bulleribokk]

I'll try that. So running sudo ./retropie_packages.sh mcpi configure multiple times, is normal/not harmful? Like I just add the one letter that's missing and run again? No need to remove or uninstall etc?

@mitu said in MCPI and MCPI-reborn:

I'd have expected that any game that runs fullscreen would use their own mouse handling

Well the original minecraft-pi does ofc, once it is running you got the game cursor, but prior to that there's GTK zenity dialog boxes for enabling/disabling features, some settings, like setting your player name etc. I'll see if I can get cursor on that :)

[mitu]

@bulleribokk said in MCPI and MCPI-reborn:

I'll try that. So running sudo ./retropie_packages.sh mcpi configure multiple times, is normal/not harmful? Like I just add the one letter that's missing and run again? No need to remove or uninstall etc?

Yes.

[bulleribokk]

Your advice was great! With the XINIT-WMC there is mouse already prior to game load so it is easier to navigate through the GTK dialogue boxes, and there is no double mouse, i.e. when the game is up and running there's only the game mouse cursor visible :)

[fede843]

Hi here. I have a rpi4, the original minecraft is not available.
When trying this, I get

Module 'mcpi' is not available for your system (rpi4)

Is it there a workaround here?

[fede843]

all right, it was a silly one:

#!/usr/bin/env bash
rp_module_id="mcpi"
rp_module_desc="mcpi-reborn"
rp_module_licence="PROP"
rp_module_section="exp"
#rp_module_flags="!all videocore"

function depends_mcpi() {
    getDepends xorg matchbox-window-manager
}

function install_bin_mcpi() {
    [[ -f "$md_inst/minecraft-pi" ]] && rm -rf "$md_inst/"*
    aptInstall minecraft-pi
}

function remove_mcpi() {
    aptRemove minecraft-pi
}

function configure_mcpi() {
    addPort "$md_id" "mcpi" "mcpi" "XINIT-WMC:/home/pi/RetroPie/roms/ports/.data/minecraft-pi-reborn-client-2.5.3-arm64.AppImage --default"
}

Just needed to get rid of the filter flag.
And by the way, all those intro setup windows can be skipped using the --default flag.

Thank you!