It's completely obvious why the Marathon community is in its current state.

1. AlephOne is a failing project- It has a grand total of one-and-a-half developers (even that may be a charitable estimate now), and far too much attention is placed on bolt-plating new bells and whistles on an inadequately bugtested base engine. 3D models, OpenGL/Vulkan/Metal/Metal 2/Direct3D whatsits, bloom, bumpmapping, etc. etc. all needs to take a backseat to bugtesting and QA. You've got a software renderer you don't want to maintain for no good reason that I can see, and two separate OpenGL renderers for no adequately explained reason. To top it off, no one thought to code in warning messages or safeguards for when the user does something monumentally stupid with the engine settings (crashing is not a safety net, it's a sign of sloppy usability practices). You need to emphatically notify the user "Hey guy these settings are not possible to use in software rendering." or "This feature is not available in the classic GL renderer!".

2. No easy way to create new content- Weland and VisualMode are nowhere near as easy to use as Forge/Anvil, and as best I know Vasara never took off. Having an easy way to just fire up an editor and crank out maps (without have to juggle programs or download an entire runtime library, WELAND.....) is essential to long-term survival of any community. AlephOne has failed utterly on that front. A plugin is not the appropriate place for content creation. This is one place where everything *but* the actual coding has already been done for you! Someone get real cozy with a copy of the fabled Marathon editing tools and treat them like the Grail Diary. You should be copying every button, tooltip, toolbar, and feature, until you have a solid facsimile on which to start making general improvements. Treat them like your design document.

3. A community that's borderline self-destructive- I've seen you guys attempt to discuss stuff constructively among one another. Frankly, you suck at it. The sense I get is that some of you almost *want* the remaining bits of the community and project to go under. Frankly, this strikes me as irrational. You're not trapped, here on the Phorums or anywhere else for that matter. This is the internet, and when people don't like a place they're visiting, they leave. It's unfortunate, but inevitable. There's no reason to keep "going through the motions" in the Marathon community if you actually can't stand it anymore. Find a new hobby, or enjoy Marathon off by your lonesome, there's no sort of shame in that. But being passive-aggressive dicks to one another will get you nowhere. You can't afford to keep doing it.

That's the Big Three, well as I can ascertain. Of course, some of you may no doubt wonder, "Where do YOU fit in? Anyone can piss and moan, after all. What are you going to do about all this, the whining complainer that showed up in our midst?". Well, that depends on the answers I get to a few things....

A. I cannot code, unfortunately.

B. I am willing to do anything short of coding, however.

C. No seriously: documentation, testing, bug reporting, I can be very thorough and exacting if you want me to be.

D. I'm even willing to compile, if people would only walk me through it.

E. I do have one condition for helping though, and that's that the software renderer is maintained again.

F. Also, over 30 open issues on Github with only a fraction even addressed (nevermind closed) looks pretty shitty. You're going to need to actually *respond* to my input, not drop a one-word sentence three months from now.

G. My operating system is OS X Mountain Lion. I quite like it, so for Windows or the flaky newer releases of macOS you'll need another guy. I shouldn't think access to Windows testing platforms would be an issue though, right?

If you're interested, fine. If not, I can Wander somewhere else (it's the internet, remember?). I would hope any developers who may be listening (or see this message) would be wise enough to take me up on the offer I presented. I have plenty of free time, and I'm eager to finish my Marathon journey (your releases have been so buggy I've been too frustrated to attempt Infinity). All that's needed is someone to take the first step.

Wrkncacnter wrote:Also, it seems unlikely to me that any active alephone developers (if they exist at all) will respond to your message, as I don't think any of them have posted anything to the Pfhorums in over a year.

Last commit was in February of this year.

I wonder if that means the project is truly dead? I thought that public beta test hopper did got a decent amount of replies...

EDIT: Both devs' profiles show they visited some time this month. That means if they're feeling cooperative they may see this message.

The_Wanderer wrote:I thought that public beta test hopper did got a decent amount of replies...

You mean the beta test from almost 2 years ago that never resulted in an actual release?

Has it been 2 years already.....?

Yes, I can see you're right. Never knew it hadn't resulted in a release.

Wrkncacnter wrote:By the way, if you think the current state of AlephOne is buggy, you should check out what's in the latest master in git!

Elaborate. I tried the last beta, which was even more unstable than the older releases (which were already riddled with bugs). I recalled seeing a recent topic on a failed build with vanilla master. I assumed it was user error and never investigated. Do you mean to tell me the codebase as-is really no longer compiles?

Some crazy issues I remember off the top of my head:* The mouse scroll wheel scrolls the wrong direction in the UI* Only about 5% of each sprite renders unless you're using OpenGL shader or using high def monster/item plugins. (I didn't try software)* Secondary fire doesn't work the first time you use it.

Wrkncacnter wrote:* The mouse scroll wheel scrolls the wrong direction in the UI

That sounds like something went wrong with one or more of their changes to mouse handling.

