Base Building DayZ 1.2 Released

yeah it logs to client rpt. and I get a value for _objectUID, and a 0 value for_objectID. But it doesn't delete, as mentioned it just creates new entry in the db.

but then if I create a *new* object it also has _object=0, but yet it does delete properly and recreate with a new code.

it is very strange.
 
Yeah that's normal that it's returned values. The point of doing that though was so you could compare what it said in the log, to what the UID is in the DB.
As I said before, the objectUID is recalculated at every startup of the server. So yes, it will always match what's in the DB if the server hasn't restarted because the UID assigned when it's created is exactly what it's written to the DB. This eventually breaks though because the object shifts slightly during a startup and then it never goes back to the exact decimal place it was sitting at when it was first built.

Take the UID it printed in the log and compare it to the UID of the object you're trying to delete in your DB to see if it matches. Chances are, it doesn't.
 
Ok I'm obviously missing something extremely fundamental here, so I'm going to go through it step by step:

1. I create a new object:

Code:
23:06:40 "DEBUG: Checking if Object: 1755dd00# 1056727: fort_bagfence_long.p3d REMOTE is allowed published by Server"
23:06:40 "DEBUG: Object: 1755dd00# 1056727: fort_bagfence_long.p3d REMOTE published by Server is Safe"
23:06:40 "ATTEMPT WRITE: CHILD:308:1:Land_fort_bagfence_long:0:76739142:[2.80381,[4115.15,2664.99,0.377721]]:[]:[]:8.205:411512665043:"
23:06:40 "WRITE: "["PASS"]""
23:06:40 "PUBLISH: Created Land_fort_bagfence_long with ID 411512665043"

Object is created in db with unique_id=411512665043

2. I change objects code to 2222:

Code:
23:08:41 "objectID: 0"
23:08:41 "objectUID: 411512665043"
23:08:41 "ATTEMPT WRITE: CHILD:310:411512665043:"
23:08:41 "WRITE: "["PASS"]""
23:08:41 "DELETE: Deleted by UID: 411512665043"
23:08:44 "DEBUG: Checking if Object: 1755dd00# 1056727: fort_bagfence_long.p3d REMOTE is allowed published by Server"
23:08:44 "DEBUG: Object: 1755dd00# 1056727: fort_bagfence_long.p3d REMOTE published by Server is Safe"
23:08:44 "ATTEMPT WRITE: CHILD:308:1:Land_fort_bagfence_long:0:76739142:[2.8055,[4115.19,2665.02,0.000106335]]:[]:[]:2.222:411522665003:"
23:08:44 "WRITE: "["PASS"]""
23:08:44 "PUBLISH: Created Land_fort_bagfence_long with ID 411522665003"

object 411512665043 is removed from db and object 411522665003 is created with code 2222.

3. server is restarted

4. I change objects code to 7777:

Code:
23:15:37 "objectID: 0"
23:15:37 "objectUID: 411522665000"
23:15:37 "ATTEMPT WRITE: CHILD:310:411522665000:"
23:15:37 "WRITE: "["PASS"]""
23:15:37 "DELETE: Deleted by UID: 411522665000"
23:15:40 "DEBUG: Checking if Object: 21d85600# 1055904: fort_bagfence_long.p3d is allowed published by Server"
23:15:40 "DEBUG: Object: 21d85600# 1055904: fort_bagfence_long.p3d published by Server is Safe"
23:15:40 "ATTEMPT WRITE: CHILD:308:1:Land_fort_bagfence_long:0:76739142:[2.80928,[4115.21,2665.03,0.000109673]]:[]:[]:7.777:411522665003:"

I now have *2* objects with the same unique_id of 411522665003, the original one with a code of 2222 and the new one with a code of 7777.
 
You're not missing anything, except what I'm saying about it miscalculating the UID on restart. :p

