Incoming Steam Update with SteamID + Databases, Server admin discussion

[kenx]

hmm cause for somereason that playeroldid isn't working

well what i mean is with base building when u die u cant rebuild u have to take the plot pole down and playeroldid wont work with it and anything u built priar to dieing u cant remove anymore either the steam id stuff really made a mess

[BetterDeadThanZed]

where do I get the 125548 patch for my server? we cant figure it out because we need to do the playeruidold otherwise plot poles are fucked along with removing stuff you put down with base building we cant figure out where to get that beta patch

 

Is your server hosted with a server host or do you run it on a dedicated machine?

[kenx]

dedicated machine

[Uro]

Way to hijack a thread about steamID's and databases. thanks!

 

Clearly you didn't READ my OP.

 

Use the forum search in future theres a bunch of threads about updating!

[Uro]

Just looked at all the other irrelevant posts in this thread.

 

Honestly!!!!! 

 

People try to start a serious discussion on these forums about a very serious issue regarding the mod and it's the same bloody forum trolls posting the same bloody crap thats in a million other threads on here, really don't know why I bother to try and highlight possible issues to the community.

 

I'm going to keep my thoughts and reservations to myself and the people who it concerns from now on.

 

Really pisses me off with the trolls and post counters on here!!!!!!

[ekroemer]

That's a very shortsighted point of view.

The new command getPlayerUIDOld is clearly stated as a temporary stopgap measure and not intended to be used indefinitely.

Any attempt to keep backward compatibility for a longer interval is bound to fail, imo and any mod that makes use of getPlayerUIDOld to avoid issues or the pain of upgrading now, will have problems, later.

 

Imo the most elegant and only future-proof way to go is to change the DB fields and the according read/write procedures in the hiveExt.dll.

 

Now I'll sound like a wiseass, but: changing the dll now would be a lot easier if from the beginning one would have used DB column specific typedefs instead of standard variable types. Then the conversion for object_Data_characterID could have been done simply by changing the corresponding object_Data_characterID_type from int to long (or whatever standard type covers the needed range) in a central header file instead of having to hunt down every occurrence.

[RimBlock]

I would think with the getPlayerUID if a player who doesn't have a PlayerUID it will report back the SteamID instead.

 

I wouldn't want to rely on the getPlayerUIDOld command for too long though, as it will be classed as legacy support, and like all legacy things they eventually get phased out over time as they are replaced with newer better things :)

 

Doh...  You know when you have been coding Epoch sqf too much when you forget ARMA II OA does not need a persistant DB.

 

Yep, so as long as the underlying data is still accessable by ARMA II OA (i.e. the CD Key or something else) then both commands will work.  It clicked when reading a response on the BIS forums and looking at the big picture.  Thanks

 

Yep, fully agree with the legacy view.

[RimBlock]

That's a very shortsighted point of view.

The new command getPlayerUIDOld is clearly stated as a temporary stopgap measure and not intended to be used indefinitely.

Any attempt to keep backward compatibility for a longer interval is bound to fail, imo and any mod that makes use of getPlayerUIDOld to avoid issues or the pain of upgrading now, will have problems, later.

 

Imo the most elegant and only future-proof way to go is to change the DB fields and the according read/write procedures in the hiveExt.dll.

 

Now I'll sound like a wiseass, but: changing the dll now would be a lot easier if from the beginning one would have used DB column specific typedefs instead of standard variable types. Then the conversion for object_Data_characterID could have been done simply by changing the corresponding object_Data_characterID_type from int to long (or whatever standard type covers the needed range) in a central header file instead of having to hunt down every occurrence.

 

Agreed.  Rather than using the playeroldUID to keep the playerUID valid, it should be used to convert old players to the new SteamID so the old playerUID can be phased out in a more controlled manner without people loosing everything.

 

It should be good for changing the buildables ownership in my mod from playerUID to SteamID but have not really thought on how it could be leveraged to convert player records.

 

How about on login;

1. Load player info.
2. Get players old playeruid
3. Fire a hivecall to load the old player record based on the old playerUID
4. Check to see if already marked as converted (see step 7).
5. Copy the field values to the current players field values.
6. Save the current player record.
7. Change a field in the old player data so as to indicate the conversion has completed and the record can be deleted.
8. Change the old player alive to dead (0 IIRC).
9. Save old player record to the DB.

Will have a look once my Plot For Life release is considered stable (few days hopefully).

 

oh, one other point.  I have had the new BE exe flagged in Norton as a trojan virus.  Seems sother have two on the BIS threads for the betas. 

[ekroemer]

It should be good for changing the buildables ownership in my mod from playerUID to SteamID but have not really thought on how it could be leveraged to convert player records.

 

I must admit that trying for a smooth transition from only the old characters to new ones seems to be a point of minor importance judged by the reaction of our server's community.

 

Our facebook group is full of people who had absolutely no clue whatsoever about the Gamespy shutdown and the need to switch to 1.63.

