RimBlock
-
Posts
1140 -
Joined
-
Last visited
-
Days Won
3
Content Type
Profiles
Forums
Articles
Posts posted by RimBlock
-
-
Unless you update the buildables characterID to the linked playerUIDs current alive characterID on login (if needed).
Not the neatest solution but it may be a reasonable 'tactical fix' for the short term until a more robust long term fix is put in place. Actually, thinking about it, apart from a slowdown on logging in, that could be done in maybe one or two sqf files and the rest would not need to be changed at all. We would not need to link the playerUID to the buildables but just keep the buildables updated with the players most current alive character. Only problem I can see is if a player has two alive characters (multi character mod from AxeCop for example).
Hmm, something to sleep on.
-
Thanks for the heads up on that BetterDeadThanZed.
Ok, so two things.
I should be able to put an sql update together to revert the buildables ownership back to characterIDs so people can continue playing without the plot for life mod.
I suspect the Steam playerUID will blow the max value for the characterID field but I have two other ideas on how to handle this and one of them was to be used for my second release. That was to be after my "better refueling" mod but I may have to push it to the front of the queue for now.
Zupa has made a HiveExt.dll available with 98 and 99 calls in it. I am yet to test but that should make putting custom tables in the DB for things like storing buildable ownership a very real possibility without any affect on any of the standard Epoch structure.
The other way was to put a nested array in another field that could better handle the playerUID. I have been discussing this with OtterNas3 who has also been using the same technique (it is also used to store tagged friendly player characterIDs by the Epoch team) and we think we have come up with a best place to store it. Need to check suitability based on Steam playerUID size but shouldn't be a problem doing this way either.
I will give this a priority but please bear with me whilst I work on it. I will get it out for testing ASAP but it is likely to take a few days.
-
Try setting "DZEdebug = true;" in your init.sqf and then look at your client ARMA2OA.RPT file usually located at C:\Users\[Windows profile name]\AppData\Local\ArmA 2 OA
I am currently building two new test instances for both 1.0.4.2 and 1.0.5 and will give both zips a test tomorrow after they are setup and verified.
Did you check to make sure the variables.sqf has the variable that is used to control the plot boundary in it (s_player_plot_boundary) ?.
-
would suspect player_updategui issues although the changes are fairly minimal there and the plot pole mod does not touch anything to do with the eye or ear symbol although they both have code in the same file.
Please report it in the mod thread and I will take a look.
-
Just trawling through the Git for EPoch I am not seeing any other changes in the last few days that are likely to affect anything here. I need to rebuild one of my test environments for 1.0.5.1 so will do so tonight and download the zip from dropbox to install just in case there is some sort of corruption with the latest version.
@KoTaS:
What is not working ?. Can you build, can you upgrade, can you downgrade, can you tag friendlies, what characterID values do you see in the DB for the new items you have just built ?. Any messages in your server rpt file or your client rpt file ?.
If you do not already have it, you could try setting DZEdebug = true; in your init.sqf file. That should help pinpoint what is going on.
-
Cant get this to work with epoch 1.0.5.1. done manual install and tried to install MPmission made file, still nothing. Get no errors on MySQL base.
The manual install is currently only for 1.0.4.2 but with a bit of looking around it can be made to work for 1.0.5 (mainly just changeing the 'search for' items slightly).
I need to check the differences between 1.0.5 and 1.0.5.1 which I will do tonight. If it is not working with the MPmission file then they may have changed something in those files.
-
=170= Sven2157
You are either not reading what I am writing or there is some sort of language problem. As such there really is no point in trying to communicate with you based on your aggressive and deliberately argumentative responses.
@mgm, zuba & TacticalStealth.
Sorry guys, I am going to bow out as I really don't need the abuse from this guy. Clearly there is something stopping us being able to communicate and I seem to be provoking more and more aggressive responses. I am happy to provide ideas and suggestions but will no longer monitor this thread. Feel free to reach out to me via PM or in my other threads.
@ Zuba
Thanks for the dll, I may reach out to you via PM on this. I will continue to work at seeing if it can be leveraged of the modding communities use if a safe manner without any recompilation.
-
Rim From what Zupa informed me on is 998 are the same as 999.
Thanks although from the repo I have looked at, 998 is listed as custom execution and 999 is custom streaming. Of course naming and functionality don't have to match :-).
-
If you fancy a bit of a learning experience then you could take a look at one of the software firewall / router distributions. Build up a small server (old PC with two network ports or a virtual machine to give some protection.
I have a Cisco RV320 (Small business dual WAN) router but will probably look at something else to help considering the number of over-entitled tantrum queens out there with scripted DDOS programs. I host a dedicated server (Dell 6100) from home.
-
Arma2Net allows querying any table with any table cell name...this new dll does not give you total freedom (yet) so it cant be used as a general solution especially in the editor...since god knows what type of scripts people are gonna be scripting. Update/insert/delete to any table and cell (with whatever name the modder wants to have) is a must in the editor.
Until this .dll gives you total freedom...then i cant update this mod.
I still dont understand why its not working with your machine....You are trying this in your home computer right ? Not the real server....What type of windows do you have ? Did you try disable UAC and firewall ?
Try disabling them and test again.
On the ARMA2NET really don't know. I did catch Norton removing the ARMA2NET Explorer because "not enough info on safety so quarantine'. That 'feature' has now been disabled.
Being able to UID I would think should be enough as I cant see why dynamic table creation and management would be required from scripts when structures can be created on a mod install. Indexing may be useful but only really on server start. SP execution would be nice and 998 may cover that.
THe ability to use ARMA2NET has improved as connectivity is possible with the explorer (which wasn't previously) but now the ARMA2NET GPFs when streaming objects loading the mission file.
I am using Windows 7 Pro with Dot Net 4.5.
-
What does the 999 call not allow you to do ?. The source code is not quite as easy to read with no c++ background.
I am also wondering if the .dll also has the 998 call as well (custom execute).
-
Hi Zupa,
Are 998 (custom execute) also included in the dll ?.
Thanks
-
Now we have a hiveext.Dll with the 999 call available, will you be producing a version using that so we are not dependant on ARMA2NET ?.
Would be fantastic if you are able. ARMA2NET with the mission editor still throws guys for me even though ARMA2NET explorer works and pulls back data.
-
I am quite happily using the beta server and client (1.63) via Steam. The client is marked as (Obsolete) in Steam but still works :) .
I get options for lan, Steam and one other option I cannot remember at the moment on the multiplayer server screen but the Gamespy logo is still in the top right corner.
-
Seems there is a 1.0.5.1 and may well be a 1.0.5.2 going by other threads.
May give this a go shortly, especially if you have got DZAI running on it. Just going to read the previous pages to play catch-up.
-
Those are performance related changes so do not omit them. Although the code will work fine without those changes.
Yes they are and I didn't :).
-
How do you figure all this?
- VBAWOL and the Epoch team, have already added, then removed the 999 calls, as they are a big security issue.
- Re-purposing fields is not a solution it is a band aid. You still have to use 999 calls to update the fields.
- As for your third bullet point. HUH!? but can't get a solid answer.
Having said all that -
I have my VS IDE setup, and over the next day or two, I will be trying to add a SPECIFIC set of functions to READ / UPDATE / DELETE data in a new relational table called:
`banking_data`. <-- There I made a decision.
Then you guys can code to that and its column names - to be listed shortly.
=170= Sven2157
On 999 calls.
You seem to be missing the point I have been making about trying to secure them, either that or you are deliberately ignoring it. Whilst the dev team on Epoch have put in great work I do not count them as the "end all" authority on 999 calls or hiveext. If you don't mind, I would like to take a look myself.
You may not like the idea and that is fine. You stating that they should not be used or even investigated closer at all because the Epoch team does not want to use them 'for security reasons' seems very closed minded.
For securing 999 calls, various techniques could include
- Locking down the sql query ('key' parameter) passed to server_functions.sqf by validating before firing to the DB much as you would to try and protect against sql injection attacks.
- Further lock down the queries with only parameters being passed from the client calls in the key parameter to the server_hivereadwrite function and then that 'key' parameter is checked, verified and if seems valid is inserted in to canned sql queries in the server side functions to create the final sql query to be fired at the DB. Each server could have their own canned sql queries.
Neither are particually hard to do and will give, if implemented correctly, a secure use of the calls.
Even without those restrictions, damage limitation can also be enforced by limiting the functions the Epoch DB user account has. As standard it should not be able to do much more than UID (update, insert and delete) to a limited set of tables. I read somewhere about people being concerned that 999 calls could be used to drop tables. Why would the Epoch DB account have access to that command ?. The only reason I can think of would be because the person setting up the account was not aware of best practices for secure application account creation and no guide seems to have been produced as part of the Epoch install.
On repurposing fields.
We seem to have different definitions on the term solution then. "Low hanging fruit" is a term commonly used in project scoping meetings and leveraging the currently available resources are just that. It gives people a working solution whilst developers are working on a better implementation.
The tag friendly system does the same with the players currentstate field. This is part of the Epoch release put out by the Epoch dev team.
On new calls.
Last I read (which you linked to) was "If I have time, I could dust off my C++ skills..." which would indicate nothing has been done. If you have started working on this then fantastic. It would be good to see what progress you have made.
For the rest...
Fully agree. As an IT project manager by trade I am finding it quite hard to not try and better organise the effort but as this is Zupas baby and, TBH, I have enough work on my plate and would rather just help out here and there. I am happy to offer suggestions, as I have, and people can take them or leave them. OPne major concern is that there seems to be no list of deliverables, schedule of when donators are expected to donate or how the donations are expected to be split between the people working on this. There also seems to be no organisation on team meetings (when, what is on the agenda etc).
Whilst it is great that you are looking to expand the hiveext.dll for this project, I am looking to see how the hiveext.dll could be leveraged to provide better DB interaction for all mods without people needing to go to ARMA2NET.
For custom calls, a more open solution would be
- Being able to write parameters to a set table via one hive call and then calling a stored procedure with another. The stored procedure would then only take data from the table the first call writes to.
This would depend more heavily on sql procedures for results which some are not so comfortable with but would lock the sql code away on the DB server rather than in scripts.
Creating a custom call to modify only a set table is great but will you then be creating more custom calls for any other tables that any other mods would like as / when requested by other mod makers ?.
- STENCHOVDETH and mgm
-
2
-
Ok, actually, let me confirm tonight. I def have it in my head that they are but the details are a little fuzzy about the testing as it was a while ago. I will recheck.
Personally I would rather remove based on last updated than the numeric value as if they are not reused then they should be else the number is just going to keep going up.
-
Hey throwing this out there, i am not one to judge on who thinks what is better, but from what zupa and i found the 500 calls are to retrieve data.
Re-reading with that thought in mind it would seem to be fairly obvious from the descriptions :D . Damn, not sure how that was missed.
Oh well. Good for reading static data.
So the three current possibilities for DB access and storage of persistant values seem to be
- Nest an array or repurpose a field for currency storage (already done).
- Use the 999 calls (Already done but maybe insecure in current state).
- Develop a new set of calls (nothing done on this yet).
-
Re-read earlier parts of this thread and it's probably best to do what's said to prevent folks from potentially losing their humanity when deleting dead characters.
Update: they are not recycled. Removed incorrect info.
The sql is still more robust though in the links below.
I posted a solution a page back based on the last updated date Put it in a stored procedure and fire it from a batch file or sql timed event (like the other Epoch housekeeping sql).
-
re-upped. Missed the init.sqf on the first upload.
Fixed now.
-
First, Happy Birthday.
Second, I am confused. So you have already compiled the new HiveExt.dll?
Why 999 calls, when they were already discussed and passed on? There is support for 50N calls, in the existing library, why not just use those? They are used exactly the same, but provide better security, through stored procedures. Why don't you just add the new calls, if you can compile it?
Not sure I agree with this call.
I feel that anything existing should not be touched. Unless you go through EVERY line, in EVERY script, you have NO WAY POSSIBLE, to say that they are not used. Also, if your scripts glitch, what impact does that have on the rest of the table? If the 999 calls are indeed, problematic, why give access to the real data of the server? Seems like a disaster waiting to happen.
Not sure that was warranted ... :huh:
=170= Sven2157
If you look further up you will note that I specifically asked for the hiveext.dll with 999 calls activated in it when Zuipa said he had a version. You will also notice that I said I had an idea I wanted to explore for securing the 999 calls.
999 calls were discussed and veto'd by the Epoch team but not here. It was acknowledged that 500 series calls would probably be better but 999 would be a fall back alternative as a system was already working with them (Zupas) and there is no known system out there using the 500 series calls but a few posts on gpfs when people have tried and no solutions that I have yet found. I will take a look at them though as the less changes that need to be done, the easier it should be to implement for people.
Doing a quick wgrep for various keywords related to the fields used give a responsible idea of any impact of using the fields. Personally I would not use a 'virgin' field as it may be used now or in the future. I would use an array field and nest another array inside and then just split it out on the object load to a internal variable. Adding another nested variable in the inventory or backpack after the last nested array can be easily managed and as the field is longtext with over 2bill characters (give or take hiveext limitations) should cause no problems. Doing it this way is a quick win for people. Refining it to use 500 series calls may be a preferred upgrade.
-
A lot of the changes I have seen are tidying up stuff like changing "and" to "&&", changing "foreach" to "count" and stuff like that.
I have just updated and released a new zip file for my Plot for Life mod for testing on 1.0.5. The manual instructions will be updated later this week.
The changes I had to make were pretty minimal hence being able to get an updated test version out in 3 hours after I started working on it.
-
Ok so: the sql/sqf current 999 calls.
_key = format["CHILD:999:SELECT `PlayerMorality` FROM `player_data` WHERE `PlayerUID` = '%1':[0]:",_playerIDzupa]; // current money gets loaded with normal sync _result = _key call server_hiveReadWrite;
_key = format["CHILD:999:UPDATE `player_data` SET `PlayerMorality`= %1 WHERE `PlayerUID`= '%2':[0]:",_banking,_playerid]; _result = _key call server_hiveReadWrite;
_headShotsZupa =_character getVariable ["headShots",0]; _key = format["CHILD:999:UPDATE `character_data` SET `HeadshotsZ` = %1 WHERE `CharacterID` = %2:[0]:",_headShotsZupa,_characterID]; _result = _key call server_hiveReadWrite;
Thanks and happy Birthday.
Steam Patch + Battleye + bans
in General Discussion.
Posted
Thats not good. Cannot even link playerUID -> SteamID changes via the battleeye GUIDs then...