What happened to OC? - CLOSED Carnage?!

IceCrow14

Member
  • Content count

    21
  • Joined

  • Last visited

  • Raffle Tickets

    0

Everything posted by IceCrow14

  1. It's here, finally... To anybody who has ever read my topic about this in the CE development section, you may remember that I mentioned that this script would be meant to work for every single map that contains AI and that's what I'm going to release here. The game and the community deserve it. However, it still has some limitations: - This WILL NOT work for protected maps, if the server is running this script and it loads a map that is protected, it will crash, and even if it doesn't it is highly probable that it won't work at all. - The clients must have Chimera installed and the client script in their respective scripts folder. You can do this renaming the script to the name of the map with AI you want to sync and moving it to the map scripts folder if you want to keep it sandboxed, but I would recommend you to place it in your global scripts folder so you won't need to rename and copy it manually. I've disabled all the console_out commands to avoid annoying messages coming out every time a map is loaded. - There are some minor aesthetical glitches still, but they rarely would affect the gameplay (Most, if not all, are just related to aesthetics). And... I think that's all! If you are going to run a server with this on it just load the server script from the init.txt file and it will do the rest, I've made sure to reset everything that's needed every time a new match starts so you won't have to modify anything, however, I've kept some cprint and say_all lines for debugging purposes but I think they won't be needed anymore, you can disable them easily, just search any of those commands in the code and comment or erase them. To finish, a video of me running it on a dedicated server and playing as a client: In this file: AI synchronization scripts by IceCrow14 v.1.1.rar I've included both the server and the client scripts. If you aren't going to run a server, just drop the client script to your Chimera global scripts folder. Anyway, just for caution, if the bipeds' appearance looks strange try leaving and joining back the server you are playing in, if any error message jumps out to your console, feel free to send me any information about it and I'll try to find out what causes it (and possibly fix it) and delete the script if you feel it's needed.
  2. Hello everyone, this is a Chimera Lua script that basically changes your weapon reticle's color to green whenever you aim at an allied player, this is achieved through some real-time tag manipulation. Don't expect it to work on protected maps, also, as far as I know the reticle doesn't change if you're in a vehicle (unless you're in a passenger seat). Like always, let me know if you find a glitch and I'll try to fix it. Enjoy: ally_reticle_enabler.lua UPDATE: @aLTis's edited script (Latest version): ally_retical_modified_by_altis.lua
  3. Yes, you can use .hsc scripts to spawn AI actors, although I would suggest to have some sort of "host check" in the script/s meant to spawn them to make sure that only the server will create them (otherwise the clients will spawn their own client-side AI too), another way to go would be to use a SAPP Lua script, but that's up to you, both ways should work. Also, AI can be spawned throughout the match safely, there is no problem if you spawn more after it has started.
  4. Forgot to mention that you must have reading/writing user permissions in your Halo folder or the scripts will not be able to create the files (and therefore, will run under the default settings), or you can try running the game as administrator once. I've made a pair of small changes that should fix the problem .
  5. Good news, a new release version is here, and it comes with a lot of improvements. I'll be running low on time soon so I've decided to release the scripts the way they are right now, not lacking anything basic but with some cut features that I'd like to add later. Here are some of the key features of this version: - Named, and encounter-free bipeds will synchronize now - AI actors that use the player biped tag will synchronize too - RCon packets are compressed - Aim velocities will be updated - Introduced the in-game menu for the client script, which allows to change and save new values for parameters that can affect the game's performance - Aditionally, a settings file for each script will be created in the root directory if they don't exist - Protected maps can be "excluded" from the scripts' memory manipulation functions, so game crashes/exceptions can be prevented. This has to be done manually - Improved compatibility with other Lua scripts - Settings files will be created after the first execution, for example, the client's will appear when you join a dedicated server for the first time, and the server's, when you load the Lua script in SAPP. And some usage: Additional notes: - I've removed the capability to disable server-side garbage collection because it is pretty stable now, however I would like to bring it back in future versions - Other features that might come back are: Automatic g. c. of bipeds that no longer are updated by the server, manual reset and adjustable visual quality commands - As a side effect, the scripts are a bit heavier this time. I seriously encourage anybody that uses them to play with the available settings because they start off with the "safe" configuration, not the best for optimal performance - For the next version, features that I might introduce (finally) are AI synchronization for vehicles, usage of the automatically created server-side bipeds instead of local copies, and the previously mentioned ones - These scripts (v.1.2) are NOT compatible with those from version 1.1. Special thanks to anybody who has tested this, provided feedback, made suggestions and/or shared their knowledge and tools for the public. This (probably) wouldn't have been possible without them. Download: AI synchronization scripts by IceCrow14 v.1.2 (Fixed I).rar
  6. It's time for an update. After a deep re-work of both of the scripts, I've managed to increase their stability and fix most of the critical issues that I'm aware of, practically this version is ready for continued use in a dedicated server if anyone desires to do so. Also, I'm working in the addition of customization options for the client script with the purpose of disabling (or reducing the impact of) certain features in exchange for better performance. And last but not less important, the possibility to disable any of the scripts from inside the game or in specific maps is in my plans too. Here's a video of the actual progress (I recommend turning on the subtitles, there is additional information about every clip):
  7. Hello Devieth, sorry for the late reply, I've been very busy lately. This stuff for sure will be very useful to improve the client scripts, you may have already figured out that there's a function that iterates through all the objects using a static range, 1 to 1024 if I recall correct (I haven't touched the code in some time), each iteration being a dynamic object ID, I guess. The client script works fine using this scheme of taking the data and replicating whatever the server is doing locally with it, but for the latest method that I had been developing after this (the one that uses the real networked bipeds), getting the client to manipulate the bipeds using only their dynamic IDs was kind of... Frustrating, but that may be over, in case the object table you provided keeps the static IDs, just like SAPP's do (I might be wrong, but I've done some testing before and have found that every time a new object was spawned, its ID number was greater than the previous one's). There's some information that you may want to know about the script if you want to know somewhat more about how it works. Basically, both the client and the server scripts have two main roles, the first one (and probably the most important) being the Rcon messages stuff; the server reads the memory, makes a new string containing the basic information of every biped, it formats this string and sends it to the clients, the client script, on the other hand is meant to 'split' the string and extract the information from it to then make a NEW local biped out of it (if it doesn't exist), there are also some specific sub-functions that basically format the strings to avoid some bugs in the case of the server, but overall the string management functions are placed in the middle, below the setup. On the other hand, there are the tag manipulation functions, I placed these at the bottom because they are used generally only on startup of the maps and aren't supposed to affect the string manipulation functions. I'm conscious that there's a lot that can be polished in the code but unfortunately I can't do anything about it right now. Maybe in some weeks I will be able to retake this to fix the critical glitches and release a more 'readable' version. There's also more that I'd like to know about reading the game's memory, currently I just know how to read and write to it through SAPP and Chimera's integrated functions but have no idea about how to do it externally (which would be useful to debug some stuff quicker and find out more information not always available in the offsets and addresses lists). I slightly know how it works, but nevertheless I have very little experience on this so any advice from anyone would be very appreciated.
  8. @Sceny For none of them, actually. The script is meant to read and write to the 'child' object ID tag (the biped's weapon), and vehicles, if I recall correct are considered as 'parent' objects to the biped (even though it would be possible to upgrade the script to also manipulate vehicle HUDs). @Devieth About your first post, you're right, that can save some lines of code (Thx for the syntax tips you wrote in the edited scripts, they may be useful for other proyects). The reason why with the main script the reticle is somewhat oversensitive is because what triggers the color change is an address that changes its value everytime a player's name is about to be displayed in the screen. Initially I thought about implementing the detection part the way you did in your second edit but I didn't want to mess with the math back then but it's great that you did because now it might be possible to improve the script to also detect when you're aiming at NPCs. Possibly implementing something that constantly performs 'collision checks' between the camera vector and the bipeds' in-game collision model would do the thing but I think I have no clue about how to do that yet. PS: I'll add all the files that have been posted here in the main post.
  9. Thanks, and about the audio... I didn't notice it until I uploaded it, lol, sorry. Windows' Game DVR doesn't provide me with the quality I'd desire but at least it's enough to show up the kind of updates I'm used to make/upload. In other news, today I spent some time to work on SAPP and Chimera scripts again and found some awful mistakes in this script's code and reworked some stuff like... The server updaters, I forgot to add something that would update their limits (in other words, the last biped that would be updated would be the 300th, no single biped with an index higher than that would be updated anymore), got rid of a glitch that sometimes messed up some bipeds' animation playback and position updates, and also reworked the main 'Updater' function a little so it would now be able to send the current health and shield states of the bipeds. I also found a way to manipulate the networked bipeds successfully in another script (so local duplicates wouldn't be necessary) but it is very susceptible to failure in bad connections or when a pair (or more) bipeds are very close to each other. Out of curiosity... Does anybody know any in-game memory addresses/offsets where info about the FP model is stored?
  10. It's time for another update on the AI synchronization stuff, and I'm glad to say that I'm close to release a first public version of the scripts I've been using for this, because having the whole thing there just getting older... Well, it would be better if people would start making new content with it because it's stable now that I've fixed a lot of glitches for both the server and the client's scripts, and added a bunch of functions that do most of the scripting job that was needed automatically. Currently the only thing one has to do to sync AI for a new map is declare the path of the scenario tag inside a specific function in the scripts to get everything running, which makes the process a lot quicker and less susceptible to glitches because unlike in the previous version, you had to declare the bipeds used by the AI manually and you could accidentally forget to declare one biped type and everything would be messed up. The next step is making a function that retrieves the path of the scenario path and declares it automatically so having to edit the scripts won't be needed anymore. Just dragging the file to your map scripts folder and that's all. This is how everything has been going: I am going to write the main changes here, but will edit the main post aswell to have a full log of the progress that I've made since the beginning. Improvements - Now only the path of the scenario tag has to be declared and a bunch of functions do the rest. - The client's script only runs on dedicated servers, so you can test the map in single player or in a local multiplayer match if you want. - The limit of simultaneously existing AI has been increased to 300, however, I wouldn't recommend you to have more than 150 at the same time (seriously, don't do that). - The server's script runs a function that sets the projectiles of the weapons used by the AI not to be client-side only, so you will be able to see the fired projectiles. - Velocity synchronization: The bipeds' current velocity is sent to the clients, this means that you will be able to see their movement on 60 FPS (if you have Chimera's interpolation enabled). - Now the dead/alive state of the bipeds is updated automatically, this is a fix to a bug I had found in previous versions, which kept your crosshair flashing if you aimed at a biped with it's health empy unless you hit it one more time. Known glitches - Neither the bipeds' weapons or their firing effects show up for the clients, however, the weapons appear right after the biped holding them is killed. - I haven't set the "shields drained" effect to show up right (you can notice this in the video). - AI spawned by default when the map loads can't be synchronized yet (this is something that should only affect the server). - AI still doesn't sync inside of vehicles. I know how to get rid of the first three bugs right now, about the last one, currently I don't know but I'll set up a function that disables vehicle combat for the AI at least until I find a fix for it.
  11. 8/28/2018 Well, first of all, I haven't given an actual name to this thread (I'll do later) because there are two "projects" (if you want to call them that way) on which I've been working on. I'm not so good with explaining this kind of stuff without getting into details, so... Let's take a better approach: Biped / AI synchronization Recently I've been playing with both SAPP and Chimera's Lua scripts to achieve this, and I have managed to get a somehow "more authentic" way to sync client-side stuff like bipeds, scenery and even vehicle custom animations (in theory we should be able to sync even object permutations, which could allow any server manager to set different model permutations for every team's vehicles and players in a CTF game, for example) using remote console messages. By now, I've made a pair of scripts, one for SAPP (which sends the data to the clients) and another one for Chimera that modifies anything that the server tells the clients to change. In comparison with other AI sync methods I've seen before (like the one that uses map scripts to attach and detach vehicles to AI bipeds, or the SAPP one where the server spawns a vehicle for every biped depending on it's current animation state to then assign it the current biped's location, rotation, etc.) with this one the client updates the actual properties of the server's biped, so you can see aditional stuff that is missing within those methods such as their effects and the crosshair's flash when you aim at an enemy. Also, another incredibly good new about this is that you won't need to modify the map files in which you use these scripts as long as the AI encounters' data and tags are there. Another great feature of this is that you don't need to modify lots of code or do massive tag witchcraft to get different types of bipeds simultaneously, however there is a long way to get this working smooth and pretty at the same time. End of the speech, watch with your own eyes what I'm talking about: Flood survival (PvE and PvP) Something I wanted to work on since a long time ago, basically what I'll try to do, at least by now is a multiplayer map that supports all the gametypes but also allows the players to summon Flood hordes to bring a somewhat new and strategic approach to Halo CE and also spawns them automatically in certain areas of the map. I plan to use the default tagset but with some balance changes (No more OP pistol and useless automatic weapons), add upgraded variants of certain vehicles and weapons and if possible, an option to choose your battlefield's spawn point (I'll set the spawn points for team based game types inside a pair of ships, part of the BSP). I'll be posting updates on this thread, currently, the scripts are a bit unstable and the BSP isn't finished so... I guess I won't be able to release anything yet. 10/3/2018 UPDATE: AI sync It's been a long time since my last post, sometimes I wonder what I would be able to do if I was motivated enough... Enough sentimentality for today, because there's a lot of new stuff. Let's start, in my last post (from this topic) I mentioned something about taking advantage of some client side stuff to develop a somehow different mechanism to sync AI, and that's what I did (in the description of the video I wrote more information about it): Basically, the main difference is that the client no longer has to manipulate the bipeds spawned by the server (at least, not like it had to do before), what does this mean? That the bipeds a client sees in its map are spawned by itself (obviously, following the server's instructions received through RCon messages) and the bipeds spawned automatically by the server are moved to a hidden location (they are supposed to be deleted too, but it seems that it isn't possible). Now you may be asking yourself why I didn't just use these bipeds instead of spawning a local duplicate, well, because to manipulate an object's properties (a biped in this case) in the game through SAPP and Chimera you must know its object ID and memory address, and I had found that the object IDs between the server and the clients aren't the same (I already expected it would be that way before making sure), so I tried to use their "temporary" object IDs (iterating from 1 to 1024, the max amount of objects default Halo supports simultaneously, as far as I know, using a 'for' cycle to see which objects were bipeds and had a certain set of properties and so on... In the beginning I didn't think it would work, but it did), the problem about this was that once a biped disappeared, other objects spawned after that could take their temporary object ID, also, after leaving and joining back the server, the objects aren't spawned in the same order, besides making a join-friendly feature out this would've been incredibly tedious, this caused a lot of trouble that isn't worth mentioning. Let's move to the most important changes: Improvements The matches are join-friendly now, you can leave and join the same server as many times as you want and you'll always see the AI's bipeds at their current state (location, rotation, animation). The Lua scripts I wrote can be used to sync AI over any MP map without having to modify it, as long as any AI encounter/biped (other than the players') isn't set to spawn by default (there are more cautions that should be taken, but this is the most important one). The bipeds' effects are displayed properly. Limitations/Glitches The max amount of bipeds that can be synced is about 150, it may be a little higher, but know that some features may be unstable if you have this, or a higher than that amount of AI simultaneously. The total amount of AI bipeds a client will have in its map is the double of the server's current amount (for example, 17 AI would mean 34 bipeds spawned in the client side). Almost every biped must be hit one more time after being detected as dead by the server (this is just an aesthetic glitch). Bipeds that can be killed by chain reactions (like the flood carrier and the infection form) become glitchy after being destroyed by other biped's explosion. It seems like the server kicks the clients that can't receive all the RCon messages and execute the necessary commands after that on time (this may only affect low performance computers). Despite the limitations about this, I've automated as much as possible to make the process of syncing AI for a new map insanely faster than it was before, now just a dozen lines of code, or even less (actually, calls to other functions) can do all the job for themselves depending on the different amount of bipeds you include in a map.
  12. Main post updated, I wrote the changes under the previous content.
  13. "Cprint" only prints the message to the server's console. I guess what you want to do is displaying the messages in the chat but without the server's prefix, if that's the case I think you could change the server's prefix to an empty string every time a death message is about to be displayed and then change it back to its default value. Something like this: elseif last_damage[PlayerIndex] == tank_shell then msg_prefix("") -- If not possible, you could try using " " instead, or a small character. say_all("$name was killed by $kname\'s Scorpion"), PlayerIndex)) msg_prefix("[Your default server's prefix]") Anyway, I only mod CE so I may be missing something. Hope this helps!
  14. As far as I know, there isn't a known offset/address for such variable, it probably exists in the engine, but I don't know its location and unfortunately I don't know how to find memory addresses on my own (yet), I've been working only with the ones that are on the memory addresses and offsets document. The addresses I've used are for the object's X, Y, Z, Pitch, Yaw and Animation state (I haven't messed with the ones for the biped's body parts' data because that would mean sending a lot of information to the client, that should be read as substrings and consequently end up reducing the performance of the game) and I've achieved nice results, like this: At the ending of the video you can see the glitch I mentioned before, some bipeds disappear when they play certain animations and still I haven't figured out what causes them to do such thing, it's almost senseless that they just go away like that because their coordinates are supposed to be updated on every tick, but strangely, if I erase/deactivate the code that updates the animations everything runs fine, just like it should... I'm actually thinking on using another method that involves using some client-side stuff instead of this, but I'm not sure if it would work.
  15. Awesome! Glad to see more people working on syncing AI, I just have a little question. Are you using client-side AI? I mean, something like using the server to send its bipeds' data to the clients so they can spawn their own local bipeds and move, rotate or animate them the way the server tells them to do instead of using the braindead bipeds spawned by the server on the client-side? (Sounds quite strange, but maybe you know what I mean), anyway, I could share the scripts from my last post if you think you could find something useful in them.
  16. Fortunately there are memory addresses for the object's rotations and animations, actually, I've already managed to update them too in a previous test but it was very resource consuming because the server had to send a message for every piece of data on every tick (For example, one for the biped's X, another one for the Y, for the Z, for the animation state, etc...) and as the amount of bipeds increased, the amount of messages did as well and at some point the server wouldn't be able to send all those messages to the client (about 7 per biped, multiply that by the amount of bipeds and then by the amount of players) or the client wouldn't receive all the messages it should, honestly I don't know but the result was that the client was disconnected from the server after a few seconds if you had about a dozen of bipeds. So what I'm doing currently is pure optimization, I made some changes to reduce the amount of messages per biped to 1 (That's why in the video you can see all the coordinates' data sent into one message. Much of the client's job is based on reading sub-strings). About the bones... I think there are offsets for their location and rotations too, but I'm only focused on the main object's properties to make this script somehow "universal" for every type of biped you include in the map. Finally, the animations... I've found very weird glitches that cause the bipeds to suddenly disappear when they play specific animations and I suspect it's something related with the "frame info type" setting of such animations.
  17. Hello! I'm new to the community (This, and maybe to the whole Halo CE one too), now you may have already guessed the reason why I've come, I've been making content (some tags, scripts, and maps, obviously) for the Custom Edition. I've learned a lot from this forum and halomaps.org, and I thought that it would be time to return the favor (even though I might have come a "little" too late for it, lol). Maybe in a few hours/tomorrow I'll post my first release. Things you should know about me? Maybe that english isn't my main language, so, if I write something wrong (grammar or orthographic errors) please let me know (if possible by PM, otherwise it'd be pretty embarrassing). I'd be thankful about that. PS: I love the dark grey scheme of the site, congratulations to whoever thought of making it that way!
  18. Thanks, and about how I started doing this... Well, it was like a gradual process before I knew anything about modding, I used to ocasionally watch videos about PC or console mods but at that time I could only be amazed by them because I used to think that such stuff could be added/changed only through the use of tools that my lack of knowledge wouldn't allow me to use at that time, such as Hex editors or anything that involved "breaking" (you know what I mean) the game, but when I knew the HEK was a thing and finally got it in my hands, everything changed. Now, about 5 months later I've done more than I thought would be possible with the engine and do not regret a single second. And yes, I hope to be helpful when possible during my stay, would love to see new and fresh content, just like the one you guys have been making through these years.