New Pre-CU Planet: Hoth

Takhomasak

Member
Joined
Aug 17, 2014
Messages
230
Timbab said:
Takhomasak said:
what TA pointed out is that there's a limit on snapshot IDs...  0x000000 I believe he said, which is a little over 16700000.  I'd set my Hoth snapshot IDs to a number much higher, to avoid any future conflict.  
Wait, what?

First of all, 0x000000 is a typo, I'd assume?

Also, you don't want to set it over the limit, you want to keep it under the limit, maybe this is where the sync issues are coming from? Or am I understanding you wrong.

Can you test placing a regular PreCU house and see if you have the same issue?

When you go inside the house, do the ID's match up to what you have in your snapshot?

Press Shift+Ctrl+G:


Also asking the obvious, but you do have the same snapshot on the clients and the server, right?

Takhomasak said:
I learned quite a bit about objects, APTs, POBs, CMPs, LODs, MSHs, and others, at least, while trying to make this work.
All have nothing to do with a snapshot sync issue.

It can be one of two things. Either there is a problem server side, or it's client side and the ID's are either clashing with something or are out of bounds.
Yes, that was a typo (am not a programmer), and yes I get the idea. The limit is an upper limit, so I am giving my objects IDs that don't belong to any other items in any other snapshot.  under 16.7mill deci.  

and yes, the IDs match and my TREs are on the server and in the client directory. and in live.cfg and config.lua

and I have an objects lua serverside that works

No other structure I have ever placed, including in my previous Taanab mod have ever done this...

I am trying all the appearance file editing because the snapshot fix didn't work...

or maybe my snapshot is corrupt, but I have tried several methods of creating one now, and put the IDS in a couple different ranges, between the ranges of the existing planets, all unused IDs...

wiping the server dbs every time before I load as well


Two characters in my current Echo Base setup will see themselves in the same cell (same cellID), but not see each other there. They'll just see the other toon's model standing in the corner, at some default point. NPCs will spawn there too if I put them in that cell, in a screenplay, regardless of the local coords I give.

If I /teleportt the characters to each other -- from each character once, they will be in sync throughout the POB, then bug on attempted exit.[hr]I really hope it's not something embarassingly easy... but it might be. As I've said, I'm not a programmer, and everything I know about this comes from learning through trial and error over a couple years. My logic, terminology, or approach may seem strange at times - I am actually an archaeologist.
 

Valkyra

Member
Joined
Aug 31, 2010
Messages
211
Yeah, just to echo (pun) Timbab's sentiments, I think it's due to how you are placing it inside of the world snapshot.

In the CU and NGE, they were placed with something called loadouts, which were basically datatable iff's of the world snapshot file. Apparently every 'area' of a loadout had a radius, which meant that it controlled the area/buildout object's viewing distance, instead of having everything set globally.

However, that's irrelevant to your issue since you'd only really need that if you were using buildouts themselves in a CU or NGE emulator.
 

Takhomasak

Member
Joined
Aug 17, 2014
Messages
230
Valkyra said:
Yeah, just to echo (pun) Timbab's sentiments, I think it's due to how you are placing it inside of the world snapshot.

In the CU and NGE, they were placed with something called loadouts, which were basically datatable iff's of the world snapshot file. Apparently every 'area' of a loadout had a radius, which meant that it controlled the area/buildout object's viewing distance, instead of having everything set globally.

However, that's irrelevant to your issue since you'd only really need that if you were using buildouts themselves in a CU or NGE emulator.
yep.  I have even looked at the buildout files...

pretty soon (hopefully this weekend), Choice will have its launcher updated, and I control the Test server there.  I will put up everything I have there, so leople can download my files and see if I've just done something silly.

Everything else works...  at least.  I thought the NPCs and creatures would give me the worst problems, but they were cake compared to E.B.  Even getting all the interior items to load in E.B. was comparatively easy.  It did take me a week or so, in the beginning, to get E.B. placeable in a snapshot at all.  Then, I didn't even realize the sync issue until I had it loaded on Choice test with testers other than myself.
 

levarrishawk

