Java

Member
  • Content count

    162
  • Joined

  • Last visited

  • Raffle Tickets

    0

Reputation Activity

  1. Enclusion liked a post in a topic by Java in Buttery Smooth: Upgrade Your Encoding Class   
    Awesome work!
     
    Now time to find the maps that have sync issues with this.
  2. Java liked a post in a topic by Takka in Funny Pictures and Videos (one per post)   
  3. Java liked a post in a topic by tarikja in Funny Pictures and Videos (one per post)   
    Merry Christmas :v
     
  4. Java liked a post in a topic by Takka in Funny Pictures and Videos (one per post)   
  5. Java liked a post in a topic by Vaporeon in Buttery Smooth: Upgrade Your Encoding Class   
    Wow, great find. Well done.
     
    I only wish it was known sooner, MCC has eaten into the Gearbox port playerbase without having the same kind of modding capability.
  6. Java liked a post in a topic by PiRate in Buttery Smooth: Upgrade Your Encoding Class   
    NOTE: No client changes are performed; the code to handle all of this is already in the clients.

    When a server issues a challenge to a connecting client, it also informs that client of the encoding class to be used for communication.
    The encoding class determines the number of bits used to encode certain fields; sightjacking and spectating fall victim to the encoding class used for public servers, but we can get buttery-smooth results if we force the encoding class:
    (The player that recorded this footage had ~200 ping to this server)

    TECHNICAL DETAILS
    It is a common misconception that the global sv_public only controls whether or not the server advertises on the master server list; it also used to select the encoding class and connection class (determines throttling limits).
    sv_public 0 sets the encoding class to the LAN encoding class in addition connection class four, the effects of which are demonstrated above. sv_public 1 sets the encoding class to the internet encoding class. The attached script effectively forces sv_public 0 only for the purposes of determining encoding and connection class - the global is not modified and when used for other purposes (e.g. determining whether or not to advertise on the master server list) sv_public behaves as normal.

    The changes have the following effects on encoding behaviour (from internet to LAN encoding class):
    angular_velocity number of bits per component increased from 16 to 31 (fixed-width encoding in range [-8, 8]) relevant fields: equipment_update.angular_velocity vehicle_update.angular_velocity vehicle_new.angular_velocity projectile_new.angular_velocity equipment_new.angular_velocity local_player_vehicle_update.angular_velocity remote_player_vehicle_update.angular_velocity remote_player_total_update_vehicle.vehicle_data.angular_velocity translational_velocity number of bits per component increased from 16 to 31 (fixed-width encoding in range [-100, 100]) relevant fields: projectile_update.translational_velocity equipment_update.translational_velocity weapon_update.translational_velocity vehicle_update.translational_velocity vehicle_new.translational_velocity biped_new.translational_velocity projectile_new.translational_velocity equipment_new.translational_velocity weapon_new.translational_velocity local_player_vehicle_update.translational_velocity remote_player_vehicle_update.vehicle_data.translational_velocity fixed_width_normal_8bit number of bits for theta (pitch) increased from 8 to 20 resolution improved from ~0.7 degrees to ~0.00017 degrees number of bits for phi (yaw) increased from 8 to 20 resolution improved from ~1.4 degrees to ~0.00034 degrees relevant fields: vehicle_update.forward and vehicle_update.up vehicle_new.forward and vehicle_new.up biped_new.forward and biped_new.up projectile_new.forward and projectile_new.up equipment_new.forward and equipment_new.up weapon_new.forward and weapon_new.up local_player_vehicle_update.forward and local_player_vehicle_update.up remote_player_action_update.facing_vector super_remote_players_action_update.facing_vector remote_player_vehicle_update.forward and remote_player_vehicle_update.up remote_player_total_update_biped.action_data.facing_vector remote_player_total_update_vehicle.vehicle_data.forward and remote_player_total_update_vehicle.vehicle_data.up fixed_width_normal_16bit number of bits for theta (pitch) increased from 16 to 20 number of bits for phi (yaw) increased from 16 to 20 relevant fields: item_accelerate.direction field type: locality_reference_position position is always encoded as an absolute position, rather than conditionally switching between a small-distance delta and absolute in the best case, improves the resolution per component from 1/64 ingame units to 4.7e-7 ingame units this change should drastically reduce the jitter observed when used with remote_player_position_update_rate 0 and similar configurations servers running HUGE maps may not want this patch, because absolute position has a range of [-5000, 5000] per component in the worst case, increases the number of bits per component from 25 to 31 relevant fields: projectile_update.position vehicle_update.position projectile_new.position local_player_vehicle_update.position remote_player_position_update.position remote_player_vehicle_update.position remote_player_total_update_biped.biped_data.position remote_player_total_update_vehicle.vehicle_data.position  
    WARNING
    I do not often program in lua, so there are probably a few errors.
    This script should be loaded in as early as possible (e.g. in an init.txt) so that the code paths that are targeted are patched before the process runs through them.
    This script increases the amount of data sent and received, but the amount is probably marginal by today's standards.
     
    For admins: this script will make packet loss and throttling stand out like a sore thumb when players are turning; do not assume a player is aimbotting on the sole basis that their aim presents a lot of jerks.

    CREDITS
    Vitor, for helping me test this, providing video, and general support.
     
     
     
    buttery_smooth.lua
     
  7. Sunstriker7 liked a post in a topic by Java in Make your own hit sound melody optic pack   
    Time for Toto - Africa mwhaha
  8. Sunstriker7 liked a post in a topic by Java in Make your own hit sound melody optic pack   
    Time for Toto - Africa mwhaha
  9. Java liked a post in a topic by mouseboyx in Make your own hit sound melody optic pack   
    I used an optic pack by Devieth for some of the functionality in script.lua.
     
    The default melody is the intro to Cannon in D.  I've included a JavaScript app that will convert guitar tabs to be used within the script.lua.  Convert the tab and replace melody={...} in script.lua with the line generated by the converter.
     
    The sound samples are simple square waves generated by audacity, starting at 82hz then incrementing by semitone up to 2637hz, using this pattern you can replace the samples with your own if you want to.  I would recommend a sample length of 0.150 seconds to 0.250 seconds.  The lower the better to avoid backing up the sound playing api.
     
    release_melody.zip
  10. Vaporeon liked a post in a topic by Java in Spark Edit - Scenario Editor   
    Yep most def, but does give some insight on map geometry and rendering 
  11. Java liked a post in a topic by fable law 458 in Halo: CE 3ds Max Basic Modeling Tutorial (2022)   
    Hello everyone, It's me fable again, I just wanted to share another tutorial I've made on how to model a basic halo level using 3D Studio Max. Please be aware this doesn't cover on how to use the halo mod tools, if you want to learn more about those watch part of the Blender video that explains the halo mod tools and what their purposes are, check out part of the blender tutorial video below to learn more. I hope you guys find this helpful as a refresher or if your someone who's new to Halo modding.
     
    3D Studio Max Modeling Tutorial:
     
     
    Halo Mod Tools Tutorial + Blender Modeling Tutorial:
     
     
    Happy Halo Modding,
    -fable law 458 
  12. Java liked a post in a topic by Vaporeon in Spark Edit - Scenario Editor   
    It's amazing how much it does considering when it was released.
  13. Java liked a post in a topic by mouseboyx in (Development Example) Call C from Chimera Script   
    This script itself does nothing to extend the client.
    If you're not looking for a development example I would not recommend downloading and running this script.
    The code is really only a boilerplate of basic calls for someone to use as a starting point if they want to learn or figure out how to call C functions from a chimera lua script.
    I spent days trying to figure out how to do this, so I wanted to share the fruits of my labor in case someone else wants or needs this example.  I still don't fully understand how it works, but I know that the code runs.
     
    The instructions for calling C from lua are included in the readme.txt in the zip.
     
    https://www.lua.org/pil/24.htm
    Is a good starting point to learn more about how to call C from lua.
    chimeralib.zip
  14. Vaporeon liked a post in a topic by Java in Spark Edit - Scenario Editor   
    Yep most def, but does give some insight on map geometry and rendering 
  15. Java liked a post in a topic by AntiMomentum in Halo server use/management - Bash Linux -update   
    Those running halo servers in Linux might fight this interesting. As you are aware the halo server console takes up the cli terminal while it's running. There are ways around this such as using Docker, screen, tmux, and more. And people running multiple halo servers in Linux have defintely run into this issue in the cli.

    But there is another way, nohup

    It's probably already in your debian, centos, other major distro if it's not a minimal build too

    By using nohup and aliases we can not only get the terminal back, run multiple halos from one terminal without extra stuff, but we can even issue halo server commands *from the terminal*

    Other uses include being able to tail the in game chat from the halo console output to look for cheat complaints, and possibly setting up an alert system:

    https://github.com/antimomentum/haloce/tree/master/wine/nohup-aliases


    *update*

    At the bottom of the github README I've added an example remote setup to view the halo console from a web browser
     
  16. Java liked a post in a topic by Takka in Donor Acknowledgement   
    @giraffe has donated his raffle winnings!
  17. Java liked a post in a topic by Takka in Donor Acknowledgement   
    @Sceny has donated his $50 of winnings!
  18. Java liked a post in a topic by Sceny in SoTM Submissions   
    Its a good time to download and replay Genital Jousting.
  19. Java liked a post in a topic by Sceny in SoTM Submissions   
  20. Java liked a post in a topic by iTails in "Everything's fucking shit" Thread   
    My rant of the day: 
    1. Broke my Red Hat Satellite server with a major release version upgrade attempt, worked with support and ran out of time to finish troubleshooting before our last maintenance window. Team agreed it was probably better just to restore from backup, resync packages, update content views and call it done. 
    2. Our backup and recovery team not only had us in the wrong backup policy, but also had our only backups going to AWS S3. It took over 9 hours to pull down.
    3. After backup and recovery team restored it on their vmware cluster, they attempted to migrate it. After an hour and a half the migration was only at 31% complete. I had to cancel the maintenance window and get an earful by upper management about it. By this point it was midnight and told them just call me when the restore migration is complete and I can log into my shit. 
    4. After all that time, it failed at 90% after 7AM. They told me they would restore and migrate it a different way. 
    5. About noon they tell me the server is back up. I log in, try to do the thing, server still fucked up. They ask me if I want to try the restore again and I tell them to fuck off and let me handle it. 3 days later, I have it fixed.
    6. The kicker... talking to someone who double-checked the backup team's work, they not only downloaded the VM snapshot from the wrong date from AWS S3,  but they also used the most recent backup to restore, not the date we requested. 
  21. Java liked a post in a topic by ShikuTeshi in September 2022 - SoTM Voting   
    Congrats to @Java!

  22. Java liked a post in a topic by Vaporeon in Spark Edit - Scenario Editor   
    Glad the source is still around, even if the tool itself has been surpassed.
  23. Java liked a post in a topic by Kavawuvi in Differences between Halo PC and CEA map files   
    I thought I would put here that this guide is now a bit outdated.
     
    They have cache version 13 in the header (0x000D) and the tag data address is 0x50000000. They also no longer use compression of any kind, so they are clear to read in a hex editor or with Eschaton.
     
    Otherwise they are still really similar to the retail Halo PC cache files, being that the game is based off of it rather than them opting to use code or features from Halo Custom Edition.
  24. Java liked a post in a topic by Kavawuvi in Differences between Halo PC and CEA map files   
    I figured that here would be a good place to put this here.
     
    Before someone asks for the difference between Custom Edition maps and CEA map files: aside from the ability to load tag data from external map files and different versions in the header, they're the same format as retail, so besides those two minor differences, all differences below also apply to Custom Edition maps.
     
    All of this information has been found from my work with Invader.
     
    Map Files
     
    Anyway, starting with the map file, itself, cache files are stored as 0x20000 byte (128 KiB) chunks which are each compressed using Deflate. This will signficantly negatively impact compression ratios, but it allows for threading for both compression and decompression.
     
    Unlike Xbox maps, the header is also compressed, so it is not possible to even identify a map file as a map file without decompressing it. The first number in the compressed file is a count (32-bit integer), followed by an array of file offsets to each block (32-bit integers). Each block is a size of the block when uncompressed (32-bit integer) followed by the Deflate stream. Using this, you can get the decompressed size by adding up the sizes.
     
    You can use Ceaflate to decompress and compress these files, but if you intend to use the map files with Invader, do not use Ceaflate to decompress them. Invader handles it automatically.
     
    Once you've got a decompressed map file, you may notice something: like retail maps, the engine version is 7, though the build string is different (01.00.01.0563 instead of either 01.00.00.0564 [maps that came with the retail disc] or 01.00.00.0563 [ui.map that came with the Halo PC dedicated server]).
     
    However, there is one key difference that will prevent many tag parsers from accessing the tag data in the map: the tag data address. Halo PC uses 0x40440000 and Halo CEA uses 0x40448000. Since the tag data header is the same size, tools that infer the tag data address based on the tag array pointer, such as Eschaton, will be able to work with the map as far as allowing you to view and edit tag data without having to update the tool.
     
    Also, there is another key difference that will prevent many tag parsers from accessing BSP tags in the map: BSP vertices are stored outside of the tag, and the lightmap pointers are meaningless here. Actually, the vertices are addressed based on file offset and size, so you'll have to use the offset values instead of the address values to find it. Fortunately, they're the same format, so they can be reintegrated back into a BSP tag and exported normally. invader-extract can already do this.
     
    There's one last difference: bitmaps and sounds are stored differently in CEA. They are not stored in bitmaps.map or sounds.map. All classic bitmaps are stored in inplace1.ipak (and referenced in the .imeta file), and all classic sounds are stored in fmod files. Also, the .fmeta contains information about file names and the uncompressed file size (which is read by the game and needs to be correct).
     
    These files not only store the data, itself, but also the actual attributes to the data. Therefore, the tag data for both the bitmap data and permutation data is actually not correct. Bitmap data can be determined by reading the .imeta and .ipak data and reading the data from that, and thankfully, MCC uses the same formats that Halo PC uses for classic bitmaps. However, sound data may not even use a format that stock Halo PC supports.
     
    How do I tell the difference between a Halo PC or CEA map?
     
    Technically, you can't safely do this if the maps are uncompressed. Here are a few scenarios:
    Yes, the build strings are different, but neither games read this value. Anyone can change these with a hex editor and it'd still be just as valid to either game. The only thing you can guarantee based on the header is whether or not something is a Custom Edition map. Yes, BSP vertices are stored differently, but the values used in one game aren't used in the other, so it is possible for either to be set to something that appears valid but isn't actually used. Yes, the tag data addresses are different, so usually the tag arrays will be different addresses, but this does not always have to be the case, and some map protections will exploit this for older, naive tag editors like Eschaton.  
    The only reliable way I can think of for telling the difference between two maps is that CEA maps are compressed. invader-compress will also set its own 563 value in the header as the engine version when decompressed so it can still tell that the map is a CEA map. Ceaflate doesn't do that.
  25. Java liked a post in a topic by tarikja in SoTM Submissions