Need Help Converting M1 Scenario

Discuss and unveil current Marathon projects.

Need Help Converting M1 Scenario

Post Feb 23rd '19, 13:23

Hello all, it's been a long time since I've played with anything Marathon related but recently downloaded the latest versions of AO and the Marathon Trilogy and imagine my surprise when I read that AO now supports native M1 files!

This was great news to me since I did a lot of map making for the original game and have always wanted to convert my last, and largest, M1 scenario to AO: Phoenix Falling.

It didn't take long to get the scenario working about 90% with using tweaked copies of the "Marathon.mml" file and "Enhanced HUD" plugin that comes with the M1 AO download (many props to those that created those!). But have a few bugs that I can't seem to figure out, and although I've been enjoying replaying this blast-from-the-past, I'd like to get it working 100% and release it to the community.

Here are some of the things that aren't working properly:

-Control Panels and Terminals don't work in vacuum levels. They just give the 'inactive' sound regardless of the polygon's light.

-Phoenix Falling added shapes sequences for monsters, but in AO they don't animate correctly. For example, one of the new aliens shares the "Hulk" collection but with new sequences. In AO, this alien's walking animation just uses one frame and for some of the views, uses the incorrect sequence altogether. Any shape that directly replaced an original M1 shape works, but added shapes don't.

-Some platform behavior doesn't seem to work correctly. For example, in a few places throughout the scenario hidden crushers are designed to kill juggernaughts to give the explosion effect. In one place I can hear the jugger's death klaxon but it never explodes and the platform never triggers its adjacent platforms.

-A few terminals don't work properly. One in particular just crashes the game, another immediately exits without displaying anything. I've checked the 'term' resource in the "Phoenix Falling Installer" (which is what I reference for the "External Resources" in the preferences) using ResEdit (how terminals are stored in M1) and they all look good.

There might be some other minor things, but these are the big ones that directly effect how the game plays.
Looking forward to getting this working and released!
Thanks for any help.
mattschenk

Post Feb 23rd '19, 21:06

mattschenk wrote:-Control Panels and Terminals don't work in vacuum levels. They just give the 'inactive' sound regardless of the polygon's light.


I think I've figured this one out by finding a save terminal that happened to work on a vacuum level and then comparing its polygon lighting to others. Apparently M1 and M:i use different minimum light values to denote whether a switch or terminal is "active" in vacuum. In M1, it just had to be above 50%. With some quick testing, it appears they work when set to 80% or higher, but not at 60% where most were.

One problem solved!
mattschenk

Post Feb 23rd '19, 21:30

Can you point us to the scenario files you're having trouble with? Otherwise it's hard to say what's going on.

Regarding platforms, I noticed that myself while testing M1R the other day, a wasp got killed on top of the the door on Smells Like Napalm and jammed it open while going through its soft death animation without then proceeding to its hard death animation. If I figure out my wasp problem, I'll let you know.
User avatar

ravenshining
Hawai'i

Post Feb 23rd '19, 22:09

mattschenk wrote:I think I've figured this one out by finding a save terminal that happened to work on a vacuum level and then comparing its polygon lighting to others. Apparently M1 and M:i use different minimum light values to denote whether a switch or terminal is "active" in vacuum. In M1, it just had to be above 50%. With some quick testing, it appears they work when set to 80% or higher, but not at 60% where most were.

Cool. Is there a save terminal in the original scenario that works differently from Marathon vs Aleph One?

Original Marathon third-party scenario compatibility is fair game for future releases of Aleph One. Would be cool to see, for instance, Trojan working.

Can you file this (and other findings) as bugs on our GitHub?
User avatar

treellama
Pittsburgh

Post Feb 24th '19, 01:50

I know very little about M1 development, but I'll chime in that it'd be much easier to debug the problems with the files at our disposal. I'll guess the shapes problem in particular is a result of a shapes editor that didn't write files the way A1 expects, but I don't know much about how M1 shapes editing worked.

I would very much like to see M1 scenarios playable. IIRC, however, the creator(s) of Trojan didn't want it ported for some reason. Maybe they've changed their minds now, though.
“People should not be afraid of their governments. Governments should be afraid of their people.” —V, V for Vendetta (Alan Moore)

“The trouble is that we have a bad habit, encouraged by pedants and sophisticates, of considering happiness as something rather stupid. Only pain is intellectual, only evil interesting. This is the treason of the artist: a refusal to admit the banality of evil and the terrible boredom of pain. If you can’t lick ’em, join ’em. If it hurts, repeat it. But to praise despair is to condemn delight, to embrace violence is to lose hold of everything else. We have almost lost hold; we can no longer describe happy man, nor make any celebration of joy.” —Ursula K. Le Guin, “The Ones Who Walk Away from Omelas”

“If others had not been foolish, we should be so.” —William Blake, The Marriage of Heaven and Hell

Last.fm · Marathon Chronicles · Marathon Eternal 1.2 · Where Monsters Are in Dreams · YouTube Vidmaster’s Challenge
User avatar

