Jump to content


  • Content Count

  • Joined

  • Last visited

  • Medals

Everything posted by A-SUICIDAL

  1. I am using Xeno's backpack script. I'm not sure if it is the most up-to-date version, but it seems to work correctly. I have done alot of searching. This is not an actual backpack, but a script that allows the player to add their primary weapon and primary magazines to a "sort of" invisible backpack. I'm sure that the majority of players and script'ers out their are very familiar with this feature. I found the backpack script here: Xeno's Backpack Script I am also using a simple "Save Loadout" script which is applied as an action to an ammo crate, which also works in conjunction with a "Weapon Respawn" script that gives the player back their saved loadout when they respawn. Both the "Save Loadout" and "Weapon Respawn" scripts do not seem compatible with the backpack script that I am using. When the player respawns, instead of having the correct weapon and magazines in their backpack, they instead have a second primary weapon. For instance, if the player had a shotgun in their backpack and an M4 in their hand and saved their loadout, if they then die and respawn - they then have and M4 in their backpack and an M4 in their hands, but no shotgun. So I am looking for some help trying to get this to work correctly. I would imagine that both the "Save Loadout" and "Weapon Respawn" scripts need additional variables set to make everything work correctly, but I am not exactly sure what to add to make it work. Could somebody please help me with this? This is an extremely useful feature for any mission creator to add to his or her mission, so I am sure that I am not the only one out there that would like to get this working. Aside from the Domi missions out there, I have played other missions that used this feature and those mission had backpack and save loadout problems too. I'm actually surprised that there is not a stand alone download at Armaholic that incorporates all of these scripts as a package. These are the script that I am using: loadout_save.sqf
  2. I'll see if I can find a good working copy of it and then I'll test it and make sure everything is working correctly. I'll then zip it up and upload and post a link for download. It might take me a couple of days. I have so many different versions of it. Back to my original thread... who do I have to pay to get the backpack script to work with a "Save Loadout"?
  3. I really don't want to give up on this. I've spent a lot of time trying to get Xeno's stand alone backpack script to work with both a "save loadout" and "player respawn" scripts, but it didn't work. I just want to get it to work exactly like it does in Domination. I tried using the Domi version of Xeno's backpack script and after over 150 hours of reverse engineering the scripts, removing all the unneeded lines of code and trying to add all of the correct defined variables & includes where they needed to be - basically trying to piece it all together to work in a stand alone sample mission - I finally got to the point where I was not receiving any errors, but the backpack weapon was still not saving correctly, but everything else did save. I continued to work on it and developed more of an understanding as to how it all worked and I felt that I was getting closer to figuring it out - when I then accidentally deleted the sample mission when I was cleaning out some older sample missions that were cluttering my mission directory - thinking that it was an older version. So now I'm back to square 1 again and I just don't know if it's really worth the effort anymore since I nearly had a mind meltdown trying to get it working the first time around. I still find it amazing that such an awesome backpack feature in Domination was never released as a stand alone sample mission including a save loadout and player respawn with saved gear. Xeno's current stand alone backpack script works great, but it only allows players to respawn with the backpack weapon that was added to the backpack before the player died. I've tried PM'ing Xeno and kindly asking for him help - requesting that he please update his stand alone backpack script with both "save loadout" and "player respawn with saved gear" features, but I haven't heard back from him for quite a while. I kinda figured all along that Xeno must be way too busy with other things to take time out to help little'ol me, which I completely understand, especially when I'm asking a lot of him and we all know he's always busy. I am still hoping that Xeno or somebody might be able to help me with this. I'm going to keep trying to get it figured out even though I am losing confidence that I will ever get it working correctly. Ever since I got stumped on this I haven't focused or worked on anything else and I still have a mission that is completed, but I don't want to release it without these features since I would never feel happy with the mission. The word "stumped" doesn't even cover it, I feel "stopped".
  4. Yeah, it's strange. I'm using the island Faysh Khabur and at the Abu Wajnam Airstrip there is a radar tower that shows an #ID 19302, but it's not working with that number. I used the script to show all ID's within a 3 meter distance and mostly flies and mosquito's are being returned. I'm having trouble getting that tower ID number. I originally thought that I had the correct number, but after applying the "destroy with C4 only" script, I thought everything was working correctly except for the addScore, but then it turned out that I was able to destroy the tower with a MAAW rocket. That's when I realized that the ID must be wrong. There is a very long fence that goes all around that airstrip, I used a few markers to spawn explosions in a few spots at mission start just so the enemy AI could get through the fence in some places. I think I am going to spawn an explosion on that radar tower just to get rid of it - since out of the 30 or so objects that need to be destroyed in the mission, that radar tower is the only map object ID# that is giving me problems. ---------- Post added at 07:28 PM ---------- Previous post was at 07:15 PM ---------- Yeah, deleteCollection caused some severe lag in one of my missions. I couldn't figure out why the mission was so laggy, then I made a duplicate copy of the mission and started removing stuff and I kept testing the mission. When I removed the deleteCollection stuff from the mission, the lag disappeared. hideObject can be tricky too, especially when you hide and object that you want to show later. For instance, I have enemy bunkers that need to be captured, so I use hideObject true to hide the bunkers in my init.sqf, but then later when that specific task is assigned, I use hideObject false to show the bunkers, but I have to script it through my task scripts, otherwise a JIP player can't see the bunker, but mission start players can. If done correctly it works great. I can basically hide lots of stuff and show it when needed and delete it when it's not needed anymore. It saves a lot of extra work using long scripts to spawn everything.
  5. I managed to addScore to a player that destroyed a radar tower that I placed in the editor, but I was trying to get it to work for another radar tower that I did not place, but is actually part of the map. I figured out that the problem that I was having was due to a hidden object ID number, but I fixed the problem. I edited this topic and posted my example for others that might want to use it. First I'll explain how I have it working for a placed radar tower. I placed a radar tower and named it "radar1" and then I added this to its init: radar1 addEventHandler["killed", {[_this select 0, _this select 1] execVM "addScore.sqf"}]; (from Xeno) addScore.sqf: _victim = _this select 0; _killer = _this select 1; if (isServer) then { _killer addScore 10; } else { paddscore = [_killer, 10]; publicVariable "paddscore"; }; (from Xeno) init.sqf: if (isServer) then { "paddscore" addPublicVariableEventHandler { ((_this select 1) select 0) addScore ((_this select 1) select 1); }; }; Now for a non-placed map object it works a little differently. I clicked the "IDs" button in the editor to find out the ID number of the radar tower map object, which in this case was "15461". I placed a Game Logic in the editor as close to the position of the radar tower as possible. I want to make sure that the radar tower could only be destroyed by C4 and I also do not want players to be able to destroy the object with C4 until Task 5 is assigned, so I added those conditions. Game Logic's init: task5_tower2 = (position this nearestobject 15461); task5_tower2 addEventHandler ["HandleDamage",{task5_started && (_this select 4 ) == "PipeBomb"}]; task5_tower2 addEventHandler["killed", {[_this select 0, _this select 1] execVM "addScore.sqf"}]; Sometimes map object ID numbers are not always visible in the editor, so I some times have to find the ID numbers using a script like this: (from Deadfast) init.sqf: while {true} do { hintSilent str (nearestObjects [player, [], 3]); sleep 0.01; };
  6. It sounds like a lot of work involved. I really appreciate all that you are doing. Again, I don't want you to drive yourself crazy with it, so if it seems like it's too great a task, I'll understand if you want to give up on it. I like ACE, ACE is great and I do use ACE in some missions that I create, but the mission that I am working on now is about 99% complete and does not require any addons at all and I kind of want to keep it that way. A stand alone Weapon to Backpack - Save Loadout - Player/Weapons Respawn script is something that I would like to use in this mission and in other Vanilla missions that I might make in the future. Without it, my mission will suck. It's one of the things that makes playing Domi so great, I just wish that it wasn't limited to Domi only. There are a lot of mission creators out there that I'm sure would like to use it in their missions too - without always having to install a bunch of addons to make it possible. Addons are fun, but I don't always like to use them in my missions because then my mission feels like less of my own.
  7. I appreciate that Kempco. I do want the help, but if it involves a lot of work, I'll completely understand if you decide to take a pass.
  8. In the x_init_backpack.sqf file there are a few variables that are used, like player_backpack and prim_weap_player. The very bottom lines in the x_init_backpack.sqf are: _p addEventHandler ["killed", {[0] call FUNC(playerkr)}]; _p addEventHandler ["respawn", {[1] call FUNC(playerkr)}]; and FUNC(playerkr) seems to check to see if the backpack is empty or it checks to see what weapon is currently in the backpack and it also controls the "grey" actions that appear in the players menu. So it seems to me that regardless of the save loadout script, the actually x_init_backpack.sqf script has it's own sort of built in save function, but obviously I'm having trouble getting it to work correctly. Right now the way it seems to work in my sample mission... If you add a weapon to your backpack and save your loadout and then die, you will respawn with the correct weapon in your backpack along with all of your other gear and weapons. But if you switch to your backpack weapon before you die, it them some how breaks the loadout that you saved - and upon respawning it seems to add to your backpack a duplicate weapon of the weapon you were last holding in your hand before you died. So my guess is that something in the x_init_backpack.sqf is causing the saved loadout to break the moment you add or switch to a weapon in your backpack. The backpack scripts that I am using acts as a stand alone script. Xeno posted it back in March 2011 here, but he did not post or mention anything about a save loadout script, so maybe he made that script to work without a save loadout script and gave the script some sort of built in save functionality. I can't be certain about this. After doing some research and extracting a couple of the newer Domination missions that use Xeno's backpack script, I noticed that the missions seem to only use the x_backpack.sqf since I was unable to find a x_init_backpack.sqf being used anywhere in the mission folders. But there were some files that used similar functionality to that of the x_init_backpack.sqf file, but I never found anything that used: _p addEventHandler ["killed", {[0] call FUNC(playerkr)}]; _p addEventHandler ["respawn", {[1] call FUNC(playerkr)}]; so maybe these EH's in Xeno's x_init_backpack.sqf script need to be used differently in my mission. If I was a expert at this stuff, then I could probably figure out how to simply take the backpack and save loadout scripts from the Domi mission and put it into my coop mission, but there are so many other things tied into it, like ace, confusing variables and other things, that I wouldn't know how to do it. It would probably be simple for any advanced mission creator, but I'm just not there yet. Still, I am very surprised that a stand alone backpack/save_loadout/player_respawn script was never released. It is one of the things I love most when I play on a Domi server. I usually won't play on a Domi server that doesn't use it. I don't even want to play my own coop missions without it.
  9. Not in the sample mission, but in my actual coop mission I have a script that activates at mission start for each player that removes all weapons from each player and gives them customized loadouts, then I have another script that autosaves their loadout (without a hint), so if a player doesn't manually save his or her loadout - it will do it for them. This was not absolutely necessary, but in my mission each player has the ability to call a single air-to-ground missile strike every 10 minutes and I wanted to make sure that every player was equipped with a Laser Marker and Battery at mission start - to save them the hassle of equipping the gear themselves. I also did not want players that do not use the "Save Loadout" action to respawn with standard weapons and lose the Laser Marker and Battery that was initially given to them, so the silent autosave loadout script helps, but the player does not start the mission with a weapon in their backpack. I figure that the players can have fun adding a weapon to their backpack themselves and save their own loadouts from then on.
  10. Hey, I'm looking for some help with a small coop mission I am working on and I am trying to incorporate the Domi "Weapon_Name to Backpack", "Save Loadout" and "Respawn with saved Loadout". There was a time when I tried to take the chopper lift script from a Domi mission and use it in a small coop mission, but for the life of me I was unable to get it to work, then later Xeno released a stand alone Domi style lift script at Armaholic and I was able to use it in my mission without any problems. I wish he would release a stand alone sample mission that uses the "Weapon_Name to Backpack", "Save Loadout" and "Respawn with saved Loadout", but as far as I know it doesn't exist. So that is why I am here. I did PM Xeno, but I never got a response, so I figured he's probably busy with other things. So I wanted to ask if anybody could help me. I discussed it in a thread I recently created here: Weapon to Backpack - Save Loadout - Player/Weapons Respawn Problem I've posted a sample mission that does work correctly except for 1 thing, if the player has a shotgun in their backpack and an M4 in their hand and saves their loadout, if they then die and respawn they will have all of their saved gear. But if the player switches to the shotgun and then dies, they then respawn without a shotgun and instead have an M4 in their backpack and an M4 in their hand. My coop mission is a 14 man coop Force Recon mission and Force Recon cannot wear a real backpack, so that is why I want to use the "invisible" backpack system. So my backpack scripts are slimmed down and only focus on the use of the "invisible" backpacks. Meaning... there is no need for any scripting related to typeOf backpack since their are no real backpacks of any type in the mission. If somebody could please help me with this I would be extremely grateful. Or if a stand alone backpack script/sample mission exists out there that already incorporates the features I need, please point me in the direction of it. I am aware that this section is for posting about "Editing, Expanding and Modifying Domination", but I also think that this is the right place for me to ask for help since I would imagine that some of the guys that expand on Domi would know how to help me with this. Maybe discuss it further in the other thread so I don't have to feel like I hijacked this one.
  11. First I just want to say thanks for all the help. I tried testing your sample .pbo mission, but had 1 small problem where it said that it was dependent on deleted files, so then I opened the mission.sqm file and removed 2 references to something called "msv_bags" so I could then be able to open it in the editor and re-save it as a .pbo and test it. While I was in the mission folder I noticed right away that there were no "Xeno" backpack scripts and I thought "hmm". I then tested the mission in MP and noticed right away that the player was wearing a backpack and upon scrolling down through the available actions I didn't see an action for "Weapon_Name to backpack". So I think there might be a little misunderstanding as to what it is exactly that I am trying to accomplish. I'm still very grateful for all the work you did. I don't want you to think that I am ungrateful at all. Your mission did test fine and everything works great in it as far as a "real" backpack is involved, but my mission does not have any "real" backpacks in it, but instead there is only the means of an "invisible" backpack. In my actual mission, I use units that are all: USMC > Men > Men (FR), better known as Force Recon, and Force Recon units cannot wear a "real" backpack, that is 1 reason why I am using Xeno's packpack script. The other reason is... I prefer not to have "real" backpacks in my mission since most my friends never bother to use them or don't know how to use them, lol. I could still very much use some help. If you have time to look at my sample mission and examine a few scripts, you might be able to spot the problem. To recreate the problem in my mission, simply scroll down and choose the action that puts your rifle into your backpack, then grab another rifle from the ammo crate, then save your loadout. Blow yourself up with c4 and you will respawn with the same weapon loadout. Now try it again, only this time before you blow yourself up, switch to the weapon in your backpack first, now blow yourself up and when you respawn you will no longer have the same weapon in your backpack that was there when you chose "Save Loadout", but you will instead have 2 of the same rifles that you were last holding in your hand. I think Kempco might have been on to the right track, but in testing his suggested changes I ran into problems where I would respawn and my loadout did save if I switched to my backpack weapon before I died, but didn't save correctly if I didn't switch to my backpack weapon before I died. Same problem as before, but an opposite effect. ---------- Post added 10-18-2012 at 01:04 AM ---------- Previous post was 10-17-2012 at 11:38 PM ---------- In attempt to find a better "save loadout" script, I searched around a bit and found a 2.71 Domi Lingor mission here: http://www.sog-team.com/forum/showthread.php?p=171614 This is the actually link I used to DL it: Download Vincentz_Domi_2_71_V1C.lingor.pbo (4.2 MB) I don't have Lingor Insland installed, and I don't often extract pbo files, but I extracted the mission and used "Windows Grep" to search through every file that contained any text regarding "backpacks" and found some interesting stuff. The x_backpack.sqf file in my sample mission is almost identical to the one used in the domi mission, so that's a start. I found a save loadout file under "x_client/x_savelayout.sqf", but it's totally different from what I was using. I found a lot of files/scripts that all seemed to be related to a "real" backpack, so I tried to stay focused on just the things needed to make the x_backpack.sqf work correctly in my mission. "x_client/x_setupplayer.sqf" starting at line 813, "x_client/x_playerspawn.sqf" contained a bunch of stuff. I'm not using revive in my mission, but I found some other stuff in "x_revive/xr_main.sqf"; Trying to make sense of all of this is a little over my head. I remember when I once tried to use the lift script from a domi mission and I nearly lost my mind. Then later Xeno released a stand alone domi style lift script at armaholic. I wish he would release a stand alone "weapon to backpack" script that incorporates the save loadout script on respawn. I have a feeling I'm about to lose my mind again, lol.
  12. I tried what you said and when I tested it - I switched to my backpack weapon and then I died and I respawned with the correct gear. The first thing I thought was "Yay it works now!", but when I tested it further I found out that it only worked if I switched to my backpack weapon before dying. Meaning... if I did not switch to my backpack weapon before I died, I would then respawn with 2 primary weapons. In other words - it was doing the opposite of the problem that was occurring before. I figured that I might have applied the new changes incorrectly, so I removed the changes and I made a sample mission using the old scripts - previous to the changes you suggested I make. I don't know if you have time to look at the sample mission and maybe apply the changes yourself. I am going to keep trying to see if I can get it to work correctly. I'm starting to think that the problem has something to do with the way the backpack script functionality, because when I switch to my backpack weapon, it normally seems to remember what weapon was in the backpack when I respawn even if I do not save my loadout. It's as if the save loadout script breaks the backpacks memory. save_loadout_test.Desert_E.zip I'm starting to think that maybe I should just remove the backpack stuff from the save loadout script and just tell it to save the player weapons and magazines.
  13. Thank you. I'll try what you said now. I'll throw together a sample mission too.
  14. For the save loadout I tried _unit = _this select 0; but it didn't work, so I went back to using select 1. I also played around with the loudout_respawn.sqf a bit and I tried using a different EH. Again, since there are no "real" backpacks in my mission, the changes seems to work fine. The problem still exists where - if the player switches to his backpack weapon and dies, he then respawns without it. If there was some way to get the player to switch to primary after dying, it might fix the problem, lol. I don't think that can be made possible. loadout_save.sqf _unit = _this select 1; _weapons = weapons _unit; _magazines = magazines _unit; _backpack = unitBackpack _unit; _backpackmags = getMagazineCargo unitBackpack _unit; _backpackweap = getWeaponCargo unitBackpack _unit; savedloadout = [_weapons,_magazines,_backpack,_backpackmags,_backpackweap]; hint "Loadout Saved"; loadout_respawn.sqf WaitUntil{not isNull player || isDedicated}; player addEventHandler [ "respawn", { _weapons = savedloadout select 0; _magazines = savedloadout select 1; _backpack = savedloadout select 2; _backpackmags = savedloadout select 3; _backpackweap = savedloadout select 4; removeAllWeapons player; removeAllItems player; removeBackpack player; {player addMagazineCargo _x} foreach _backpackmags; {player addWeaponCargo _x} foreach _backpackweap; {player addMagazine _x} foreach _magazines; {player addWeapon _x} foreach _weapons; _muzzles = getArray(configFile>>"cfgWeapons" >> primaryWeapon player >> "muzzles"); player selectWeapon (primaryWeapon player); } ];
  15. Everything you said makes sense. I was kind of wondering how "typeOf" would work too, since there are no actual backpack types in the mission. I will try making some more changes and testing a bit more. Right now everything seems to work except for one thing, for instance, if I put a shotgun in my backpack and have an M4 in my hand and save my loadout, when I die and respawn I have the same loadout, but if I switch to the shotgun in my backpack before I die, I then respawn without it and wind up with an M4 in my backpack and an M4 in my hand. I really appreciate all the help you are giving me. This is literally the only bug left in my mission that I am trying to sort out. Oh, I'm not sure if you meant that it was your Birthday today, but if it is, then I want to wish you a Happy Birthday! :)
  16. Ok, I'll try that now. Actually, the part in red was the one thing I changed and then it started working correctly. I changed it to that because I had noticed that _backpack = typeOf unitBackpack _unit; was already being used in the loadout_respawn.sqf script, so I then changed it in the loadout_save.sqf script so they would match. The loadout_save.sqf script used to have: _backpack = unitBackpack _unit; Though I am a little confused about what you said. You highlighted the line in red that referred to the actual backpack, but then you mentioned changing the line below it that referred to the backpack magazines. Should I change both lines so they look like this: _backpack = unitBackpack _unit; _backpackmagazines = getMagazineCargo unitBackpack _unit; And then what about the line that refers to the backpack weapons? Should that also be changed to be: _backpackweapons = getWeaponCargo unitBackpack _unit; I also just noticed that the loadout_respawn.sqf uses: _backpackmags _backpackweap and loadout_save.sqf uses: _backpackmagazines _backpackweapons So I changed those to match as well(using the shortened version), though I'm not sure how much that matters.
  17. I once tried to extract a mission .pbo file so I could examine a specific script that was used in the mission. After finding the script I then tried to make a new change to the script, then I saved the mission and tested it and the change I made did not take effect. It was as if the mission had some sort of protection built in, or scripted in - that prevented people from further editing the mission. I would actually like to be able to do this to one of my own missions if it's possible, but I don't know how I would do this. Does anybody know of a way that I could protect my mission so nobody can edit my mission further? A friend of mine released a mission and somebody decided to extract his .pbo file and then they added a bunch of Apaches and A-10's to his mission and they renamed the mission and were running it on their dedicated server and the credits in the mission were removed. My friend was very upset by this. Normally I wouldn't care if somebody were to do this to one of my missions, but then there are times when I might want to protect my mission.
  18. Honestly man, and I'm not trying to sound mean, but I didn't start this thread because I was interested in your opinion. Out of the zillion missions out there, you shouldn't really care if I apply some protection to 1 mission. Please don't use my thread to discuss your opinions. I started out simply asking how it can be done. I have seen it done, but I do not have the mission anymore that incorporated it and I don't remember the name of the mission or the author. If you want to "discuss" your opinions on it, please do it someplace else. If you do not know how it can be done, then you don't need to reply at all, because your opinion isn't helping at all. It's just spam. Again, the mission that it was applied to did not allow me to make further "saved" changes. If I added a truck to the mission and hit "Save" and then reload the mission, the truck was gone. It would not "Save" any new changes. Maybe there was a way to remove the protection that was added to the mission that prevented the ability to save new changes to it, but I didn't bother to look into it further since I was not interested in the protection feature at all at the time. Now I am interested and I would like to use it in 1 mission. I have no problems with somebody with mission editing experience from doing whatever they want with my mission, be my guest, but I do have a problem with an inexperienced editing noob that simply wants to place a bunch of A-10's and Apaches in my mission and save it his own mission with his name as the author and all credits removed. It happened to my friend and I wouldn't want it to happen to me. It honestly wouldn't be that big a deal if it did happen to me, but I'd still like to prevent it. My best guess is that it maybe had something to do with the name of the mission, like maybe there was some strange characters in the mission name. For instance, if you create a new "Desert.E" mission and place a few things in it and save it as "MyMissionVersion1.0" the game will save the mission as "MyMissionVerison1%2e0.Desert_E". So maybe the author might of somehow renamed his mission at the last moment and instead of using the editor to "Export to multiplayer missions", maybe he used some other method to compile/save it as a multiplayer .pbo file. I've always used the editor to save my missions, so I don't know if there is another possible way to save it as a multiplayer .pbo file. Again, this is my best guess as to how the author prevented the ability to save new changes. Yeah, an experienced mission creator could find a way to somehow duplicate the mission and edit it further, and they would probably add more cool stuff to the mission, but I am just interested in preventing noob mission creators from doing it.
  19. Gives me an idea. Add a small herd of goats, but make it so one of the goats can talk, but randomly, and make him still sound like a goat. Record a few growly voice files. Make the goat say3D something like, "Behhh, behhh, damnit this grass tastes terrible, behh, behh". Or make it so the cows sound like chickens and chickens sound like frogs.
  20. I can't remember the name of the mission, but I extracted the pbo and was able to open it in the editor. I then started to examine how the mission was created and found the part that I was most interested in, which was a "container in net" that had an action to deploy a motorcycle. I changed 1 little thing and hit save and preview, but it never saved the change that I made. So I tried again and the same thing happened. I then placed a bunch of west units all around just to see see if I was going crazy and hit save and preview and they didn't appear at all. So I went back and they will still showing in the editor, so I hit save again and then I reloaded the map and they were gone. I placed a truck and hit save and reloaded the map and the truck was gone. So I figured that I was happy enough that I was able to learn how to do what I wanted to do and I applied it to my own mission, then I deleted the extracted mission. It never occurred to me back then that I might one day want to learn how to apply the same "save" protection to my own mission. So yes, the mission did block the ability to save somehow. If anybody remembers a small coop mission where you start out behind a wall with some ammo crates, then you have to fight off a few squads of enemy at a near by town, and just as you make it into town there is a "container in net" near the road that offers the ability to deploy a motorcycle, ...that is the map I am referring to. It was a good mission. It had some working enemy mortars on a hill top too. It was made by somebody that I know from the forums, but I can't remember who. I am sure that the "save" protection that was put into the mission could probably be disabled easily somehow, but it had me stumped and I gave up pretty fast. It seemed obvious that the mission creator didn't want anybody messing with his mission. I'm still looking to find out how it was done. I'm not looking to discuss opinions as to why it should or should not be used. I like sharing, I share all the time, but I would still like to put that "save" protection in my next mission if I can. If it will prevent some noob from butchering my mission, hell yeah I wanna use it.
  21. That's just the thing. I have no problem with somebody extracting my mission and examining how I did something. They could simply take what they want from the mission and apply it to their own mission. I was just wondering how to make it so somebody cannot edit the mission further and re-publish it. It's just that... maybe I might not want to see a specific mission that I worked very hard to create get butchered and wind up on some dedicated server with somebody elses name on it as the author and all credits removed, like what happened to my friend. I don't think that is being selfish.
  22. I created a health status HUD feature for a coop mission. It's currently working great for single player, but there is an issue in multiplayer where if a teammate gets hit, his or her current health status is updated across each players health HUD/dialog. I have been trying my best to figure out how to fix this. Basically it's a very simple dialog in design. It just shows "Health: 100" in the bottom right corner of the screen at mission start and remains there throughout the game. It gets recreated when the player respawns. There are few different things that will update the health status like, an addEventHandler "Hit" that detects when the player is hit and calculates and converts the damage and then updates the HUD, then there is a heal script that will also update the HUD, there is also a trigger that will detect if the players health == 0 and update the HUD, and finally there is a trigger that detects when the player is alive(after respawning) and recreates the HUD. I need to find out a way to update the status of each players health HUD locally without it updating every players HUD. 2 basic things get updated. The color of the word "Health:" and the number value of their damage. Currently I am using the following code to do this: (_ui displayCtrl 1002) ctrlSetTextColor [0.25, 1, 0, 1]; (_ui displayCtrl 1003) ctrlSetText format ["%1", _hp]; Is there a way to update this info locally? My whole approach to making this health HUD possible might not have been the best route to take, but I am trying my best. I've discussed the HUD idea in other threads a little, but I wanted to create a new thread that relates specifically to what it is I am trying to accomplish. Here's an editor sample mission. It incorporates additional body armor, heal scripts, a vehicle to heal at, one invincible enemy rifleman, an ammo box so you can throw frags near yourself to test the updated health status. Oh, and a hide body script. health_hud_sample.Desert_E.zip I hope somebody can help. I care more about making this health HUD thing possible than anything else I've ever worked on for this game. ===================================================== These are the scripts and stuff used in the sample mission: Trigger to create the HUD: null = [] execVM "dialog\health_status.sqf"; description.ext: #include "dialog\dialog.cpp" dialog.cpp: dialog\health_status.sqf: player init:
  23. I wish I new why the armor acts differently for some units. I'm going to keep testing it. Here's a new sample mission with working Health HUD. I changed the HUD positioning and realigned the text. I tested at 800x600, 1024x768 and 1920x1080 and it looked good. I removed the background and added shadow that surrounds the text. I also tried to match the changing text colors to be consistent with colors seen in the game. The additional armor given to the units still needs a bit more testing since my friend seemed to die easier with fewer hits taken than me when I was hosting. It might actually work smoother on a dedicated server. health_hud_sample_2.Desert_E.zip For anybody that wants to test it, you can change the armor value by doing the following: The files called "EH_handlers.sqf", line 17: _damage = _olddamage + ((_this select 2) - _olddamage) * 0.25; you can change * 0.25 a value of * 1 would equal normal "overall" damage. Special thanks to SaMatra for all his help. I owe you big time.
  24. It works great now. OMG thank you! I made a few changes to the setHit stuff and that's working correctly now too. I got the medkits working as well as the heal at vehicle HUD update. The only thing I need to do now is align the text better. I had another problem with the damage stuff, but that is unrelated to the HUD. Basically both players have additional armor, but for some reason my friend seems to die much faster than I do and I don't really understand why since we are both using the same script. I'm going to try to get everything sorted out. I will repost a new sample mission soon.