New Pre-CU Planet: Hoth

Aug 17, 2014
I have scoured the code...  though I have a good concept of what needs to be done, I am still not technically capable of making the change that will allow Echo Base and the Morag Cave to be fully functional.  Server admins can change their close object range at their own risk, I'm not going to start sending out code that might mess people up.

Because of this limitation, and the fact that I know everyone will want to do what they please with Hoth regardless of how I populate it...

I'll be releasing the terrain as a standalone this week for sure.  I am making the package today, and will be asking Sytner for a map render. I will include a basic snapshot as well, and basic datables, string entries, etc... possibly make an asset and spawn pack to follow up eventually.

Though on my private environment, I am close to achieving my personal vision, it is made possible by a few band-aids that I just can't push out in a release.

I will keep building the planet on Choice Test, and as the code stabilizes and possibly includes new features, I will keep Hoth up to date and include it in my eventual "big stack o' planets and content" mod ..

just a note... (though a fully restored Kashyyyk is on the long term list for myself and others)... I really like Myyydril/Morag on Hoth. I made a special ice cave entrance and everything, but it just has similar issues as EB... still going to populate it on Choice Test, tried to come up with a plausible story line for some quests and content there.
Aug 17, 2014
Heard from Sytner, so unless the map reveals something horrible and ugly, on track for a quick-release.

Also... I figured out a few things with Kashyyyk... so I might have this terrain file ready soon as well - the snapshot is another story, but I'm working on translating from buildout. Thanks to langelusse for motivating me
Aug 17, 2014
Nee said:
Is  the dream still alive...?
Most definitely.

I mean, It's been released...  as a standalone terrain AND a full version for MTGClient

and it's live on Sunrunner II 24/7...


Echo Base is still held back by the hangar bay bugs.  I've made everyone well aware of the bugs, they are available to be experienced and tested first hand on my server and in my releases.

This is partially why I started my own server, to have a place to keep the projects live and open for testing.  I certainly plan to have my final version available when I launch for play in July/August.

Hoth in particular has required me to step aside into areas of modding that were completely new to me... and I'm doing it all myself, not just taking others' work... so for instance, I *just* got mountable tauntauns, flyable snowspeeders, wearable snow armor integrated in the past month.

There are also other general developments on my server that may render some of the Echo Base problems moot. I'm looking at a couple of unique ways to work around it...

-- also... There will still be terrain updates, I just have to get over some technical humps in order to return to world building as my primary...


Super Cool Person
Staff member
Aug 31, 2010
I'm not on my main PC right now so I can't really reference code I've written, that being said though, I've recently done a lot of buildout spawning manager code rework for CUEmu.

Basically, I have it reading from the TOCs in Core3, BuildoutManager is it's own instanced managed service. First, it reads the datatable file for the buildout scenes in the CU client, which opens the areas_(planetname).iff file in the same directory, based off that name in the first datatable. Then, it iterates and opens each buildout area within THAT Datatable, which the final datatable iff has the buildout objects that are spawned within the buildout area, with offsets in the world coodinates from the Buildout Area. Basically, it establishes a x1/z1/x2/z2 world point area on a planet, and the objects are not global (solely using the buildout object coords), but also factoring in the coords of the area.

I also have the formula SOE used for version 1 of the Buildout IFF's calculating object ID's, because they are not in version 1. Example, in our CU Client, attempting to radial a selected object (for example), on per say Mustafar, will always give the same object ID argument. The caveat is, all of these objectID's are signed int64 data type. Unfortunately Core3 doesn't have the capability to store negative OID objects within BDB datatables, so I had to modify each object-parsing packet file in Core3 to more or less invert the negative to make it unsigned. Though none of this really applies to a Pre-CU Hoth, since you're using world snapshots in a Pre-CU client.

More to the issue present, object range. Since I'm spawning all buildout objects in a new manager, I have put in code that sets the visible range value in the QuadTree based off what is in the CU datatable file, the column name is 'radius', a Float. For some reason Mensix Facility on Mustafar is kind of short range, but they probably did that because even on my powerful PC rig, it still takes awhile for the entire building to fully load.

To modify this, you just have to have a Zone pointer in the cpp function, and call "inRange", which will set a specified scene object pointer's range, which is the 2nd parameter.

So, for my Buildout Manager, I do something like: "zone->inRange(object, radius);", zone being the planet's pointer, object being the SceneObject (in this case, a building), and radius is the float pulled from the datatable. I even made new members in SceneObject for storing, setting, and getting the object's range value, but that's up to you.

Now, what you COULD do, is see how the Dathomir FS Village area is spawned in the code, I believe the file name has '768m' within, since that's it's radius meter length. Anyway, you could add similar code to that file (I'm not sure which one it's in off the top of my head), an if statement to see if the zone being loaded is Hoth. If so, spawn Echo Base similar to how the village area is spawned, then use that object pointer to set the Hoth zone's inRange value, to something I assume would be larger than the default value declared already, for Echo Base's hangar. Maybe even attach scenery alike to the FS village area, though I'm not 100% sure the purpose of that due to not extensively looking into it.

So, recap - take out Echo Base from WS and LUA, code it into CPP, along with any other problematic building, and it's children objects. I'm not fully sure on the Core3 server load order, though - example if that Zone portion of the code is loaded AFTER WS and/or LUA screenplays, and you've put child objects of the building (npcs, scene objects, etc), it won't have the parent building to reference. Though, if the Zone code is indeed loaded first, you can change your spawning within the LUA screenplay script to just get the building pointer in Lua, instead of just spawning it within Lua scripts. You may have to add some code in CPP of DirectorManager, to be able to get a SceneObject on a certain zone, at certain coordinates. I actually did this in our CU code, so that I could grab the pointer of the Myyydril caverns building on Kashyyyk, for the purposes of implementing the NK Necrosis quest instance. My code is different because there's 9 (I think) myyydril cavern buildings on the terrain, due to how SOE faux 'instances' worked, in my screenplay I have a for loop to iterate through multiples of coordinates, since that's how it's lined up in Datatables, at least for spawning the initial quest starting NPC for each building.

Kind of went a little more in-depth than what you'd need, but I'm hoping the knowledge is helpful.
Oct 10, 2017
Valkyra, you're rocking me... or smashing me with a rock. I don't know.
But my knowledge about Core3 isn't so huge.
I tried aswell to spawn Echo Base via LUA, taking it out from its snapshot but didn't work.
I'll try to understand what you mean. I appreciate your help.
Thanks, sir.