Given this fundamental lack of information the additional work of manually transferring gear pales before the effort of explaining over and over what has to be done to be able to connect to the 1.63 servers in the first place.

On the bright side: the additional outcry when we simply truncated our character_data was negligible in comparison ;-)

 

I guess there's a significant difference between DayZ and Epoch: the former makes you hold on to your gear with nails and toes, in the latter you have bases and safes and most of our players don't give a thought about dying thrice a day.

[RimBlock]

Our facebook group is full of people who had absolutely no clue whatsoever about the Gamespy shutdown and the need to switch to 1.63.

Given this fundamental lack of information the additional work of manually transferring gear pales before the effort of explaining over and over what has to be done to be able to connect to the 1.63 servers in the first place.

On the bright side: the additional outcry when we simply truncated our character_data was negligible in comparison ;-)

 

Yep good point on the 1.63 requirement and lack of advertising, even on Steam.

 

A number of servers run mods like mine though so their players can invest in large bases that they do not loose as soon as they die and this is affecting them pretty badly as well.

 

Epoch is more forgiving than DayZ but if someones found a rare weapon and suddenly loose everything and cannot access the hero trader etc it is not great for the server.  Most people will accept, some will rage quit.  Now if you can make it so the players are not affected and other servers are having that problem then +1 for your server.

 

Anyhow.

[BetterDeadThanZed]

I know if I'm playing a game and suddenly there's a change and I can't get onto any server I'd be going to the forum for that game to find out what the deal is. I don't understand how people could be so clueless.

[Kenturrac]

If people leave for such a small reason I wouldn't expect them to stay longer than a week anyway. Can you remember your gear from two weeks ago? I cant. If I cant remember right now, why should I care? It's not like I would lose a base which is worth 20h of playing. Humanity could be a thing, but hey, starting all over could be interesting.

 

And again, if they really really care, they will mention it in the side chat and you as an admin can approach them and change their humanity manually. Just watch the sidechat logs once a day. You should do that anyway.

[BetterDeadThanZed]

I agree Kenturrac. I offered to restore the humanity of any of my players due to the UID change and to help them get back to their base. So far no one asked to have their humanity restored and a couple people asked to have vehicle keys replaced but no one has complained about a loss of gear. I posted about the changes on the forum before they took effect and sent an email to all my registered users but there are still people who are confused.

[ekroemer]

but if someones found a rare weapon and suddenly loose everything and cannot access the hero trader etc it is not great for the server.  Most people will accept, some will rage quit.  

Yes, but this is happening all the time, anyhow. People are dying through glitches or are kicked for no reason while flying heli, and so on. In these cases we substitute the gear, anyhow. Reinstating humanity is standard, too, because of the frequent humanity reset on re-spawn for whatever reason...

 

The problems the update poses to your PlotForLife are vastly greater.

 

 I posted about the changes on the forum before they took effect

We announced the change, too, but it seems most of our players couldn't be bothered to read the website, regardless of the links to it on loading screen, TS, ingame chat ;-)

[cen]

 

I feel bad for Dave since that's all he gives out for donations :D

[MGT]

 

I feel bad for Dave since that's all he gives out for donations :D

 

Covered!

 

Humanity will be lost so take a note and post in this forum with the following format

Ingame Name ******

New Player UID (not guid) ******

Old Player UID (not guid) ******

Server Map ******

Humanity you had ******

 

[kenx]

so now Im totally fucking confused so for some reason I thought this whole steam update thing would prevent you from joining commander... but im able to join any server that is verison 12555 when gamespy went down I could swear I couldn't join any server on commander hence why I thought we had to update to beta... so if a server stays on 12555 they don't have to change anything on there server and people can just join like gamespy didn't exsist or am I missing something?

[tidyxgamer]

Hi,

 

First post, but thought I'd say how I am doing the changeover stuff.

 

Its a small server, so not an ideal situation for more established ones... but to save messing around with giving people new stuff, setting humanity randomly etc... I have just switched out the old character details for the new ones by overwriting the playerUID in the character_data with their new ID.

 

For small server owners its a piece of cake as you can just find the player name to get their old PlayerUID

 

Find the playerUID in character_DATA table, and replace it with the new players steamID.

 

(if there is already a character_DATA with the steam ID - its prob a fresh spawn and you can delete it) 

 

Its a tedious process, but its simple, and fairly straight forward.

 

If your users cant get the game to work / connect to your server since the update - I wrote a tutorial on my site, but not sure if I can post a link - please let me know :)

[tidyxgamer]

On another note, if you are doing the character ID switch and don't want to use PHPMYADMIN, use something like heidisql, its free and works wonders :)

[nedfox]

We welcome our old new players with 2BC and they'll carry on, just as dying once in game.. Reclaiming plotpole is all after that.

 

My thoughts are : since the playerID is now the same across all accounts (remember the AX playerID problems with Origins?) , would it be a great chance to change some code and finally bind the playerID to buildings and PLOTPOLES ?  It makes all the plotpole4life crap obsolete and would be GREAT for our players.