PPO Madness

[John Adams]

Going to need a little help analyzing what I am looking at here. I am trying to find "uniqueness" in PPOs (and this is probably a bad example). Take a look at this table of data:

[attachment=0]PPOs.jpg[/attachment]
Take note the Log ID they are in, and special attention to the parentUniqueId and objectUniqueId. In log 351 for example, parent + object are the same across 5 "cups", which are actually Fishing Trophies, I suppose?

What I am trying to determine is two-fold;
1) Are these player-placed-objects (in a house?) only "created" when they are placed IN the house? Meaning, they are not a unique spawn record in the first place, until someone Places it (thus I do not need it in parsed data)?

2) The reason I am thinking #1 is because the "mouseoverDisplay" and "drawScale" are different for the exact same prefabNameTag + objectUniqueId placed.

Seems the only thing that truly brings Uniqueness to these entries is the buildingUniqueId, which makes no sense to me.

Anyone else have their analytical hat on today? Trying to wrap up PPOs for Parsing. Thanks.

[Volt]

I got confused there too, until I renamed (in my head) building_unique_id to ppo_unique_id and building_type to ppo_type. I don't know the reason why these two are named with building_* but logically they defo are ppo_*.

As far as I have seen, chunk_id + ppo_unique_id is uniqueness at least for a session. I am not sure if they ppo_unique_id can be reassigned over time (like from one week to another).

You have both houses (there is one ppo_type, maybe '3' (I'd have to check my data to be sure) for completed houses and another ppo_type, maybe '2' for houses in construction) as well as house decoration ppo's (yet another ppo_type) as well as house chests (yet another ppo_type).

I guess we want them all in the parsed data, to be able to construct a catalogue of houses and items the players will be able to place in the world (housing areas).

Edit: Oh I forgot about the signs (yet another ppo_type). These we want to spawn in the world as is. And there is one more .. altars?

[John Adams]

Volt, thanks for the info. I generally name DB field names after the Unreal variables, so that's why at least my data is named that... if we want, we could name our DB fields anything we want. Wasn't sure if that would confuse matters though, mapping back to Unreal. You tell me what you prefer.

Also, I do remember doing some PPO sleuthing a while back: viewtopic.php?p=7864#p7864 It doesn't really relate to this topic, but thought I'd run it by you for the "types" discussion.

You are right, I should parse them all (uniquely as I can) so I will unique on prefabNameTag + mouseoverDisplay + drawScale (the size). I could do ppo_object_id and ppo_type, but then I think everything would be unique. Would you prefer that? Lots of data!

[Lokked]

These records are placed PPOs. From what I understand about PPOs, the highlighted records are all in the same "container" because the parentUniqueId is the same. I don't know what the objectUniqueId is for, but when spawning PPOs in NT, I found that it doesn't matter what this is set to, and they can all be 0s and things still spawn fine. I'd like to see these spawned, because it would provide clues as to what buildingUniqueID is for. I'm thinking these are either:

- 2 different trophies (2 different object IDs) with multiple lines of text each. BuildingID seems unique, and so this may be the unique identifier for the record. Perhaps these cups can contain other PPOs (fruit? I dunno) and so they are given a building ID).
- 8 different trophies (8 records with the same parentUniqueID), 5 provided from 1 event/transaction, 3 from another, and this is what generated the similar objectUniqueIDs. This could mean objectUniqueID is related to a transaction, for tracking/support/logging purposes.

The different sizes, I'm betting, are determined at run-time, depending on the size warranted for this particular item. It makes sense to have different sized trophies, I'd think.

In both of these, parentUniqueID might not actually be the building it's in. It could be the display case or shelf it's on.

As I said, if you can give me the SQL to add these to my DB and spawn these with the exact same parameters as what was collected, it will help provide clues.

To answer your question, from these fields alone, I believe all we need to build a table of Unique PPOs, for the purpose of building a list of available PPOs at server startup, all we need is prefabNameTag, buildingType, and another field that you don't have here, it's prefabPackName, or something like that. In viewtopic.php?f=16&t=1104#p8953, Xinux identified the possible strings used for form the hash. The server, of course, would need to know what these are. prefabName and prefabPackName. I'm not sure which prefabNameTab corresponds to.

[Volt]

[quote="John Adams"]Volt, thanks for the info. I generally name DB field names after the Unreal variables, so that's why at least my data is named that... if we want, we could name our DB fields anything we want. Wasn't sure if that would confuse matters though, mapping back to Unreal. You tell me what you prefer.[/quote]
I take it you hint that we somehow had access to the Unreal variable names, and these names come from there. That was good info for me, thanks.
They are named the same in VGTesty and in the server source. I prefer names to be consistent and self-documenting. Consistent triumphs self-documenting. So from my perspective keep doing it the way you are doing it, by having the same names in the db.

[quote="John Adams"]Also, I do remember doing some PPO sleuthing a while back: viewtopic.php?p=7864#p7864 It doesn't really relate to this topic, but thought I'd run it by you for the "types" discussion.[/quote]
Good. I should be able to complement yours and Lokkeds types info.

[quote="John Adams"]You are right, I should parse them all (uniquely as I can) so I will unique on prefabNameTag + mouseoverDisplay + drawScale (the size). I could do ppo_object_id and ppo_type, but then I think everything would be unique. Would you prefer that? Lots of data![/quote]
I believe we will want "one of each object that was spawned in the world". I just don't know how to express that in SQL'ish . Since the PPO's are static (the one exception is when someone moved an item inside her/his house) prefabNameTag + x + y + z + pitch + yaw + roll should achieve this. Too much? Skip the pitch + yaw + roll? I love lots of structured data .

Lokked (/Xinux) I think it looks like prefabNameTag already is the combination of PrefabPackName + PrefabName?

[Volt]

Rough investigation of objectUniqueId: viewtopic.php?f=16&t=1104&p=9821#p9821. It kept me awake :p.

[John Adams]

[quote="Volt"]They are named the same in VGTesty and in the server source. I prefer names to be consistent and self-documenting.[/quote]
Not sure if you knew this, but VGVisualParser does use VGTesty's UnrealBitLib.dll, so yes it is exactly the same properties I think you knew that though, so I could be mis-reading your english

Either way, sounds like we're on the same page.