The Man
Sarasota, FL

Post Feb 24th '19, 03:09

If A1 is able to just play the M1 Trojan files, then no porting is necessary.
User avatar

Pfhorrest
California

Post Feb 24th '19, 03:33

I wonder if they made weird edits to the m1 executable the same way they did for M2. If you install the win95 version of trojan, it gives you a specific executable. If you just drop the normal marathon 2 windows executable in the trojan directory and try to use that, things don't work right. That's why alephone can't play the m2 version of trojan correctly.
User avatar

Wrkncacnter

Post Feb 24th '19, 04:52

I thought I’d read that they’d made some changes to the M1 app, too. IDK the specifics, though, nor do I even know if I’m remembering that right.
“People should not be afraid of their governments. Governments should be afraid of their people.” —V, V for Vendetta (Alan Moore)

“The trouble is that we have a bad habit, encouraged by pedants and sophisticates, of considering happiness as something rather stupid. Only pain is intellectual, only evil interesting. This is the treason of the artist: a refusal to admit the banality of evil and the terrible boredom of pain. If you can’t lick ’em, join ’em. If it hurts, repeat it. But to praise despair is to condemn delight, to embrace violence is to lose hold of everything else. We have almost lost hold; we can no longer describe happy man, nor make any celebration of joy.” —Ursula K. Le Guin, “The Ones Who Walk Away from Omelas”

“If others had not been foolish, we should be so.” —William Blake, The Marriage of Heaven and Hell

Last.fm · Marathon Chronicles · Marathon Eternal 1.2 · Where Monsters Are in Dreams · YouTube Vidmaster’s Challenge
User avatar

The Man
Sarasota, FL

Post Feb 24th '19, 12:48

ravenshining wrote:Can you point us to the scenario files you're having trouble with? Otherwise it's hard to say what's going on.

Regarding platforms, I noticed that myself while testing M1R the other day, a wasp got killed on top of the the door on Smells Like Napalm and jammed it open while going through its soft death animation without then proceeding to its hard death animation. If I figure out my wasp problem, I'll let you know.


I've added a zip folder with all scenario files to a shared Google Drive folder: https://drive.google.com/open?id=13sR_0N5A-q-wVpddAZlboLGk7aBuVsUR

I haven't tried editing any of the original project files using modern utilities, but I'd imagine you'd need to edit them using original M1 editors. I used Pfhorte for the map, Pfhred for Shapes, etc... in OS9 via SheepShaver

ravenshining, your issue with the wasp preventing the platform from completing its cycle is exactly what's going on with my crushing juggxrnaught effect.

---

I'll try to keep this whole process documented as it could help other M1 conversions. I'll also try to update any bug reports, treellama. BTW, I just discovered Weland (I've been out of the AO loop for many years...) and it's renewed my interest in map-making! It's so nice being able to create content on a modern OS and not rely on my buggy SheepShaver install :)
mattschenk

Post Mar 1st '19, 01:55

After tinkering with a "crusher test map" I made, I've found the issue with juggernaut's not correctly exploding. In AO, if the platform's poly height is set below the height of the juggernaut's hit box, the juggernaut will be stuck in a perpetual death animation with the klaxon going off and never explode. If the platform is set to "Activate Adjacent Upon Deactivating" it'll never activate its neighbors. Apparently M1 didn't act this way.

It was an easy fix to adjust platforms in the map, so I should be able to fix this for Phoenix Falling, but could be something to keep in mind for other 3rd part scenarios that use this FX.

I've attached a copy of my crusher test map that should work with the M1 AO scenario (but not M1A1) if you want to see my quick research. Interestingly enough, Pfhor fighters get crushed to death just fine when the platform is too short for them.
Attachments
crusher.zip
(10.76 KiB) Downloaded 29 times
mattschenk

Post Mar 1st '19, 04:07

That's an interesting find! Fighters are different in that they only play through a single death animation, unlike most flying monsters who loop through their soft death until they hit the floor, and then play their hard death.

I imagine with my wasps, who did not start on the platform but flew over it, their hit-cylinder must have clipped the door at the moment of death, perhaps because I was shooting them.

I believe this is the relevant code from Aleph One, monsters.cpp:610-615:

Code: Select all
if ((definition->flags&_monster_has_delayed_hard_death) && monster->action==_monster_is_dying_soft)
{
   if (!monster->external_velocity && object->location.z==monster->desired_height) //&& !monster->vertical_velocity)
   {
      set_monster_action(monster_index, _monster_is_dying_hard);
   }


A quick patch to fix this case might be to change line 612 to:

Code: Select all
if (!monster->external_velocity && object->location.z<=monster->desired_height)


However, that would cause monsters to start playing their hard death below floor level, which you might not want if the polygon is not a platform.
User avatar

ravenshining
Hawai'i


Return to Projects



Who is online

Users browsing this forum: No registered users