
IceCrow14
Member-
Content count
21 -
Joined
-
Last visited
-
Raffle Tickets
0
About IceCrow14
Extra Information
-
Gender
Female
-
Vuthakral liked a post in a topic: Universal AI synchronization
-
IceCrow14 liked a post in a topic: Universal AI synchronization
-
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.
-
DSalimander liked a post in a topic: Universal AI synchronization
-
DSalimander liked a post in a topic: Universal AI synchronization
-
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 .
-
MrChromed liked a post in a topic: Universal AI synchronization
-
MrChromed liked a post in a topic: Universal AI synchronization
-
Takka liked a post in a topic: Universal AI synchronization
-
aLTis liked a post in a topic: Universal AI synchronization
-
IceCrow14 liked a post in a topic: Universal AI synchronization
-
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
-
IceCrow14 liked a post in a topic: Universal AI synchronization
-
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):
-
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.
-
@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.
-
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
-
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?
-
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.
-
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.
-
Main post updated, I wrote the changes under the previous content.
-
"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!
-
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.
-
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.
-
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.