What happened to OC? - CLOSED Carnage?!

th3w1zard1

Member
  • Content count

    25
  • Joined

  • Last visited

  • Raffle Tickets

    0

2 Followers

About th3w1zard1

Extra Information

  • Gender
    Female

Recent Profile Visitors

1,437 profile views
  1. Greetings everyone, this will probably be the last phasor announcement of all time, but I have heard that the current phasor source is not buildable due to general lack of knowledge, BOOST issues, and some undefined external objects that needed to be commented out for some reason. Anywho, I have built you guys phasor builds that you may use to your liking. My build has a couple of extra functions, off the top of my head getplayervehicle, getplayerweaponid, Nolead, and some other minor bug fixes. Check out my thread for more info. Here yall are: Latest Phasor Build: https://www.dropbox.com/s/lgz75lmvwlgvenw/Oxide's Builds.zip?dl=0 Latest Wizard's Phasor build: https://www.dropbox.com/s/2flhuhfmers6tqf/Wizard's Builds.zip?dl=0 Go nuts. EDIT: Wizard's build does not work due to a merging issue in the last commit that I forgot about. I may or may not decide to fix this depending on how motivated I am
  2. I don't see why it wouldn't. That script uses a timer instead of an event, so that removes most of the incompatibilities. The only way to know for sure is to try it. If you do have issues I'd be happy to help you resolve them.
  3. Before I start talking about this script, I would really like to thank Sehe, the current developer of sapp, for all of his hard work. He's gone above and beyond my expectations in working with me and adding features that made this script possible, so thanks a million and keep up the good work. This script will allow you to 'magically' make any script compatible with BOTH Sapp and Phasor with one line of code. It is a module that can be loaded into a script, and will use logic to combine the phasor api with the sapp api. Please note that this script is NOT a finished product. It is still in beta, and should be treated as such. If you run into an issue, please reply to this thread and I will fix it ASAP. (skip this if you don't care how it works) This script will combine both the Phasor and Sapp APIs, so it will act like your script is running with sapp AND phasor. For example, let's say I define 'function OnPlayerSpawn'. This is a default Phasor event function, so it will be treated like a Phasor function. However, if you have 'register_callback(cb['EVENT_SPAWN'], "OnPlayerSpawn")', it will override Phasor's default OnPlayerSpawn and call it like a sapp function, with sapp arguments. So be careful. There is something important I should mention about the way this script works. Let's say your script has an 'OnServerChat' (phasor event) and an EVENT_CHAT (sapp event). Now let's say your script is setup to block messages in the Phasor event. This module causes Phasor events to be called first. They, in a sense, take priority. So will will happen is Phasor's OnServerChat will be called, and that will cause sapp's EVENT_CHAT to NOT be called. It should also be known that Phasor is using Lua 5.2, and Sapp is using LuaJIT, which is based on Lua 5.1 with some additions. Because of this the libraries are a bit different. For example, loadstring does not exist in Phasor, yet it still is in Sapp. This module defines MOST of the ones that are different between both lua versions, but I am only human and I cannot find all of them. So if you find that a function isn't doing what it's supposed to, reply to this thread with your issue. As I mentioned earlier, both the Sapp API and the Phasor API's are available in this script. By that I mean you can use all the sapp functions (to_real_index, execute_command, player_present, drop_weapon, etc) and all of the phasor functions (rresolveplayer, svcmd, getplayer, destroyobject, etc). I did my very best to make sure that all functions would work how they do in their respective server app. For example, destroyobject will fail if you pass it an invalid Object ID because that's what Phasor does, but using Sapp's destroy_object will simply do nothing. There are a few issues and problems with this script, just because of limitations in sapp's and or phasor's api. I know the point of this module is to make your script compatible with both server apps with ease, and I tried my best to make sure there were as little issues as possible, but sadly there's still a couple of them left. These will hopefully be fixed soon. If anyone has any input or ideas or solutions for some of these issues/workarounds please let me know. Current Issues and Workarounds in this script: -- The 'kill' function has been renamed for both API's. Please use 'sappkill' if you want to kill a playerIndex, and 'phasorkill' if you want to kill a playerId. * Using your script in Phasor * :: Events :: -- Workaround: EVENT_TICK is imitated by using a timer that's called every 33 ms. It may or may not be possible to still use this as a 'tick' event, depending on how Phasor timers work. -- No functionality: EVENT_AREA_ENTER, EVENT_AREA_EXIT, EVENT_SNAP, EVENT_WARP, EVENT_CAMP, EVENT_LOGIN, and EVENT_ECHO are not supported by this script :: API Functions :: -- Workaround: 'drop_weapon' will destroy the weapon instead of dropping it -- Most functionality: 'get_var' is missing $botscore and $afk variables. -- No functionality: No 'safe_write' or 'safe_read'. Phasor automatically makes all reads/writes safe. -- Most functionality: 'cprint' does not support colors. -- No functionality: 'sig_scan' is not available. However, the unreleased beta version of Phasor contains a sig-scanning function. * Using your script in Sapp * :: Events :: -- No functionality: No OnDamageLookup or OnDamageApplication. Apparently these will be added in 9.1. -- Most functionality: 'OnWeaponReload' cannot be blocked. -- Most functionality: 'OnPlayerKill' will not distinguish 'server kills' from 'falling death kills'. It will always assume falling death. -- Hacky but works: Blocking vehicle entry in 'OnVehicleEnter' will allow the player into the vehicle, then eject them 2 seconds later. -- Hacky but works: Blocking vehicle exit in 'OnVehicleEject' will put the player back in the vehicle after 1 second. -- Most functionality: No distinguishing between team changes via the 'st' command and changing your team in the escape menu. It will always assume it can be blocked. -- Some functionality: No way to change a player's name OnNameRequest. However, if you attempt to block it, this script will not allow the player to spawn, and will not let them continue joining until they leave and change their name. -- Hacky but works: Blocking someone in OnBanCheck will cause the player to join for a split second, then leave. The player will still see the 'server operator has banned you' message. -- Some functionality: 'OnServerChat' will not pass what type of message it is (vehicle, team, global, etc). This event is also not being called for server messages and private messages (I couldn't figure out a good way to do that). :: API Functions :: -- No functionality: Sapp does not have any of the damage functions that phasor has (applydmg, applydmgtag, odl_multiplier, odl_causer, odl_flags, odl_multiplier, odl_receiver, odl_tag) -- No functionality: No 'log_msg' in Sapp scripts. Might change it later to use log_note. How to install this module: Download the script, find your server directory, and put it in the lua folder. If your server does not have a 'lua' folder, then just create it manually. How to use: Using this script is easy, simply add this line to the BOTTOM of your script: _G = require"PhasorSappCompatibility" Download this script here
  4. Ah I see, because phasor functions handle the player as 0 - 15 and sapp functions handle the argument as 1-16 you don't even need to worry about the player. Brilliant.
  5. Question. I just looked through your code, and I'm not seeing any handling for 'playerIndex vs player memory id'. You do realize sapp passes the playerIndex (a number from 1 to 16) while phasor passes the player memory id (a different number from 0 to 15) right? EDIT: Looks like you're handling it correctly for 'loop_start' and 'loop_end' but not in OnPlayerSpawn.
  6. the grenade issues have been fixed, never got around to posting that they have but it was in my commit message
  7. I see your point. I just thought it would be easier for everyone because everyone was already used to the way SAPP's nolead worked. We can't please everyone, if we change it to the way that's 'right' and 'preferred', then the people who use sapp's nolead will be upset. I personally think it's better to have it unified between all versions, so everyone doesn't have to ask 'is this sapp? do I need to use /lead 0 or /lead -1? why is set not working?' etc. You're probably right, I was assuming it was already 'less level' because people could already turn their lead on and off. But on the other hand, if everyone can do it, then how can it be exploited? Also I just realized I never actually provided a built copy of this Phasor (I guess I expected everyone to want to build it themselves) but for anyone else just reading the thread, here you go: http://dl.dropboxusercontent.com/u/32815290/Release.zip Install the official Phasor first following its instructions, then replace the files with the ones I've included in that zip
  8. I don't know what you all are talking about. /lead 0 means lead off (nolead on) /lead 1 means lead on (nolead off) which is the same as sapp. Some people do not like nolead on (lead off) and also do not like having to lead by an incredible amount when they have 300 ms of ping, especially when they're not used to it. So what's wrong with letting a person set their lead to 67 ms? That feature is actually the only reason I even bothered putting nolead into phasor in the first place, I hate having nolead, but I hate having to know the location of the server and know my ping to know how much I need to lead. This doesn't apply to if a person is just lagging really hard, which the leadcontrol code probably wouldn't help them at all. I also don't understand what you are saying when you say '/lead set x' because that feature is already in, just remove the set part of it. Doing /lead 67 will simulate 67ms of ping and allow you to play as if you DID have 67 ms. Period. I'm at a loss as to why you are complaining about features just because they are there, if you don't like them, then don't use them. If someone is dumb enough to set their lead to 10000 then they deserve no pity.
  9. Yes. I tried to make it work almost the same way that Sapp's works, just because people are already used to typing /lead 1 and /lead 0. I don't understand why reversing the command to be /nolead 0 would make it any easier, because then people couldn't type /nolead 67 (because that would make no sense). The coding may not be the best coding in the world, but it gets the job done as best as it can.
  10. I have successfully added nolead (with the help of a lot of various people of course, I couldn't have done it without them) into phasor. https://github.com/th3w1zard1/Phasor/ It is using PaulusT's HaloLagCompensation, Oxide is eventually going to make the legitimate lead with hooking the collision function (that I've explained earlier), but if he doesn't I was going to look into it and see if I could at least get the codecave hooked, and whatever else I could do in my skillset to at the very least make it easier for Oxide when he does plan to do it. Anyway, Type these commands in chat to modify your lead: /lead 0 (will turn lead off) /lead 1 (will make lead normal) /lead (any other number) will make your lead to whatever you set 'any other number' to (so if you want to pretend you have 67 ping instead of 133, type /lead 67) You can also use these server commands: sv_setlead <player> <lead> changes a specific player's lead sv_default_lead <lead> sets the default lead for the entire server (a player doing /lead 1 will override this default) sv_average_ping <true/false> will force leadcontrol to use average ping in its calculations or not. If you want to change the lead from a script, I made phasor commands to do so. setlead(player, lead) changes a specific player's lead setdefaultlead(lead) sets the default lead for the entire server (a player doing /lead 1 will override this default) and that's that. I probably should put this in its own thread but don't care right know. link again: https://github.com/th3w1zard1/Phasor/
  11. here are the PC 1.09 addresses directly from my git repo: unsigned long FUNC_UPDATE_OBJECT = 0x0052F2F0; unsigned long FUNC_UPDATE_ALL_OBJECT = 0x0052BFE0; unsigned long FUNC_UPDATE_PHYSICS = 0x0052F710; you should be able to replace them inside of the HaloLagCompensation, and it should just work
  12. PaulusT's fix doesn't do anything with velocity AT ALL. All the code having to do with velocity has been commented out (except the saving it inside player_info.vel or w/e) but it doesn't use it anywhere, it just uses position which is what you want, which I mentioned earlier. It already runs standalone on PC if you modify the addresses from CE to PC (which is pretty simple)
  13. Look at NoLead.cpp inside of Phasor/Phasor/Halo/Server/ at https://github.com/th3w1zard1/Phasor EDIT: Made your life easier: https://github.com/th3w1zard1/Phasor/blob/master/Phasor/NoLead.cpp EDIT2: Link to the original HaloLagCompensation by PaulusT: http://www.modacity.net/forums/showthread.php?24803-Release-Halo-No-Lead-Fix-%28Server-side%29
  14. Hmm? Did you call for the Wizard? How may I help you today? I did find HaloLagCompensation by PaulusT and I did manage to get it to work with PC (it was really simple, change a few addresses he has to PC and it was good to go) when I tried to implement it into phasor (you can see how I did it here: https://github.com/th3w1zard1/Phasor/) it didn't work for some reason (guessing it was because LagCompensation used detours, from injecting code, while phasor's didn't, and I probably missed a step in the codecave transfer process somewhere that I don't care about) and since c++ isn't my specialty I have no idea how to fix it :/. I've been convincing Oxide to add no-lead to phasor, and he's been working on it (or so he claims) when he has had time, but no idea when it will be released. Told me two days ago he promises to finish it yesterday, except I haven't heard from him since, so.. looks like we're just going to have to wait. The version Oxide has been working on should be a lot better than the one from HaloLagCompensation. From what I understand, instead of the updateobject codecave reverting position to whatever it was (ping) milliseconds ago and then resetting it back to normal, Phasor will keep track of the player's location every tick and save it into an array buffer for that player, then hook Halo's collision function (pc 1.09 address 0x53D8D0 if anyone cares to reverse) and use the other player's buffer indexed by the damaging player's ping to determine what player data from how long ago should be used. I believe this is how Sapp's nolead works as well (thank you btcc) I don't know if Oxide plans on adding true pings so nolead can be more accurate, but it could be done very easily if he doesn't, new thread, ping player, instead of pinging in ticks or w/e halo does, just like WaeV said, simple. EDIT: I actually don't know if true pings would help because of how halo's collision function works, but then again I didn't feel like reversing it so I wouldn't know. Keep your eyes peeled for updates, you should be hearing something sometime soon if oxide actually holds up on his end. Otherwise, someone can probably help me with PaulusT's lagcompensation and figure out why it doesn't work. Thank you for calling the Wizard. Have a great day.
  15. OK so it looks like I was wrong, rider_ejection DOES work on PC, I just had to execute it as the server (I'm such a derp). Now my issue is I need a way to determine if a vehicle is flipped over (like not on it's wheels). I'm not very good with physics and pitch/yaw/roll, so any help is appreciated.