Aleph NONE (Request: M2 XBL binary file)

[Asylum]

https://github.com/0x7F800000/Aleph-NONE/tree/master

OSX build coming whenever $lave gets around to building it.
Windows build coming whenever making a windows build stops being a pain in the ass.

Basically, fork of Aleph One that does not attempt to support films, or old save games. Do not plan on changing the format for any files other than those. Basically an attempt to make the source human-readable and add features galore to Lua/XML. Majority of changes so far are just in the source.

Monsters in Lua have had the following fields added to them:
collection
immunities
weaknesses
flags
_class
friends
enemies
sound_pitch
activation_sound
friendly_activation_sound
clear_sound
kill_sound
apology_sound
friendly_fire_sound
flaming_sound
random_sound
random_sound_mask
carrying_item_type
radius
height
preferred_hover_height
minimum_ledge_delta
maximum_ledge_delta
external_velocity_scale
impact_effect
melee_impact_effect
contrail_effect
half_visual_arc
half_vertical_visual_arc
visual_range
dark_visual_range
intelligence
speed
gravity
terminal_velocity
door_retry_mask
shrapnel_radius
hit_shapes
hard_dying_shape
soft_dying_shape
hard_dead_shapes
soft_dead_shapes
stationary_shape
moving_shape
teleport_in_shape
teleport_out_shape
attack_frequency

If you wrote a Lua script that depends on changing MonsterType fields to change all monsters of a type, this breaks your script. Instead MonsterTypes determine what these values, belonging to single monsters, get initialized to. So if you change something in a monstertype and then spawn a monster of that type, those changes will reflect in these fields. But after that monster is spawned you can then edit these fields independently of the monstertype.

Although I haven't written the code for lua to do it yet the melee and ranged attack definitions for each monstertype are also modifiable in the same way.

Next big update might be doing the same thing but with projectiles. Also need to make all of this get saved to save games.

[Wrkncacnter]

Any plans to add support for 3D glasses? That would be awesome.

[Asylum]

Didn't The_One already do something like that?

[patrick]

where giants have fallen you can conquer

[Herbert West]

Nice! Having those extra fields available in Lua will allow for some very interesting monsters: multi-stage boss battles, enemies altering their attacks when wounded or when there are few other active enemies left, monsters which require a combination of damage types to finish off, etc. I see a lot of exciting possibilities here!

However, I do have a concern. Didn't the Marathon community come to a near-consensus a long time ago that we would focus on one fork of A1, so as to avoid splitting our efforts? I think that the idea was that, since we are a fairly small community compared to DOOM, which has multiple forks, we would need to focus out efforts in order to get anything done.

If feasible, could you please look into adding these features to the main fork of A1? We probably couldn't have new-save-and-film-to-old-engine backwards compatibility, but we could have old-save-and-film-to-new-engine compatibility, and this is, I would argue, the type of backwards compatibility that really matters. Actually, we already have a similar situation with Lua: Lua v4 scripts work in recent A1 releases thanks only to compatibility triggers, if I understand correctly.

[Asylum]

Nice! Having those extra fields available in Lua will allow for some very interesting monsters: multi-stage boss battles, enemies altering their attacks when wounded or when there are few other active enemies left, monsters which require a combination of damage types to finish off, etc. I see a lot of exciting possibilities here!

However, I do have a concern. Didn't the Marathon community come to a near-consensus a long time ago that we would focus on one fork of A1, so as to avoid splitting our efforts? I think that the idea was that, since we are a fairly small community compared to DOOM, which has multiple forks, we would need to focus out efforts in order to get anything done.

If feasible, could you please look into adding these features to the main fork of A1? We probably couldn't have new-save-and-film-to-old-engine backwards compatibility, but we could have old-save-and-film-to-new-engine compatibility, and this is, I would argue, the type of backwards compatibility that really matters. Actually, we already have a similar situation with Lua: Lua v4 scripts work in recent A1 releases thanks only to compatibility triggers, if I understand correctly.

I'm not sure whether my code would be accepted. With open source projects there's usually some sort of politics involved, you have to consult people before doing stuff, and you can't make radical changes easily. Also, some of the contributors to the main fork dislike me, for good reasons. Hence the fork.

[Herbert West]

Politics, right. I can understand why you'd want to avoid that - but declaring at the outset that this is going to be a separate fork might make those politics worse. Also, in the long run, two separate forks would require twice as much work to keep updated as computers change. As a mapmaker, I'd prefer to see these abilities in the main A1 fork as that is the one fork which is the most likely to be maintained.

On the other hand, I can see the value of pursuing a separate fork for now, in order to have a testbed for your ideas that is free of interference.

