Marathon 1 Redux

[ravenshining]

Lots more work done on Cool Fusion, and then some on Arrival, up on GitHub. I've decided to go the invisible oxygen tick method of creating pseudo-vacuum. It's behaving much better than using liquids, although I can't disable weapons this way.

I'm having a bit of a problem on Arrival where there's a monster who refuses to budge.

Spoiler:

My intention is for the BoB to activate as the player enters the airlock.
Then the fighter, which is set to blind and deaf, activates when the player enters the corridor.

However, the BoB fails to activate until the second trigger, the one meant for the fighter, is crossed, and then he refuses to leave his polygon - he runs up to the side and starts glitch-running in place. If the fighter survives and the BoB dies, it will walk right past where the BoB gets stuck with no problem.

[philtron]

If I'm reading this correctly and the dark blue squares are Zone Borders then these are blocking any signals from triggers. So, the BoB not activating until you hit the Trigger in the hallway is correct; the zone border between the airlock and the BoB should be removed. However, if I'm reading this correctly, the Fighter should never get activated at all since he's surrounded by Zone Borders and no trigger signal should ever reach him. The only thing I can think of is that he's not actually "blind".

As for the BoB glitching out. Might have something to do with where he's placed. Is his height at "0.0"? That's the only thing I can think of.

[The Man]

Can the monsters access all the polygons in that map? They need to be able to move between at least three polygons to activate. I can't think why that geometry would pose a problem, but I don't know what polygon heights you've used. It doesn't look like any are monster & item impassable, at any rate.

You can disable weapons on a level-by-level basis using physics, if that helps. Lua can probably make it impossible for certain weapons to fire in certain polygons, though you'd have to update that if you ever deleted any, so it might be a pain in the arse. You can also change the behaviour of liquids on a level-by-level basis by embedding MML for the level, though I don't know if you can make it possible for the player to run under them (that might be another Lua thing). But there's probably a way to disable swimming in specific liquids in specific levels using either Lua or MML or both to make them mimic vacuum conditions more closely.

[ravenshining]

The Man, if I knew how to use Lua to do those things, I would, but I don't.

Philtron, my understanding is that Visible/Invisible/Dual Monster Triggers can cross one Zone Border but not two, whereas Glue Triggers can not cross a single Superglue polygon. I am not sure how or whether the M1 and M2 polygons interact with each other.

