Mirata - A WIP launcher for AlephOne & etc

Discuss and unveil current Marathon projects.

Mirata - A WIP launcher for AlephOne & etc

Post May 17th '18, 02:43

Current Hot Mess of Code ------→ Github.
==========================================
Places for discussion:
Here (obviously)
#chocothon on freenode
#mirata on the Marathon Speedrunning Discord
The github
==========================================
Hello Hello, tbcr here with another Fine Quality project.

So today I somewhat announce a project that I have been working on/off for the past 2 weeks. Even though it’s code is NOT done at all; Asking around, I was told that it would not hurt to put what I had online.

This particular project has a 3 step path for it.

1. A guided installation application (mainly for linux and UNIX systems atm, but could obviously be extended to windows/mac, at least for part 2) that guides through the installation of Aleph One. This can involve either compilation of source code or downloading the current stable through various package repositories on the internet. This particular part was inspired by the last time I had to setup Aleph One on a linux machine (particularly Fedora 28, which had some particular flags during the "make" step of compilation). This is not an unattended installation, because the user has to be at the computer to select some options. This install process will also grab the tar.gz's of the trilogy from the lhowon.org page and extract as well.


2. Later on down the road, I would like to get this so not only does it install the source port , but it also functions as a launcher for opening up scenarios. The main problem I have with Aleph One on linux is that you either have to go into terminal or make alot of either .sh or .desktop files to open individual scenarios. With this,there would be a folder created by the program for scenarios, drag and drop them into that folder and then select from the list. ||ADDENDUM: After discussing with Wrk on this, having an option to download third party scenarios should also be a idea to shoot for. Evil, RED and Eternal have versions on various package repos. (Eternal on openSUSE games for instance)

3. There is a particular chocolate-Marathon type source port that I am (somewhat) working on atm that I would also like to get working with this as well, but that is later on down the road (since that has not really been enough work to even post a thread on here about it)
==================================================================
Why are you programming in ANSI C and not C11. Why not even bash?

Three reasons
1. I know more C than bash scripting atm, and I can just use system calls for the time being.
2. I was taught in ANSI C and I have not gotten around to learning the bridging material from ANSI to C11.
3. Just so it can be a cross platform application later on down the road.
==================================================================
Why is the code a hot mess

Various reasons but here are a main few:
1. I recently started working at Red Hat, and my time has been a bit limited in terms of when I could work on it. Since I have gotten my RHCSA I have a bit of free time to work on this before my RHCE stuff begins.
2. My ADHD raddled mind jumped all over the place to focus on particular areas.
3. Some particular distributions I have never used or have not installed A1 on, at least package wise. So I was mainly doing research on which particular packages (and their repective namings in the repos)were needed. openSUSE, Gentoo, Sabayon, Ubuntu and Fedora I have had some experience in installing on. 3 of the 5 have options for easy installs for stable.

Like the code, This post is probably a hot mess too, but I am willing to answer questions related to the project.
Last edited by TBCR on May 17th '18, 03:05, edited 1 time in total.
Marathon Speedrun Times: Discord
M1A1 - 26:57 - PB
M2 - 33:52 - PB
M2 - XBLA - 38:59 - PB
M2 - Coop with ApertureGrillz - 27:17 IGT/29:09 RTA - WR
MInf - 15:42 - WR
Minf all main levels - 27:49 - PB
Image
User avatar

TBCR
Raleigh,NC

Post May 17th '18, 03:03

I don't know man, are you going to be able to keep up with the fast paced alephone development and release cycle? You'll have to keep it updated every time there's a new release!
User avatar

Wrkncacnter

Post May 17th '18, 09:50

Sounds ambitious, but I applaud your effort!

TBCR wrote:The main problem I have with Aleph One on linux is that you either have to go into terminal or make alot of either .sh or .desktop files to open individual scenarios. With this,there would be a folder created by the program for scenarios, drag and drop them into that folder and then select from the list.


Really? I just made one single desktop configuration file in a convenient location (~/Aleph One/, which also has all my scenario folders), gave it a pretty icon, and set it to handle the inode/directory mimetype. Then I just drag-n-drop the scenario folder onto it to play. No scripts or multiple files. This is in KDE4, YMMV with other DEs.
User avatar

ravenshining
Hawai'i

Post May 17th '18, 12:26

You could just make a snap out of it with a .desktop launcher...no need to write C code. But if you want to write C code, knock yourself out. Just be prepared to answer stupid questions if you release it!
User avatar

treellama
Pittsburgh

Post May 17th '18, 14:32

Preface: I'm still half awake when writing this post so I might be overthinking these.

