RimBlock
-
Posts
1140 -
Joined
-
Last visited
-
Days Won
3
Content Type
Profiles
Forums
Articles
Posts posted by RimBlock
-
-
I am currently thrashing out a proposal for encrypted codes which would allow tying the playerUID to the buildables. It may be helpful when I get round to start coding it. Need to finish my scripts first though.
-
While an interesting concept, I have a couple of problems with this as an admin.
Good points addressed below. Got me thinking about authorised parties. Thanks for the reply.1. A hacker will be able to bypass this pretty easily if they can execute scripts. why wouldn't they just animate the door open instead of entering the code?
1. How do you prevent this and why could the same technique not be used to prevent it as part of this suggested solution ?.
2. As an admin, it is helpful to have a key to tie an object in the in game world to the database. While a 3 digit code is extremely limited, it is still nice for me to be able to look it up and change it at the database level on one factor alone.
2. You can tie back to the object in the DB by objectID and you would have access to the encrypted key which would be the same in the DB. The difference is the method of authorisation being controlled by by a server side function to validate, not just on matching a client side number to a DB value.
3. Server impact. Making a server-side system to handle door codes will just put more stress on the server. Servers with large object tables area already slow enough. Having a server side handler for door code generation/validation might not put too much stress on the server but there will obviously be some overhead.
3. I can foresee 2 server side functions accessible whist the server has players on it.
- The first will take the player entered code and object (most probably cursor target). It will get the stored encrypted code from the object data and perform a simple decrypt (to make it simple lets say it will minus the server side value). It will then compare the result with the player supplied code and return true or false depending if there is a match or not.
- The second will take the playerUID (characterID dep on server setup) and validate the player as the safe owner and then re-encrypt the key (for simplicity sake lets say it will add the server side value to it).
The strength comes in the fact that the server side value is randomly generated on a weekly / bi-weekly basis and the keys are re-encrypted using the new value server side during a restart when no players are logged in.
4. How are players going to enter codes? Are they going to have a key fob that generates a random sequence for them based on the time? Are they going to just get in with their characteruid? Say I have 10 doors in my base, I use a spreadsheet to track them, now the values are going to change randomly, how do I keep track of this? how do I keep my group updated with the new codes?
4. Same as they do now. The solution is completely transparent to them apart from the fact they will get a self service option to reset the code if they are the owner of the item.
5. New Hive DLL. Do you have the sourcecode for the latest hive? If so can i have it . Unless you plan to use the existing character_id column and its limitations, you'll need to implement something new to work around this.
5. No hiveext.dll changes would be needed. The inventory field will have another subarray embedded (the same as the tagfriendly does in the character_date -> current state field). The field is longtext allowing over 4 billion bytes so is not an issue at a DB level. The data can be accessed in the same manner as the tagfriendly system gets the data from the currentstate field. There would be no requirement to convert the varchar playerUID to numeric for the characterID field meaning there is no risk of the result of the conversion being non-unique.
Current Inverntory field structure = [[Weapon][quantity],[ammo][quantity],[backpack][quantity]]
New inventory field structure = [[Weapon][quantity],[ammo][quantity],[backpack][quantity],[ownerID][encrypted lock code][permalock],[authorised access playerUIDs]].
If permalock is set then the item would need a code reset (owner or authorised parties self service).
A one time alignment would need to be performed for lockables as part of the install and from there onwards the code will add the new subarrays when the items are built.
The lock code is never in the clear on the client side or DB so hacker tools scanning the object data will not reveal the lock codes.
The security lies in the server side value changing regularly and hackers only getting 3 or 5 attempts before lockout. The only manual step at this time would be for an admin to change the server side value in a config file unless someone has a way of doing so automatically. Maybe a batch file randomly selecting a character_data playerUID then inserting the value in to a new variable (new_code_value). If new_code_value <> current_code_value then run the re-encode function on server start then change the new_code_value to current_code_value and clear the new_code_value (probably via batch file again). If the code change in the config files is not manual then some thought would need to go in to automating it.
Here's how I "solved" this problem. 1. Added 3 strikes rule. After 2 unsuccessful tries, the user is given a warning that if they continue they will be slain. On #3 they are killed 2. Logging: Any time a door code is entered, it gets logged either unlocked or a bad combo log. When an unlocked door is opened this is also logged. 3. Implemented a rule regarding not accessing doors in bases you don't have permission to acceess. With logging, it is easier to see who did what here. Rule #3 is mostly a catch all. I hate making arbitrary rules but we have people exploiting glitches to bypass the anti-brute force methods we have in place above. At least with logging, we can see who got in and how.
The logging is clearly needed in any solution. The management seems very admin intensive though. How does the admin know who the owner of the lockable is or do you keep a list of all lockables álive' on the server and compare when they get an unlock request ?.
There seems to be no mechanisum for non-owners but authorised parties to request a code reset.
The solution relies on the player having to get hold of an admin to change the code. That may be fine for your server if you have a number of admins available over a 24*7 period but for others who do not, a more automated solution may be better.
Log files will still need to be checked and activity flagged as is standard with any decent setup but the amount of admin cerntric work is likely to be a lot less.
-
The structure of the DB does not match the requirement of holding the safe code and owner with the present implementations.
The log reports that actual playerUID of the person who placed the item.
WinGrep will report on the log file and in a batch file can be scheduled to producte a report.
-
So I have some more movement.
Most of the undefined variables are now sorted.
I managed to get the fuel truck to flood fill (400l cycles) my Chinook from 45% full to totally full.
What this means.
- Fuel truck is recognised
- Chinook is recognised.
- Chinook is recognised as a flood fill compatible vehicle.
- Fueling rate per cycle is correctly set.
- Cycles are updating the fuel amount in both the truck and chinook correctly.
- Cycles stop when the chinook is full.
Current issues to check or resolve before moving to the next test.
- Full vehicle message did not have the vehicles name displayed - track variable and fix - fairly easy.
- Need to confirm the final cycle which required less than 400l actually removes the correct amount from the source (one or two extra debug lines should confirm).
Next test
- Fill non flood fill compatible heli (AH6)
- Fill non flood fill land vehicle (SUV)
- Same tests with source as fuel pump rather than fuel truck.
Hope to have most if not all of these done over the weekend dependant on family commitments. If all goes well I will start to optimise the code, do another full set of testing and then put a release together for Beta testing.
Interested parties please let me know.
-
Thanks.
I have tried to make it as [copy] -> [find] -> [copy] -> [paste] as possible.
I will get round to releaseing a package which people can then just extract to a vanilla Epoch server and be good to go. Probably will get this done over the weekend.
Good to hear it has stood up well with such numbers. This solution will work for now and I have tried to build in some longevity by allowing it to convert any characters in the PlayerUID rather than just known combinations that exist today as other mods have but I will get out a much more robust solution soon(ish) after I finish my Better Refueling project. The better solution will not use any conversion so the PlayerUIDs will always be unique and buildables will be linked to the plot poles rather than the players. Plot pole owners and authorised builders will be saved with the plot pole data.
@Line2.lv : Any luck with that script ?.
-
Does the Epoch flip vehicle not work ?. Have never tried it myself yet (https://github.com/vbawol/DayZ-Epoch/blob/master/SQF/dayz_code/actions/player_flipvehicle.sqf).
-
Just use wingrep on the rpt file to check for the text "VaultStorageLocked".
It will list out all instances in the log which you can then check.
Wingrep also has a command line so you could also wrap it up in a scheduled batch file.
-
Better trader city design and with their own ai guards would take out the need for safezones.
Sure someone could shoot you but then the AI would retaliate.
Give the AI a vehicle the players cannot destroy or use and have them send out hunting parties if attacked.
Make the AI deadly but not unkillable.
Put them on a headless client for minimal impact.
Have the trader cities with proper cover and multiple points of entry / exit.
Have a car park with guarded gate (someone posted up a bus as a gate script somewhere to give a Max Max type feel).
Have a heli landing area with a sheltered corridoor to the trading area.
Personally I like the idea of Starty having better walls, better parking facilities (there are plenty of good places near the trader city that can be adapted), and a stationary Shuka (ZSU_TK_EP1) on a slightly raised platform in the middle. Possibly CAS available from the NE hero trader (apache hunting down the bandits FTW).
For the backpack stealing, there is a script around to limit opening to only those tagged friendly but a method really needs to be developed for the removal of tagged frienlies or a open backpack request notification to the backpack owner that they then need to accept or have the backpack owner able to lock the backpack (right click the backpack from the gear menu).
The thought of having trader cities without any protection seems unrealistic (yeah I know.. in a Zombie infested world). The current setup is limited based on the awesome amount of work that the Epoch dev team had to contend with to get Epoch up and running and it works fine as a starting point. Safe zones are really just a bandaid for the problem where a more realistic solution is really needed. I would like to work on a better solution but it will have to go to the end of my todo list. I am also happy to collaborate with others if someone else wants to take the lead on this.
RB
-
Rimblock use Sandbird's editor for writing code. no need to restart a server, only thing you need to do is press a button. It has full database integration and for your needs you will be able to do everything you need.
Believe me when i tell you it will save you hours and days of frustration
Possibly, the problem is that Arma2Net is not working. I suspect it may be down to dot net 4.5.1 rather than dot net 4.0 that is required. Read that is has problems with Win 2012 r2 servers which come with 4.5.1 as default and are not able to downgrade (from what I remember).
I found the issue with the missing '')''. Turns out to compare a variable I believe was a string with a "text" value I need to use if(str(variable) == "text) rather then if (variable == "text"). That is now sorted.
Resolving some undefined variables then, hopefully on to testing basic functionality.
-
Mine came back with "False" after that command in the ARMA2NetExplorer.
What version of Dot Net are you using. I seem to recall a post concerning Windows Server 2012 r2 not working due to it having Dot Net 4.5.1 installed as default.
-
Check the HiveExt.ini to make sure all is what it should be.
Are you connecting via IP address or hostname to the MySQL server ?.
Do you have access to ping from the Epoch server ?.
Logs as MatthewK mentioned may be helpful.
-
Yep, he clarified (or pointed out my inability to read sometimes) in the other thread on the scripting help sub forum.
-
lol, i would never do that to my server.
This is what i am trying to do:
- Go up to a trader
- Buy/sell an item.
- Do a pickup animation (not the medic one)
- Complete transaction
- Happy :)
I dont know why you thought i was trying to replace pickup animation to medic one :huh:
Ok, my bad. That makes more sense :) .
I guess I do not generally see any pickup animation as I am usually in the gear screen when it plays for for me it is pretty instant
RB
-
Any chance you can include a menu similar to the traders where you could actually charge people for the refueling?
Such as 1L would cost x silver/gold etc... Would of been pretty cool, i know maca has this on his servers but i doubt he will share something like that :)
Should be faily easy to do, on the face of it.
Would just need to work out the mechanic for running the refuelling script after a trader item has been bought with a set of variables (amount of fuel to fill, target vehicle etc). Needs a bit of thrashing out but will add it for investigation after the core parts are done.
I do want to make the script more generic so it can be used many other places and its effects are tailored by the parameters it is passed. This would be an example of an area that could take advantage of it.
Saying that, I spent a couple of hours searching for a missing ")" in the first cut code which is currently unoptimised and at around 320 lines with multiple nested if statements. Each time I thought I may have found the issue I have to copy the files to the server, start up Epoch Server, login from the Epoch client, unlock the fuel truck, get-in and turn on, eject, choose the fill option.
All very time consuming so please don't expect a quick fix.
-
I would look at object_pickup.sqf in dayz_code/actions/ not sure if it iw where you need to put it but, going by naming, it could well be.
Animation names can be found here. Just change "medic" to one of the other animation names to get it to play.
Have a look at dayz_code/configs/configmoves.hpp for an idea of what may be available. The actual moves may be in the anim.pbo file.
Would think about adding an action to picking up items though.
Consider this....
Current system
- Running from zombies with an empty gun.
- Spot a stanag mag on the floor.
- Highlight it with the cursor,
- Open gear.
- Grab it.
- Close gear.
- Run and load gun.
- Shoot zombies / players.
- Much fun.
- Many happy faces :D .
With animation
- Running from zombies with an empty gun.
- Spot a stanag mag on the floor.
- Highlight it with the cursor.
- Open gear.
- Grab it.
- Close gear.
- Animation (1st sec).
- Zombies catch up.
- Animation (2nd sec).
- Zombies hit,
- Player bleeding,
- Animation (3rd sec).
- Many zobies surround player.
- Zombies hit again from multiple zombies.
- Player bleeding like a bucket with a hole at the bottom.
- Player tries to run and is blocked by zombies
- Zombies hit again from multiple zombies.
- Breaks out and runs.
- Finds somewhere to bandage.
- Loads gun.
- Tries to get blood back up.
- Get shot hunting for food and blood bags.
- Many, many sad faces :( .
THat is not taking in to account bandits who may place items somewhere and know that when someone picks them up there will be a 3 sec+ animation where they know the players movements and can easily snipe them.
Of course some people do like it Hardcore :) .
RB
-
bump, I would love my player to do an animation that happens when you pick an item from the floor.
Really ?. Everyting time you pick up a single object from the floot you want it to play a 3+ second animation even if you have zombies or players chasing you. I can see that getting very frustrating very quickly.
Is it possible in a future update to change the animation used when buying/selling to a trader to a shorter one? The current 'medic' animation is simply too long when you want to sell like 12 ammo mags...you can go make a cup of tea and it's still going when you get back! :)
Very easy to change but any suggestions which one to use that does not look ridiculous for trading.
The better suggestion is a trader gui where you can purchase or sell multiple quantities of an item in a single animation. Epoch has a trader GUI in the code but it is not active AFAIK. Not sure if it will be activated with 1.0.5 or is being expored for a future release / was a canned experiment.
I will be looking at traders and guis for a future mod I have in the queue (see my sig).
RB
-
Just tested on my server, works fine! :)
Thank you for the release!
Thanks, it is always good to hear it is working as expected.
I think i found it and looks easy enough.
fn_gearmenuchecks i have this
// IN SAFE ZONE if( !canbuild ) then { if( isPlayer cursorTarget and alive cursorTarget and vehicle cursorTarget == cursorTarget ) then { _friendlies = player getVariable ["friendlyTo",[]]; _ownerID = cursorTarget getVariable ["CharacterID", "0"]; _friend = _ownerID in _friendlies; // check if friendly to owner if( !_friend ) then { cutText["\n\nBag access is restricted in safe trader zones except with those tagged as friendly.", "PLAIN DOWN",0]; _display closeDisplay 1; }; }; };I changed CharacterID to playerUID and added it to the private array at the top, this should fix it correct?
Almost.
As some PlayerUIDs can have characters and the ids are being stored in a numberic field (object_data -> characterID) for the buildables, we need to convert, where needed, to numeric.
To run the conversion we use (<> denotes a value you need to put in, without the "<>".
<result variable> = [<object>] call convertPlayerUID;
<Result variable> = The variable you need the converted PlayerUID placed in.
<object> = The input object that have the PlayerUID you need to convert.
For your case I would try.
FInd
_ownerID = cursorTarget getVariable ["CharacterID", "0"];
Change to
_ownerID = [cursorTarget] call convertPlayerUID;
RB
-
That is probably the reason.
The old tagging used the charID. The new tagging used the PlayerUID converted in to a number (some playerUIDs can have letters as well).
The conversion needs to be done on anything that used the tagging to check.
If you are able to direct me to the post or post the code up here I can probably advise on the changes that need to be made. They are probably pretty simple.
RB
-
Although it may be a tagged friendly who placed it ;) .
Check the plot pole and then check the currentstate field of the owner. The last set of brackets holds the list of tagged friendly charIDs (or PlayerUIDs if you are using one of the charID -> PlayerUID mods for plot poles.
-
You could setup two variables. One that checks for the combat timer and one that stores the result fo the last check. If the last check = true but the current check = false then the timer has switched off and you could perhaps give a screen prompt that 3rd preson view is available again.
1st person only in combat and frivig at not slow speeds sounds interesting. Suits my play style more but I would imagine a lot of the CoD crowd would not be happy. Imagine all of Frankies videos if 1st person was the only choice :o. Oh the horror :D .
RB
-
Warn the user that if they logoff while disconnected they will lose any pending changes.
I tend to agree that object which can store other objects should have their own object_data record so they can be better tracked to make sure they are not duped.
Macas script (if it is the same as was orginially posted here) is centered around checking pre and post vault lock to make sure the souce and destination inventories have not changed in-between. There is still a potential for cheating though as a third party could unload the safe during the vault and their inventory is not under the checks. It would be tricky to execute as you cannot lock / unlock with another player within a set distance but may still be feasible. There was also the possibility of someone adding or taking from the locking players inventory (possibly innocently or without the locking players knowledge) whilst they are locking the safe and getting them flagged as trying to cheat. Macas soluion also had emphasis on reporting those who tried to perform the duping.
I personally believe in closing the holes and am not too concerned on reporting on opportunists who try to exploit them. I dont report everyone who port scans my firewall to their ISPs for example.
The suggestion to disable someone accessing the gear while the safe is locking was made on the original thread here (since deleted when Maca got banned) but Maca did not seem interested in engaging in any discussion around that line.
Having just scanned through the current vaultlock.sqf code, it seems the process is
- Check if safe already being locked by player.
- Check the safe still exists.
- Play animation
- Check safe is not being locked by someone else.
- Check player knows the combination.
- Create a new locked safe.
- Place the new safe.
- Copy the unlocked safe contents to it.
- Delete the unlocked safe.
Easiest fix would probably be to amend dayz_code/actions/dayz_spaceInterrupt.sqf and add code to check if the cursotTarget object is being locked.
This is not tested. Use at your own risk (this means it if turns your computer blue, gives you uncontrolable bowel movements or turns your mother in to a unstopable ninja killing machine, or anything else unexpected I am not liable ;) ). Something like the following may work.
Findif ((_dikCode in actionKeys "Gear") and (vehicle player != player) and !_shift and !_ctrl and !_alt && !dialog) then { createGearDialog [player, "RscDisplayGear"]; _handled = true; };Change toif ((_dikCode in actionKeys "Gear") and (vehicleplayer != player) and !_shift and !_ctrl and !_alt && !dialog) then{ _Cobj = cursorTarget; _CobjType = typeOf _Cobj; _Cobjectname = getText(configFile >> "CfgVehicles" >> _CobjType >> ("displayname"); if (_Cobjectname = "safe")then { if(s_player_lockvault < 1) then{ createGearDialog [player, "RscDisplayGear"]; _handled = true; }; }else{ createGearDialog [player, "RscDisplayGear"]; _handled = true; }; };Find
private ["_dikCode","_handled","_primaryWeapon","_secondaryWeapon","_nearbyObjects","_nill","_shift","_ctrl","_alt","_dropPrimary","_dropSecondary","_iItem","_removed","_iPos","_radius","_item"];
Change to
private ["_dikCode","_handled","_primaryWeapon","_secondaryWeapon","_nearbyObjects","_nill","_shift","_ctrl","_alt","_dropPrimary","_dropSecondary","_iItem","_removed","_iPos","_radius","_item", "Cobj","CobjType","CobjectName"];
What that should do is disable the lockers gear dialogue whilst the lock vault script is running.
THere is an object variable used as a flag to denote the safe is being locked ("packing") but it is only set after the animation...
Again, this is code I have written away from any test server so I have no way of confirming it works in any way, but logically it should be sound. It can also probably be improved upon so if anyone else wants to chip in then please go right ahead.
RB
-
I thought it was probably a good idea to have a resource with a list of helpful tools for Epoch server admins and mod makers that are not just Epoch mods. Hopefully it will help new server admins run decent servers and mod makers create content easier.
Tools for server admin
Robocopy - Like rsync for Windows. COmmand line or with GUI, can sync folders / files locally or remotely. Great for making a backup of files.
Tools for mod makers (Generic)
WinDiff - Compares two files and displays differences between them. Windows GUI version of the UNIX diff command. Part of the WinXP SP2 support tools free package from MS.
Wingrep - Will search for a text string in files in various locations. Great for finding references to variables or scripts from unpacked pbo files. Windows GUI version of UNIX grep.
DIffMerge - Compares locations, highlights differences in files and allows you to merge the differences. HamBeast wrote a great tutorial on it
WinMerge - Compares locations, highlights differences in files and allows you to merge the differences.
UltraEdit / Ultra Compare - Paid for product with many great features. SQF highlighting files are also available.
Notepad++ - Advanced text editor with SQF highlighting download available.
Sublime Text 2 - Advanced cross platform text editor. Free to evaluate but paid license required for extended use.
Tools for mod makers (ARMA II specific)
UnPBO - Extract files from PBOs.
Kegetys Tools - Contains
- CPBO - Extract files from PBOs.
- unRap - convers config.bin to readable config.cpp
- PPAPlug - Experemental PPA graphic file format plugin for Photoshop.
Bohemia Interactive Editing Tools Suite - Personal Edition 3 - Contains
- Oxygen 2- Personal Edition for Arma II - model editing and animation package
- Visitor 3 - Personal Edition for Arma II - terrain and map editing
- TexView 2 - texture convertor and viewer
- BinPBO - Personal Edition - packer
- Sound Tools - sound and lipsync utilities
- FSM Editor - tool to edit and compile fsms used in Arma 2
- BinMake - conversion tool
- Tools Drive - main working directory for tools with mandatory data files
- FontToTga - utility to create fonts for Arma 2
Armaholic has a large selection here but I have tried to highlight above the tools that seem most popular or that I am using so can attest to their quality / usability.
Source code repositories and version control.
- GitHub - Cloud based source code repository which is also currently used by A2 Epoch.
- Subversion - Source code repository software. Usually self hosted but some vendors now offer cloud hosting.
- CloudForge (see Gr8Bois info )
Post up yours and I will add them to the first post.
If we get a decent list then maybe it could be made a sticky.
-
We all know that feeling, you just got your server tweaked and optimized just how you like it and an Epoch update comes out! OH NO! what do we do? Wait for the mod authors to release their own patch? Hell no! We diffmerge!
....
Nice writeup.
Have been using wingrep and windiff and Notepad ++ but will now also take a look at this. Could help work out what changes users need to make to get a newly developed mod working (changes sometimes go unrecorded when debugging) :).
RB
-
I would suggest all to download Ultraedit and Ultracompare. Its Notepad++ on steroids.
Its 'compare' program is the best i've seen
But it is also US$99 for both and Notepad++ is free. DiffMerge, whilst free seems to have nagware to register for a small fee (how much is the fee ?).
I did like Ultraedit when I did the free trial but probably not $99 over Notepad ++. Saying that, Notepad++ text colouring is a bit annoying with some items being light blue or grey on a white background. Makes reading printed copies hard as well but that is more due to the syntax highlighting configuration I suspect.
RB
[WIP] - Better refueling (Accurate fuel capacity, multiple fuel sources, choose vehicle to refuel, GUI).
in A2: Epoch Mods (1.0.5.1)
Posted
Bit of an update.
In order to make the testing cycle a little faster I have taken out the requirement to turn on the engine of the fuel truck in order to get the fill option. Doing this has highlighted a bit of a potential exploit. Not this has not been tested but is most likely possible.
I found that although the refueling was working fine in game, it was not saving to the hive between reboots. I have now tracked down why...
Vehicle fuel data is saved to the hive when either all data on the vehicle is saved or the position data (which is included in all data) is saved. These saves are fires either on vehicle get in / get out or player_sync.
Not tested but, this leads me to believe you could use a fuel truck to refuel a vehicle. After the vehicle is refueled, don't touch the fuel truck (don't get in to turn off the engine, touch the gear or move it at all) but get in the refueled vehicle. I suspect on server restart, the refueled vehicle will be refueled and the fuel truck will revert back to the original fuel before refueling the other vehicle. Probably best to try fairly close to a server restart.
If someone can test and report back please it would be very helpful. If that is the case then I will file a bug report.
My script does a forced save to the hive of source vehicle and destination vehicle on exit so will stop this potential exploit.
Fuel truck to Chinook is working as desired. I will start testing with other combinations tomorrow.