SWGEmu – Mods Need Math and So Do You!

It’s hilarious how many times in my life I have been wrong, despite thinking at the time that I couldn’t be anything but right. “Android? Yeah, that will probably be like all the other Linux distros and won’t really catch on. Blackberry is where it’s at!”… “Algebra? Seriously, when am I ever going to actually use that in my daily life?”…

😐

There’s a whole humorous train wreck of “wrong” in my past musings, but I did “call” a few things correctly over the years too, so it’s not all bad I guess. Still, as a person who enjoys programming and who doesn’t live under a rock, I have to admit that the above two visionary assessments of the future were pretty funny.

When it comes to math and modding SWGEmu, my latest project takes the cake for being thoroughly annoying in its need for math. You see, after building and testing a couple completely different ways to add player housing to NPC cities (which are noted here and in the GitHub repo for Legend of Hondo Classic), I decided that for myself and others it would be nice if I created a system that uses sites, plots, and layouts to make for easy and consistent city building. As a result, I needed to figure out the math that would ensure all structures on a site were placed correctly, no matter where the site is and what direction it is facing.

Unlike working with Blender, where the “engine” takes care of the math for you by way of allowing you to “parent” objects, SWGEmu doesn’t have such a feature for linking buildings together into groups. If you want to place a group of buildings relative to each other, you either place them that way manually or you calculate it manually and load them with a script. That’s fine really, but it’s not enough to accomplish what I wanted. I needed to come up with a way to essentially parent a set of buildings to a center point, such that an admin only needs to enter the world x, y, and heading (angle) of the site into the setup script and choose his desired layout to configure a site. The players would then go about picking which buildings they want to use, from the list of ones the admin made available. It sounds easy and I am certain that for someone who stuck with college math long enough, it would be easy, but I had a heck of time researching and coming up with something that works.

This is what I have…

Sites
Each site has a number of plots. The center (or “origin”) point of the site is the imaginary point all buildings are placed in reference to. The site config tables only consist of the x,y,angle,ow,oy, and layout name, making them super easy to setup. Here is an example of the location table for Tatooine,

tatooine_locations = {
  { — Site 1
    layout = “tatooineEstateSmall”,
    center = {x = -2697.4, z = 5, y = 2335.85, angle = -108, ow = -0.587785, oy = 0.809017},
  },
}

Plots
A site can have one or many plots, with each plot being the home of a single building. Plots are noted in the config table by the x,y position of their center relative to the origin of the site. This is called their “local position”.

Layouts
Layouts are the footprint of a site, comprised of the position of each plot and the buildings available on each plot. I’ve pre-made somewhere around twenty layouts of various types, but it’s easy to add more. The idea with using layouts is that using them removes an enormous amount of redundancy from the config files, while still allowing the admin a large amount of customization options (by editing existing layouts or adding new or modified ones). You can make one layout once and then use it in fifty different locations, for instance. Here is an example of a layout (pardon the jpg, but my blog theme doesn’t respect the code element…),
layoutTable

Terminals
Each site is managed by a single terminal that sits on the road side of the site. It’s position is noted as 0x, #y from the origin of the site. Players use this terminal to purchase buildings at the site.

A visualization of the situation.

A visualization of the situation.

To ensure that buildings are located correctly when rotating a site, I needed to do the following math.

EDIT: Well I’ll be a monkey’s uncle! In the process of writing this post, I had an epiphany – in lua math.cos() returns a radian value, which I had to turn back into degrees with math.deg(), but… I had been feeding it degree values in my calculations! That’s why the rotation matrix math wasn’t working! What’s more, when it I fixed it in the math I had been using that mostly worked, said math stopped working. I just finished testing the rotation matrix math using degrees -> radians and it works exactly as it should!

1. We use a rotation matrix to the determine new world position of the center of each plot, where childX/childY is the x,y offset value from the site center and orgX/orgY is the world x,y of the site center. This is SO MUCH BETTER than what I had cobbled together before and it’s only slightly off due to the way SWGEmu applies angle values as integers rather than floats.

