Droid Engineer Archive

Well, that's my idea for making droid's cool again. I have some other ideas, but I thought I should make sure there's enough interest among the droid engineer community. Any feedback would be greatly appreciated, specifically about the level of complexity, the prerequisites for programming, and any new ideas for commands.

dude those are pretty cool ideas, but if all that goes through then there had better be a manual the purchaser of the droid will get cause ill be dammed if i will do that much customer service. As of now i dont like explaining how to tame the droid.

Cool ideas, although if you allow the droid to execute /commands then create_waypoint is a bit pointless since you could just do /waypoint $x $y.

atomic, I think you might have missed part of the point, only DEs will be able to program disks, the command to program them would come at Int Droid Refinement, since only DEs can program droids, this would mean you wouldn't have to explain to users how to program them, just how to use disks, and how to use the program you've installed. I would assume that some form of Holocron entry would have to be written, but the general population wouldn't be able to write droid code.

I like the idea of a programming language, one that can be hot swapped in the droid, althought it might be better to create them as datapad objects rather than add a seperate module for a disk drive, this way you would be able to put a data module in an MSE droid and have droid programming contents, like maze solving. Only allow DEs to create the data object types, we could then sell them on the bazaar or vendors, and a droid could hold multiple programs. If we added a /execute command (or a radial that lists the available program objects) you could quickly change the programming on your droid.

Also if we can sell programs it means that DEs can make a name for themselves by providing the best software, with the most features, it would also allow us to make protocol droids useful again (well Advanced protocol anyway) since we could embed abilities, if we had a $language variable we could do the following

sub when_hear

if $player!=$owner
if $language!="basic"
/tell $owner "$player said '$messsage'"
end if
end if

end sub

Which would automatically translate everything the droid hears that isn't in basic, but only the owner would hear it.

Obviously if we had some more functionality, for example in_range($player) which would check to see if the $player was withing range of the droid, we could make sure the droid only told you things when you were close it it, so if you left it in town it wouldn't continually spam you with everything everyone in the area said, unless you wanted it to act as a spy for you.

Interesting idea, but I can guarentee you thatdevelopers would not want to an extra scripting language in, just for some silly profession who in their minds is already 'fixed.'

I like the idea alot, looks good. Would need to be ironed out a bit but still could be fun. I'd also suggest that the only ones who can see the code on the disk is the creator ...that way your software cant be "copied". I'd like to know that if I forgot my code or accidentally erased it I could just pull the chip back out of my droid and read what I wrote ...kinda like a proprietary card reader.

Anyway, anything that makes droid more useful works for me, and the programming thing I could easily spend weeks on end with (just thinking of the possibilities, harvestor maintenance chips, survey droid chips, sentinels, spy droids, food / drink service droids, scout droids (check for mean enemies ahead of me on my way to my harvestors), the list is endless with the right code snippits.)

-Kralis

Awww man, it would be awesome if programming a droid was really like this. Each droid engineer could really add their own personality to the droids they make, giving someone a reason to buy a otherwise identicaldroid from one engineer over another.