When you look at what you've posted in the third code block there, you can clearly see that what it thinks the UID of the object is, is not what the actual UID is in the database. This has happened because the object has shifted by a tiny amount during restart so it's miscalculated and now it can't remove the object via it's UID. There is no way to stop it miscalculating the objects UID that I know of (and I've looked a lot for a solution). It's the reason our original code system fell apart, and it's the reason removal of objects often fails to remove them from the DB.

For the time being, disabling the edit function will at least allow your players to use the 4 digit code they are given when building the panels and those will work reliably.
 
hmmm yeah, ok i think i'm beginning to understand. It's a shame but i guess these are the limitations of the underlying code. thanks once again for your help.
 
Just a quickie, something I've been thinking about for a while now...
regarding concrete walls and info stands.

To explain my idea it's best if I set the scene, say I have a base, the base is built out of double stacked shipping containers. In the center are two concrete walls used as a gate. In front of this, to provide cover for anyone entering the base is a "tunnel" made from double stacked shipping containers.

The idea I've been throwing around is having the ability to have a second lot of concrete walls at the end of the tunnel that are on the opposite sequence to the "doors" So say I enter the code to lower the doors that allow access to the base, the second set will close blocking any enemies from entering the tunnel, giving me cover while I fanny about and get into the camp...

Is it possible to change parts of the script to allow this or would it be much more work?
 
There aren't any SQL scripts to add more buildables.
To add items to the build list you need to do three things; add them to the build list in the client files, add them to the build list in the server files, then add them to your database.
Adding to the database varies on which hive version you run. If it's @reality then you just need to do this as an SQL query.
Code:
INSERT INTO `deployable`(`class_name`) VALUES
('item1'),
('item2'),
('item3')
 
That's what I figured, Rosska. Your explanation was what I figured. I was hoping there was an SQL table file exported from the 'instance deployable' table that I could use to import or open with Notepad++ and go about adding to the table. Anyhow, thanks for the reply.
 
So BB 1.2 works well....however I cannot build the "infostand" even when I have the materials. The "build" button is "whited out", not allowing me the option to build. Anyone else have this issue or a fix?

Thanks.
 
I've got a couple of weird issues .. I have some tent inventory updating that is not working, but only sometimes, and tent placement has to be completely in the open, collision isn't being allowed. Can someone look at my server monitor and see where I may have snafu'd?

http://pastebin.com/YKUc5zh0

Here's the server_updateObject
http://pastebin.com/nZ9UGLWM
Thanks!

Hmm... You already have the tent fix in place so I'm not sure why they would be having inventory update issues. As for the tent placement, that's not something you've done wrong, that's just the "intended behaviour" for 1.8+ tent placement. It sucks majorly. I actually altered the scripts for tent placement to just allow placement everywhere and to bypass the checks. I'll try and dig out the files and PM them to you, but I have the flu just now so it might take me a little while to find them.

So BB 1.2 works well....however I cannot build the "infostand" even when I have the materials. The "build" button is "whited out", not allowing me the option to build. Anyone else have this issue or a fix?

Thanks.

Can you build everything else ok? Have you edited the build lists at all?
 
Hmm... You already have the tent fix in place so I'm not sure why they would be having inventory update issues. As for the tent placement, that's not something you've done wrong, that's just the "intended behaviour" for 1.8+ tent placement. It sucks majorly. I actually altered the scripts for tent placement to just allow placement everywhere and to bypass the checks. I'll try and dig out the files and PM them to you, but I have the flu just now so it might take me a little while to find them.

The problems I have may have been related to restoring some rows to the instance_deployables table so I will try to sort that out. Thank you for looking over my files, given you had mentioned that there are different versions of the server_monitor floating around, I started to second guess myself.

I'm sorry to hear that your down with the flu. Whenever you get a chance to find those placement overrides I'd appreciate it; that was the direction I had started with my code, but at a first blush it was still checking the placement so I reverted my configs.
 
No Rosska, I haven't edited anything in regards to the BB 1.2. It's all default. Nothing special or edited. I haven't looked through any info for fixes or found any threads yet about anyone else having the same issue, although I'm sure I'm not the only one.

I'll keep sorting through this thread (I've read the first 20+ pages).
 
The problems I have may have been related to restoring some rows to the instance_deployables table so I will try to sort that out. Thank you for looking over my files, given you had mentioned that there are different versions of the server_monitor floating around, I started to second guess myself.

I'm sorry to hear that your down with the flu. Whenever you get a chance to find those placement overrides I'd appreciate it; that was the direction I had started with my code, but at a first blush it was still checking the placement so I reverted my configs.

Ah possibly yeah. I've noticed some strange results myself when restoring data to tables. I tried restoring a couple of vehicles at one point and somehow it stopped any vehicles updating to the DB after that point, which was annoying as I ended up having to wipe the entire table to fix it. :(

Thanks man. I will try to get them to you tonight or tomorrow, I just need to be able to focus long enough to remember which files I had to edit haha.

No Rosska, I haven't edited anything in regards to the BB 1.2. It's all default. Nothing special or edited. I haven't looked through any info for fixes or found any threads yet about anyone else having the same issue, although I'm sure I'm not the only one.

I'll keep sorting through this thread (I've read the first 20+ pages).

If you can upload your mission files somewhere and link them to me, I can take a look at them when I get the chance and see if it's maybe something simple. It's a strange bug though, that's for sure. Have you noticed the problem with any other build items, or is it just the info stand?
 
Here rosska I will save you the trouble mate, here's a 1.8 object_build.sqf that will allow you to place tents anywhere you like

http://pastebin.com/vSQctrGg