function HondoHousingSystem:getWorldPosition(angle, childX, childY, orgX, orgY)
    angle = math.rad(angle)

    local x = (math.cos(angle) * childX) + (childY * math.sin(angle))
    local y = (math.cos(angle) * childY) – (childX * math.sin(angle))

    x = x + orgX
    y = y + orgY

    return x, y
end

2. Next, we apply any local rotation to the angle value. By default (most…) buildings would be spawned with the doors facing to the north of the site. So if we want the door to be facing 90 left from the site north, we just add -90 to angle value we calculated earlier.

local rotation = SiteAngle + localRotation

With that bit of math, I was able to have the computer do all the heavy lifting of computation, allowing we lowly humans to easily create layouts by simply loading up the “simple” testing planet, which is conveniently flat at world 0,0, and placing structures where/how we’d like then noting their x,y locations. That’s actually one of the places where I use my custom slash command /hondo admin getBuildingInfo log, because it spits out the x, y, ow, oy, and angle data into a handy file on the server. The ow, and oy quaternion values are needed to properly rotate the terminal.

I’ve spent a lot of time working on this housing stuff, more than I really need to for my own purposes with Legend of Hondo, because I figured that I may as well make a system that is as useful to others as it would be to myself. With my focus now being on “adding to default SWGEmu” rather than simply modding it, I’ve been forced to consider things from a new perspective. While there is a lot of stuff that default SWGEmu can do, there’s also a considerable amount of code that actively prevents it from doing something it wasn’t designed to do. Placing temporary structures is a good example – sure you can load them in a lua script using the spawnBuilding() function (which erroneously fails to apply the angle btw), but the building will be automatically deleted by the server’s structure maintenance system, if you’ve spawned it using an owner that isn’t a player (such as tying it to an NPC, because you don’t want it to belong to a player). And, lot of other things like that, which either need to be modded away or “coded around”, by making nearly redundant functionality that does exactly what you need it to do. So when combined with my own iteration and testing of various ways one can solve the “player housing in an NPC city” problem, the process has been and remains long.

As of today, I have completed the layout and config system, created some layouts, made the system that spawns temp buildings on a site until the player buys one, and a slash command for an admin to test a layout for 15 seconds. In a previous version, I had the terminal SUI, purchasing, and building tour systems completed so now it’s a matter of doing the same for this version. I also need to come up with a way to address the single plot sites that can host huge buildings such as NPC hospitals, cantinas, and theaters – they’re so enormous that their site centers are quite far away from the road, meaning that any smaller building placed there would have a weird amount of empty space around it.

In any event folks, the “Hondo Housing System” is coming along, thanks to… the math I thought I would never use. 🙂

Touch Screen Digitizers – Why Don’t Reviewers Review Them?

As a person who used a Blackberry for many years and who absolutely loathed touch screens until recently, I have to say that I find it odd how often phone reviews don’t mention the digitizer at all. “What is a digitizer anyway?”, is a question many people might be thinking, given how little they are talked about!

A digitizer is an array of nearly invisible wires that cover the screen of touch screen devices, which translate human touches into x,y location data for the device to use. Without a digitizer, a touch screen is just a screen. So… It’s kinda important! 

Typing on my previous touch screen devices, such as the Blackrerry Z10, Motorola E, and HTC One, was pretty frustrating compared to typing on my Blackberry Bold 9900 (or even my ancient Blackberry Curve 8520), because button accuracy was awful a lot of the time. What made matters worse with the on screen keyboards was the auto correct, a feature designed to make up for the inaccuracies of touch devices, was quite often obnoxiously “auto-wrong”! It was so bad in the Z10 that I got to the point whre I had to turn the damned thing off… but then typing on it was so annoying that I went and got a Blackberry Q10 to replace the Z10. 

As much as I liked the Q10, it unfortunately suffered from a hardware defect known as “double typing”. Many folks will say that I am wrong and that the issue was fixed in a software update, but all those folks also decline to take me up on my offer for them to come and use my fully updated Q10 to see it for themselves; The Internet is full of trolls and “stupid”… I couldn’t be arsed send it in for “repair” and get a refurbished device back for my damned near new and barely used one, so it sits on a shelf gathering dust, being the utter disappointment that it has always been. The Q10: not a replacement for the Bold 9900. The 9900 was a device I used every day for almost 3 years without it ever having a single issue.

