[Release] - A Plot for life v2.5. Keep your buildables on death. Take plot ownership

[RimBlock]

A test zip file is up for 1.0.5 

 

Give it a go and let me know of any issues.

 

Note that in one of the files I found that the version for 1.0.4.2 had "object" as the variable and version 1.0.5 had changed it to "obj".

[RimBlock]

re-upped.  Missed the init.sqf on the first upload.

 

Fixed now.

[justchil]

So far so good.

 

This may just be the laggy connection/computer I'm using... but I built a cinder half wall - upgraded it.  Then tried to remove it.  It said "deconstruction of ."   Started looking at a file and came back and tried again and it worked just fine.

 

I don't actually play the game so I'm not sure how to test player_downGrade.  I also haven't tested tag friendly.

[oOSmokyOo]

Nice Job, it works perfect with 1.0.5  ;)

[KoTaS]

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.

[RimBlock]

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.

[Pro_Speedy]

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.

 

I thought the hotfix only changed a random chainsaw file nothing else so should still work fine, but ofc always make sure :)

[MrTesla]

I didn't notice any differences in the compiles, variables, fn_selfactions, fn_damageactions, or player_tagfriendly sqfs when I checked last night. From what I understand the hotfix didn't change anything scriptwise. There's a new key and entries for 2 different versions of the AH6J Little Bird: AH6J_DZ (spawns with ammo, but no Hydra pods) and AH6J_DZE (ammoless, no Hydra pods); neither have radar.

[RimBlock]

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.

[Phyrstorm]

I'm having an issue with the "Show Plot Boundary" still showing up when I am not looking at the Plot pole. Even if I am looking at another object it is still there. The section of code in fn_selfActions.sqf that deals with the maintain and boundary options is exactly the same between my selfActions file and the one included in your zip. I have not had a chance to test on a clean version of epoch yet but does anyone have any idea why this option won't go away and keeps multiplying every time I look at the plot pole? I am currently still on version 103718 of the arma 2 OA beta build and running this on a 1.0.4.2 overpoch server.

[RimBlock]

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) ?.

[BetterDeadThanZed]

It looks like the Player UID has now changed to a player's Steam ID, meaning every buildable will be unable to be maintained. I hope an SQL query can be made to change the old UID to the new Steam UID. 

[RimBlock]

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.

[BetterDeadThanZed]

Thanks for looking into this. I hope it can be worked out. However, there's a bigger problem. If everyone's PlayerUID becomes their SteamID, all players will start off as fresh spawns, so converting everything to their CharacterID might be moot.

 

For reference, here's a link with the changelog for Arma 2 125402: http://www.armaholic.com/page.php?id=10989

[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.

[mgm]

RimBlock,

 

Can you give me some advice please...

 

I have concluded my "play time" with Epoch and decided to host an actual server i.e.: won't be located in my house but in an actual data centre :)

From what I see Overpoch is the most popular mod variation since I want to have some human players (Sarge AI is fun and all but they tend to have a boring routine lol) I think I will attempt setting up the new server using latest epoch + latest overwatch.

 

So my question is, can I use your "testing" zip or should I just not do anything about plot poles for now and wait for your proper version 2.0 release? (for latest epoch).

 

Thanks

[RimBlock]

Hi MGM,

 

I have not seen or touched Overwatch or the Overpoch variations so really cannot comment if this will work for it.  Personally, if you are not currently running a server then I would not start now (am delaying making my server public too) until the switch to Steam is complete and the dust has settled or your new players are going to see a number of issues and assume it is your server and not the background changes that are causing the problems.

 

I would wait for the Plot for Life v2 if you are not running a server yet.  If you have 1.1 working fine then you could use that but a new method will be used for storing owner info so you will have to go through a conversion process from 1.1 -> 2.

[BetterDeadThanZed]

I just tested this in Epoch 1.0.5.1 with Arma 2 125402 and buildables are not being saved to the database. I can only assume this is due to the long UID's.

[RimBlock]

What is the current stable version of ARMA OA being pushed out via Steam ?.  Just want to get a feel on who many are likely to get affected.

 

Yep, if the SteamID is now being used, the object_datas characterID field cannot hold it due to size.

 

I have just started working on a solution now (9am where I am).  Will update on progress later.

[RimBlock]

First cut is almost ready for its first run.

 

I hope to have this also include tent and vaults (safes) which were still tied to characterIDs in the precious releases.

 

Currently there are 17 files that need amendment.  I will release as a zip  :) .  If all goes well I may have a beta ready for late in the coming week.  It will need a fair amount of testing as it touches the fn_selfactions and compiles.sqf quite a bit.

 

