Halomods Community Portal: Megalo Engine - Halomods Community Portal

Jump to content

  • 3 Pages +
  • 1
  • 2
  • 3
  • You cannot start a new topic
  • You cannot reply to this topic

Reach
Megalo Engine

Bungie's most recent MP engine, as seen in Reach

#41 User is offline   kornman00 

  • SourceGuy 2.0
  • Group: Administrators
  • Joined: 15-November 01


Users Awards

Posted 30 December 2012 - 10:17 AM

The scope of my research covers the entire variant structure for both Reach and Halo4. I don't usually glaze over things in the engine, and in this case the encoding makes it impossible to not reverse engineer what something is. I have parts of both the megalo scripting variant structures and runtime (since much of the scripting data needs execution context to figure out) code reverse engineered in both games. Not everything I've RE'd has code support in the library I developed as I first tackle the things which can blockade development of the overall infrastructure. There's also the hindrance of having to find/build logical similarities between the engines as to keep code duplication and complexity to a minimum.

#42 User is offline   kornman00 

  • SourceGuy 2.0
  • Group: Administrators
  • Joined: 15-November 01


Users Awards

Posted 03 January 2013 - 06:13 AM

Variant modding shenanigans:


#43 User is offline   kornman00 

  • SourceGuy 2.0
  • Group: Administrators
  • Joined: 15-November 01


Users Awards

Posted 05 April 2013 - 04:42 AM

Horizon finally includes a variant editor for Halo4 in v2.6! Reach is next. The backend for this has been done since Jan, but the Horizon dev I work with hasn't had as much free time to integrate it lately. Actual Megalo script editing (along with additional features) is to come in an update, as we're trying to make it accessible for all.

#44 User is offline   kornman00 

  • SourceGuy 2.0
  • Group: Administrators
  • Joined: 15-November 01


Users Awards

Posted 31 May 2013 - 04:30 PM

Halomods CTF

This variant of CTF re-enables the 'Sides' option from previous games, giving you the ability to not only play standard 'multi' flag, but also One-Flag and Neutral Flag.

On top of this, there is support for all eight teams. However, it requires the map to also have such support for the CTF objects.

Two other new variant options include:
Flag Pickup Radius: Select how narrow or wide the automatic pickup radius is for enemies of the flag.

Capture Bro Radius: It's good to play together. So when you see your buddy carrying the flag, it may be worth while to stick close to him. Within this radius, "Capture Bro Traits" (see below) will be applied. The default radius is twice that of Flag Pickup Radius

Three new player traits have been added, although one isn't tweakable using the standard game (engine only exposes the first four variant player traits, even though the variants support up to 16):
"Aggro" Traits: In all game modes, when a team's flag is away, these traits will then be applied to players on that team. The only change I made with this trait is applying the 'flood' visual effect, to give a "seeing red" sense.

Capture Bro Traits: Players within the Capture Bro radius gain these traits. The only change I made with this trait is applying the 'damage boost' visual effect, to give a clear indication of who may be sporting extra traits. A better option may have been to just have Waypoints visible to all, so as to not confuse actual damage boosted players within the Capture Bro radius.