Anyhow, it wasn’t until I upgraded to the Samsung Galaxy S6 this year that I found a touch screen that is nice to type on. And I discovered this totally by accident.

I chose the S6, after much research, based on its physical size (good screen to chassis ratio meant less wasted space for my tiny man-hands to traverse), and its hardware specs for the dollar. At 5.1″, the screen is on the small side for Android phones these days, but to me it’s actually too big. Even with the great use of space, this device is too big for my hands to use comfortably as a communication device. But, if I was going to spend the money on an upgrade, I wanted it to be money well spent, so I got the best device in the not ridiculously huge range I could. Lucky for me, it also has a good digitizer too!

Some reviews do indeed talk about the specs of digitizers on devices, but very few put any time into discussing the typing and text editing experience. That’s a shame for folks who like using their phones to write blog posts, post on forums, and take part in other text adventures that require the use of punctuation and sensible grammar. If I did phone reviews, it’s definitely something I would test and write about!

With that in mind, I guess I can say this about the writing experience on the Samsung Galaxy S6: It doesn’t drive me fucking bonkers, so it can’t be too bad. I should note that I am using the Google Keyboard (with the snooping features off…) rather than Samsung keyboard, as I find the Google one has better sized buttons and better word prediction (even with learning off). As a test, I wrote this post using the WordPress app on it. I have had the app installed on previous devices and never used it, because I figured it wasn’t worth the frustration. However, typing and editing on this new phone is not much different than it was with the venerable Bold 9900, so I can probably use it to post more often.

I guess there are two “take aways” from this rambling post: 

  1. Reviews need to spend some time focusing on the typing and text editing experience.
  2. I was lucky to discover that the Samsung Galaxy S6 is a worthy replacement for the Blackberry Bold 9900, in use and chassis quality. I did my research, but ultimately I was just lucky not to hate typing on it.

I don’t have other phones to test out, so maybe all newish devices are this nice to type on, but chances are that’s not the case. If only we could read about it somewhere! 🙂

Here is a fun comparison of the size of various keyboards I mentions. Desktop keyboard thrown in for good measure. :)

Here is a fun comparison of the size of various keyboards I mentioned. Desktop keyboard thrown in for good measure. 🙂

Ps. I edited and added the media using the desktop PC, which I was sitting at while writing the rest of the article on the phone as a test. PC’s are awesome! 🙂

The World (Still) Needs PCs

When someone writes or says something along the lines of, “the PC is dead”, what’s immediately obvious to me is that said person isn’t a content creator and they have confused low PC sales with the usefulness of PCs. That latter part about low PC sales is doom and gloom that is always “in the news”, yet the explanation for it is simple: Any PC from about the year 2006 and on is perfectly acceptable for daily use by the vast majority of PC users and given that many of the PCs sold in the last 10 years still work, people haven’t felt the need to replace them. I don’t know about you, but I don’t toss out my forks every year, “just because”, when my 20 year old ones still work fine at shovelling food into my face.

With that important myth dispelled, allow me to help you better understand my perspective, by taking a step back for a moment and considering what a PC physically is.

What’s the fancy word OEM’s such as Dell, HP, and Lenovo use to refer to “business class” PCs?

Workstation

That single word pretty much sums up my whole argument as to why the PC is not only very much alive, but is also fundamental to our modern “connected” lives. However, let’s take some more time to explore the concept. 🙂

PC manufactures spend a lot of money on selling the concept that a “Workstation is a professional grade, reliable machine for all aspects of business and development”. To their credit (and to varying degrees), most of the workstation class PCs on the market have, at the very least, a more robust chassis than your average consumer desktop. A factor that’s important for handling those surprisingly common occasions where employees use them to hold up their cars while rotating their tires in the parking lot. Internally, apart from the power supplies that OEMs love to skimp on, there’s very little difference between consumer PC hardware and workstation hardware – to the point where most of the time they’re entirely identical. What does this mean?