ravenshining wrote:Really? I just made one single desktop configuration file in a convenient location (~/Aleph One/, which also has all my scenario folders), gave it a pretty icon, and set it to handle the inode/directory mimetype. Then I just drag-n-drop the scenario folder onto it to play. No scripts or multiple files. This is in KDE4, YMMV with other DEs.


That would still involve dragging and dropping. You could even do that with DOOM wads.

Taking a look at your response kinda gave me a stronger push toward offering support for downloading third party scenarios in the launcher. With going down that particular pathway, you wouldn't have to do something like that, since they would already be in the folder from downloading. Then all you would have to do is select and press enter/click play.

I'm also trying to view how to tackle this from the perspective of new linux users. The main reason I considered starting this project was because of pains setting A1 up for speedrunning purposes. Linux currently is the best OS to run the games in due to it being easier to compile the developement versions in (and those versions you can actually beat the game in one sitting without having it softlock on you). I feel like the process for getting the games running should be as painless as possible. Mac has the luxury of having the trilogy in standalone apps. Windows for the most part has a "drop the A1 in the folder and run it" process.

treellama wrote:You could just make a snap out of it with a .desktop launcher...no need to write C code. But if you want to write C code, knock yourself out. Just be prepared to answer stupid questions if you release it!


I'll have to take a look at the options that are involved with going down that path. If anything, I still want to make the launcher part. I could probably make a home file server containing snaps of both the launcher and A1.

Wrkncacnter wrote:I don't know man, are you going to be able to keep up with the fast paced alephone development and release cycle? You'll have to keep it updated every time there's a new release!


Update checking for newer versions of A1 and the Chocothon project would actually be a fantastic idea. I have a feeling a script or program to go through the task of compiling the newest stable/dev and making a snap might be a thing that would need to be made.
Marathon Speedrun Times: Discord
M1A1 - 26:57 - PB
M2 - 33:52 - PB
M2 - XBLA - 38:59 - PB
M2 - Coop with ApertureGrillz - 27:17 IGT/29:09 RTA - WR
MInf - 15:42 - WR
Minf all main levels - 27:49 - PB
Image
User avatar

TBCR
Raleigh,NC

Post May 17th '18, 17:00

TBCR wrote:I'm also trying to view how to tackle this from the perspective of new linux users.

You're welcome to do whatever you like and publish whatever you like, but downloading and compiling some C executable masquerading as a shell script is not something I'd ever advise a new Linux user to do.

If you truly want to make a difference, become a package manager for a newbie-friendly distro and make sure they can install it with yum or apt. That's not as glamorous as writing C code though, so, examine your true motivations.
User avatar

treellama
Pittsburgh

Post May 17th '18, 19:11

ravenshining wrote:Then I just drag-n-drop the scenario folder onto it to play.

That sounds awful. Who wants to navigate to scenario folders using a graphical explorer and drag and drop them?
User avatar

Wrkncacnter

Post May 17th '18, 20:28

treellama wrote:
TBCR wrote:I'm also trying to view how to tackle this from the perspective of new linux users.

You're welcome to do whatever you like and publish whatever you like, but downloading and compiling some C executable masquerading as a shell script is not something I'd ever advise a new Linux user to do.

If you truly want to make a difference, become a package manager for a newbie-friendly distro and make sure they can install it with yum or apt. That's not as glamorous as writing C code though, so, examine your true motivations.


I am somewhat conflicted on how to respond this constructive criticism, but I am going to make an attempt.

It should be obvious that the main motivation for this is to have an application for linux that makes even getting marathon to work on linux easy across the board. I used that particular sentence of a new linux user because that is how painless I would want the application setup to be.

After thinking about it during my lunch break, I came to some conclusions:

1. I, for the most part, understand that having a C source (which I would never have a new person compile. that would be like asking someone to try out a beartrap with their foot) with a metric fuckton of system calls might make someone weary. I am planning when I get back home tonight to look at the "drawing board" in terms of how to implement things better to cut down on the amount of system calls immensely. (If you have any particular suggestions that have worked for you in the past, feel free to mention, I will gladly take suggestions on how I should handle this)

1a. Wrk worded it best in a conversation on the main dev chat for this. "You're basically creating steam for Marathon stuff"

2. This particular one is a corollary to the previous note and involves what you mentioned about snap packages. Snap packages ( at least for the stable versions of A1) might make this considerably less painful to implement. I agree that making it cross distros though should be a main target. There were two particular situations though that would arise (at least in my opinion): Automatic creation of snap images for developmental versions of A1 and downloading of archives and whatnot on the internet. The second situation I could remedy by having a file server (which would technically make me a package manager) that could host snap images and archives of scenarios (with permission, of course).

