VoidsShadow

Ah, good to know! Yeah. It's a shame the CEA map formats aren't being versioned well. People prefer the stock tools for two reasons: 1. The stock tools are more "searchable". This is because... 2. They have a long history of use and documentation in the form of tutorials, and–therefore–community support. Only a polished product offering the same features and more in addition to documentation and tutorials will be able to overshadow the usefulness of the stock HEK. Even then, the only way it could become well-known is if news outlets pick it for a story. For that to happen, Invader needs to be impressive. Very impressive. A well-though-out and extensible format will solve a lot of headaches in the future.

# Issues There are several issues with the way non-vanilla map formats are being created and distributed. 1. End-User File Transparency - Vanilla maps already have this issue. Xbox, Trial, Retail, Custom Edition, and MacDemo engines all use the same filename extensions despite their maps using different, incompatible formats. - OpenSauce has a .yelo filename extension for maps that have a non-standard format. However, it also uses the .map extension for maps that the engine can run without OpenSauce installed at the cost of the map's OpenSauce features not working. This allows maps to work, but not as the map-maker intended. - Compressed .map files made for CEA or by Invader for the classic PC ports. Again, file transparency. CEA uses/used a similar file format as Custom Edition, but it compresses the file header, making it incompatible with the engine version indicated in the header. Invader compresses the map data, but this too creates .map files that are incompatible with any engine that can run .map files out of the box, without Chimera or some other plugin. What are some ways the user can be informed of a map file's prerequisites? A new file name extension, file header changes, et cetera. How can we display the map header to end-users? A file format API/SDK may be necessary for other developers to add support for this file format to their applications (mod and map managers, server applications, et cetera). The API/SDK could then be wrapped or rewritten for different languages as needed. However, that contribution would be the responsibility of developer-users, not maintainers of the file format. 2. Format versioning. After file transparency is resolved, format versioning would be the next issue. However, jamming every prerequisite into a filename and extension would be ridiculous. If OpenSauce did this, we would have .yelo, .yelo1, .yelo2, et cetera. Then what if the .yelo format is extended to Halo 2 maps? CE Retail? Trial? At best, the major version of the file format should be included in the filename's extension to indicate compatibility-breaking changes. In addition to this, I believe this new format needs both a format version and a feature set list (see Feature Flags). This concept is similar to the way DirectX and OpenGL feature support is stated and handled by GPUs and their drivers. They indicate support for both API versions as well as individual feature flags. Likewise, a map's format version should indicate a standard of core features while feature flags indicate individual features, including potentially non-standard extensions to the format. To be honest, that last part worries me as we can only hope feature flags are supported by publicly shared plugins. Again, See Feature Flags for more info. ---- # Feature Flags Metainfo in the file header indicating features required for the map to work as intended. Note: Feature flags may be redundant if only used to indicate features already indicated by the format version. They would be more useful to indicate non-standard features as well as inform the user of the plugin(s) required to support said features. This should allow for a more extensible map format at the cost of file compatibility transparency to end-users. (See File Transparency above) 1. Plugins that are made to work with this proposed file format will first need to be told how to handle a base set of features (those that are part of the file format's specifications), then know how to deal with unsupported/unrecognized feature flags (format extensions). 2. One issue that may arise from Feature Flags is the requirement of privately-shared plugins to support a feature while the map file itself is public. Although these unrecognized, non-standard feature flags could be handled by plugins, it would suck to have maps floating around that require a privately shared plugin to work at all. 3. Another issue is how these maps would affect multiplayer map-downloading experiences. How would the client handle an unsupported map without first downloading it? For many rural and developing countries, downloading large files that can't be used can be problematic. This could be resolved by transferring the map header first, but only if the isn't supports that in the first place 4. Lastly, how would someone know which plugin(s) they need to get in order to support a feature flag? See File Transparency. 5. How do we differ between standard feature flags and extension feature flags? Perhaps compiler could enforce a naming scheme for feature flags e.g. std_tagspace, ext_PBR 6. How do we handle extension feature flags that are beginning to be used as often as standard feature flags? Hopefully, the developer of the extension feature flag would agree to and help integrate it into the standard format specifications These six issues need to be addressed before this feature can be added to this map format's specifications.

