Welcome to Open Carnage

A resource for Halo 1 modding and tech, with unique means of rewarding individual content creation and support. Have a wander to see why we're worth the time! EST. 2012

All Activity

This stream auto-updates   

  1. Past hour
  2. No pictures??
  3. Today
  4. Some heavy fog set visibility down to around a 100 meters and made night shift look like something out of Silent Hill. Freezing point temperatures weren't helping :v
  5. At the time of this post, HAC2's last update (by MSalerno, current HAC2 dev) was 2019-12-18. See the following link for new HAC2 download link, update information, and more: http://wiki.halonet.net/index.php/HAC2/Installation The current version of HAC2 no longer uses loader.dll nor hac.dll. Regarding dgVoodoo2, DirectX9 support has hit mainline releases, but Halo CE support isn't quite perfect. See this thread to keep up to date: https://www.vogons.org/viewtopic.php?f=59&t=68379
  6. Yesterday
  7. Not until we honk honk.
  8. Well, I guess we don't need a competition for this month.
  9. Last week
  10. Stubbed my toe on kitchen island. Threw my head back in pain. Hit my head on kitchen cabinet. 10/10 Sunday so far
  11. Found some interesting strings in a sapien decompile. So it's: Looking, Aiming, Facing for the vectors. it's Aiming_speed instead of actor focus. Animation state for actor state. Throttle instead of velocity (though personally I prefer velocity)
  12. Debug_recording: shows current recorded animation running on a unit, and how many ticks are remaining. Debug_scripting: Shows current script, how long it's sleeping(if sleeping) and what functions will be called. debug_sound_channels: displays how many channels are being used for sounds. Mono 3d: are location based sounds. L/R determined by location, but sound is originally mono (same L/R) Mono Stero 44k: higher quality sounds, 44k is sample rate. debug_sound_channels_detail: shows current sounds playing, amp, and max volume debug_sound_cache: shows how many sounds are loaded, how much ram it uses, and allocated space available. debug_sound_cache_graph: is a visual representation of the cache. Not sure what the colors mean though. debug_sound_environment: shows which background sound TAG is playing. for the debug_SOMETHING_messages I believe this corresponds to the hud_items_messages.unicode_string_list messages, but ill look into it later c: Frustum usually corresponds to the projection matrices as far as programming goes. I believe this determines what should be culled. Considering there is a "debug_no_frustum_clip" function, I further believe this. small contribution; however, it's a few i've used in the past
  13. Washing machine leak. Fucccckkkkkk
  14. Not bad c: keep up the awesome work!
  15. Well, as i mentioned before, i started this map back in 2015 but didn't go far. It took me a little over a month to finish it when i came back to it.
  16. This is amazing! How long did it take you to make this?
  17. SteamFox actually suggested a blender plugin, it is a thought. But I was more aiming for a IDE that would load in a unit, allow you to create keys and have the program calculate out the tweens with a timeline. I also want to be able to pick points in a timeline scrubber to attach scripts. This way I could do scripting in synch with the RA. Say update the camera, or start a different units RA. Since I'm also focusing on scripting for tiaraCE I also want to have a solid understanding of the scripting data. I want a full fledged IDE for halo scripting as well. From basic syntax highlighting to intelisense style text prediction.
  18. Definitely gonna read all the way through in the next few days, just able to skim at the moment. Somebody did release a small utility on Halomaps a few years back to make your own recordings in-game and save them as separate files which would be accessible through Opensauce I believe. Would be cool to have a tool compatible with stock CE, if that's what you're talking about doing.
  19. OG Reach screenshot taken years ago
  20. NEW ENTRY Ascetic by @aLTis
  21. Hello! I recently moved across country, and I forgot my laptop in the other state -.- This put a lot of my projects on hold, Luckily it's with family. In the meanwhile I fell back to one of my older projects I can tackle. I've been studying recorded animations (RA), and I feel I have gathered enough information for an interesting read. Since I'm also working on scripting for other projects, I felt a good way to get a grasp is to write a program to process them. My goal is to create a IDE for halo script and RAs, since they're so closely related. I've already started writing an interpreter for RAs I call Radium. Hopefully with our collective knowledge we could expedite that a bit. Recorded Animations: What are they? A good way to think of recorded animations is "Emulated input." It's the engine controlling a character during say, a cutscene. A map can have many RAs, they are attached to a unit via script, or Devmode console (These will return a true value if it was able to start the RA on the unit, false if there was an issue.) recording_play <unit> <cutscene_recording> recording_play_and_delete <unit> <cutscene_recording> recording_play_and_hover <vehicle> <cutscene_recording> recording_play: will play the recording normally recording_play_and_delete: plays the recording, and deletes the unit it was attached to after recording_play_and_hover: plays the recording, and hovers once done. Think dropship; the pause between in, and out. You can see the remaining time on, or kill, a unit's RA recording_time <unit> recording_kill <unit> Recorded Animations: Where are they? RAs can be found in your maps scenario. To add one to your map: open in tag editor of your choosing, and find the Recorded Animations section. Add RA into the map. Save the scenario. open your scenario in Sapien. Add a biped marker, Assign the biped, give it a name. Compile the map, and attach the RA to the unit with the command above (console and devmode) (Making one isn't easy right now, but theoretically is possible) Recorded Animations: How does it work? Well, I'll be honest and say I don't know 100%, but here is what I have found out. I haven't completely figured out the differences between the versions yet, this is only version: 4 control version: 4 currently. The header is structured as follows: struct RecordedAnimationHeader { char Name[32]; byte Version; byte RawAnimationData; byte ControlVersion; byte LengthOfAnimation; int Unknown1; int Unknown2; int DataOffset; int Unknown3; }; To be honest I haven't looked too much into this yet. I haven't concluded if unknown1 and 3 is padding or not. The header is pretty much the information we had available to us in our tag editors. The Recorded animation its self is a bit more interesting. This is where I've been spending most of my time struct RecordedAnimation { ActorState InitActorState; ActorFocus InitActorFocus; ActionFlags InitActions; short InitWeaponIndex; short InitGrenadeIndex; Float InitVelocityX, InitVelocityY; Float InitFacingX, InitFacingY, InitFacingZ; Float InitAimX, InitAimY, InitAimZ; Float InitHeadX, InitHeadY, InitHeadZ; int SOMETHINGTODOWITHRAV4 int SOMETHINGELSETODOWITHRAV4 Float InitAdjustX, InitAdjustY, InitAdjustZ, Event RecordedAnimationEvents(); //Pseudo code, fight me }; All things prefixed are the units initial parameters for the RA. Most of the events inside of an RA basically just alter these parameters. Actor State: This determines the condition of the unit. enum ActorState { Sleep = 0, Alert1, Alert2, Stand1, Stand2, Flee, Flaming }; Actor Focus: Determines the units reflexes enum ActorFocus { Alert = 0, Relaxed }; Action Flags: struct ActionFlags { Nothing = 0x0 Crouch = 0x1 Jump = 0x2 User1 = 0x4 User2 = 0x8 Light = 0x10 LockFacing = 0x20 Action = 0x40 Melee = 0x80 VectorDesync = 0x100 Walk = 0x200 Reload = 0x400 PrimaryTrigger = 0x800 SecondaryTrigger = 0x1000 Grenade = 0x2000 Exchange = 0x4000 }; Actions are kind of interesting. They act kinda like MIDI. Once the flags are set, if you don't change them back the action will repeat/continue. Lock Facing: Lock Facing causes all of the viewing vectors to synchronize. Hard Setting an exact facing and aim when a rotation is applied. Vector Desync: Vector desync causes all of the viewing vectors to desynchronize, allowing for independent control of the three viewing vectors. Move the head, but not the aim or facing for example. Weapon Index: Current weapon (Primary or secondary) Grenade Index: Grenades Vector2F Velocity: Velocity is used to control both walking, and driving. These are floats (I'm assuming since it was originally xbox) but for the most of the time the velocity is set to -1,0, or 1. (Note if vector desync isn't on you won't be able to alter these independently with events, it will rotate the whole group) Vector3F Facing: Controls which way the feet are pointing, and which direction the unit will walk. Vector3F Aim Controls the torso, and where the gun is pointing. Vector3FHead Controls the looking angle. Integer SOMETHINGTODOWITHRAV4: This is something that is only present in v4. Sometimes it looks like a reference, sometimes a tag. Most the time it's zero. I personally believe it has to do with RAs being called into another RA Integer SOMETHINGELSETODOWITHRAV4: This one is usually -1; however, there are some circumstances where I see it as something different. Vector3F InitAdjust: This is a final angle update before the RA begins. I believe this is so you can easily rotate an RA after it's been made for final adjustments without having to update all of the other vectors by a small portion over and over. Now the fun stuff..... Recorded Animations: Events Events are the whole way that recorded animations work. They are a single byte, and usually take a few parameters. There are four primary event types, and they're descriptors on the size of the time it takes to do the action. Instant: Instantly does the command. One Tick: Does the command in one tick worth of time. Byte Time: does the command in a byte sized chunk of time Short Time: does the command in a short sized chunk of time. they take up the first two bits of a byte. 0x______10 is some function byte tme, 0x______01 is one tick, etc. Every function has these 4 variations. When I give the functions later I will give you the instant function, to get the others just add the bit mask to it with your desired period. Eg. 0x04 (binary: 1 00) = end 0x05 (binary: 1 01) = end one tick 0x06 (binary: 1 10)= end byte time 0x07 (binary: 1 11) = end short time The time it takes to do the function is applied BEFORE the event happens. Think of it more as a delay. so if you tell it to do an event to update to primary fire, and you put a 120 tick time on it, it will wait 120 ticks THEN begin firing. If you want to pause AFTER the event, you put a delay on the NEXT event after it. If there is a time period designated, it will be the next byte or short in the stream before the parameters for the event. Example as it would show up in hex: rotate everything by (1,3): 3a 3f 01 03 3a = event 3f = time 01 = DeltaX 03 = DeltaY So here are the functions I have found so far: Nothing = 0 () End = 0x4 () UpdateActorState = 0x8 (byte State) UpdateActorFocus = 0xC (byte Focus) UpdateAction = 0x10 (short ActionFlags) ChangeWeaponIndex = 0x14 (byte Weapon) UpdateVelocity = 0x18 (Float X, float Y) Still to be researched = 0x1C ChangeFacing = 0x20 (SByte DeltaX, SByte DeltaY) ChangeAim = 0x24 (SByte DeltaX, SByte DeltaY) Still to be researched = 0x28 ChangeHead = 0x2c (SByte DeltaX, SByte DeltaY) ChangeHeadFacing = 0x30 (SByte DeltaX, SByte DeltaY) ChangeHeadAim = 0x34 (SByte DeltaX, SByte DeltaY) ChangeAimHeadFacing = 0x38 (SByte DeltaX, SByte DeltaY) Some of these might be SLIGHTLY off, I'll update these as I learn more; however, the current understanding is these so far I'm still doing a lot of studying on how it works; however, for now as a brief dump I wanted to share what I had. I'll keep updating as I find out more c: If you have anything to share please do, it'll definitely help. PS Hopefully this wasn't too hard to follow, I will edit for grammar after work.
  22. Good news to MEK users: Mozzarilla now supports creating both PCM and Xbox ADPCM sound tags! It does not yet support Ogg Vorbis, though, so I'm not going to put it on the list until that's completed, but if you want a GUI-based program that can generate sound tags and you're okay with being limited to uncompressed PCM or low quality ADPCM, you now have an option for that.
  23. Earlier
  24. No problem. You are still able to pick up grenades, so if that's an issue then let me know.
  25. I've increased the bounties of most of the requests above. I've also reduced the minimum script count to enter in the Friday mini-contest from 3 to 2. Go ahead and grab yourself some easy tickets, as this offer won't last forever. Note: Any scripts completed that were requested in the past 7 days will also be awarded 6 tickets as per the monthly raffle, but they will not be counted towards winning this contest. The +6 tickets do not count towards the Friday mini-contest as this is operated separate from the Monthly Raffle (though only non-staff can still participate since it uses raffle tickets), so you are not at a disadvantage if someone else is on the ball with the latest script requests. That said, I still recommend completing recent script requests as you get more tickets for doing so. Anyway, I've put the current standings now that someone has actually completed a script request from this list.
  26. It works!! Thank you!
  1. Load more activity