3. I am pretty much sure that I will have to work on the launcher stuff alongside the "behind the scenes" stuff. Luckily I can use Glade/GTK for the GUI and whatnot.
Marathon Speedrun Times: Discord
M1A1 - 26:57 - PB
M2 - 33:52 - PB
M2 - XBLA - 38:59 - PB
M2 - Coop with ApertureGrillz - 27:17 IGT/29:09 RTA - WR
MInf - 15:42 - WR
Minf all main levels - 27:49 - PB
Image
User avatar

TBCR
Raleigh,NC

Post May 17th '18, 20:37

I don't think combining easy install and developmental versions of Aleph One makes sense. I'd really rather that not be a thing.
User avatar

treellama
Pittsburgh

Post May 17th '18, 20:45

treellama wrote:I don't think combining easy install and developmental versions of Aleph One makes sense. I'd really rather that not be a thing.


I might have worded that a bit odd. I would say to consider it like snapshots like in Minecraft. The ones that compile correctly for snap imaging are available for you to use, but it is still up to you whether to use them or not.

The developmental version idea was mainly because the heartbeat problem that is in 1.2 (and M2 and Infinity on mac) is fixed in the developmental builds but not the 1.3 preview and there are also some really neat-o ideas in the most recent commits.

If it ultimately comes down to it, I can drop it. But I do want to see if it is pratically feasible.
Marathon Speedrun Times: Discord
M1A1 - 26:57 - PB
M2 - 33:52 - PB
M2 - XBLA - 38:59 - PB
M2 - Coop with ApertureGrillz - 27:17 IGT/29:09 RTA - WR
MInf - 15:42 - WR
Minf all main levels - 27:49 - PB
Image
User avatar

TBCR
Raleigh,NC

Post May 17th '18, 21:19

While you're at it, you should figure out cross buliding for windows and mac as well so we can finally reinstate nightly builds.
User avatar

Wrkncacnter

Post May 17th '18, 22:24

Wrkncacnter wrote:
ravenshining wrote:Then I just drag-n-drop the scenario folder onto it to play.

That sounds awful. Who wants to navigate to scenario folders using a graphical explorer and drag and drop them?


Or I could just type alpehone ./Aleph\ One/scenario/ into a terminal without setting up the DCF. But, I grew up on Mac OS 7 - remember the Launcher? Drag-n-drop is my go-to easiest method of doing things.

TBCR wrote:That would still involve dragging and dropping. You could even do that with DOOM wads.

Taking a look at your response kinda gave me a stronger push toward offering support for downloading third party scenarios in the launcher. With going down that particular pathway, you wouldn't have to do something like that, since they would already be in the folder from downloading. Then all you would have to do is select and press enter/click play.