For the most part, Desktop PCs are Workstations.

This is especially true when you consider that an Intel Core i5 6500 CPU performs the same in a workstation as it would in a custom built desktop. A difference of +/-2%, usually in favour of the custom build due to custom builders often choosing faster RAM than OEMs, doesn’t really make for a compelling argument that one is better than the other. They’re pretty much the same thing in every tangible, realistic way (even well beyond the warranty periods of the products).

So why do we care that a PC is Workstation?

Well, it boils down to the reality that almost every piece of technology you use and much of the media content you consume, is designed and built on PCs. Some of those PCs might be called Workstations or even Macs (heck, they may even be in the form of a “laptop”), but they’re still PCs.

Smartphone Apps?
Designed, updated, and managed with PCs.

Movies?
Edited, rendered, modelled, story boarded, etc. on PCs.

YouTube?
Edited, rendered, modelled, story boarded, etc. on PCs.

Music?
PCs!

Cars?
Yup, they’re designed with PCs too!

And then there’s the obvious stuff, such as console games and other software that is designed and built entirely on PCs, along with countless other products and services. Indeed, many services these days are delivered “through the cloud” (I really hate that nonsense term btw…) and are hosted on servers, which are definitely not PCs, but… people don’t sit at servers making content – they sit at PCs making content and the PC uses the resources of the sever. And, all that server hardware and software itself was… designed on PCs! 🙂

If the “Personal Computer” as we know it, in its desktop and its laptop form, magically ceased to exist, the instant it happened the world as we know it would grind to an almost immediate halt. You know, because a lot of it only works when connected to a PC, but also because millions of people would all of a sudden have absolutely nothing to do at work. Millions more people, such as content creators around the world, especially software programmers and “YouTubers”, would have to do something crazy like… go outside or clean up their house or something… because without a PC, their crafts would be nightmares to achieve on other devices. Heck, even novelists wouldn’t be happy and computer work doesn’t get any more simple than processing text, so that’s saying something.

What about tablets? People say they’re just as good a PC for making content.

Sure they are, once you connect a keyboard and a mouse to them. Then guess what? That’s a PC too!

So there ya go, not only do you now know that the PC is not dead, you have a pretty clear understanding that in many ways our modern existence wouldn’t be what it is without the PC being part of our daily lives. From content creators in professional or “indy” settings to the kind folks who keep the electricity running, the fingers of the world dance the 104 QWERTY with no sign that they’ll ever sit down.

SWGEmu – How-To Add a New Slash Command

How-To Add a New Slash Command
Introducing new commands to SWGEmu, either for admin use or for players, can be a handy way to improve the end-user experience. Thankfully, it’s not too difficult to do, though doing so does require a minor client side update. I’ll take you through the process step by step. For the example, I’ll add the /helloWorld command.

Requires: IFF data table editor (TRE Explorer, Jawa ToolBox, Sytner’s IFF Editor)

1. Extract a copy of the following command data table to your working folder:
datatables/command/command_table.iff

2. Open the data table in the editor and add your new command(s), one per row. Have a look at the other admin commands, then add the following entries to your new one:
– commandName: helloWorld
– cppHook: helloWorld
– targetType: optional
– displayGroup: EDA57E75

3. Save the data table, pack it into your TRE structure, and make sure it is loaded by both the client and the server. That’s it for the client side modding! If you need help with this part, see the following post on Mod The Galaxy,
http://www.modthegalaxy.com/forums/thread-tool-sytner-s-iff-editor-3

4. Register the new command in the server software:

MMOCoreORB/src/server/zone/managers/objectcontroller/command/CommandConfigManager.cpp
– Scroll to the bottom and add a new call under the last one listed, like so:

commandFactory.registerCommand(String(“helloWorld”).toLowerCase());

MMOCoreORB/src/server/zone/objects/creature/commands/commands.h
– Scroll to the bottom and add the include line for header file of your new command:
#include “helloWorldCommand.h”