Offense/Defense Traits: These only apply in One-Flag (the original Assault). Offensive teams get Offense traits. The team on Defense gains the defense traits (this is the trait that can't be edited ingame).

I was wanting to add a few more definable options and tweaks (eg, an object filter which would delete certain objects when not playing One Flag), but people have been really asking for neutral flag lately so I figure I would release what has been at least tested.

Ending notes:
  • The newly added traits don't change anything except where noted. So you can play this CTF variant like 'normal' without having to perform much cleanup. All the traits should be setup to where they will stack, unlike some other traits in other variants. So in One-Flag, the Defensive team could gain both Defense Traits and Aggro Traits. Likewise, Offensive team players within the Capture Bro radius could have both the Offense and Capture Bro Traits. I figured this would give better 'custom' gameplay.
  • There can be multiple offensive teams in One-Flag. If there's enough rounds as teams, each team should get a chance to play defense.
  • I tried to keep as many options as I could localized to other languages using what the game and other variants have used.
  • While you can't edit Defense Traits ingame, you could use something like Horizon (a game save editor) to tweak it. Its Halo4 and Reach game type editors are free to use without a subscription.


#45 User is offline   kornman00 

  • SourceGuy 2.0
  • Group: Administrators
  • Joined: 15-November 01


Users Awards

Posted 13 June 2013 - 09:51 AM

After about 8 weeks of development, I'm releasing an update today to KSoft.Tool for support for decoding/encoding game type (aka, game variant) files from HaloReach and Halo4. You may have heard of KSoft.Tool before, it's the same command line tool I released for modding Halo Wars archives. This release still has that functionality, but I haven't used/tested it in probably six months. So I can't say for certain that any changes I've made to the KSoft core haven't broken anything related to it.

Anyway, this tool will take a file with a game type blob nested in it and explode it into an .xml file which you can then use to edit the properties of that variant. Note that options/values which are considered 'default' won't be output to the .xml. This is meant as a means for saving space from repetitive or unused data. This is desired because this .xml data is meant to act as a project file of sorts for a GUI application which edits the data you see at a higher level (with proper bounds checking, etc). However, such works won't be made overnight which is why I took the evening to write this command line wrapper.

With that said, you can use Horizon's Reach/H4 game type editor to edit everything except MegaloScript-specific stuff in an actual UI. Though it will be missing some options which I have named in the .xml.

Another thing to note about this tool is that it is essentially a full debug build, and is thus inherently not optimal in speed or memory. However, you shouldn't be waiting longer than 2 seconds for it to decode/encode a game variant, even when using the non-optimial decode/encode switches. Since my focus isn't to develop a half-assed console app like this, but a program with an actual UI, I won't be making any updates to this unless there are problems which break usability with no possible work around.


Some basic information on MegaloScript:

You may wish to first read this post. Scratch that, you should first read this post about MegaloScript. At the end of the day, the best way to learn is by example. You can do this by decoding all the current Reach/H4 game variants and examining the data in their 'MegaloScript' XML element. However, for now I'll also provide some insight into MS in the context of how it is represented in my .xml.

MegaloScript is broken down into three operating constructs: triggers, conditions, actions.
  • Normal triggers are executed every game tick. All other triggers are executed as subroutines of normal triggers or are 'triggered' at specific points in the game's life cycle (eg, host migration). Normal triggers and subroutines are able to 'execute' on specific sets of data. Eg, all players, a all teams, an object filter, etc.
  • Conditions are operations which will permit the actions that follow it to execute should the condition(s) evaluate to true. Normally, consecutive conditions are evaluated as logical ANDs. Like Player0 != NONE AND Player1 != NONE. Those conditions are part of two separate unions. A new union group is created when 'unionGroupID="-2"' is encountered in a Condition's xml. However, when you wish conditions to evaluate in a logical OR fashion, you would use 'unionGroupID="-3"'. -2 basically means the parser should create a new union, -3 tells it to put the condition in the same union as the condition before it.
  • Actions are, as the name suggests, execute specific actions on the game simulation or MegaloScript data (eg, variables). Some actions have one or more 'output' parameters, ie they have a result(s). However, it should never be assumed that the result will have a valid value after the action executes, as most actions will return early if one of the parameters are 'out of bounds'. This is why you'll see temporary, or 'scratch', variables be Set to 0 or NONE before an action is executed. Were I releasing an actual compiler or editor, this kind of implementation details would be hidden from users like yourself. But not today. You're stuck with WYSIWYG.


Halo4 introduced something I call 'virtual triggers'. These are essentially triggers but without an contextual properties like execution mode or associated parameters. They are just composed of conditions and actions, that's it. Essentially a block of script code. Halo4 also introduced proper temporary/scratch variables. In Reach, if you wanted to have a variable to temporary hold some value you had to define a Global variable with no networking priority.

So I mentioned parameters for conditions and actions. Parameters can be fixed absolute values (eg, 'true', '5') or variable references (ie, references to data which aren't fixed). There are only five kinds of variables which can be referenced. Numeric (custom) data, Players, Objects, Teams, and Timers. A Custom variable reference refers to whole numeric data. There's no support for real/floating point values.

Besides the normal game engine options like 'score to win' and 'respawn time', Megalo variants can specify 'user defined options'. These are options you see under menus like "King of the Hill Options" in game. IE, they are options you provide to tweak the way the script is ran. Eg, CTF in Reach had a "Sides" option which would change the behavior of the script by spawning a flag for each team ('Multi'), spawning a single neutral flag ('One-flag'), etc. You may define up to 16 different user defined options, and with them up to 16 unique values which that option may be set to.

On the topic of engine/user options, the Megalo variant also has two lists for both which tell the engine if an option is disabled or hidden from view. In this version, I only support dumping these lists with the user options names. Engine options are specified by their parameter id.

So why does my tool poop out XML instead some kind of BASIC language or such? Well, because formalizing a scripting language, especially one you have no control over, takes time and research. It also takes time to write boilerplate parsers/compilers/decompilers. Which is why I went with a source-agnostic model/AST which I also support serializing to/from tagged documents like XML. The goal is to have a visual editor for MegaloScript a la Unreal's Kismet or bitsquid's Flow script (but not exactly like them, all of these scripts are DSLs and don't really share the same properties). However, the model I have for representing MegaloScripts would be very simple to create a compiler for should a formal language be crafted in the future.

But again, for the time being you're stuck with this low-level XML crap. Beggars can't be choosers.

In my XML, normal triggers (ie, non-subroutines or life cycle entry points), conditions, and actions support a "commentOut" attribute. Defining this attribute with 'true' will cause the construct to be skipped from the compiling process (and thus won't be encoded in the output). This is useful if you wish to disable a specific block of script which is still WIP or has effects which you don't want, but you don't want to also flat out remove the script data from the file. Note that if you wish to comment out a virtual trigger or a subroutine trigger, you can just define the commentOut attribute on the parent action.

Example variant xml (CTF)

#46 User is offline   kornman00 

  • SourceGuy 2.0
  • Group: Administrators
  • Joined: 15-November 01


Users Awards

Posted 15 June 2013 - 08:15 AM

It has come to my attention that you may need to install some patches in order for the tool to run on your system.

Patch for Win8
Patch for Win7

#47 User is offline   kornman00 

  • SourceGuy 2.0
  • Group: Administrators
  • Joined: 15-November 01


Users Awards

Posted 20 October 2013 - 06:15 AM

New version of KSoft.Tool has been released. This update improves the game variant tool support and addresses some script data debugging issues (still no line/column information, not something I can reasonably add right now).

This new version is incompatible with .xml files generated from previous builds.

Share this topic:


  • 3 Pages +
  • 1
  • 2
  • 3
  • You cannot start a new topic
  • You cannot reply to this topic