See, to me that sounds way more complicated than drag-n-drop, seeing as that's how I open most files when I'm using a Mac anyway - see the Launcher in OS 7-9 or the Dock in 10. On Linux I usually have to get fiddly right-click and "Open With" and the program (stupid GIMP won't work with DCFs), so to me a DCF makes A1 more convenient than most things on my computer.

What could be nice if your little installation thingy automatically added in a theme plugin (A1 will not run and give you a completely misleading error message if you don't have one in the scenario plugins folder) and set up your preferences file against some global default.
User avatar

ravenshining
Hawai'i

Post May 17th '18, 23:03

The obvious problem here is that everyone likes doing things differently. Apparently people coming from a mac background like drag and drop, while linux users would find that abhorrent. People on windows are used to copying binaries everywhere and they probably think that's just fine.

If this thing doesn't work just the way the person wants it to, they probably won't use it at all. So, you should probably figure out who you're targeting exactly.

If there's just a few speed runners that want to get the game going and don't care about linux (you said it's for new linux users, so they likely don't have any preference about distro), then maybe you should just target one distro, make one easy to use package for that distro, and tell speedrunners to use that. Just a bash script to apt get the package, wget the scenario files, and create the various .destkop files or set up aliases or whatever.

Then tell the speedrunner to install some distro, and run your script. Meh.
User avatar

Wrkncacnter

Post May 18th '18, 19:04

So thinking thing over some more, I think atm I should at least focus on getting the package stuff worked out first, since that would be the most important thing to deal with. I can luckily use the libcurl API for that. The installation and launching stuff I can push off to the side until the package management is done. I am though slowly working on how the layout of the application should be also.

In response to your post Wrk, I do agree with you on your first two paragraphs. I can't really blame people if they are used to doing something in a particular way.
Marathon Speedrun Times: Discord
M1A1 - 26:57 - PB
M2 - 33:52 - PB
M2 - XBLA - 38:59 - PB
M2 - Coop with ApertureGrillz - 27:17 IGT/29:09 RTA - WR
MInf - 15:42 - WR
Minf all main levels - 27:49 - PB
Image
User avatar

TBCR
Raleigh,NC

Post May 18th '18, 21:59

FWIW, since Marathon started out life as a Mac game, the drag-and-drop approach will probably be more popular among its user base than it would among gamers more generally. But apart from that, I have little helpful to add; I haven't played around with Linux distros and compilers enough to have anything relevant to add on that front. (I did use Kali Linux fairly extensively for a mobile security class last year - spoiler alert: "mobile security" is more or less one of those oxymorons like "jumbo shrimp" or "business ethics" - but I don't think I've used it since and have probably already forgotten at least half the commands I learned. I'm sure a lot would come back to me if I looked at my class notes, but I doubt I'll be in the correct frame of mind for that for the next month or so.)
People should not be afraid of their governments. Governments should be afraid of their people.

Fool's Gold · Last.fm · Marathon Chronicles · YouTube Vidmaster’s Challenge
User avatar

The Man
Sarasota, FL

Post May 23rd '18, 12:51

The Man wrote:FWIW, since Marathon started out life as a Mac game, the drag-and-drop approach will probably be more popular among its user base than it would among gamers more generally. But apart from that, I have little helpful to add; I haven't played around with Linux distros and compilers enough to have anything relevant to add on that front. (I did use Kali Linux fairly extensively for a mobile security class last year - spoiler alert: "mobile security" is more or less one of those oxymorons like "jumbo shrimp" or "business ethics" - but I don't think I've used it since and have probably already forgotten at least half the commands I learned. I'm sure a lot would come back to me if I looked at my class notes, but I doubt I'll be in the correct frame of mind for that for the next month or so.)


As mentioned before, that is completely understandable.

While I'm in the middle of working on the GUI for the application(which I decided would probably be a good idea to work on at the same time as the code), I did decide to build an amd64 snap of the stable AlephOne. I had to do a bit on convolution in terms of actually getting it to build in snapcraft, because my base Fedora install refuses to compile the program. This means I had to make a lubuntu VM to even get it going. The snap itself has no ogg playback nor webm export. When I get home later, i'll set up another build that will have the music playback. In addition I will try to setup a i686 build of A1 as well for anyone wanting to run A1 on a 32 bit system. Make sure you install the snap using the --devmode flag.

The download for that is here

For anyone interested as well for the YAML file for the snap, it is located here

ADDENDUM: Pushed a new commit to reflect current standings on things.
Marathon Speedrun Times: Discord
M1A1 - 26:57 - PB
M2 - 33:52 - PB
M2 - XBLA - 38:59 - PB
M2 - Coop with ApertureGrillz - 27:17 IGT/29:09 RTA - WR
MInf - 15:42 - WR
Minf all main levels - 27:49 - PB
Image
User avatar

TBCR
Raleigh,NC

Post Jun 4th '18, 04:26

Leaving an update on here in regards to recent developments.
N E W C O M M I T

So after a good week or so having my brain turned to mush from RHCE material, and looking up various ways i could implement what I would want this project to do, I decided to scrap what I had in C code in exchange for implementing it in Python.

The main plus side to this, (at least to me) is that I was able to minimize the amount of system calls needed by the application. Other than clearing the screen, the only direct system call was for installing the snap package. Switching to Python also made implementation of downloading everything a bit more easier to follow along. What was about 8 lines in libcurl was 3-4 lines in Python. This also meant that I was actually able to get my damn installer proof of concept made literally in a single day.

The main important thing is that I can use tepache on GLADE later on once the GUI is complete in order to get a baseline for the full launcher+installer program. This part alone was the main reason for switching, with file downloading being a close second.

I am going to attempt to improve on this in the coming days in addition to working on the GUI, but I have my RHCE exams next week, so that gets top priority. Suggestions on how to improve the installer part is always welcome.

EDIT: I did not notice this until this morning, but I do need to go back and fix the snapd detection (to be fair, this was the part I was worried was going to go wrong somehow.
Marathon Speedrun Times: Discord
M1A1 - 26:57 - PB
M2 - 33:52 - PB
M2 - XBLA - 38:59 - PB
M2 - Coop with ApertureGrillz - 27:17 IGT/29:09 RTA - WR
MInf - 15:42 - WR
Minf all main levels - 27:49 - PB
Image
User avatar

TBCR
Raleigh,NC


Return to Projects



Who is online

Users browsing this forum: No registered users