Have had a play with he new hiveext.dll and have finally managed to get a status response back but needs more work so will look at that for a future update after I get this one out due to the urgency.

[ftwbren]

Whenever I load in my server (using this script/mod) I load in with a black screen. Any advice?

 

arma2oaserver.RPT

 

All help is appreciated, I really am trying hard to fix it but left with no other options but to ask for help here. :(

[cen]

not looking good so far, come through Rim!

 

[RimBlock]

not looking good so far, come through Rim!

 

 

 

 

Whenever I load in my server (using this script/mod) I load in with a black screen. Any advice?

 

arma2oaserver.RPT

 

All help is appreciated, I really am trying hard to fix it but left with no other options but to ask for help here. :(

 

Guys,

 

There seems to be quite a bit of confusion.

 

Two things are going on at the same time.

1. Epoch release 1.0.5.1
2. Steam (mandatory) release of ARMA 2 OA which changes from BIS playerUIDs -> SteamIDs for identifying players.

Item 1.

Low concern and priority (see below).

 

Item 2.

Mod breaker.

 

Why is this so.

The BIS PlayerUID fits in the object_data characterID field (with a little conversion from text to number as the filed is number only).

The SteamID is 16 characters long and will not fit in the object_data characterID field (it is an integer field with a max size of 11 digits).

 

How does the issue manifest.

Hive errors as the code is trying to put data too big to fit in the characterID field.

 

But why was this not fixed before the Steam change.

BetterDeadThanZed was kind enough to point it out when it was discovered two days ago on the 28th June.

 

So what needs to be done to fix it.

It cannot be fixed in its current incarnation.  One of two options are curently available.

1. Store the SteamID of the owning player in a different DB field in the object_data table.
2. Use a custom hiveext.dll which enables more open DB communication so custom tables can be added and then utilised by sqf scripts.

So which direction is this mod going in.

Option 1 I had already been discussing with OtterNas3 when discussing collaboration on  various future projects before all these issues with SteamIDs came up.  We had already come to a conclusion on a good candidate field to store the data and roughed out a theory on how to do manage that data.  As the basic groundwork is already thought out, for the sake of a faster turnaround, I will be doing that.

 

How far have you got.

I have a first cut of the code and am just starting Alpha testing (checking the techniques work as expected / finding any typos or missed ';' and making sure basic functionality works).

 

When can we get our hands on it.

After I have finished Alpha testing I will release a test zip for Beta testing for those who want to take a look and partisipate.  After a bit of Beta testing, if the results look good, then I will release PlotForLife v2.

 

Will it be backwords compatible with v1/v1.1

No.  I will have to write a bit of SQL code to put the owners SteamID in to the new field being used of storing it in PlotForLife v2.  I hope to release that shortly after the PlotForLife v2 Beta but the main code is my current main focus.

 

But when will it be ready.

Sorry, no ETA as of yet.  Please bear in mind that I also work and have family commitments but I am aware that this is very important to a lot of you and I am spending as much time as I can to get this out as fast and as safely as possible.

 

What about option 2.

Option 2 I will explore after PlotForLife v2 is out as it will be the better solution but currently has some risks which I need to fully test and build in safeguards against before asking anyone to put it on their servers.  Safety is a major concern for me.

 

I will also put this information on the first page and take out the install info and download links to safe people installing and it not working.

 

Keep an eye on this thread as I will post updates as reguarly as possible to keep you all up to date.

[RimBlock]

What I may be able to do as a stop gap for the time being is put together some SQL so you can convert the already built items back from PlayerUIDs to CharacterIDs so you can just take out the mod and contine running the server.

 

I can only link back to the BIS playerUIDs though so you would still need to link the new SteamID characterIDs to the buildables afterwards just as anyone without the Plot For Life mod has to.

 

If this would be helpful for you then let me know and I will get something sorted out ASAP tonight.  If not I will continue working on v2.

[ekroemer]

Would performing this sql-statement on the object_data table help?

 

(beware, I did not yet test it)

ALTER TABLE object_data MODIFY COLUMN CharacterID bigint