* Only about 5% of each sprite renders unless you're using OpenGL shader or using high def monster/item plugins. (I didn't try software)

They're attempting to deprecate everything but the Shader renderer. While even I think the Classic GL renderer should go, they don't need to be killing off the software renderer like that. Their given justification didn't even make sense.

* Secondary fire doesn't work the first time you use it.

This why when you are a developer it is important to finish what you start. It sounds like the mousing overhaul almost caused more problems than it solved, all because everyone wants to add but never bugfix or test.

I'm still waiting for that tour of duty. I can't wait to see which one they end up doing!

The_Wanderer wrote:They're attempting to deprecate everything but the Shader renderer. While even I think the Classic GL renderer should go, they don't need to be killing off the software renderer like that. Their given justification didn't even make sense.

Can you please link to the discussion on this topic? My memory is failing me.

The_Wanderer wrote:They're attempting to deprecate everything but the Shader renderer. While even I think the Classic GL renderer should go, they don't need to be killing off the software renderer like that. Their given justification didn't even make sense.

Can you please link to the discussion on this topic? My memory is failing me.

Apologies for the late reply, the board software does not make it at all obvious that the current poster has edited his/her post unless one is physically in the forum subsection itself. Now, keep in mind, that says it removed the 8-bit renderer but *also* talks of a "TrueColor Renderer", the differences of which I'm unaware of. As for the deprecation of the OpenGL Classic renderer, I confess I'm unable to find where I read it was being phased out, which really really bugs me because I swear I saw it.

So...Maybe I'm just full of shit... But I'd like to help if we can get a dev back. Marathon deserves to live.

General Tacticus wrote:8-bit and "true color" were just two different modes for the software renderer to operate in. Some old macs couldn't process 16 or 32 bit color, so 8-bit was an option for those older machines.

...Oh. So, hopefully the software renderer is safe after all? It would've been nice for treellama to weigh in on this, since he is a dev (I'm not too sure we'll ever see much of hopper again, if what I'm inferring from his Github commits is in any way true).

It would actually be pretty nice if all this was just a misunderstanding.

Admittedly, my exposure to the engine is limited to the classic renderer on mobile, but I've found the latest code from February to be surprisingly stable. I've majorly abused the codebase, and have only encountered a few crashes in A1 (all of which were easy to fix).

Personally, I think the number of build environments required to test patches on the desktop is an obstacle. If someone were to volunteer to put together a few Parallels or VMware images with A1 in a build-ready state, that would be super useful.

TrajansRow wrote:Personally, I think the number of build environments required to test patches on the desktop is an obstacle. If someone were to volunteer to put together a few Parallels or VMware images with A1 in a build-ready state, that would be super useful.

A single Linux VM would cover Linux and Windows. I don't think it's legal to release a VM image with the mac OS build tools though. So I don't know how you'd handle that.

Even a Linux image to build those two OSs would still be great. Another question that arises is whether accelerated graphics can be tested in a VM. I believe Parallels has support for this, but it depends on the operating system.

TrajansRow wrote:Admittedly, my exposure to the engine is limited to the classic renderer on mobile, but I've found the latest code from February to be surprisingly stable. I've majorly abused the codebase, and have only encountered a few crashes in A1 (all of which were easy to fix).

Personally, I think the number of build environments required to test patches on the desktop is an obstacle. If someone were to volunteer to put together a few Parallels or VMware images with A1 in a build-ready state, that would be super useful.

Latest all-in-one releases on OS X still crash routinely for me, on top of the copious rendering issues. It doesn't have to be fatal to ruin the experience, just persistent, ubiquitous, and irritating.

The_Wanderer wrote:Elaborate. I tried the last beta, which was even more unstable than the older releases (which were already riddled with bugs). I recalled seeing a recent topic on a failed build with vanilla master. I assumed it was user error and never investigated. Do you mean to tell me the codebase as-is really no longer compiles?

That was me. Part of it was user error, I wrongly assumed I had to have all the config options enabled for it to run which is not the case. Treelama was able to point out this to me within several days.

The other part is that I'm running Linux, so some of the libraries needed to compile with those optional features are also required by my OS. Since Debian oldstable is using *much* newer versions of some of those libraries than the code is written for, the fullest possible Aleph One didn't compile until I went in and edited the code so it would compile against the newer libraries. I should probably submit what I changed, if I can figure out how that works...

I had another hitch, where A1 refuses to start unless you have a theme plugin installed. It took me a while to figure that one out since the error message was misleading me into thinking I had bad game files.

Now I've got it all set up properly I'm having a blast. I even configured KDE so that I can start a scenario by dragging it's folder onto an alephone symlink. Apart from the occasional trippy texture, it hasn't crashed or bugged out on me at all. Now that I have Weland running, too, I'm enjoying creating maps that can take advantage of A1's new features.

ShapesFusion, on the other hand, stubbornly refuses to compile, so I have to do all my shapes/sounds/physics editing with Hackvil, Pfhred, & Wail via Basillisk II.