Member
Joined
Dec 15, 2012
Messages
61
Takhomasak said:
Valkyra said:
Yeah, just to echo (pun) Timbab's sentiments, I think it's due to how you are placing it inside of the world snapshot.

In the CU and NGE, they were placed with something called loadouts, which were basically datatable iff's of the world snapshot file. Apparently every 'area' of a loadout had a radius, which meant that it controlled the area/buildout object's viewing distance, instead of having everything set globally.

However, that's irrelevant to your issue since you'd only really need that if you were using buildouts themselves in a CU or NGE emulator.
yep.  I have even looked at the buildout files...

pretty soon (hopefully this weekend), Choice will have its launcher updated, and I control the Test server there.  I will put up everything I have there, so leople can download my files and see if I've just done something silly.

Everything else works...  at least.  I thought the NPCs and creatures would give me the worst problems, but they were cake compared to E.B.  Even getting all the interior items to load in E.B. was comparatively easy.  It did take me a week or so, in the beginning, to get E.B. placeable in a snapshot at all.  Then, I didn't even realize the sync issue until I had it loaded on Choice test with testers other than myself.
I had similar issues a few years ago when I downgraded the echo base files for heat to implement on bloodfin.   Not sure if he ever did anything with them or not.

Seeing your progress on this though has kinda inspired me to work on planets again in a hardcore sense for the first time since I made Dromund Kaas years ago for ProjectSWG, then eventually released here.

As for OIDs for snapshots, I have never had any issues such as that with snapshot OIDs.  When I snapshot I typically do so in the 30000000 - 40000000 range.      The only thing that should matter is that there is no conflict with any server side object id in the database, which are typically 12-16 digits in length.
 

Takhomasak

Member
Joined
Aug 17, 2014
Messages
230
levarrishawk said:
Takhomasak said:
Valkyra said:
Yeah, just to echo (pun) Timbab's sentiments, I think it's due to how you are placing it inside of the world snapshot.

In the CU and NGE, they were placed with something called loadouts, which were basically datatable iff's of the world snapshot file. Apparently every 'area' of a loadout had a radius, which meant that it controlled the area/buildout object's viewing distance, instead of having everything set globally.

However, that's irrelevant to your issue since you'd only really need that if you were using buildouts themselves in a CU or NGE emulator.
yep.  I have even looked at the buildout files...

pretty soon (hopefully this weekend), Choice will have its launcher updated, and I control the Test server there.  I will put up everything I have there, so leople can download my files and see if I've just done something silly.

Everything else works...  at least.  I thought the NPCs and creatures would give me the worst problems, but they were cake compared to E.B.  Even getting all the interior items to load in E.B. was comparatively easy.  It did take me a week or so, in the beginning, to get E.B. placeable in a snapshot at all.  Then, I didn't even realize the sync issue until I had it loaded on Choice test with testers other than myself.
I had similar issues a few years ago when I downgraded the echo base files for heat to implement on bloodfin.   Not sure if he ever did anything with them or not.

Seeing your progress on this though has kinda inspired me to work on planets again in a hardcore sense for the first time since I made Dromund Kaas years ago for ProjectSWG, then eventually released here.

As for OIDs for snapshots, I have never had any issues such as that with snapshot OIDs.  When I snapshot I typically do so in the 30000000 - 40000000 range.      The only thing that should matter is that there is no conflict with any server side object id in the database, which are typically 12-16 digits in length.
That's what I was thinking...  

Bloodfin never implemented EB onto their version of Hoth as far as far as I can tell.

Yeah...   I am nearly at a loss on what to try next.   it seems agreed that none of this should be necessary for any building, but either there's something special about EB, or I' an idiot :p

I just don't want there to be any special conditions on open-world Hoth.   don't want to have people zone into Echo base directly.

Also, honestly, none of the file downgrading except for shaders has seemed to even make a difference for me. The client will run all of the appearance files with the wrong numbers exactly the same as the right ones. I spent a while yesterday converting the POB portal chunks to 0004s, not just renaming... no difference at all. Still loads fine, no sync with world.[hr]I've made a new object IFF now... patching my server *fingers crossed*
 

Timbab

