PiZZADOX

Member
  • Content count

    90
  • Joined

  • Last visited

  • Medals

Community Reputation

42 Excellent

About PiZZADOX

  • Rank
    Corporal

core_pfieldgroups_3

  • Occupation
    Weapons Technician

Contact Methods

  • Twitter
    @PiZZADOX
  1. Just letting everyone know that we continue to be active, have a squad+ of players on weekend operations, and maintain a dedicated server as well as a completely custom modpack tailored to our unit, with custom addons and missions. We play a mix of pvp and coop missions.
  2. To keep object objectively level to the sky: this setVectorUp [0,0,1]; To keep object objectively level to the terrain slope: this setVectorUp surfaceNormal position this;
  3. The effectivecommander behavior, especially in MP with players inside your group inside your vehicle, is very, very strange. So far I have not found a way to set the effectivecommander of the vehicle when players are in the vehicle. In singleplayer you can force the effectivecommander by ejecting the player, making the player the group leader, and then loading the player in. Changing the group leader after the player has reembarked the vehicle has no effect on the effectivecommander. This technique does not work at all in multiplayer with a player already inside the vehicle. In multiplayer, the first person in the vehicle will be the effectivecommander, but a gunner or commander turret will overwrite the effectivecommander status and will take control of the vehicle. Is this config based, or hardcoded? The intent is to get the driver of all armored vehicles as the effectivecommander, for purposes of dictating the turnout/in of the vehicle to stop the disabling when a commander/gunner turns in.
  4. Can't really blame or expect comments from Dwarden, I doubt the corepatch project occupies more than 1% of his attention right now.
  5. Unless someone puts a lot of work into it again (which is unlikely, unfortunately) then it is broken. You can blame BI's script interpreter update and Corepatch.
  6. Try setting a different memory allocator. Via the new corepatch my server was crashing until i used "-malloc=tbb3malloc_bi" in the launch options
  7. He wont listen, our only hope is for Bohemia to take away his update privilege.
  8. Corepatch is to fix the common core parts of the game that we all use (like the gear menu errors and such) Those BI scripts affect everyone playing the game and should have been changed. Didn't interfere with any mods and improved the game in every aspect. Fixing the mission specific scripts also was necessary and good for the entire community. I am not disagreeing with the principle of fixing bugs. I am saying you are too overzealous in your desire to fix random barely useful things that impact compatibility with mods, the thing that keeps arma 2 alive. I suggest you work on modules and scripts, not on Cfg values. Let's fix the civilian modules.
  9. Many of those tickets were created ages ago. I'm not saying they shouldnt have been addressed, but we are not an large active community anymore, and we have a wealth of mods to supplement the game and solve many of the games few drawbacks. Bohemia didn't fix a lot of tickets because they were either too unrealistic in the amount of time to fix them, they were a design choice, or they would have broken mods. The few major updates they did push were in line with and communicating with mod developers and server hosters. If BI was in your shoes, they wouldnt have made those choices; they knew the impacts of changing configs and the structure and importance of mods in the community. Arma is a platform, and the platform should be enhanced of course but the content is in fact less important, especially when the development cycle of the game is long over and mod support is almost nil.
  10. I guess Bohemia doesn't care about ArmA 2 and has no reason to continue satisfying their clientbase, but I sometimes wonder if they would want to ruin both DayZ and ACE for the ability to zero a weapon with their simplistic zeroing computer system. If you are working on Corepatch in the hope for any future development portfolio, people usually look at the outcome and satisfaction of your customers, not just the work you put in. Now I have to spend extra time out of my day to work reverting stupid changes to make to continue the community I play with survive and utilize ArmA 2. Completely unnecessary changes that do not improve realism or gameplay now affect an actual group of customers and players in a drastically negative way. If I wasnt there to revert and update ACE, they wouldnt be able to use these features and the mod would be completely broken. Here's a couple mods I made in my spare time. They add some stuff to the game, especially the base game, and they don't break a lot of stuff for almost no gain whatsoever. Maybe we should add these to the game in a corepatch, dont you think?
  11. That is what I am saying; I am saying Corepatch has overstepped its bounds (and not even fully delivered on its original mantra) I appreciate very much continued community patching, but lets not kid ourselves, you are also creating necessity for people to update mods and fix their missions, work that might never be done. Why dont we do more work on things that expand usability and fix errors such as fixing the civilian and civilian vehicles module (which are broken as hell and cause numerous problems since 1.63) instead of creating more undue work that really has a tiny effect on the gameplay but a large effect on usability of mods, mods which are the basis of the game's community? CPP is all inhereted in order, If I want to use some of the changes but then revert others, I need the more recent patch, specifically the one I want to revert later. If I want to change discretedistance on a vehicle (a feature that breaks the more realistic ACE range adjustment) but keep the maxelev for some of the helicopters as well as some of the new turret names, I need to first load the dependency of corepatch in order for corepatch_vehicles to load, and then load the dependency of corepatch_vehicles for my corepatch_vehicles_ace_compat to load. There is no guarantee that corepatch_vehicles would load if I was to only put corepatch as a dependency, as I tested a few times. Does that make more sense?
  12. "This is a simple config/script patch for Arma 2 OA. My objective is to correct all the errors that ArmA 2 OA (1.63) show with the launch command line -showScriptErrors. Upon rollout of 1.63 patch, Bohemia included a new script interpreter that show all the undefined variable present inside scripts. There are a lot of them and maybe they cause script to not run properly. Because of ArmA 3, BI programmer have not much time to spend try correcting errors of an old product, as a programmer I understand this, so I decided to use my skills to try to fix these errors as best as I can." EDIT: Please do not change the class names of the addons in your configs. Changed Corepatch_Turrets to Corepatch_Vehicles. Any mods that use these classes as dependencies (any that want to revert some of your changes) break and need to be updated for the tiniest of reasons. What was wrong with Corepatch_Turrets? That addon modifies the turrets...
  13. Fixing script errors due to new interpreter != changing values in configs. Corepatch was meant to be fixing BI content and performance gains, not to change aspects of the game.
  14. g36 and AS VAL/VSS optics broken on most mods due to new muzzle config.