5. Create the header file that will perform the actions:
MMOCoreORB/src/server/zone/objects/creature/commands/helloWorld.h

6. Program the actions. In this case, we will simply send the player a system message that says “Hello World!”, however you can program a command to do pretty much anything you’d like. You can even run a lua function.

#ifndef HELLOWORLDCOMMAND_H_
#define HELLOWORLDCOMMAND_H_

#include "server/zone/objects/scene/SceneObject.h"

class HelloWorldCommand : public QueueCommand {
public:
HelloWorldCommand(const String& name, ZoneProcessServer* server)
: QueueCommand(name, server) {
}

int doQueueCommand(CreatureObject* creature, const uint64& target, const UnicodeString& arguments) const {

if (!creature->isPlayerCreature()) // If not player, bail
return GENERALERROR;

creature->sendSystemMessage("Hello World!");

return SUCCESS;
}
};

#endif //HELLOWORLDCOMMAND_H_

6a. If you’d like to run a lua function, make the function as part of a class (like a screenplay) and include its file in the screenplays.lua list, then add the following to your helloWorld.h after the “if not player” check.

Lua* lua = DirectorManager::instance()->getLuaInstance();

Reference myLuaFunction = lua->createFunction("MyLuaClass", "myLuaFunctionName", 0);
*myLuaFunction <callFunction();

For the Lua side of things, your command would be like so:
MMOCoreORB/bin/scripts/screenplays/tools/myLuaFunction.lua

local ObjectManager = require("managers.object.object_manager")
MyLuaClass = {}

function MyLuaClass:myLuaFunctionName(pPlayer)
CreatureObject(pPlayer):sendSystemMessage("Hello World!")
end