Administrator
Staff member
Administrator
Moderator
Joined
Oct 6, 2010
Messages
1,057
Location
Magna Germania
Out of curiosity, what did you do in the object .IFF department?

I don't see any real reason why that would cause issues.

P.S. What happens if you place it via the screenplay?

Also, if you want, PM me the snapshot and I'll take a look at it.
 

Takhomasak

Member
Joined
Aug 17, 2014
Messages
230
Nope on the IFF test.

Timbab, I had taken the IFF and made sure it was in-line with other pre-CU caves, following the right structure, the right PCNT numbers, removed the NGE tags, etc. Still no change.

For reference to those who are giving suggestions and trying to help, here are screenshots of two test characters standing in the exact same place at the same time. Their view of each other, and their exact location info. As you can see, both are inside, but to each other, appear to have stopped at the threshold. If I were to /teleportt Forko to Koedoe, and THEN /teleportt Koedoe to Forko, they would be in sync, until they ran outside, when they'd bug, and sometimes, the whole Echo Base appearance will bug from their perspective, unless they reload significantly far away.

http://i.imgur.com/2wejAG1.jpg

http://i.imgur.com/VNmfppV.jpg

(one of those cell numbers got cropped, but trust me, it's the same. It's always been the same)

If I softlog them both, they'll appear, still out of sync, in a 'default' location further back in that cell. and appear to stay there to each other, until they run out.


Thanks again, to all who have shared and thought about this too. Like I said before, my files will be available to dissect and test live on our server pretty soon.
 

Timbab

Administrator
Staff member
Administrator
Moderator
Joined
Oct 6, 2010
Messages
1,057
Location
Magna Germania
Takhomasak said:
Nope on the IFF test.  

Timbab,  I had taken the IFF and made sure it was in-line with other pre-CU caves, following the right structure, the right PCNT numbers, removed the NGE tags, etc.  Still no change.
Yeah, the .IFF object read ignores anything it doesn't know, it also doesn't check the versions, which is why NGE .IFF objects work out of the box.

My editor auto downgrades them to PreCU format and after that, it didn't show any real difference to a PreCU cave, which is why I asked.

Takhomasak said:
For reference to those who are giving suggestions and trying to help, here are screenshots of two test characters standing in the exact same place at the same time.  Their view of each other, and their exact location info.  As you can see, both are inside, but to each other, appear to have stopped at the threshold.  If I were to /teleportt Forko to Koedoe, and THEN /teleportt Koedoe to Forko, they would be in sync, until they ran outside, when they'd bug, and sometimes, the whole Echo Base appearance will bug from their perspective, unless they reload significantly far away.

http://i.imgur.com/2wejAG1.jpg

http://i.imgur.com/VNmfppV.jpg

(one of those cell numbers got cropped, but trust me, it's the same.  It's always been the same)
Yeah, so, basically it's as if the server can't see the cells, for example, you can have 2 clients on Bas have a modified snapshot that places a building on Naboo, both would run in and the same thing would happen, ie, on your client, you'd be inside, but the server doesn't 'get it', therefore will show those characters in place of where the entrance would be (I believe, otherwise they'll run around mimicking your movement outside, but I'm pretty sure they stand still at where the entrance is.)


Takhomasak said:
Thanks again, to all who have shared and thought about this too.  Like I said before, my files will be available to dissect and test live on our server pretty soon.
Well, I meant it more as an offer to help you solve the issue before it gets pushed to your server. Screenshot of the WS editor with the cell ID's (And first cell selected) might help, ie like:

 

Takhomasak

Member
Joined
Aug 17, 2014
Messages
230
Timbab said:
Takhomasak said:
Nope on the IFF test.  

Timbab,  I had taken the IFF and made sure it was in-line with other pre-CU caves, following the right structure, the right PCNT numbers, removed the NGE tags, etc.  Still no change.
Yeah, the .IFF object read ignores anything it doesn't know, it also doesn't check the versions, which is why NGE .IFF objects work out of the box.

My editor auto downgrades them to PreCU format and after that, it didn't show any real difference to a PreCU cave, which is why I asked.