Back on the subject of the code:
Have you considered making Lua able to change a monster's type after it has been spawned, instead of editing each of the characteristics that normally follow from the type? This would slightly reduce the flexibility available to scenario makers, as there are only 40-something monster types, and it would require the use of custom physics in order to have monsters do anything other than just obviously switch types. However, this would mean that you don't need to put extra data in your saved game files and thus allow full compatibility with conventional A1.

Here's another idea:
If we had the ability to edit the types of active monsters, plus some fields associated with each monster which are initialized from the monster's type upon starting from a saved game, this would make a nice compromise. Scenario designers could make changes to individual monsters which do not require a custom physics model, but those changes would not persist across saved games (which wouldn't necessarily be a problem - say if the change is dependent on a monster's location, it will resume as soon as the new game starts anyway). Changes could be made to persist across saved games, with less flexibility, by using a physics model which has the altered monster as a separate monster type. With this system, you could avoid having to put compatibility-destroying extra data in saved games - it's good all around!

Regarding the name:
It's curious that you've chosen to call this project Aleph NONE, as Aleph naught means regular old infinity in mathematician-speak. Perhaps Aleph 2 might be a more suitable name if you decide to keep this as a separate fork.

[treellama]

Right now I would say the changes would not be accepted because they break existing Lua scripts, are incomplete (missing saved game support), and also unfortunately we haven't moved to C++11 yet. That last part is up for discussion.

I'll consider patches from any contributor based solely on the merits of the code, and I think Hopper will too.

Cleaning up the game structures, and making things more object oriented in general, is a goal we share. To the extent that you are able to pull just those changes out, without breaking stuff that is core to Aleph One, I'd be happy to merge them.

On the other hand, it's nice to have a fork where you can do whatever you want without worrying about breaking films and net games and so forth. I've considered switching to working on Aleph Modular, which has way fewer features and could be made really clean and object oriented and C++-y, and then become the basis for yet another fork to implement modern server-authoritative net game code. Maybe when I retire...

[Bobwithkeycard]

yay, fork it up, baby.

best of luck to Aleph None.

[Pfhorrest]

Regarding the name:
It's curious that you've chosen to call this project Aleph NONE, as Aleph naught means regular old infinity in mathematician-speak. Perhaps Aleph 2 might be a more suitable name if you decide to keep this as a separate fork.

I think it might actually be kind of appropriate, as if I understand correctly one of the goals of this fork is to be more modular or, in a sense, discrete, and as aleph one is the cardinality of the continuum, using aleph "none" for a more-discrete (and thus not continuous) fork of the project kind of makes sense.

[Hopper]

IMO, compatibility with existing scenarios is a top priority for Aleph One, because there's a lot more content already made and released than is likely to be released post-2014. The idea is very cool, and an explicit toggle (like Game.proper_item_accounting) could retain compatibility with older scripts, though getting these changes working with saved games could still be tricky.

If you want to identify the parts appropriate for Aleph One, or ever feel like adding the compatibility and features to bring it in line with our goals, that's great. If not, we understand how nice it is to just focus on the task at hand, and since it's on GitHub anyone sufficiently motivated can work on blending the code bases.

For the record, I also judge the code, not the person. Aleph One is bigger than any one contributor, and putting my personal friendships or grudges above what's best for the project would be like restoring Ecce Homo without training. To those folks whose patches I've rejected, it's truly nothing personal, and it always hurts to do it.

TL;DR - what Treellama said.

[Asylum]

Politics, right. I can understand why you'd want to avoid that - but declaring at the outset that this is going to be a separate fork might make those politics worse. Also, in the long run, two separate forks would require twice as much work to keep updated as computers change. As a mapmaker, I'd prefer to see these abilities in the main A1 fork as that is the one fork which is the most likely to be maintained.

On the other hand, I can see the value of pursuing a separate fork for now, in order to have a testbed for your ideas that is free of interference.

Back on the subject of the code:
Have you considered making Lua able to change a monster's type after it has been spawned, instead of editing each of the characteristics that normally follow from the type? This would slightly reduce the flexibility available to scenario makers, as there are only 40-something monster types, and it would require the use of custom physics in order to have monsters do anything other than just obviously switch types. However, this would mean that you don't need to put extra data in your saved game files and thus allow full compatibility with conventional A1.