After hearing about A1's capability to export video on The Man's thread, I figured out how to do the same on my machine (I use a US windows keyboard under Linux set to Apple's Mali layout, modifiers can be awkward. A1 registers the meta key as "option" whereas X11 uses the right alt as "option"). So here's a video of BoB's bad behaviour that should also answer your geometry questions. I've seen him do the same thing on the petals of The Rose, but it would take a much longer video to demonstrate it there.

In case you're wondering why the purple fighter dies before I shoot it, that's the hangar's invisible oxygen tick at work. I wish there was a way to prevent the Pfhor from trying to attack it without removing the Berserker tag.

I've tried and completely reconstructing the area with more polygons, this time using Glue, Glue Trigger, and Superglue polygons. BoB no longer gets stuck, but now the triggers completely fail to function. Despite neither monster being set to blind, they don't react until you fire a weapon or hit them. Here's a composite screenshot of Weland draw and polygon type views:

Spoiler:

On an unrelated note, it's a pity 3D models cause depth testing bugs. I like how with 3D I can start the player IN the escape pod...

[philtron]

Philtron, my understanding is that Visible/Invisible/Dual Monster Triggers can cross one Zone Border but not two, whereas Glue Triggers can not cross a single Superglue polygon. I am not sure how or whether the M1 and M2 polygons interact with each other...
I've tried and completely reconstructing the area with more polygons, this time using Glue, Glue Trigger, and Superglue polygons. BoB no longer gets stuck, but now the triggers completely fail to function. Despite neither monster being set to blind, they don't react until you fire a weapon or hit them.

[/quote]

Unless Weland and AlephOne deal with these things differently, then a single Zone Border will block any signal sent by a Monster Trigger.

I've never used Glue or Super Glue, but if I remember correctly: A monster placed on a Glue polygon will only activate when the player steps on a Glue trigger or if it sees or hears the player. A monster placed on a Superglue trigger will not activate even until it sees or hears an enemy, regardless of whether the player steps on a Glue Trigger. I am not 100% certain about that, nor do I know how any of this interacts with the other Monster Triggers and Zone Borders. Does a Glue Trigger cross a zone border? Don't know, but I know it's been discussed on these forums in the past.

[philtron]

Here's another post where people discuss glue triggers:
http://pfhorums.com/viewtopic.php?f=24& ... 591#p71591
It's from 2015 but it seems that the Glue, Superglue, and Glue Triggers don't actually work unless you create some script for them. But maybe that has changed since.

[ravenshining]

With further testing, it appears BoBs refuse to cross zone border polygons, and so they count against the necessary three passable polygons needed for proper movement. This explains the freaked-out red BoB in the petals of M1A1 The Rose, he sits on a trigger polygon surrounded by zone borders and cannot move, whereas the original The Rose has him on one of several contiguous glue polygons and acts normally.

It appears monsters in the original Marathon have considerably more freedom of movement than they do in either the old or current M1A1, I shall have to get a better M1 map editor than Mia working to investigate the originals and ensure monsters enjoy the same freedoms in Redux.

Why BoBs are restricted from zone borders and not other monsters, I'm still trying to nail down. My first guess was it was the "cannot attack" flag unique to M1 BoBs and M2 ticks, but changing this did nothing. Searching through the source code for zone_border turned up this:

Code: Select all

		/* if weÕre trying to move into an impassable polygon, disallow the move */
		switch (destination_polygon->type)
		{
			case _polygon_is_zone_border:
				if (!data->cross_zone_boundaries) cost= -1;
				break;

but searching for cross_zone_boundaries isn't taking me anywhere that looks to my non-programmer eyes to be helpful,

I did find some surprising things in the monster activation code, apparently BoBs are deaf to friendly players!?

Unless Weland and AlephOne deal with these things differently, then a single Zone Border will block any signal sent by a Monster Trigger.

Looking through the source code, this does not seem to be the case. It looks like when a signal encounters a zone border, it tests to see whether a passed_zone_border flag is set: if it is, the signal stops, if it is not, the flag is set and continues.

I've never used Glue or Super Glue, but if I remember correctly: A monster placed on a Glue polygon will only activate when the player steps on a Glue trigger or if it sees or hears the player. A monster placed on a Superglue trigger will not activate even until it sees or hears an enemy, regardless of whether the player steps on a Glue Trigger. I am not 100% certain about that, nor do I know how any of this interacts with the other Monster Triggers and Zone Borders. Does a Glue Trigger cross a zone border? Don't know, but I know it's been discussed on these forums in the past.

Hmm, it appears that Glue Triggers call the same function activate_nearby_monsters() that Monster Triggers do, but passing different flags. Also there appears to be no difference between Dual and Invisible monster triggers!

All three activate deaf monsters
Glue triggers activate invisible monsters, can pass glue polygons, and cannot pass superglue.
Invisible/Dual triggers activate invisible monsters, and can re-activate a monster that has recently been activated.
Visible triggers can re-activate a monster that has recently been activated.

I may easily be wrong, but it looks like glue triggers follow zone border rules, and it looks like monster triggers cannot pass glue IF the appropriate flag is set in the map file, but can always pass superglue.

Whew. All this and I still don't know why Pfhor will cross a zone border and BoB won't.

EDIT: I think I've solved the activation dilemma, at least. It seems that deaf or friendly monsters are not activated if they are behind a zone border, while hostile non-deaf monsters are activated. At least I think that's what the code is saying, and applying this to the map solves the activation issue, although not the movement issue.

But, BoB shouldn't be running out into the hangar and suffocating anyway, however amusing that may be.

[The Man]

I intend to learn Lua, since it’ll be useful for a number of behaviours I want to program into various levels I’ve made; I’m going to be pretty busy until mid-June, but I’ll hopefully have time after then. If I figure any of this out after that point, I’ll let you know. I’ve looked at some Lua code before and it didn’t seem that impenetrable, and I’ve learned languages that were probably quite a lot more complicated, so hopefully it won’t be too time-consuming.

That’s weird that Bobs don’t pass zone borders. Is that an M1 thing? I definitely don’t remember it being a problem in any of my maps. (Also all the discussion of glue triggers is currently passing completely over my head, though it probably doesn’t help that it’s past midnight; I should probably get some sleep and then read the thread you linked discussing them.)

[treellama]

I shall have to get a better M1 map editor than Mia working to investigate the originals and ensure monsters enjoy the same freedoms in Redux.

You could try Hopper's marathon utilities to convert the M1 map into a M2 map that Weland can read. Easier than getting Bovine or Pfhorte working.

I think Weland can open Aleph One saved games, so that's another, hackier but maybe easier way to view Marathon levels. I haven't tried it in a while though.

[ravenshining]

Thanks Treelama, I'll look into that. Opening a save in Weland gave me the longest error message ever, here:

Spoiler:

[treellama]

Looks like it barfs loading the saved light states. Oh well.

I appreciate the throwback early 2000's window manager and theme though. Opera is a fitting touch as well.

[treellama]

Looking through the source code, this does not seem to be the case. It looks like when a signal encounters a zone border, it tests to see whether a passed_zone_border flag is set: if it is, the signal stops, if it is not, the flag is set and continues.

For triggers, activate_nearby_monsters is called from changed_polygon in marathon2.cpp without the _pass_one_zone_border flag. So, the signal stops without passing one zone border.

Confusing, no?

[The Man]

I’ve played around a bit more with Lua, and I think it's possible to use it to mimic at least some of the behaviour of vacuums only in specific polygons. I think it's even possible to cause oxygen damage to players only in specific kinds of polygons, or based on a light in a map. Thus, if you want an airlock, you'll set one light to 100% when a player is in vacuum, and to 0% otherwise. After that, you can do oxygen damage at a given rate to any player based on the light.

I haven't written all the code for this yet, so I haven't verified that it's possible, but I think it is. Unfortunately, the light-based approach I've described above will only work for single-player games. I'm not sure if you're making multiplayer an option; if you are, I'll probably have to come up with some other approach, though I think I might be able to formulate a script that would work based on the light in the specific polygons that contained the airlock, and based on some other factor (perhaps the floor light of the player's polygon, or the liquid it contains - you wouldn't actually have to make the liquid visible; it could probably be under the floor height of the polygon and set not to play sound unless it's above the floor height) in all other circumstances.

Of course, the other issue is that Marathon doesn't use up oxygen at a constant rate, and without knowing what criteria it uses to determine oxygen consumption, I won't be able to mimic that accurately. But it'll at least probably be more satisfying than using an oyxgen tick.

Anyway, I haven't tested all of this, so I may have to improvise some to get it to work, but I'm reasonably certain it can be done. It's certainly possible to cause monsters or players to suffocate if they go underneath a certain z value, so it should probably be possible to use other factors to cause damage to players as well.

[ravenshining]

Looks like it barfs loading the saved light states. Oh well.

I appreciate the throwback early 2000's window manager and theme though. Opera is a fitting touch as well.

With further testing, I did manage to get it to load one Infinity save. So it is possible, but most of the time it barfs.

I like Opera. It's sleek, functional, and uses a compression proxy which really helps my metred connection. Ironically, I've rarely been able to get Firefox to work properly under Linux. Only thing I don't like is how Opera keeps resetting my default search to Google, I much prefer Yandex.

For triggers, activate_nearby_monsters is called from changed_polygon in marathon2.cpp without the _pass_one_zone_border flag. So, the signal stops without passing one zone border.

Confusing, no?

What...? Ah, now I see. _pass_one_zone_border is for monsters and weapons, not polygons. It's neat finding stuff I've been wrong about for twenty years.

Unfortunately, the light-based approach I've described above will only work for single-player games. I'm not sure if you're making multiplayer an option; if you are, I'll probably have to come up with some other approach,

Making multiplayer work better is a major goal of Redux. But don't worry, the oxygen tick is doing great at depleting oxygen and killing non-vacuum-enabled Pfhor. I'll use them so rarely, I can just make custom physics for whatever monsters will be exposed to them.

It's disabling weapons in specific polygons, or disabling swimming so a liquid can be used, that are the problems a tick can't solve.

[The Man]

So, I haven’t yet gotten around to refining this script, but I was correct that it’s possible to implement a selective oxygen drain based on the content of a particular polygon. Here’s a very brief Lua script that drains a player’s oxygen by 1 per game frame (1/30 second; the player has a total of 10,800 oxygen to start, so it'd take six minutes to run out) if and only if the player is standing on a polygon that contains media (it doesn’t matter whether the player is above or below the media). This can presumably be altered to almost any other polygon-specific information depending upon what works for the map (a particularly useful property would be polygon.ceiling.transfer_mode; polygons with landscape for their ceiling transfer mode are particularly likely to be in a vacuum); what’s important is that it does, indeed, work, and it’s probably much more convenient than using an oxygen tick. Perhaps even more importantly, I can probably disable some weapons from firing depending upon the player’s polygon as well, though I haven’t gotten around to doing this yet.

Code: Select all

function Triggers.idle()
	oxygen()
end

function oxygen()
	for p in Players() do
		if p.polygon.media then
			p.oxygen = p.oxygen-1
		end
	end
end

This doesn’t scale with difficulty, nor does it change value depending upon the player’s actions. I have no idea what the algorithm Marathon uses to calculate that is, but given the relevant information from the source code I could probably replicate it within a day or two. It may also be more prudent to use the oxygen drain damage type rather than altering p.oxygen directly; this script doesn’t play the “drain oxygen” sound that occurs at all other times the player loses oxygen in my scenario, so it may not be what Marathon expects. I’ll play around with this more and get back to you. Regardless of whether you use it, I’m thinking of doing so myself, but I haven’t decided for certain.

(Also, I hope you’re staying safe; that volcano thing sounds serious, though I don’t know where in Hawaii you are)

ETA: Using oxygen drain damage still doesn’t play the sound that occurs in all vacuum/underwater situations (if this doesn’t make sense, Marathon normally plays whatever’s in, IIRC, the “unused 1” slot as soon as oxygen starts being used, and every so often every thereafter, but in this case it’s not happening). I wonder what the difference is.

[HelviusRufus]

In some o these rooms and areas with a lot o lava, it would be, in a word, HOT. You don't have to fall into the stuff to get burned, you just have to get close to it; it makes the whole room hot. So hot that there should be some penalty for just being there, i.e. losing health because your suit has to work overtime just to keep you alive, or perhaps losing O2 for the same reason; perhaps the suit uses O2 for cooling, etc.

[treellama]

I have no idea what the algorithm Marathon uses to calculate that is, but given the relevant information from the source code I could probably replicate it within a day or two.

On Major Damage and Total Carnage, you burn extra oxygen while firing.
On Total Carnage, you burn extra oxygen while running.

[The Man]

I thought so, though I didn't realise the penalties were only on higher difficulties (shows you how much I play on the lower ones lately). Do you have the exact formulae?

And yeah, I agree that there should be penalties for being above lava. (Convection Schmonvection, as TV Tropes puts it.) I'll look into implementing that as well. Maybe you lose a given amount of energy (not as much as you'd lose if you were actually swimming or standing in it), decreasing the further you are above it. Seeing the code/algorithm for lava damage would also be helpful here.

[ravenshining]

Oooh, apparently swimming may be disabled for an entire level with <player can_swim="false">. If I can get level scripting working, that will work for Cool Fusion, and maybe Arrival if I don't add in that completely unnecessary bonus sewage area I was thinking of.

The code for polygon damage is in marathon2.cpp. Minor Ouch does 15 alien lava damage every 16 ticks provided one is at location.z==polygon->floor_height, and Major Ouch does 7 alien goo damage every 7 ticks one is in the polygon.

The code for oxygen is a bit more complicated.

Also, thank you for the safe wishes. I'm on a a different island at the moment, but we felt that 6.9 all the way over here, I have friends who live right in the thick of it, and my plan for escaping my landlady's foreclosure involves moving there, so the whole real life lava thing kinda has my full attention right now.

[Meerjel01]

I always thought that the track "Flowers in heaven" fitted the G4 Sunbathing level more than the Landing track.

FIH sounded epic enough to fit in that level. But that could just be me.

[Pfhorrest]

I thought so as well, which is why I used Craig's remix thereof for Eternal's "Sahkmet Rising", which is an obvious homage to G4 Sunbathing (even previously being named "G3 Moontanning").

[The Man]

Glad you’re safe, and hope you stay so. (After that fiasco on Puerto Rico last year I no longer trust our government to respond adequately to natural disasters on islands.)

I’m going to try to write a script to disable specific weapons in specific areas over the next few days, but I’m not entirely sure how I want to go about it. One route is to just disable them from firing. This would probably be easiest if I could figure out where the Lua command is to do that. Another would be to automatically start switching weapons when the player enters a vacuum polygon until a vacuum-enabled weapon comes up. This might be a bit more complicated to code (I’m not sure if Aleph One can automatically switch two weapons ahead at once, for example), but most players would probably also consider it more convenient, and it would certainly eliminate players’ possible confusion for why weapons suddenly stopped firing (though this could also be addressed in terminals, I suppose).

I tried looking at the C++ code for the oxygen algorithm last night and it gave me a bit of a headache. It doesn’t help that I don’t really understand C++ anymore; I haven’t written code in it in probably at least 10 years. On the other hand, this’ll be a helpful mental exercise to reignite my programming skills. I’ll probably be able to give it a more serious look on Sunday; the last couple of days at work have just been rather draining, and I’m working again tomorrow, but I have Sunday off.

The lava damage script should be easier to write; I might be able to get that done tonight or tomorrow. Is it even necessary to write anything for Major Ouch polygons? IIRC, M1 alien goo already damages you regardless of how far you are above it, and I assume Aleph One kept this behaviour, but to be honest I haven’t actually used either Ouch polygon type in a map yet.

I thought so as well, which is why I used Craig's remix thereof for Eternal's "Sahkmet Rising", which is an obvious homage to G4 Sunbathing (even previously being named "G3 Moontanning").

FWIW, I pegged it as a G4 Sunbathing homage the second I entered the main part of the map. Even before then, I kind of suspected.

[ravenshining]

Did a bit more work on Arrival. Fleshed out the external view, added some swtiches, made it so you don't have to wait for the airlock to get inside, made one terminal pic and added in stock ones, made the hangar pfhor not aggro on the tick...

Also some things with the beginning. Thought I'd use the placeholder as a means of showing off the Jjaro set and be a weapons/enemy testing ground until I have an actual level going. Also cut out all the teleporting around the shuttle.

And a few other small changes. Didn't have time for anything extensive this weekend, but the map file is merged at least unlike previous github-only updates

https://github.com/ravenshining/M1R

[ravenshining]

The opening chapter screen I uploaded yesterday was kinda boring and took too long to scroll, so I made a better one. It so happens that in the system I set up in Celestia, Tau Ceti B, C, and D are all visible in the sky of Tau Ceti E-1 along with the Marathon on July 3, 2794 at about 0400 UTC.

It's still basically a stand-in should anyone decide to tackle making something better. I have a vision of it portraying the spaceport prior to the Pfhor nuking, but since the layout has yet to be determined, probably better to hold off on it until we know what the level will look like.

While I'm at it, here's my "attached figure" from the "fire and aspects of the theory..." term. Last semester at college (from which I just graduated, yay!) I took sociology, and the terminal strongly reminded me of symbolic interactionist theory, so I made a flowchart:

Spoiler:

1646.gif (40.15 KiB) Viewed 12111 times

Also uploaded music for Arrival, and re-merged.

[General-RADIX]

Stand-in or not, I do like that prologue screen.