What happened to OC? - CLOSED Carnage?!

VoidsShadow

Member
  • Content count

    34
  • Joined

  • Last visited

  • Raffle Tickets

    0

Reputation Activity

  1. VoidsShadow liked a post in a topic by Takka in What the FUCK happened to OC? - CLOSED Carnage?!   
    What a shitshow... there's no way to tell this story without giving a lot of credit to whoever began DDoSing the forum, back in April of '22, but that was only the beginning of the drama that got us to this point. I unfortunately wasn't able to speak candidly about most of the events since the beginning of the attacks, but that's no longer an issue, so this thread will serve as the explainer.
     
    For those that don't want to read the drama dump that follows, the short of our current status is that the site is back and there are no plans to abandon it. However given the decline of forums in general, and due to the loss of trust that inevitably followed the long period of outage, loss of community data, and lack of transparency provided by myself, Open Carnage is not returning as a "live" site. OC is in a read-only state for the most part. For the next few months or so, existing members can edit their content if they wish to provide any updates that were lost. Anything on OC after April 18th of 2022 is otherwise gone.
     

    Discord Server
    Our Discord server has never been known for its modding discussions. It's served as a general chatroom for the long-time members of the OC community, and made it easy for anyone to keep up to date on new community content. That latter utility is effectively gone with the closing of the forum, and just about any subject for a Discord server can still keep friends together. So what's next? I don't know, but we'll probably try doing something new with it. I'll talk with you guys there!
  2. Takka liked a post in a topic by VoidsShadow in GameSpy (Resources & Working With)   
    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
  3. tarikja liked a post in a topic by VoidsShadow in Update: New map format being worked on. Thoughts?   
    # 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.
  4. VoidsShadow liked a post in a topic by Kavawuvi in Update: New map format being worked on. Thoughts?   
    The problem is that .map is such a generic file extension. Tons of programs use files with .map extensions. And the game even has bitmaps.map/sounds.map/loc.map which aren't cache files but a completely different format to the other map files. Yes, changing the header will prevent the stock game from loading it. This is something Chimera does. However, people still want the extension changed - something I'm implementing in a future Chimera update that's in the near future.

    It's worth noting that MCC no longer compresses the header, but these maps are still incompatible as they use a different base memory address (thus they will crash the game) despite using version 7.
     
    We did give this consideration a while ago. The problem isn't so much implementing it on a client but moreso having tools that build maps with these tags. While Invader can build maps, people prefer to use the stock tools to build maps. So to get more people to use this convention, you would have to write a program that patches a .map file with this metadata.
     
    Anyway, right now, the map downloader isn't going to download things that aren't incompatible with the client you're using. HAC2 users aren't going to get a map that requires Chimera. Rather, each mod gets their own type of file.
     
    As for getting the client to only download just the header, this is something we'd have to figure out with msalerno1965, as he's the guy who runs the repo. He'd have to modify his repo.
     
     
    This is a really good writeup and some really good ideas for a new format.
     
    However, now there's yet ANOTHER format coming, this time for MCC (version 13). I have no doubt that this will create even more confusion. Not only that, but it has more tag space and support for things that Halo PC doesn't support like monochrome textures. This, too, will be .map.
     
    I'm starting to wonder if the new format I was considering will even be worth it at this point.
  5. tarikja liked a post in a topic by VoidsShadow in Update: New map format being worked on. Thoughts?   
    # 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.
  6. Takka liked a post in a topic by VoidsShadow in GameSpy (Resources & Working With)   
    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
  7. VoidsShadow liked a post in a topic by aLTis in Vehicle controls with keyboard (SAPP Required)   
    This allows you to steer some of the vehicles using your keyboard instead of a mouse. This will not work on flying or hovering vehicles. The Chimera script will not work on a server unless the server has the sapp script. If people join the server without this script then they will probably warp a lot when driving vehicles. I haven't tested this in singleplayer but it might break some cutscenes where marines drive warthogs (I could fix this but can't be bothered).
     
    There are a few settings you can edit on both server and client scripts but the client's settings will be overridden by the server settings when you join a server.
     
    I would recommend not hosting a public server with this and just keep it for private gamenights or something.
     
    DOWNLOAD CHIMERA SCRIPT: vehicle_turning_chimera.lua
    DOWNLOAD SERVER SCRIPT: vehicle_turning_sapp.lua
  8. VoidsShadow liked a post in a topic by aLTis in Halo: Minecraft Edition   
    This is a campaign mod that adds some of Minecraft's features to Halo CE. You have 3 weapons and various blocks that you can use to build things. You can also choose from 16 player skins. Read the readme file for more info.
     
    Download:
    https://mega.nz/file/MTRUiZzY#SJ4EyIEo2l_yeHPFgflgNzC9PPAXMngnnoP_OsZHKKI
    http://www.mediafire.com/file/bg8gfjnx53ido90/HaloMinecraftMod1,1.rar/file
     
    Credits:
    aLTis - scripting and tag work Benji-Mod - some of the original tags (bow and sword) Kinnet - UI Vuthakral - help with the character model Refined Halo Development Team - some tag fixes Textures and sounds have been ripped from Minecraft Skins: reekid487, SkullBelly, ShaungJi123, Hellcraftjz, ElectroDr0p, Tin711, skad03, LordProtoTypeV3, Shempimite, Seileach, AliveR360, Johnny Joestar Testers: Kinnet, Reus, The Lobo, ShaungJi123, and others  
     
    BTW here's the lua script that's used in every map, someone may find this stuff useful idk a10.lua
  9. VoidsShadow liked a post in a topic by DestroyerDarkNes in Plugins For UdrakoLoader | Repository   
    In this Post I will be putting all the Plugins I do to UdrakoLoader
     
    How to Install a Plugin?
    Extract the Plugin (.dll) into the folder "UdrakoLoader", in the root directory of the game.   
     
    - Fake FullScreen Plugin .
     
    As in the HLPCE. this plugin does the same. With the It allows you to superimpose any application you want on top of the game in "Full Screen".
    It is very useful in my opinion, especially for developers.
     
    How to use?: You open the game in windowed mode and the Plugin will automatically do the rest. putting your game on "Fake Full Screen" .  
    Download :      FakeFullScreen Plugin.zip
    Source Code : Fake FullScreen @Github
     
    Preview :
     

     
     
    - FPSCounter .
     
    FPS counter, For multiple games | Plugin for UdrakoLoader
    UdrakoLoader works for multiple games, and so does this plugin! Currently Tested on SAMP and HALO CE and PC. 
     
    How to Install?:                        Extract the Plugin (FPSCounter.dll) into the folder "UdrakoLoader", in the root directory of the game. 
     
                          My PC is very low resources, do not be surprised by my FPS xD
     
    Activation: Automatic.
     
    Download :      FPSCounter.zip
    Source Code : FPSCounter @Github
     
    Preview :
     

     

     
     

     
     
     
     
    do you need help with something? , any suggestions? . Leave your comment or contact me on discord: Destroyer#8328
     
  10. VoidsShadow liked a post in a topic by DestroyerDarkNes in Halo Launcher for PC and CE [HLPCE] | Realses   
    HLPCE is a Launcher & Server Browser for Halo CE and PC.
     
    You can set the argument options.
     
    You can put your background photos, you just have to put your images in the folder "Background"
     
    As a special feature of this launcher, it has 3 window shapes for the game:
     
    -Windowed [Window mode]
    -Full Screen [Full Screen Mode]
    -Fake FullScreen [Full Screen False Mode] [Allows you to superimpose other applications [That have the TopMost property active] on top of the game]
     
    The program is not finished yet, it lacks more features to finish.
    If you have any idea / suggestion in mind, don't forget to comment!
    The multilanguage option. will remain in the future.
     
    ------------------------------------------------------------------------------
     
    v1.0 beta
    Firs Version  
    v1.0.3 Realse
    Fixed bug not updating players and player list. The bug that does not allow deactivating the checkboxes of the comandline options has been corrected. Fixed the Fake FullScreen function. Now it works perfectly. [Allows you to overlay other apps with the TopMost property, on top of the game.] Half Optimized the function that lists the servers. A Button was added in the Settings section [Force FullScreen] for when you are playing in windowed mode. Added the option to launch with Halo CE or PC.  
    v1.0.4 Realse
    Fixed All bug . The weight of the program was considerably reduced. The Multi-client Option was added [It allows you to open several instances of HALO] . Preview :   
       
     About the Multi Client :
    Fix bug in createProcess. and add the ability to run from any directory.            [LPCTSTR lpCurrentDirectory // pointer to current directory name]
    Converted to multilanguage API to call from .NET.
     
    Thanks to Oxide for the multi client source code.
     
     
    v1.0.5 Realse {The github source code has been updated to this version.}
    Errors were corrected and the application was optimized. Added superficial handling of Error Messages. [Crash Manager] Added Ability to Launch game from the launcher. (I mean to open the game directly for those who do not want to open a server), Preview:  
    ------------------------------------------------------------------------------
     
    Source Code : HLPCE | GitHub
     
    Download :  Current Version 1.0.5 Realse
     
     
    HLPCEv1.0.5.zip
  11. VoidsShadow liked a post in a topic by DestroyerDarkNes in UdrakoLoader | .Net Scripts Loader   
    Udrakoloader is a mod, Currently Compatible With SAMP and HALO [Possibly With many more games]. Provides the ability to load scripts (DLL) developed in .Net into the game.
     
    Based on ScriptHookvDotNet and SharpNeedle. Basically consists of CLR Hosting, to run the .Net plugins.
     
     
    Installation:
    Extract everything in the Root folder of the Halo CE or PC. | [ It will ask you to Replace the controls folder, you will say YES ]  
    How to use ?:
    Compile your .Net DLL and put it in the "UdrakoLoader" folder, then run your game. Remember that your DLL must have the code architecture that I will give as an example.  
     
    Some examples: [Compile DLL and put inside the "Udrakoloader" folder]
     
    For C# Plugins, you must provide the correct Namespace directory.

    In this case Replace "namespace ExampleProject.Udrakoloader" with "namespace <Your Root Namespace Project>.Udrakoloader"
     
    UdrakoLoader C# Plugin Example:
    // Plugin.cs using System; using System.Collections.Generic; using System.Diagnostics; using System.Linq; using System.Text; using System.Windows.Forms; namespace ExampleProject.Udrakoloader { public class Plugin { public static int EntryPoint(string pwzArgument) { string processName = Process.GetCurrentProcess().ProcessName; MessageBox.Show("C# Example | The current process is " + processName); return 0; } } }  
    UdrakoLoader VB Plugin Example:
    'Plugin.vb Imports System Imports System.Collections.Generic Imports System.Diagnostics Imports System.Linq Imports System.Text Imports System.Windows.Forms Imports System.Reflection Imports System.Runtime.CompilerServices Imports System.Runtime.InteropServices Imports System.Security Namespace Udrakoloader Public Class Plugin Public Shared Function EntryPoint(ByVal pwzArgument As String) As Integer Dim processName As String = Process.GetCurrentProcess().ProcessName MessageBox.Show("vb Example | The current process is " & processName) Return 0 End Function End Class End Namespace  
    Attention:
     
    The .net DLLs must be compiled under the .Net Framework 4.0. The name of the Plugin DLL must be the same as the Root Namespace.
    Example:
     

     
     
    They can be guided by this example: SAMP Dll Injector
     
    Do not forget to comment and if you have doubts or cannot make it work, you can contact me at my discord: Destroyer#8328
     
    I do not ensure that it works in 64 bits. and this is for windows only.
     
    I don't take credit for this for the following reasons:
    Most of the code is from the SharpNeedle project, Modified with parts of ScriptHookvDotNet for more compatibility.  
     
    Download NEW : [Bring the example DLLs, which I already put the code above.]
     
     
     
    Udrakoloader For HALO NEW.rar
  12. VoidsShadow liked a post in a topic by Kavawuvi in Update: New map format being worked on. Thoughts?   
    So, first test! I want to see how well 64 MiB works on people's systems.
     
    As such, I've compiled a release of Chimera that increases the tag space usage. You shouldn't need any LAA patch for this to work, but if you do, let me know.
     
    Download: chimera-1.0.0.r698.44ada2d.7z
     
    I also got a couple questions asked from people:
     
    Does this mean Chimera will support Open Sauce maps?
    No.
     
    What does this mean for people who don't have Chimera (such as HAC2 or OS users)?
    The map format should be fairly straightforward to implement, and if I do this, I'll post documentation. I'm not planning on adding any tag extensions in the vein of Open Sauce.
     
    Anyway, if it works, let me know. Or if it doesn't, let me know. You'll know it didn't work if the game presents a "Can't allocate memory" sort of error message from Halo.
  13. VoidsShadow liked a post in a topic by Kavawuvi in Update: New map format being worked on. Thoughts?   
    I'm working on a new map format that is intended to solve a few problems:
    Halo's tag space limit is only 23 MiB Halo is fragmented into different versions, with what seems like around 25% of the player base on the retail Halo PC version and the rest on Custom Edition Halo has some tag data features locked away that requires mods to fix, namely PCM audio and 32-bit environment textures Halo has an issue where indexed tags count towards the limit, resulting in potential crashing when using non-English loc.map files from certain languages of the game if you are close to the tag space limit when building for English The new format we're coming up with should aim to alleviate these issues. These are the following features being devised:
    Extended tag space (23 MiB ---> 48 MiB or 64 MiB depending on what we can get Halo to load successfully without an LAA patch through further testing) In all honestly, unless you have an excessively large BSP, it's unlikely that most maps will exceed 48 MiB of tag space All clients that load these maps support PCM audio and 32-bit environment map textures, giving you the option for the best quality textures and audio All clients that load these maps will also support indexed tags properly without it counting against the tag space limit Maps will work on both demo and full version (including both the retail Halo PC release and Custom Edition), with two separate "blobs" for each Each tag "blob" shares raw data and model data, so only BSPs and tag data have to be different between blobs This means tag data will be twice as large, but zstandard should mostly alleviate this issue If loaded on Custom Edition, ting volume and stun values are automatically fixed All stock multiplayer maps are indexed and CRC32'd, ensuring they will work over the Internet if joining a server provided that all tags are present and accounted for As for enabling this, you will need to ensure you have Custom Edition resource maps present. If you are on Halo Custom Edition, you already have that. If you are on the retail version of the game or the demo version, refer to this topic:
    I wanted to put this here before I started releasing tools that actually let you build these maps. I don't imagine I'll actually receive very much input about this, but I figured it was worth a try.
     
    It's worth noting that it isn't difficult to implement these things. Other mods are welcome to implement these changes, and if I do finish this, I'll document as much as I can about it.
  14. VoidsShadow liked a post in a topic by MrChromed in Update: New map format being worked on. Thoughts?   
    I totally agree with all of this! Especially when it comes to the extended tag space limit thing. We've been developing an entire Forge mode for Halo CE by using scenery objects, and with hundreds of objects in-game, we're running out of tag space (23MiB). That's preventing us from porting new objects (since we also have some plans of having a "season-like" system to provide fresh and new content/assets to this project by using an updating system we've been developing to avoid the necessity of uploading new map builds everytime. So any expansion to the stock 23MiB limit will be REALLY useful for us.

    Here's a pic btw:

  15. Sunstriker7 liked a post in a topic by VoidsShadow in Halo Launcher for PC and CE [HLPCE] | Realses   
    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.
  16. VoidsShadow liked a post in a topic by aLTis in Third Person Camera   
    This script allows you to play in third person. You can use hotkeys on the mouse and numpad to toggle and move the camera. Open the script in notepad to customize it.
     
    The script requires a chimera version that supports scripting (-581 or 1.0). Drop it in Documents\My Games\Halo CE\chimera\lua\global
     
    Current version: 2021-03-07
    DOWNLOAD: third_person_camera.lua
     
    2021-01-09 changes:
    small fix for maps compiled using Invader  
    2021-01-09 changes:
    fixed some issues related to the second reticle (red dot) fixed ammo icon appearing on the player in blood_covenant map fixed some issues related to scripts getting reloaded while in third person  
    Features:
    A console command to enable/disable third-person camera: tp 1 / tp 0 Should work in all maps, even if they are protected Camera position customization: allows you to change where the camera is (open the script with notepad) Third-person camera zooming: doesn't switch to first-person when you zoom (optional) Dynamic reticle. Adds a lens flare that shows where your shots will actually land. Works in most maps (optional) Bigass V3 dynamic reticle: moves the reticle where your shows will actually land Player animation fixes: fixes most animation glitches that happen in multiplayer (optional) Camera shake removal: no camera shake when firing weapons (optional) Compatible with fp legs script Known issues:
    The dynamic reticle is delayed and doesn't look that good in most cases There might still be some animation glitches Sometimes reloading animation doesn't play at all In rare cases you can see explosion lights where the dynamic reticle is
  17. Kavawuvi liked a post in a topic by VoidsShadow in Chimera Controller Config Bounties (Raffle Tickets!)   
    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.
  18. VoidsShadow liked a post in a topic by aLTis in HUD sway   
    This script will move the HUD when you aim, walk sideways, jump, etc. Works on all maps even if they are protected. Should work fine with HAC2 and Chimera widescreen fixes.
     
    DOWNLOAD: hud_sway.lua
  19. blueblob0 liked a post in a topic by VoidsShadow in Borderless windowed or windowed 1920x1080   
    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.
  20. blueblob0 liked a post in a topic by VoidsShadow in Borderless windowed or windowed 1920x1080   
    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.
  21. blueblob0 liked a post in a topic by VoidsShadow in Borderless windowed or windowed 1920x1080   
    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.
  22. VoidsShadow liked a post in a topic by Kavawuvi in Update: Chimera as a server mod?   
    I’ve been getting a few questions about Chimera as a server ever since I’ve announced that I was looking into making it into a server. I figured I’d address them here, too.
     
    I don’t like to announce things before I do them because that sort of makes me obligated to do exactly what I said, so I’ve tried my best to word things as if it’s merely planned and not promised. I could, for example, get hired for a job and stop working on Halo stuff forever, or I might simply decide not to do this anymore. Or I could tragically get hit by a bus unexpectedly, and while I do hope that doesn’t happen any time soon, I try to make as few promises as possible. So, yeah, take everything I say with a grain of salt, as always, until you can run what I'm saying on your own PC at least. This is the best way to not get disappointed with expectations - by not expecting anything at all!

    What features are planned?
     
    Chimera already has a number of bug fixes, so it only makes sense that the server should have bug fixes, too. These bug fixes include fast loading and weapon spawn timing being fixed.
     
    In addition to bug fixes, some extra features have been added such as the option to use Xbox equipment rotation, the option to delete empty weapons, and access to some of Chimera’s ini options such as the initialization options. There are also a few debug commands such as basic teleportation which “just work” on the server.
     
    Also, for Lua scripting, I imagine that many scripts that work on the client will work on the server since I'm not planning on changing the scripting API. However, some features may work differently, and there may be some events that won't work. Therefore, if your script requires features that only work on the client (e.g. camera control), I recommend checking, in your script, what version of Halo you're running.
     
    Refer to the to-do list for the planned list of features, though note that I have more ideas than what are listed here: https://docs.google.com/spreadsheets/d/1WzUCMm99xvPDXumGyC4tmmWb_BmJ-ZR-caQUcdAfeRk/edit#gid=0
     
    And, of course, you have the option to use the mods folder for loading additional DLLs just like you can with the client. Note that any mods you load will be unsupported by myself, of course, but the option is there if you want it.
     
    Will there be a readme?
     
    A readme is already included with Chimera, and you can also view this online on GitHub: https://github.com/Kavawuvi/chimera/blob/master/README.md

    How does Chimera compare to SAPP?
     
    This is a question I get asked the most. Similar to how Chimera is not and never has been or will be a direct replacement for client mods such as HAC2, Chimera is also not a direct replacement for other server mods such as SAPP. This will not change.
     
    SAPP has features such as its easy-to-use custom events and commands system which Chimera will not include. SAPP also has a very robust admin system which, again, Chimera will not include. And, of course, SAPP includes a number of other heavily used features such as scrim mode, aimbot detection, and a wealth of fun “naughty” commands which, again, will be absent from Chimera.
     
    All-in-all, besides Lua scripting, bug fixes, Chimera’s existing features, and, of course, support for Wine, there really isn’t much planned for Chimera as a server. In fact, there won’t even be auto updating just like with the client. And, of course, updating Chimera requires restarting the server unlike SAPP which can be replaced in the middle of a game if desired.
     
    I know a few of you wanted an open source SAPP option of some kind, but the truth is that I’m just not interested in making a SAPP replacement. Obviously, people who want SAPP want an option that provides lots and lots of features out-of-the-box, so I imagine most get SAPP for its utterly titanic wealth of features. Why should I take so many hours to give you basically the same thing? After all, I highly doubt most people even care about the fact that Chimera is open source when it comes to considering their choice of mod, and I don’t blame them.
     
    Chimera, on the other hand, is intended for people who want to tinker with or fix Halo, and the goal is to provide a lean but open source option with a powerful Lua scripting engine to boot. Anything extra is added through Lua scripts.
     
    When will this be released (if it does)?
     
    I don't know. After I finish Lua scripting at least?
     
     
    I hope these answer most people's questions. If you have any further questions, feel free to comment below. Don't expect any further updates regarding Chimera as a server until I have something tangible to show you.
  23. VoidsShadow liked a post in a topic by Kavawuvi in Update: More Lua information   
    As of today, I've started implementing the new Lua API, so I'm going to discuss that in this topic.
     
    First of all, for the API, itself, there are a lot of changes being done in here, with the inclusion of dozens of new functions and callbacks that have been planned. Most of the read_*/write_* functions are the same, but how callbacks are set is mostly different, and some functions have been changed. Scripts that target this API, therefore, will require this to be set:
    clua_version = 3.0 Also, an optional global can be set in addition to this to run a function immediately after initializing. This will allow Chimera to check the Lua API version before executing anything else.
    clua_init = "OnScriptLoad" As you can guess, version 3 of the API, itself, is not backwards compatible with older scripts (which use version 2), meaning you'll have to use the older API for these scripts.
     
    Which brings me to the next point: How Lua scripts are loaded is now slightly different, and it uses the chimera.ini to determine which scripts to load automatically. Here is an example (commented) configuration:
    [lua] ;=============================================================================== ; Lua initialization settings ; ; This is used to configure Lua ;=============================================================================== ; Set whether or not scripts, by default, are loaded automatically without ; needing the `chimera_lua_load` command. By default, this is disabled. ;autoload=true ; Set whether or not Lua scripts compiled into maps are supported. ;internal_map_lua=true [lua.scriptname] ;=============================================================================== ; Example Lua initialization settings for "scriptname.lua" ;=============================================================================== ; Set whether or not the script can be loaded automatically without needing the ; `chimera_lua_load` command. If unspecified, use the global "autoload" setting. ;autoload=true ; Use an older API (by default, the latest version is used) ;   3 = Chimera 1.0's Lua API ;   2 = Chimera -5XX's Lua API ;backwards_compatibility=2 This does alter how you load scripts. Instead of merely copying the scripts into the scripts folder, you also need to indicate in your ini whether or not you want to automatically load. You can still use the older behavior of loading everything automatically, but you have to set that, yourself. Also, since the newest API is not backwards compatible, you need to specify which API you want to use if you want to use something that is not the latest version of the API.
     
    For example, if you wanted to install the fp_legs script, then you would copy it to the [Halo's -path]\chimera\lua\global folder as usual, but you also need to put this in your chimera.ini:
    [lua.fp_legs] backwards_compatibility=2 If you don't do this, then it will try using the latest version (version 3) of the API of the Lua API and you'll get an error.
     
    For scripts that use the latest version of the Lua API, you do not need to put anything in chimera.ini unless you want to configure how scripts are automatically loaded.
     
    Also, Lua version 5.4.0 is used, and this was released last month. These are the main changes from the Lua readme:
    Lua version 5.4.0 is used regardless of if you use the older or newer API. Simultaneously including two versions of Lua is infeasible, and the differences are likely not significant enough to break any existing scripts.
     
    Note that everything in this topic is subject to change as I'm still at the start of working on this, and it may be a while before you see a Chimera build with Lua scripting. If anyone has any questions, feel free to reply here.
  24. VoidsShadow liked a post in a topic by Zatarita in SeT - sdk   
    SeT
    Saber editing Toolkit is a set of python scripts dedicated towards editing saber files.
    While i was working on SuP, i realized that the path I was going down would limit the abilities I have to work with the data. I decided I would migrate to a more generalized toolkit, and use this as a backbone to program a more versatile set of tools. I intend to write a full SEK for editing saber files once I have fully mapped out the structures. hopefully, this may be useful to others who would like to create their own modding tools as well. It will be an ongoing project until everything is mapped out.
     
    The github has a readme that explains how to use it. Basically it allows programmatic access to the contents of saber files saving others the stress of having to reinvent the wheel every time they want to make a modding program.

    https://github.com/Zatarita/SeT

    Currently I have s3dpak, ipak, fmeta, imeta, TexturesInfo, and SceneData defined; however, ipak, and imeta are partially implimented.
     
    I am willing to accept any help if you wish to contribute to the project. join the discord for smaller updates. major updates will be brought to this post. You don't have to be a programmer to help! Anyone willing to poke around with a hex editor can be a big help c:
  25. VoidsShadow liked a post in a topic by Kavawuvi in Dark Circlet   
    Here's a progress video for the past month.