Takhomasak said:
For reference to those who are giving suggestions and trying to help, here are screenshots of two test characters standing in the exact same place at the same time.  Their view of each other, and their exact location info.  As you can see, both are inside, but to each other, appear to have stopped at the threshold.  If I were to /teleportt Forko to Koedoe, and THEN /teleportt Koedoe to Forko, they would be in sync, until they ran outside, when they'd bug, and sometimes, the whole Echo Base appearance will bug from their perspective, unless they reload significantly far away.

http://i.imgur.com/2wejAG1.jpg

http://i.imgur.com/VNmfppV.jpg

(one of those cell numbers got cropped, but trust me, it's the same.  It's always been the same)
Yeah, so, basically it's as if the server can't see the cells, for example, you can have 2 clients on Bas have a modified snapshot that places a building on Naboo, both would run in and the same thing would happen, ie, on your client, you'd be inside, but the server doesn't 'get it', therefore will show those characters in place of where the entrance would be (I believe, otherwise they'll run around mimicking your movement outside, but I'm pretty sure they stand still at where the entrance is.)


Takhomasak said:
Thanks again, to all who have shared and thought about this too.  Like I said before, my files will be available to dissect and test live on our server pretty soon.
Well, I meant it more as an offer to help you solve the issue before it gets pushed to your server. Screenshot of the WS editor with the cell ID's (And first cell selected) might help, ie like:

when I say live, I mean Choice public Test server.   they've basically been kind enough to turn it over to me completely to develop and test this stuff, and learn server administration.

Also, what you said about client-server communication, this is why I have sought to force the issue in the server scripts... as it is forced to work by admin teleportation, or I would assume, making the planetary travel point inside the cells (which I do not want to resort to)[hr]well. Days of intense discussion with higher minds on the subject, dozens of trials... and I have decided this:

I will wrap the project up, get everything finished, and load it onto Choice Test as-is. Echo Base will be available in its current state for others to enjoy and test. I'll release a full package after some more serious testing.
 

Pake

Member
Joined
Dec 8, 2011
Messages
147
I can give you a hand with testing this weekend. I'll try connecting up on chat.
 

Lasko

Moderator
Staff member
Moderator
Joined
Feb 13, 2012
Messages
295
After more conversations with Reoze and Miztah last night, I'm pretty sure the server isnt actually spawning the base.

As Timbab says, what your seeing is both clients are loading the base from the snapshot, but not processing any movement data once you enter as it isn't receiving any from the server, thus each player sees the other at the last known point. ie. the door.

Have been trying to spawn it as a sceneObject but it will not load., whereas other Pre-CU building load fine from a screenplay.

My guess is the POB/cell processing issue.
 

Takhomasak

Member
Joined
Aug 17, 2014
Messages
230
Lasko said:
After more conversations with Reoze and Miztah last night, I'm pretty sure the server isnt actually spawning the base.

As Timbab says, what your seeing is both clients are loading the base from the snapshot, but not processing any movement data once you enter as it isn't receiving any from the server, thus each player sees the other at the last known point. ie. the door.

Have been trying to spawn it as a sceneObject but it will not load., whereas other Pre-CU building load fine from a screenplay.

My guess is the POB/cell processing issue.
I deeply pursued that angle last weekend...  

but the server DOES recognize it.  It just requires coaxing.  (re: my experience in teleporting and different spawn points)  Perhaps the appearance file structure is inhibiting its normal handling, yes...  but I've got some new experiments on deck.

Yeah, I absolutely can't get it to spawn as a scene object...   but I've had interesting results trying to spawn it in the planet manager... and there was a clue, that we can look at, when I did so it caused the client crash that referenced the component file specifically... which... *is* a little different than normal pre-CU structures in that it references MSH instead of LOD, but looking at the server code, I don't see that this is a problem... I want to say it's the POB because of the fact that interior cells seem to work if you don't pass thru the r0 portals... You can isolate them in the POB file (I made full conversions with no success). Beyond that, and converting the LOD and IFF as I have... not sure what to try...

In the meantime, I have reconnected with my first love, the TRN file... and am getting spectacular results...
 

Timbab