6b. To make the command for administrator’s only, the easiest way is to simply add the following after the “if not player” check. Note that a standard player’s admin level = 0 and a full server admin = 15. There are various levels in between that are described in MMOCoreORB/bin/scripts/staff/levels/*.lua

ManagedReference ghost = creature->getPlayerObject();

if (ghost == NULL)
return GENERALERROR;

int adminLevelCheck = ghost->getAdminLevel();

if (adminLevelCheck != 15){
creature->sendSystemMessage("Sorry, the /helloWorld command requires administrator privileges.");
return GENERALERROR;
}

7. Compile the server code, boot the server, load the client, and enjoy your new slash command!

That’s all there is to it, at the basic level. Depending on the functionality of your new command, you will need to add more C++ or lua code to various existing or new files. Just keep in mind that everything starts with the doQueueCommand() function in your helloWorld.h header file.

If you’d like, you can also research how the lua admin levels framework operates and then add your new command into that framework as well. This turned out to be more trouble than it was worth for me, so I didn’t bother using it.

SWGEmu – A Server-Client Mod to Build Walls, Bridges, Posts, and other Static Objects

After spending a few hours puttering away at editing the layout of Mos Espa recently, by way of using Sytner’s IFF editor and my dev game client/server to edit the Tatooine world snapshot file, I’d had enough. It was time to make myself the ability to move and rotate walls, pillars, bridges, and all manner of other “static” type objects that we can’t normally manipulate in the game, because bumping numbers and rebooting the server ad nausium isn’t a fantastic use of my time. So, I did.

At the moment I have only added two items to the system, but I figured I would share it now as, system wise, it’s complete and functional. “Just” need to add more items to it and I will add a guide for that aspect, because I am most likely only going to be adding the Tatooine items and some misc stuff for my purposes. It’s not a hard process, just time consuming, because there are lots of items.

Here is a video of me walking through the steps to add an item:

The commit to my Legend of Hondo repo for this feature is here,
https://github.com/Tatwi/legend-of-hondo/commit/d724dad170349ecac243e9c561684c1241a597a0

Here’s how it works:

1. I created new “tangible object” iff files for each static item, using a potted plant as template, added them to the CRC table file, and added the server side lua files required. Same process as adding any new item in the game, only I simply pointed the appearance template inside the iff to the static object I wanted rather than the plant (I did also change the name and description to ” ” and a common description in the string files). Note that is required adding the new iff files to a TRE file for the client and server.

2. I added these items to an otherwise unused terminal type, using the Character Builder system, so that admins can easily spawn them and get to work.

3. I added a new function to the /getObjVars command that spits out a spawnSceneObject screenplay command which points to the original static object version of the item, rather than new tangible version the admin is working with. This is so we can work with the fully manipulable targetable version, but load the normal non-targetable version as the final product.

/getobjvars static
Example Output:
spawnSceneObject(“tatooine”, “object/static/structure/tatooine/shared_wall_archway_tatooine_wide_style_01.iff”, -2980.62, 5.0, 2528.85, 0, 0.963207, 0, -0.268761, 0)

Summary

So that means that the workflow is the same as decorating normally, even while outside using bridges, walls, pillars, and so on. Just drop, move, rotate, hit your /getObjVars static macro, open your chat log text file, copy/paste the code into your screenplay!

Now it’s a matter of adding more tangible versions of these static items (many already do exist btw) and to see if the same general principle can be applied to buildings. If buildings are possible, then effectively would give us SWGEmu modders a basic “World Building Tool” that’s built right into our development server/client. In any event, these tools I have made aren’t perfect, but they do have the benefit of being open source, free, and available right now.

List of changes/new files:
bin/scripts/object/allobjects.lua
bin/scripts/object/tangible/beta/donham_terminal.lua
bin/scripts/object/tangible/furniture/static/structure/tatooine/objects.lua
bin/scripts/object/tangible/furniture/static/structure/tatooine/serverobjects.lua
bin/scripts/object/tangible/furniture/static/structure/tatooine/wall_archway_tatooine_large_style_01.lua
bin/scripts/object/tangible/furniture/static/structure/tatooine/wall_archway_tatooine_wide_style_01.lua
bin/scripts/object/tangible/serverobjects.lua
bin/scripts/screenplays/hondo/tests.lua
bin/scripts/screenplays/screenplays.lua
src/server/zone/objects/creature/commands/GetObjVarsCommand.h
tre/misc/object_template_crc_string_table.iff
tre/object/tangible/furniture/static/structure/tatooine/shared_wall_archway_tatooine_large_style_01.iff
tre/object/tangible/furniture/static/structure/tatooine/shared_wall_archway_tatooine_wide_style_01.iff
tre/string/en/frn_d.stf
tre/string/en/frn_n.stf

SWGEmu – A System for Buying/Selling Existing Structures

Ever had one of those times where you achieve what you set out to accomplish and you end up not being totally sold on the results? That happened to me today in regards to the following “To Do List” points I was working on:

– Allow the player to purchase buildings that already exist in the world, where that is possible.
– Tie the option to the Structure Management Terminal and place one in each of the building templates.

I was able to do both of those things as well as making a droid who rents structures, learning a lot in the process, but it wasn’t exactly what I wanted after all, due some issues and convolution. The problems basically amounted to,

1. I had to put the Structure Management Terminals into the building style template, so they loaded for every building of that type – even if there were some that I didn’t want the player to buy. This was because I wasn’t able to get admin-spawned terminals and screenplay loaded terminals to find the parent structure that they were in, leaving the building style templates the only functional way to get the terminals into the buildings. Many fruitless hours there, but at least the template loaded ones worked great!

2. I was not able to separate the server loaded structures from the clientobjects database and put them into their own database, using the data in the same manner as player housing data is used. Given that I had to delete the clientobjects.db every time I needed to reboot the server while figuring out where the new house signs needed to be, I can easily envision a time down the road where I will need to delete it on my play server, so the last thing I want is for it be full of my house items. About placing a house sign… it’s SUPER ANNOYING, because you need to place it x/z/y distance from the center of the building’s main cell, but once you step outside of the building you loose that reference point, as it’s replaced by your world reference point, leaving you to eyeball and guess your way to success. I digress…

3. Lag. Using playing structures prevents lag, as the contents aren’t loaded by the client until the player steps inside. Unfortunately not so for the server loaded structures.

4. The poor rental droid… It took me many hours to get him working just right and all of a few seconds on the toilet a day or two later to realize he just wouldn’t work in the real world. I made him rent a structure by adding the player to the admin list for a time, then automatically removing him later on. Unfortunately, it didn’t occur to me until after I did all the work that as a building admin, the renter could just add all his other characters to the admin list and never need to rent again! Oops. I thought of various work-a-rounds, but the more I thought about it, the more the whole concept of renting a structure fell apart in my mind. Renting a room (programming cell) wouldn’t have the permission issues and can be done with the lua scripting, but, ultimately I think it is a little pointless.

So despite putting in a lot of time and effort on those features, I’ve removed them from git (because the branches got all freaky deeky weird on me so I cleaned them using dumpster approach) and have started working on a new approach. For posterity, I have kept the code for these features in zip files, which you can find on my MEGA storage in the newly created “Stuff_I_Did” folder.

So what am I going to do about those two “To Do List” points?

Well, I have decided that letting the player use player housing is not only better for data and lag management, but it’s also better for personal satisfaction, in that it allows the player to have a larger visual and practical impact on their environment. As such, I am going to clear out some of the default buildings around Mos Espa to make more room for placing structures. I’ve already gone through and removed most of the zoning restrictions, so I just need to finish that up and add some merchants who sell the housing deeds (I actually already did that last part). Then when that is finished, I will remove the city hall building deeds from Architect crafting to prevent the player city system from being used (as it’s totally pointless in a single player situation and over lapping NPC city/Player city regions can be problematic).

I’ve also successfully tested making a player housing deed out of an NPC only style structure, (the steps for which you can find in our discussions about Tarkin 2.0, another project I will be working on with some friends) and that’s something I may do for a couple of the unique Tatooine house styles, the large hospital, and any other building I can’t live without living in! lol…

SWGEmu – How to Decorate with a Screenplay the Easy Way (With Server Mods!)

They say necessity is the mother of invention. Well, allow me to share a Legend of Hondo feature with you that I made to make my life easier when populating and decorating the world. While I made these changes in my 2015 era SWGEmu code base, you can most likely get them to work fine with the current code base with little to no extra effort.

Feature: Admin Decoration Tools
= = = = = = = = = = = = = = = = =
src/server/zone/objects/scene/components/ObjectMenuComponent.cpp
src/server/zone/objects/creature/commands/RotateFurnitureCommand.h
src/server/zone/objects/creature/commands/MoveFurnitureCommand.h
src/server/zone/objects/creature/commands/GetObjVarsCommand.h
src/server/zone/objects/creature/commands/FindPlayerCommand.h
bin/scripts/object/tangible/terminal/terminal_character_builder.lua
tre/object/tangible/camp/*.iff
– – – – – – –
– Added radial menu options for Admin Characters to drop and pickup objects while outside. Works on most objects, including some items loaded by screenplays and world snap shot files. Some items, such as armor, can’t be picked up, but they can be dropped and moved/rotated.
– Admin Characters are also able to move and rotate objects outside.
– Added new options to /getObjVars command that output helpful information into the chat log, such as fully formatted spawnSceneObject and spawnMobile screenplay calls.
– /getobjvars spout = spawnSceneObject or spawnMobile for the targeted object.
– /getobjvars onme = spawnMobile based on where the player is standing and facing. Defaults are “commoner” mobile template and 1 for respawn time.
– /getobjvars myparent = returns the objectID of the structure you are standing in.
– With chat logging enabled and the commands put into toolbar buttons via macros, this allows an admin to decorate normally and then cut and paste fully formated code directly into a screenplay file.
– Added the Structure ID to the output of the findPlayer admin-only command, because it’s handy.
– Uncommented some decorations on the character builder terminal.
– Fixed some iff files for some camp items that couldn’t be targeted. Note that the files only *need* to be on the client for the for targeting to work (fyi adding targetable = 1 to the server template doesn’t allow the client to target the item).


Rather than go through the arduous process of adding a new slash command to the game, which requires editing client side files, I decided to mod my desired functionality into the /getObjVars and other admin commands. It was just a better use of time.

The great part about using these mods is that they allow the admin account to place, move, and rotate objects outside in the world, as well as inside structures, and it totally removes the need to type out location and rotation values when writing screenplays. Now an admin can build an outdoor scene pretty much the same as you would decorate a house, then (/log to turn on chat logging) target each item and press a toolbar key to spit out the code that will load the same scene from a screenplay. It’s a much more normal way to populate and decorate locations and it means you’ll be able to be in the scene as it’s right there around you, rather trying to visualize it or continuously rebooting the server to see your changes.

Pretty cool, eh? Here’s a guide on how to use it.

/getobjvars
Emails a bunch of data about your targeted object as it normally would.

/getobjvars id NUMBER
Emails a bunch of data about the object id provided as it normally would.

/getobjvars spout
Spits out a fully formatted spawnSceneObject screenplay command into the chat box for the targeted object. When used on an NPC, it will spit out a spawnMobile screenplay command instead.

Example Output:
spawnSceneObject(“tatooine”, “object/tangible/camp/camp_tent_s1.iff”, -2980.62, 5.0, 2528.85, 0, 0.963207, 0, -0.268761, 0)

spawnMobile(“dathomir”, “singing_mountain_clan_sentry”, 360, -4573.5, 34.7, -6556.4, 138, 0)

getobjvars onme
This spits out a fully formatted spawnMobile screenplay command based on your current position and the direction you are facing. Simply stand where and how you want the NPC and fire off this command. By default the NPC name is “commoner”, so you just need to replace it with the name of the NPC mobile template that you want. This workflow might be faster than spawning / placing / rotating and “/getobjvars spout” on the mob itself.

Example Output:
spawnMobile(“tatooine”, “commoner”, 360, -4573.5, 34.7, -6556.4, 138, 0)

getobjvars myparent
Returns the ObjectID of the building you are standing in, unlike CTL+SHIFT+G which shows you the ObjectID of the cell you are standing in. It’s sometimes handy to know this quickly when making content.

Step By Step How-To

1. Merge the changes listed above into your development server. No real need to put these into a live server, yet no reason not to have them on a dev sever! 🙂

2. Compile/build and boot your server.

3. Log into the game on an admin character and decorate as you normally would in the game, inside or out. When outside you will notice new radial menu options for Admin Drop Outside and Admin Pickup Outside.

4. Type /log to turn on chat logging, so that everything in the chat box gets written to a file on your hard drive. You’ll want to turn off the time stamping in the Options > Chat menu in the game as well. To avoid duplicate messages, you need to get rid of System Messages in your Combat chat log by right clicking the combat tab, choosing Modify Tab, and moving System Messages from the right side box to the left side box.

5. Open the command window and make a macro for /getobjvars spout and drop the macro onto your toolbar in the first (or any) slot.

6. Target an object or NPC that you placed as a decoration and press the key for the macro you put on your toolbar.

7. Repeat step 6 for every object or mob that you placed.

8. When you’re finished step 7 type /log to turn off logging.

9. Alt-Tab out of the game and head to your profiles folder in the game installation folder and open the chatlog text file in Notepad. This will look something like so: C:\SWGEmu\profiles\accountName\serverName\281474993500826_chatlog.txt where the long number is the character’s reference number. Smaller number = older character. I made a handy shortcut to the file so I don’t have to go rooting around for it.

10. Remove all the [Spatial] text and extra spaces before the commands you want. Copy one instance of [Spatial] and go to Edit > Replace ( or press ctl+h) in Notepad. Paste [Spatial] in the “Find what:” text box (empty spaces included if you’d like) and press the “Replace All” button.

11. Now all you need to do is copy and paste every spawnSceneObject and/or spawnMobile line into your screenplay. SHAAAHH BAM!, YOU’RE DONE!

12. Note: Any object you dropped outside will be deleted when your server reboots, so no need to clean up after yourself.


So there you have it, a much more natural and quick way to populate your server with decorations and NPCs. Maybe down the road I’ll figure out how to use static objects, such bridges, walls, buildings, etc, in the same way, but this will do for now.

Happy world building! 🙂