Jump to content


  • Content Count

  • Joined

  • Last visited

1 Follower

About Logi

  • Rank

Recent Profile Visitors

836 profile views
  1. Its good to see that this script is still working with the latest version and still useful to people. Its been a long time since I played Arma, I have just update to 1061 today to give it a try.
  2. Does your AH.sqf file contain this line: if (isNil 'vehicles') then {vehicles = [];} else {if (typeName vehicles != 'ARRAY') then {vehicles = [];YOLO = true;};}; If so, change it to this and it should work: if (isNil 'vehicles') then {vehicles = vehicles;} else {if (typeName vehicles != 'ARRAY') then {vehicles = [];YOLO = true;};};
  3. What you are trying to do is actually very easy, but strangely I have never seen anyone post information about it. I have also been on many servers that have re-textured vehicles but none of them had actually modified the vehicles names in the trader menu. Anyway here is what you need to do: Get the player_traderMenuConfig.sqf from the dayz_code.pbo and place it somewhere in your mission file. Then in your compiles.sqf find this: call compile preprocessFileLineNumbers "\z\addons\dayz_code\compile\player_traderMenuConfig.sqf"; Change the file path to point to the location where you have just copied the file. Now open the player_traderMenuConfig.sqf file and find this line: _index = lbAdd [TraderDialogItemList, format["%1 (%2)", _textPart, _name]]; In the above statement, _textPart is the vehicles class-name and _name is the vehicles display name. So directly above that line all you need to do is check the vehicles class-name and if it is one of your re-textured vehicles you just alter the display name. Here is my example using the SUV_Blue and SUV_White. if (_name == "SUV_Blue") then {_textPart = "SUV Custom Texture 1"}; if (_name == "SUV_White") then {_textPart = "SUV Custom Texture 2"}; _index = lbAdd [TraderDialogItemList, format["%1 (%2)", _textPart, _name]]; EDIT So here is an example to match your question: if (_name == "SUV_Pink_DZE4") then {_textPart = "Hello Kitty SUV"}; This will only change the name that is displayed in the trader menu.
  4. Logi

    category file

    I have just had a quick look at your files and your EpochConfig.sqf still contains this: //Mission Based Traders DZE_ConfigTrader = true; Remove that or set it to false. Also in your MissionInit.hpp remove this: //Traders #include "TRADERS\cfgServerTrader.hpp"
  5. Logi

    category file

    Actually what Antichrist said will use the database traders and not the config traders, so his answer was correct :)
  6. I would suggest replacing the player add weapon command because it does not check if the player already has a weapon in the particular weapon slot. Instead I would recommend using the BIS function inventory add. Information on the command can be found here: http://www.ofpec.com/COMREF/index.php?action=read&id=231#invadd I would replace: player addWeapon _weapon; With: _result = [player,_weapon] call BIS_fnc_invAdd; Then check if the _result variable equals true or false. If the variable is true then the player got the weapon and you can remove the cash. If the _result variable equals false then the players weapon slot must already be occupied, in which case they would not be given the new weapon so you would not remove the cash. Edit You could also be nice to the player and do this (Only do this if the _result variable equals true): // Make the player select the weapon player selectWeapon _weapon; // Get the array of magazines for the selected weapon _magazineArray = getArray (configFile >> "CfgWeapons" >> _weapon >> "magazines"); _magazine = _magazineArray select 0; // Attempt to add 3 magazines for the selected weapon for "_i" from 0 to 2 do {_magResult = [player,_magazine] call BIS_fnc_invAdd;}; // Reloads the current weapon reload player; Basically it attempts to add 3 clips for the new weapon if the player has space in their inventory. If there is not enough space for 3 clips it will add 2 or 1 or none. The player will also select their new weapon and reload it.
  7. Hey calamity, lots of the files needed for version 2.0 are still not on the github. I think Nox just needs to authorize them and then they should be on there. Here is an example of mine anyway to give you an idea. AdminList = ["76561198134932428","76561198016880311"]; AdminNameList = ["Logi","D45"]; ModList = ["76561198134932428","76561198016880311","76561168916880111"]; ModNameList = ["louis","duncan","codz"]; The reason why I added these name lists was to enable users to have multiple privileges using the same PUID. For example if I login as Logi, I will be an admin, if I login as louis, I will be a mod and if I login with any other name, I will be a regular player. I done this so that I could play on my server as a regular player with no tools, but I can quickly re-log with an admin account if I need the tools for any reason. I am not sure if this is a feature that other people would want to use? I just left it in the tool for now to see what people think.
  8. I definitely think filtering the items is a good idea. Another control which may be worth considering is a textbox. I have not used textboxes in Arma before but you could try and filter the items based on the string from the textbox. That could save a lot of space in the GUI, but may be harder to implement. I have just created a quick mock-up with a textbox to see how it may look. It is barely bigger than a debug monitor.
  9. Yeah it would have been a better idea to discuss it in this thread. It is a lot easier getting all of the items from the config files and it makes the code much cleaner. Two commands which I often find useful for filtering the items are: isKindOf and inheritsFrom. typeOf can be useful as well. When I started making the GUI it was a lot smaller, it just got bigger as I added more features. I tired to keep it fairly small by making the spawn menus toggle-able and pre-mapping some scripts to the buttons. I like the idea of allowing the user to filter between the different categories of items especially for the buildings menu, there is lots of stuff in there. This could also be done for the other spawn menus such as vehicles and weapons. But there may be lots of different sub-categories for the buildings menu and I think it might not be very practical to create a lot of buttons in the dialog for the different categories. You would probably end up having to define a separate dialog for each different spawn menu. It might be better to list the different categories in a single listbox control. You could use a single dialog for all of the different spawn menus and just load the data dynamically from the config files like the other items. A listbox might also make it easier to show the sub-classes by using indentation or colour formatting. For example a mini GUI for the scroll menu could be implemented like this:
  10. Have you got any screenshots of your GUI so far? How are you planning on categorising the different buildings? I thought the tool was released under GPL. Obviously if you don't like my GUI and don't want to collaborate, I will ask your permission before I upload anything.
  11. Hi Nox, the code for the GUI that I created was on one of my test servers in a VM and I deleted it when I formatted my PC a couple of weeks ago. I have not really been on Epoch for the last 4 or 5 weeks because I have been very busy with coursework over the Christmas period. When I noticed your message, I had a bit of spare time so I was going to re-create the spawn building dialog menu for you, but I got a bit carried away. I ended up creating a full admin menu with all of the different spawn menus built into it. Then I had to modify the majority of the scripts to work with the dialog. I also had to completely re-write a couple of the scripts including all of the map marker scripts. I added a few new scripts as well. I modified my vehicle locator script to work remotely by selecting a player from the player list and searching their toolbelt for any vehicle keys. All of the tools work at the moment but I have only been developing it for 3 days so there is still a bit of work to do before it will be finished. Currently the dialog controls are pre-defined in a hpp file and then populated and modified dynamically in the code. I want to remove the hpp file and create the entire menu in the script. I don't know what you where planning on doing for a GUI but we could possibly collaborate if you like my GUI that I have built so far. The tool is a bit different now though. A lot of scripts have been pre-mapped to buttons, such as the lock/unlock, point to repair, show code and delete item scripts are mapped to buttons. The admin scroll menu is toggle-able from the dialog but I have not done many mods to the scroll menu or thought about what tools should be in it. I have created a github repository and will upload the code when I am happy with it. Here is a couple of screenshots.
  12. What I meant was, because our scripts are very similar, if you needed a infistar fix or if you had wanted to provide a version for the masterkey script, you could have got the information from my thread. The infistar fix is basically the same for both our scripts. You did not need to wait for ebaydayz to provide a fix you could have just looked at the one that I had provided with my script.
  13. You could have found everything that you needed here I had already created a very similar script. I had already provided the fix for Infistar users and I had also created a version to work with the masterkey script.
  14. He may not be taking credit for the code but he did not give any credit to the original author either. Nor did he mention where he got the code. Did the original author want this released? Was it stolen from a mission file? From the looks of those variable names, I don't think this was intended to be released.
  • Create New...