you also need to update player_build.sqf to call the updated object_build.sqf line 73 and 74 need to be changed to

Code:
s_player_tent_build = player addAction [localize "str_player_build_complete", "fixes\object_build.sqf", [_object, _item, _classname, _text, true, 20, _sfx], 1, true, true, "", "!isNull (_target getVariable [""constructionObject"", objNull])"];
s_player_tent_cancel = player addAction [localize "str_player_build_cancel", "fixes\object_build.sqf", [_object, _item, _classname, _text, false, 0, "none"], 1, true, true, "", "!isNull (_target getVariable [""constructionObject"", objNull])"];
^ Assuming you put the object_build.sqf in a fixes folder.
Can't remember if the old 1.2 basebuilding uses the default player_build.sqf or not to be honest, if it does just change line 73 and 74 in that file. If not add player_build.sqf to your mission file and change compiles.sqf to include it
E.g
Code:
player_build= compile preprocessFileLineNumbers "dayz_code\actions\player_build.sqf";
 
Here rosska I will save you the trouble mate, here's a 1.8 object_build.sqf that will allow you to place tents anywhere you like

http://pastebin.com/vSQctrGg

you also need to update player_build.sqf to call the updated object_build.sqf line 73 and 74 need to be changed to

Code:
s_player_tent_build = player addAction [localize "str_player_build_complete", "fixes\object_build.sqf", [_object, _item, _classname, _text, true, 20, _sfx], 1, true, true, "", "!isNull (_target getVariable [""constructionObject"", objNull])"];
s_player_tent_cancel = player addAction [localize "str_player_build_cancel", "fixes\object_build.sqf", [_object, _item, _classname, _text, false, 0, "none"], 1, true, true, "", "!isNull (_target getVariable [""constructionObject"", objNull])"];
^ Assuming you put the object_build.sqf in a fixes folder.
Can't remember if the old 1.2 basebuilding uses the default player_build.sqf or not to be honest, if it does just change line 73 and 74 in that file. If not add player_build.sqf to your mission file and change compiles.sqf to include it
E.g
Code:
player_build= compile preprocessFileLineNumbers "dayz_code\actions\player_build.sqf";


So, after running with this code, I had even more inventory update "issues" than before. Before I believe the problem was related to placing a tent with the default process, then trying to move the tent's position via editing the location field in the database. Doing so made the tent "read only". With this script, I was able to place the tents correctly, but they too became "read only". What's weird is that the tent would record correctly to the database, but you could not update the contents. It would persist through a restart, and you could remove the tent. I have removed the tent placement addon and newly placed tents are fine, but the old tents are still bugged. The only thing I can see is the worldspace coordinates for their location seem different if placed by the default process or by the addon:
Default: (OK)
[335,[5564.52,13865.5,3.052e-05]]
Addon: (Bad)
[269.966,[4734.26,5127.15,0.01]]

Any ideas ? I know this is a weird one...
 
So, after running with this code, I had even more inventory update "issues" than before. Before I believe the problem was related to placing a tent with the default process, then trying to move the tent's position via editing the location field in the database. Doing so made the tent "read only". With this script, I was able to place the tents correctly, but they too became "read only". What's weird is that the tent would record correctly to the database, but you could not update the contents. It would persist through a restart, and you could remove the tent. I have removed the tent placement addon and newly placed tents are fine, but the old tents are still bugged. The only thing I can see is the worldspace coordinates for their location seem different if placed by the default process or by the addon:
Default: (OK)
[335,[5564.52,13865.5,3.052e-05]]
Addon: (Bad)
[269.966,[4734.26,5127.15,0.01]]

Any ideas ? I know this is a weird one...



Yup you will see that bug more frequently when not using the default object_build. I believe this bug is the reason the dayzmod team added all these constraints to where you can place a tent in the first place. You will definitely see it if you move a tents worldspace because you haven't update its uid to go with the new worldspace.

The objectUID from the database is calculated based on the position of an object. It is nothing more than a different representation of worldspace coordinates. It's used for all the keycodes in basebuilding 1.2. This is the unique identifier used by a client to update a tents inventory etc. The clients cannot read the database they pass the uid based on the objects position, if that uid doesnt match the uid that was originally inserted into the database (because something has caused its position to shift, like another object being close to it) then no database updates are possible. Even if you pack it it will respawn after a restart afaik.

I suggest staying on the default object_build and deleting all tents an stashes that have not been updated recently in the database if you are having problems. In basebuilding 1.3 rosska stores and reads the uid for BB objects differently so it cannot change over time, this wouldn't be possible for tents without a lot of work changing more dayzmod files though. You will see this bug on any dayzmod server but obviously basebuilding makes it more likely an objects position can shift slightly after it was originally built.
 
Back
Top