Here's another idea:
If we had the ability to edit the types of active monsters, plus some fields associated with each monster which are initialized from the monster's type upon starting from a saved game, this would make a nice compromise. Scenario designers could make changes to individual monsters which do not require a custom physics model, but those changes would not persist across saved games (which wouldn't necessarily be a problem - say if the change is dependent on a monster's location, it will resume as soon as the new game starts anyway). Changes could be made to persist across saved games, with less flexibility, by using a physics model which has the altered monster as a separate monster type. With this system, you could avoid having to put compatibility-destroying extra data in saved games - it's good all around!

Regarding the name:
It's curious that you've chosen to call this project Aleph NONE, as Aleph naught means regular old infinity in mathematician-speak. Perhaps Aleph 2 might be a more suitable name if you decide to keep this as a separate fork.

Great idea! I poked around a little and found a way that at least seven of the fields could be made accessible in the main branch of A1. And with a messy solution more of them could become accessible. The monster_definition structure is 128 bytes, while the monster_data structure is 64. Those sizes can't change. For each monster, three seperate, "dead" monsters would be created. These monsters would be flagged as unused by aleph one, with no associated map object or anything.

The unused seven fields cannot be used to reliably indicate whether or not the monster has its own personal definition. instead an existing one has to be used, the monsters mode.

enum /* monster modes */
{
_monster_locked,
_monster_losing_lock,
_monster_lost_lock,
_monster_unlocked,
_monster_running,
NUMBER_OF_MONSTER_MODES
};
The value of the monsters mode is 16 bits, but only 4 bits are actually needed to represent it. The fifth bit can be used to indicated whether the monster has an extended definition.

I think that, in theory, this is all pretty sound and should work.

[Asylum]

Right now I would say the changes would not be accepted because they break existing Lua scripts, are incomplete (missing saved game support), and also unfortunately we haven't moved to C++11 yet. That last part is up for discussion.

I'll consider patches from any contributor based solely on the merits of the code, and I think Hopper will too.

Cleaning up the game structures, and making things more object oriented in general, is a goal we share. To the extent that you are able to pull just those changes out, without breaking stuff that is core to Aleph One, I'd be happy to merge them.

On the other hand, it's nice to have a fork where you can do whatever you want without worrying about breaking films and net games and so forth. I've considered switching to working on Aleph Modular, which has way fewer features and could be made really clean and object oriented and C++-y, and then become the basis for yet another fork to implement modern server-authoritative net game code. Maybe when I retire...

A large portion of the work that's been done so far is just grunt work, like inverting if statements and making expressions look prettier. Most of that could be moved over the A1. I also removed a lot of ancient dprintf's and dead code. Most of the accessors are defined with macros.

The only real issue is no C++ 11. I intend to use lambdas to clean up some of the really insane functions and I've been replacing the types of primitive lvars that are initialized by a function returning or a field from a structure with auto.

[Herbert West]

I poked around a little and found a way that at least seven of the fields could be made accessible in the main branch of A1. And with a messy solution more of them could become accessible. [...]
The unused seven fields cannot be used to reliably indicate whether or not the monster has its own personal definition. instead an existing one has to be used, the monsters mode. [...]
The value of the monsters mode is 16 bits, but only 4 bits are actually needed to represent it. The fifth bit can be used to indicated whether the monster has an extended definition.

That sounds kludgey. Workable, but kludgey.