FYI, the GameProgressive organization on GitHub maintains the most active fork of the GameSpy/OpenSpy SDK as well as a GameSpy server emulator. SDK: https://github.com/GameProgressive/UniSpySDK Server emulator: https://github.com/GameProgressive/UniSpyServer Docs: https://github.com/GameProgressive/GameSpyDocs

The application crashes after partially loading the GUI. Debugging reports a lot of Illegal instruction - code c000001d and Integer divide-by-zero - code c0000094 I'll try compiling a debug build from source to figure this out. EDIT: I'm having trouble compiling due to a missing dependency reference to Guna.UI (not to be confused with Guna.UI2). I've DMed Destroyer about this.

I suggest you take a look at HXE, the library/executable SPV3's launcher is built on. You may save time if you choose to go the route of parsing player profiles and related files. HXE also handles passing parameters to HaloCE.exe (not Halo.exe, yet. We'll work on that later). I plan to add the ability to configure game and profile settings for player profiles so it will have equivalent functionality to Halo's Settings menu.

It seems I was already using that version.

When paired with SPV3, there is no "unzoomed" state. When the player has a zoom-capable weapon, they are forced to use the first level of zoom or the second level, but they cannot unzoom completely.

I use HXE for borderless mode. It works around Halo's window resolution limitation by subtracting the window frame's pixels from the native resolution. So, 1080p borderless is actually around 1060p. By default, HXE will just start the game, so you have to create a shortcut to it to add `--config` to open the GUI. You can also just start with via a command line terminal (PowerShell, PowerShell Core, Command Prompt, Bash, et cetera). Downloads are here. Newer versions are available (0334), but the list hasn't been updated for a while. Miris has been notified.

Damn. If I only I was active in this community when I still played Warframe.

Summary: Razer Serval can be treated identical to an Xbox 360 controller after Razer Synapse 2.0 is installed. Razer Serval (Optimized for Android OS) Xbox-styled with two extra buttons for Android usage. * Requires Razer Synapse 2.0 for triggers to work correctly on Windows else Z-axis will bind to R-Stick horizontal axis and Z-rotation will bind to R-Stick vertical axis. After drivers are configured, there are three axes, ten buttons, and an 8-direction POV hat according to Windows' game controller joy.cpl applet. Listed as an Xbox 360 controller in Device Manager. The Android buttons are remapped as extra Back and Start buttons. The power/Guide button is no longer mapped. There are 10 buttons However, LT and RT are now mapped to the Z-axis. R-Stick is now mapped to X-axis (Horizontal) and Y-axis (vertical). Button IDs are changed to match a standard Xbox 360 controller's IDs. Should I try getting my Xbox 360 Kinect working on Windows again? That would be a really stupid and pointless endeavor especially seeing as it wouldn't translate well to the button press strings.

nb4 "why not just replace it with Xbox buttons?" 1. Dualshock gamepads do not have Xbox buttons. 2. Switch JoyCons and gamepads don't have Xbox buttons. 3. Only some controllers have Xbox buttons. Currently, the most popular way to inject images into the game's memory is via DirectX API calls. This is what HAC2 uses for medals and chat emotes.

Does this support OS DLMs?

Chimera downloads maps from the HAC2/HaloNet maps repository. The bandwidth bottleneck may be on the server's end, but I do not know for sure.

Chimera 1.0 dropped support for HAC2 and Open Sauce.

An unofficial release of Optic has been posted here on OC! This version is seemingly compatible with Chimera 1.0 which is great since Chimera will no longer make an attempt to be compatible with HAC2—even the new HAC2 (I think?). This old, non-HAC2 version of Optic will be useful up until Chimera's Lua API is re-implemented after 1.0 is released.