An awesome idea... for the next sci-fi fantasy MMORPG. SOE probably wouldn't touch this idea cause it's just too much work for them (isn't the programmer in charge of ALL artisan stuff also in charge of Droids?).

They can barely address the game breaking bugs that have been around since beta, let alone add cool functionality to droids. Another good idea lost on deaf ears and daft developers.

you think... when people are capable of doing intergalaxy jump, going hyper light speed, they still can't figure out how to make computers understand basic language? you think they still program in assembly or machine language? it's as real as it gets, the first computer that understand English will appear in our lifetime, and no you ain't never gonna see people traveling outside of solar system before you die. You are playing SWG, you need to THINK SWG.

Introduction: How to Add Droid Programming

1. Two new crafting schematics become available:

Droid Disk Drive - Granted at Advanced Droid Construction, this takes up one general use module slot and enables the droid to use programmed disks. It adds two commands to the droid's radial menu, "/ejectdisk" and "/insertdisk".

Droid Programming Disk - Granted at Novice Droid Engineer, this is a reusable (not reprogrammable) disk that, when programmed, can be used in a Droid Disk Drive to control the droid.

2. One new ability is granted at Intermediate Droid Refinement:

/program - Requires a blank programming disk and allows the droid engineer to write a program to the disk using a simple text editing window or load it from a text file on their hard drive.

Part I: Programming Basics
Note: Those of you with programming experience can probably skip this section.

Basic Structure
Each command must be on a seperate line. The language is not case sensitive.

Comments
Putting a pound sign (#) at the beginning of a line tells the droid to ignore the rest of the line. This is important because the examples will be using comments to label various things.

Quoting and Escaping
There are two types of data in a droid program: numbers and text. Text have to be enclosed in single (') or double (") quotation marks, but numbers do not. Some characters (",',\,$) have special uses in a text string. To use these characters as plain text, just put a backslash (\) in front of them.

$x="abc"

$y="$xdef"
# $y is "abcdef"

$z="\$xdef"
# $z is "$xdef"

Variables
Variables can be used to store information for use later in the program. All variables begin with a dollar sign and can contain letters, numbers or underscores. Values are assigned to variables using the equals sign (=). Here are some valid examples of variables:

$myvariable=1
$my_variable_2="some text"

If you try to read a variable before giving it a value, the droid will assume it has a value of 0. Some names are reserved for special variables, listed in Part III.

Subroutines
Subroutines are blocks of code that can be executed, or "called", at any time during the program. Subroutines follow the same rules for naming as variables. You define a subroutine by using the following method:

sub my_subroutine
#
# some code
#
end sub

The example defines a subroutine named my_subroutine, which contains whatever code you put between the "sub" and "end sub" lines. To use this code, just add the command "call my_subroutine" or "my_subroutine()" to your program. The second method allows you to pass information to the subroutine by including it between the parentheses (example: "my_subroutine($x)"), however, this is only useful when calling the special predefined subroutines. The program will automatically go through the subroutine before continuing from where you called it. Some names are reserved for special subroutines, listed in Part II.

Events
Events are special types of subroutines. They always begin with "when_" and are defined like normal subroutines, containing whatever code you want. The difference is that events are automatically executed when something specific happens. For example, the event "when_attacked" is called when something attacks the droid. See Part IV for a list of events.

Other Commands
Droids can use some of the noncombat commands that players can use. These are basically identical to subroutines, except you use them in the same way you would as a player (example: "/command target").

If statements
If statements are a basic way to add structure to your program. They basically tell the program, "If this is true, do this, otherwise skip it." Here's an example:

if $x=1 then
#
# do something
#
end if

If $x does have a value of 1, the if statement proves to be true, and the program goes through all the code in the statement. If $x equals something else, the program will skip to the "end if" line.

Other Operators
Besides an equals sign, there are other ways to compare two things: less than (<, greater than (>, less than or equal to (<=), greater than or equal to (>=), and not equal (<>. In addition, you can do simple math with addition (+), subtraction (-), multiplication (*), and division (/).

Fuzzy Matching
Sometimes you'll want to to match only part of some text. You do that with the tilde (~) after the equals sign like this:

if $x=~"thing"
#
# will match "something", "anything", etc.
#
end if

Loops
Sometimes you need to keep doing a certain thing a set number of times or until a specific condition is met. To do that, use a loop like this:

while $X < 5
#
# repeated code
#
end while

This will continue to execute the code between the "while" and "end while" lines until $x is no longer less than 5. In this example, it's important to change the calue of $x within the loop or it will continue forever. The easiest way to do this is to add the line "$x=$x+1".

Part II: Special Subroutines

These subroutines are predefined and occasionally require some input from the program. If no information is given to pass to the subroutine, the droid will attempt to use the name of its current target instead.

create_waypoint($x,$y) - Creates a waypoint named $y at coordinates $x. This requires a data module to be installed in the droid.

cycle_data - This cycles the droid's target through all available data in its data module.

cycle_target - This changes the droid's target to the next available. It's the equivalent of pressing "Tab", but also includes players.

data_type($x) - $x must be the name of some data contained in the droid's data module. This returns either "waypoint" or "schematic".

data_name - This returns the name of the currently targeted data.

faction($x) - $x must be the name of a player or NPC within range. This returns either "rebel" or "imperial" if the player is overt, "covert" if the player is a covert member of the same faction as the droid's owner, and "neutral" otherwise.

gender($x) - $x must be the name of a player or NPC within range. This returns either "male" or "female", unless $x is a droid, in which case it returns "other".

go_to($x) - $x can be either coordinates or the name of a waypoint in the droid's data module. This will cause the droid to go to the specified coordinates or waypoint. The "when_arrive" event is triggered when it actually gets there.

pause($x) - The droid waits $x seconds before continuing with the program.

race($x) - $x must be the name of a player or NPC within range. This returns the species of $x.

random($x) - $x must be a number. This returns a random number from 1 to $x.

sex($x) - see gender($x)

species($x) - see race($x)

wait($x) - see pause($x)

Part III: Special Variables

$action - Contains the droid's current action pool value.

$city - Contains the name of the city, set by "when_enter_city" and "When_exit_city".

$coords_x - Contains the x coordinate of the droid's current location.

$coords_y - Contains the y coordinate of the droid's current location.

$date - Contains the current date.

$day - Contains the name of the day of the week.

$health - Contains the droid's current health pool value.

$instructions - Contains no value to begin with, but displays this value when the droid's owner uses the "Instructions" command on the droid's radial menu. This is useful for more complex droids that require some instruction for the user.

$message - Contains the text of what a player said, set by "when_hear".

$month - Contains the name of the current month.

$mood - Contains the mood of the player speaking, set by "when_hear".

$name - Contains the droid's name.

$owner - Contains the name of the droid's owner.

$player - Contains the name of the player speaking, set by "when_hear" and "when_see".

$power - Contains the amount of power remaining in the droid.

$target - Contains the name of the droid's current target.

$time - Contains the current time in military notation (example: 1600).

Part IV: Events

when_arrive - This is triggered when the droid arrives at the destination set by "go_to".

when_attack - This is triggered when the droid attacks something.

when_attacked - This is triggered when something attacks the droid and assigns the name of the attacker to $player.

when_called - This is triggered when the droid is called from the datapad.

when_commanded - This is triggered when the droid's owner uses one of the programmable commands.

when_damaged - This is triggered when the droid takes damage.

when_enter_city - This is triggered when the droid enters a city and assigns the name of the city to $city.

when_exit_city - This is triggered when the droid exits a city and assigns the name of the city to $city.

when_first_run - This is triggered when the programming disk is inserted into a droid.

when_get_data - This event requires a data module installed and is triggered when the droid receives new data.

when_get_item - This event requires a storage module installed and is triggered when the droid receives a new item.

when_hear - This is triggered when someone within the droid's hearing range speaks. It assigns that persons name to $player, their mood to $mood, and what they said to $message.

when_incapped - This is triggered when the droid becomes incapacitated.

when_owner_attacked - This is triggered when the droid's owner is attacked and assigns the attacker's name to $player.

when_owner_incapped - This is triggered when the droid's owner is incapacitated and assigns the attacker's name to $player.

when_owner_killed - This is triggered when the droid's owner is killed and assigns the attacker's name to $player.

when_see - This is triggered when a player or creature gets within range of the droid's radar and assigns their name to $player.