Administrator
Staff member
Administrator
Moderator
Joined
Oct 6, 2010
Messages
1,057
Location
Magna Germania
Takhomasak said:
Perhaps the appearance file structure is inhibiting its normal handling, yes...
Apt/lod (Beyond a version change)/mesh def isn't causing any issues as none of those changed. They've always worked unless there is a non era related issue with them (Which I doubt, as the client works fine with it).


Takhomasak said:
Beyond that, and converting the LOD and IFF as I have... not sure what to try...
Like I mentioned before, no need to convert the .IFF Object, as the read code in the client only reads what it knows and doesn't have a version check. It works fine for everything else in the last few years, including NGE buildings.


I'll ask again, have you tried spawning in an NGE player building that has 100% worked for other players in the past? Being able to rule that out as an issue, would at least narrow the problem search down.

I'm not seeing too many reasons for why it'd be a client side issue, considering the client works just fine with it. Now, there might be an issue of communication between the client and the server, ie providing not expected data from inside some of these NGE files (Guessing here, not sure how the communication works fully and what is sent), such as the .POB, but yeah.

Factually, NGE buildings worked in the past, so either you're having a general problem with NGE buildings or it's purely this one in particular, in which case, it'd be quite strange, as, to my knowledge at least, it'd be the only one that's misbehaving so far.
 

Takhomasak

Member
Joined
Aug 17, 2014
Messages
230
I got it to spawn in a screenplay! It takes the server a few minutes to load it and make it persistent...

So maybe this is the most valuable data yet:  It still won't sync. Exact same results with multi-players. It still shows the interior cells and IDs correctly as you run around... NPCs won't chase inside either. Floor/collision/ all visuals here though.

Yes, it is completely removed from the snapshot...

It doesn't stop the server, but errors come up from dataTransform.h and objectControllerMessageCallback.cpp... so I will be checking those lines out.
 

Timbab

Administrator
Staff member
Administrator
Moderator
Joined
Oct 6, 2010
Messages
1,057
Location
Magna Germania
That's something at least, at least you have errors, too now.

And again, you should also see if you can get an NGE player house to work that was 100% working on other servers in the past.
 

Takhomasak

Member
Joined
Aug 17, 2014
Messages
230
Timbab said:
That's something at least, at least you have errors, too now.

And again, you should also see if you can get an NGE player house to work that was 100% working on other servers in the past.
I am just prioritizing tests right now...    I have never messed with player structures personally, so that would take a little time.

I will, if necessary.  I am not ignoring any suggestions, just prioritizing according to where I am in the processes.  

Certain changes I can test rapid-fire right now, and others will require me reorganizing my workspace.  My method of 'version control' is slow, not automated, but very reliable...
 

Timbab

Administrator
Staff member
Administrator
Moderator
Joined
Oct 6, 2010
Messages
1,057
Location
Magna Germania
You can just slap it in, in a snapshot, same principle as Echo base, no need for extra stuff, which is why I suggest it.

It'd rule out things, like, if that works, it's def something weird about Echo base itself, if it doesn't, then you're missing something or something on the server changed in the past year or so that would have potentially broken NGE buildings in general, as they worked in the past.

That's why I keep pestering you with it. :p
 

Takhomasak

Member
Joined
Aug 17, 2014
Messages
230
I just got two players in-out-back-in synced.  (using a snapshot, spawn distance was too low in the screenplay)   I removed an entrance exclusion in the terrain, as I suspected getting stuck in that was compounding the bug.  I still suspect a portal error, but maybe set on purpose, to facilitate the NGE instancing.   Getting close on this...

so far, the portals *seem* to all go where they should, but it's starting to seem obvious that some aren't connected the same one side as on the other.  

Unfortunately, I have to take a break now until later tonight.
 

Nee

Member
Joined
Oct 27, 2016
Messages
47
Location
EARTH
Takhomasak said:
I just got two players in-out-back-in synced.  

  Getting close on this...


Unfortunately, I have to take a break now until later tonight.
Get some rest, eat some Bantha-crackers, and maintain your sanity!

p.s.  I've decided to name one of my integral  (eventual)  HOTH  Post-1.0  quest-npc's  after You, Takhomasak, to honor your efforts in some small way.  I hope that's okay.  If it isn't, let me know.
 
Top Bottom