I was thinking of giving every monster an extended definition, which sits in an entirely new data structure (let's call it monster_moredata). The game would read from monster_moredata instead of monster_definition for the fields that monster_moredata defines, but monster_moredata would be filled from monster_definition when the monster is created, so the default behavior would be the same as in plain A1.

Lua scripts could change monster_moredata to change an individual monster's behavior.

In order to preserve compatibility with old A1 saves, monster_moredata would not be stored in saved game files. This means that changes made by editing monster_moredata cannot persist across saved games. However, monster_moredata would be filled from monster_definition upon loading a saved game, meaning that persistent changes could be created by editing a monster's type (which I assume is specified in monster_data, right?)

A large portion of the work that's been done so far is just grunt work, like inverting if statements and making expressions look prettier. Most of that could be moved over the A1.

That's good to hear.

Speaking as a mapmaker, the monster-related improvement which I'd like to see the most is the ability to edit an active monster's type. This ability wouldn't be quite as versatile or convenient as what we could have with that and a monster_moredata structure or the like, but it would allow for some very cool multi-stage battles and alternatives to berzerker mode, and I (perhaps foolishly) expect that it would be feasible to add to the main A1 fork.

Alternatively, the ability to delete a monster (similarly to what one can do with scenery) would do just as well, as you could effectively alter a monster by deleting it and placing one of a different type in the same place with the same facing, external velocity, etc. Actually, this might work even better, as it would avoid any complications which may arise from changing a monster while it is in the middle of doing something that it's new type can't do.

[Asylum]

I poked around a little and found a way that at least seven of the fields could be made accessible in the main branch of A1. And with a messy solution more of them could become accessible. [...]
The unused seven fields cannot be used to reliably indicate whether or not the monster has its own personal definition. instead an existing one has to be used, the monsters mode. [...]
The value of the monsters mode is 16 bits, but only 4 bits are actually needed to represent it. The fifth bit can be used to indicated whether the monster has an extended definition.

That sounds kludgey. Workable, but kludgey.

I was thinking of giving every monster an extended definition, which sits in an entirely new data structure (let's call it monster_moredata). The game would read from monster_moredata instead of monster_definition for the fields that monster_moredata defines, but monster_moredata would be filled from monster_definition when the monster is created, so the default behavior would be the same as in plain A1.

Lua scripts could change monster_moredata to change an individual monster's behavior.

In order to preserve compatibility with old A1 saves, monster_moredata would not be stored in saved game files. This means that changes made by editing monster_moredata cannot persist across saved games. However, monster_moredata would be filled from monster_definition upon loading a saved game, meaning that persistent changes could be created by editing a monster's type (which I assume is specified in monster_data, right?)

A large portion of the work that's been done so far is just grunt work, like inverting if statements and making expressions look prettier. Most of that could be moved over the A1.

That's good to hear.

Speaking as a mapmaker, the monster-related improvement which I'd like to see the most is the ability to edit an active monster's type. This ability wouldn't be quite as versatile or convenient as what we could have with that and a monster_moredata structure or the like, but it would allow for some very cool multi-stage battles and alternatives to berzerker mode, and I (perhaps foolishly) expect that it would be feasible to add to the main A1 fork.

Alternatively, the ability to delete a monster (similarly to what one can do with scenery) would do just as well, as you could effectively alter a monster by deleting it and placing one of a different type in the same place with the same facing, external velocity, etc. Actually, this might work even better, as it would avoid any complications which may arise from changing a monster while it is in the middle of doing something that it's new type can't do.

What you described beforehand is already what an1 does. Each monster has its own definition instance created from the original definition. Switching between types is seamless and shouldn't pose a problem. In fact I believe the feature is available in the main fork? Not sure.

[treellama]

Switching between types is seamless and shouldn't pose a problem. In fact I believe the feature is available in the main fork? Not sure.

Monster.type is read-only

[Asylum]

Switching between types is seamless and shouldn't pose a problem. In fact I believe the feature is available in the main fork? Not sure.

Monster.type is read-only

Ah. I'm sure you had a good reason for that. Could you explain the dangers of that though?

[Asylum]

I've been really busy and haven't been able to work on this recently. I have a lot of free time on my hands now so I'll probably resume working on this.

[Bobwithkeycard]

excellent, sometimes all you need is three real life betty BoBs (old M1 mod) to jump around pointing at your PC in order to get back to work. Hope this is what happened ; )

[Asylum]

excellent, sometimes all you need is three real life betty BoBs (old M1 mod) to jump around pointing at your PC in order to get back to work. Hope this is what happened ; )

Aww Bob, I think you might be my biggest fan around here.

So here's the game plan now:
This fork is a bit of a mess. I started trying to do things that were a little unnecessary with the code. Like attempting to create a run-time reflection system for use with templates. Also, I abused automatic type deduction for integer types in some functions in places where it was important for types to have a certain size. Behaviour for monsters differs from the main fork in subtle ways.

I found this out testing an1 over netgames with aliens. I go OOS every time aliens are involved. I'm going to keep this fork around for integrating the Damage code, but eventually I'm going to just merge the acceptable parts into A1. I have had a lot of fun working on this, and learned a lot about A1's internals from debugging with GDB. This also was my first project using C++11/C++14, which was very interesting. C++14 has a lot of potential but only Clang and SVN builds of GCC support all of its features right now, and I don't think A1 could really benefit much from compile-time code execution anyway.

So yeah, this is just a test fork for getting the damage code working now.

[Asylum]

Also, if someone could provide the binary file for the M2 XBLA version that would be pretty helpful. I just want to peek at the assembly for archaelogical purposes.

[Bobwithkeycard]

Aww Bob, I think you might be my biggest fan around here.

you might be right there. I have introduced weekly fanclub meetings in the House Of Pain with free ammo for everyone for a while now. Since I usually kill everyone it might very well be that I'm your only fan now, though

I go OOS every time aliens are involved.

reminds me of playing M2 for Windows over LAN back in the late 90s. You were about to go OOS as soon as you were rocking the table during the gathering process.