NOTICE: The wiki has undergone updates and everything is running smoothly. I am still working on the CSS so there are a few minor visual kinks.

From JAWiki

Ever since I made the first JA map mods and showed Boba the technique, 
one of the most common questions we've been asked is how to do it.
Anyway, I hope you all enjoy this. :)
- Jahandar

I've just added a couple of new techniques here, read and enjoy :P

- New edit: (July 12 2007) Added model placement and shader remapping and limitations to keep in mind :P

- BobaFett

Added info on legality of the map modding process.

- Update (June 08 2008): Added BSP insertion. It's not just for Lugormod anymore ;)

- Seto

[edit] About

Also known as entity hacking, Map modding involves modifying the default set of entities that are included in a map. This technique is popular because it allows the alteration of maps for functionality or esthetics, without requiring players to download a new map. Customarily, this technique only allows the addition, removal, and alteration of entities. While Brush modification is theoretically possible, it is difficult and extremely prone to errors, and the results likely won't be what you were hoping anyway.

Entity hacking is possible and practical because of two facts:

1. Entity data is only used by the server. It does not matter what the entities a player has in the BSP file on his computer. When a server loads a map, the server will read the entity data from its own BSP file, and then it will tell the clients about the map's entities. This ensures that everyone on the server has the same set of entities.
2. Although the map's brush information is stored in compiled binary form within the BSP, the entities are stored in plain text (human-readable) form. If the entity definitions weren't plain text, it would be harder to edit them, and if they weren't independent from the compiled brush data, a new BSP would have to be compiled, requiring players to download a whole new map.

[edit] What You Will Need

The BSP file of the Map you wish to edit

This will commonly be found in one of the game's PK3 files.

To create or extract files from pk3's, either use Winzip 10 (which supports directory creation) or pakscape

Compiler

The easy way to acquire this is by downloading GTKRadiant, which includes the q3map2 compiler. GTKRadiant Website

A text editor

Notepad will do, WordPad is better and easier, but if you're going to do this often, you'll want a more sophisticated w:text editor.

JA MP Entity Reference

Available here.

Quark (Optional)

Some people have a hard time extracting the entities from the BSP. To them I recommend QuArK, which can extract the entities for you (among many other things beyond the scope of this article). QUARK Website

Some familiarity with using the command line.

A good guide can be found at CommandWindows.com

[edit] The Procedure

For a quick and dirty explanation, you're basically going to grab the entity data from the BSP, make your changes, then recompile the new entities into the BSP.

Step by Step:

1. Get the BSP
   • If the BSP is in a PK3 file, you will need to extract it. Always make a copy of the BSP and edit that, do not overwrite the original. Whenever doing any kind of mod, you should always work in such a way that all you have to do is remove your mod, then your game (and maps) should be just as before.
2. Extract the entities
   • You will need the current entities because when you make your changes later, all of the current entity data will be replaced, so the best thing to do is to grab the current entity set and work off of that. Anything you don't want to mess with, you can just leave alone and it'll go right back in the map as before.
   • As mentioned above, you can open the BSP file in a text editor or Quark. In a text editor, you'll see a lot of garbled illegible symbols and such, this is the compile binary brush data, ignore it. You'll know the entities because they'll be the part that is human-readable, with { curly brackets } enclosing each entity definition (you will want to keep these brackets intact).
   • In Windows, some of the simple text editors like Notepad don't recognize the line ending characters, and replace them with little rectangles. You can either fix this after you paste it in the next step or use WordPad or something more advanced instead. Linux users should have no trouble in any text editor.
   • Copy and paste the entities into a new blank text file. Save this file as a .ent file with the same name and in the same directory as the BSP file.
3. Edit the Entities
   • Use the Entity Reference and the Best Practices below as your guide and start making your changes.
   • If you are new to map modding, I recommend skipping this step for now (or at least not doing anything major), to make sure you understand the complete process. Often beginners will start editing right away, and this leads to problems if they run into errors, because they don't know if the map would've compiled to begin with, or if they extracted the entities incorrectly. They can't tell if the errors they get are due to the changes they made or something that was there before.
   • When you're ready to start making changes, I'd suggest starting small. First just try modifying what is already there and see how things change, then move on to more complex stuff when you're comfortable.
4. Compile the entities back into the BSP
   • Before you start, make sure that both the entity file and the BSP are in the same directory as your compiler, usually this is the GTKRadiant directory.
   • The word compile is a bit misleading. I say "compile" because you will use the compiler, but you're not really compiling, you're just using a feature of the compiler to fold the new entities into the pre-compiled BSP.
   • Open up a command-line terminal, navigate to the appropriate directory, then run the Q3Map2 compiler using the -onlyents switch. For example: q3map2.exe -v -game ja -fs_basepath "YOUR_PATH/Jedi Academy/GameData/" -fs_game base -onlyents MAP_NAME.ent
   • If the compiler returns any errors, fix them then try again.
   • For people having problems with this, here is an alternative method created by BobaFett, a compile script.
   • To use it, open notepad, and copy/paste the following code:

@echo off
cls
title Entity Recompiler - Wrapper made by BobaFett
echo q3map2 entity recompile wrapper
echo by BobaFett
echo.
m:
cd X:\Program Files\GtkRadiant 1.5.0
q3map2.exe -v -game ja -onlyents %1
echo.
echo Compiling finished, press any key to close this window
pause>nul

1. • Change the 'cd X:\Program Files\GtkRadiant 1.5.0' line to reflect the location of your GTKRadiant directory
   • Save it as EntityCompiler.bat and put it in your GTKRadiant directory (where the compiler resides)
   • To use it, simply drag 'n drop the entity file into the script and it will automatically start the compiler
2. Test the Map
   • If you followed my recommendation, you should still have the normal version of the map installed. We are not going to mess with it, we simply want to make sure that the game uses the modded map instead. The easiest way to do this is to put the BSP in a PK3 file, mirroring the directory structure of the original (so if the original is in /maps, put it in a maps folder, if its in /maps/mp, follow suit) then put this pk3 file in your base folder. The game loads the PK3 files in alphabetical order, so make sure that the name of your PK3 file comes after that of the original map. The standard JA maps are in the asset files, so this shouldn't be a problem.

[edit] Proper Syntax

Each entity has the following structure:

{
"property 1" "value 1"
"property 2" "value 2"
"property 3" "value 3"
}

The curly braces must be on seperate lines, {"property 1" "value 1"} is not allowed and will cause compiler errors

Each lines can contain either an opening/closing brace, a property, or a comment (preceeded by //), these cannot be combined, therefore you cannot place comments after properties or after braces or but multiple properties on 1 line

Comments can be places either inbetween entities or inside entities as long as they're on a seperate line

Properties must be enclosed in quotations, and each line must contain exactly 4 quotation marks, no more, no less. Please note that the compiler doesnt always detect quotation errors, but the server will, and that will result in a fatal error.

Each entity must have a classname property, which defines which entity it is, invalid classnames won't cause errors, but will simply result in the entity not spawning and a warning in the server console

The properties that can be used for particular entities are listed here

A very important thing to realize, is that the worldspawn MUST be the first entity of a map, or the server will crash (well, get a fatal error) when loading the map

[edit] Techniques

Got the hang of it? Ready to move on to more advanced things?

Boons

In this context, boons refer to the technique of using item entities as generic trigger relays to add additional functionality to a map. This technique was developed by Jahandar and BobaFett as a way to add additional triggers without being able to add new trigger brushes, and the first map to feature it was Jahandar's modded T3_Byss. The technique is named after the item_force_boon entity which is item most commonly used for this purpose. Other commonly used items are item_jetpack and item_ysalimari. The way to do this is to specify a target in your entity then set up the entities with that targetname. When the entity is used, it will call its target, and each of the entities with the given targetname will be activated. An example may better illustrate this.

Note: powerup items (force boons and ysalamiri's) create a global respawn sound when respawning, which can prove to be very annoying.. for this purpose, if you use powerup items, diable respawn sounds using "noglobalsound" "1" (this setting is undocumented)

{
// This entity is the actual boon that the players see. 
// When a player touches it, any entity with the targetname "msg_MapInfo1" will activate.
"classname" "item_force_boon"
"target" "msg_MapInfo1"
"wait" "4"
"origin" "180 -334 109"
"count" "-1"
"noglobalsound" "1"
}
{
// This entity displays a message to the player's screen whenever activated
"classname" "target_print"
"targetname" "msg_MapInfo1"
"spawnflags" "4"
"message" "Hey, quit grabbing my boons!"
}

Here is a more advanced example, showing a boon used to teleport a player:

{
// Teleporter Boon
"classname" "item_force_boon"
"target" "teleToDisneyworld"
"origin" "1039 1470 700"
"count" "-1"
"wait" "4"
"noglobalsound" "1"
}
{
// The teleporter activated by the boon
"classname" "target_teleporter"
"targetname" "teleToDisneyworld"
"target" "teleToDisneyworld_spawn"
}
{
// Message displayed to teleported players
"classname" "target_print"
"targetname" "teleToDisneyworld"
"message" "I'm going to Disney World!"
"spawnflags" "4"
}
{
// The teleport destination
"classname" "target_position"
"targetname" "teleToDisneyworld_spawn"
"origin" "1247 1740 858"
"angle" "0"
}

• Note that whenever using boons on a server with force disabled, you will need to use a small script to allow boons to be displayed. This script should be run by the server immediately after the map is loaded. You can view this script here.

Brush Trigger Manipulation

When modding maps, it pays to be resourceful. If the trigger brush's original function is no longer needed, you can alter it to do something you want. You can tell which entities are tied to brushes because they will have a model property that is set to a number preceded by an asterix, like *23.

While this technique can yield great results, it can be difficult for beginners because identifying which brush out of the thousands is referred to by a given model value can be troublesome. Jahandar's T3_byss map is one example of a map that has made use of this technique, and it is available for download if anyone would like an example.

Brush Duplication

This technique allows you not only to alter existing brushes, but also to create new brushes by copying existing ones. This is done by creating a new brush-entity using an existing brush (noted by "model" "*<number>" as explained above). To move the brush, simply specify an origin. This origin has to be the RELATIVE position of the brush. An origin of 0 0 20 will place the new brush 20 units above its original location.

This technique can be used to make new trigger brushes, or new doors. The new entity does not have to be of the same type as the original one. If you create an invisible entity (like a trigger_multiple) out of a visible brush (func_door for example), the brush will still be invisible and non-solid, despite the fact the original was solid. An example of this technique can be found on Seto's (aka T-RCX) ffa3 map, located on the LOA server. BobaFett has also been known to make use of this technique on his maps.

Worldspawn Editing

In every map, the very first entity is the worldspawn. This entity is essential to the functioning of the map, so editing most of its properties is not recommended and may produce unstable results. Editing the "message" key, however, can be done easily. This allows for the title of a map as it appears on the loading screen to be changed in any way, including the use of color codes. Worldspawns also have a "music" key that can be edited at will, but remember that if the music file referenced is not something that all clients have, it will not be heard by those clients who do not have it.

Model Placement

In order to place models (md3) files on your map, you'll have to 'abuse' health dispensers. Now, i see you asking why, which is logic. I'll tell you why: health dispensers are one of the very few entities that let you pick the model to display.

Now, of course, health dispensers will heal you, so in order to fix that, you have to disable the health dispenser. The best way to do this is with an icarus script that set SET_PLAYER_USABLE to false, and assign it as the spawnscript of the health dispenser. Keep in mind that the health dispensers come with their own fixed-size hitbox, which cannot be changed. So making models solid may, depending on the model you're using, be quite difficult.

The entity for a health dispenser is misc_model_health_power_converter

Shader Remapping

This technique lets you change shaders. Allowing you to make things look different, or even have things 'disappear' (only visually).

Examples of the uses of shader remaps, would be displaying video's on 'TVs' (models/map_objects/rail/view_panel.md3 for example), or making lava disappear (or even change into something else)

Please note that remapping shaders that contain a lightmap, *might* cause odd results

To do a shader remap, you need an entity that can trigger its targets, because a shader remap will only be triggered when the entity with the shader remap info, wants to trigger its targets (Note: when it triggers its targets! not when it GETS triggered!). For this reason, the best entity to use for this would be a target_relay, as it triggers its targets when it gets triggered, making it easy to control.

The entity in question (like a target_relay) needs to contain 2 keys in order to do a shader remap: targetShaderName and targetShaderNewName, the first one being the original shader, and the second one the new one

To change a remap again, use the original shader name again. To illustrate: If you remap shader A to shader B, and you want it to remap to shader C, remap A to C.. and not B to C

Icarus Scripting

Jedi Academy supports sequence scripting for both singleplayer and multiplayer using Icarus II. See Icarus for more info. Please note that Icarus was developed for singleplayer only, and in multiplayer, its abilities are very limited. BobaFett has been known to use icarus scripting on his map mods frequently.

BSP Insertion

One of the least used yet most incredible entities in Jedi Academy is the misc_bsp entity. This entity allows for the placement of complete BSPs into another map at the specified origin, essentially allowing you to place a map within a map. Once seen only in Lugormod, this technique has been extensively researched and successfully employed in JA+/base compatible map modding by T-RCX (aka Seto) using the multiplayer duel6 map as the base test subject. This map is publicly playable at 208.43.15.112:29070, when it is in use. Complete and proper usage of this technique is fairly complicated, however, so the following information must be kept in mind when attempting to use misc_bsps in your map mods.

1. The selected bspmodel is treated as one giant bmodel entity (like func_static), plus every additional entity contained within the map. Because of this, every misc_bsp added will increase your total entity count by the number of entities contained within the chosen BSP plus one for the misc_bsp bmodel itself (see Important Limitations below). Furthermore, since the entities from the misc_bsp are not originally a part of the base map you started with, the q3map2 compiler will NOT show the correct number of entities in your map. The number shown will always be lower than what you really have, so it is easy to exceed the max entity limit without realizing it.
2. Misc_bsps can be placed in the void outside of the normal map boundaries, but in order to successfully do so, you must locate "portaled void" first. This refers to a property of the voidspace that creates areaportals, which allows for the normal rendering of entities. If the misc_bsp is not placed within a region of portaled void, the entities contained within it will not show up in game. Generally, portaled void appears several thousand units away from the base map's boundaries and can be located by using noclip to fly far away from the map into the void, and then activating your saber. If you hear the sound of your saber activating, you are within a portaled void region; otherwise, you must keep looking. BSPs can also be inserted within the boundaries of the base map, but care must be taken to avoid creating architectural conflicts.
3. The areaportal void has a distinct visibility radius that impacts the size of bspmodels that can be used. This concept can be understood by imagining a large sphere around the player that moves with the player: every entity that has its origin inside the sphere can be seen by the player, while every entity that has its origin point outside of the sphere cannot be seen at all. Since the misc_bsp is treated in part as one large bmodel entity, this means that if the origin point of the misc_bsp is at any time outside the visible radius of the player, NONE of the bmodel will be rendered, even if you are inside it at the time. Because of this, using large BSPs as your bspmodels is not recommended, as they will undoubtedly become nonfunctional in certain places.
4. Under normal conditions, the misc_bsp's associated skybox will either conflict with the base map's skybox, or not render. If the misc_bsp has a skybox and is placed within the boundaries of the normal map, the two skyboxes will conflict in a way akin to z-fighting, unless a sufficiently large space is provided for the misc_bsp. If placed in the void, the misc_bsp's skybox will appear as void itself. To remedy this, a misc_skyportal entity must be used, which will cause every skybox to be the same. Misc_skyportals are placed at any location on the map, and they then take a 360 degree snapshot of their surroundings which then becomes the universal skybox at any location, even in voidspace. For this reason, the optimal base maps for using misc_bsps are those that were designed for and already contain a skyportal entity, such as duel6, duel9, t1_danger, t2_rogue, t3_hevil; though a skyportal could be manually placed within any map. Additionally, if the misc_bsp entity also contains a skyportal as part of its bspmodel entities, the skyportal that appears last in the base map entity list will be the one used in game (so if your misc_bsp comes after the original misc_skyportal and is placed in the void, the sky everywhere will be void).
5. The targets and targetnames of entities within the inserted BSP are changed as a result of being used in a misc_bsp. This means that you cannot normally have an entity in your base map that is linked to an entity from the misc_bsp. However, Icarus scripts can be used to set targets or targetnames to get around this, if needed.
6. Bmodel entities from the misc_bsp can still be manipulated as normal, but the bmodel IDs will be changed. If the base map contains any bmodel entities, the first bmodel entity from the misc_bsp will take on the bmodel ID number that follows the last one from the base map. In other words, bmodel IDs from the misc_bsp add to the bmodels from the base map. BobaFett's Ultra Utility is capable of recognizing the accurate bmodel ID from misc_bsps. Once the bmodel ID is known, manipulation can occur as normal, and as a bonus, the bmodels from the misc_bsp act as though they are centered at (0 0 0), making placement, movement, and rotation easy. At certain times, however, a glitch may occur in which bmodels from inserted BSPs take on undesired surface parameters, such as surface slickness, which may cause problems in map functionality. If this problem occurs in your map, reload the map repeatedly until the problem disappears.
7. Spawnpoints from the inserted BSP will be used in addition to spawnpoints from your base map, so the player will spawn by default at any spawn entity present, regardless of whether it comes from the base map or the misc_bsp. There are a number of ways to prevent players from spawning within the misc_bsp if that is desired, but in order to preserve the integrity of the misc_bsp so that it can still be played separately as a solo map, you must either place triggers on every undesired spawn location that will teleport the player elsewhere, or use scripting to set the target of the undesired spawnpoints to a teleporter. This step can be tricky and may be somewhat difficult to fully understand initially.
8. Every misc_bsp used will increase the overall loading time of the map by, on average, a few seconds. This is not normally a major issue but is still important to keep in mind, especially when considering clients who may have a slower connection or otherwise require more time to enter a map.

[edit] Important Limitations

1. The server can only handle 1022 entities at any time! Any more entities will cause the server to get a fatal error. Entities that are not spawned on the server (info_null's, misc_model(_static)s, pickups that aren't spawned due to settings.. etc) do not count towards this limit as they're not spawned and therefore don't take up slots.
2. Snapshots contain up to 1024 entities, which is no problem, but only 256 are sent to cgame for processing. Meaning if any area contains more than 256 entities, entities will start disappearing. This includes event entities! The results of this are for example: no more kill messages, NPC's disappear, no projectiles are seen, grapple (JA+) disappears and has no sound, entities disappear. If you happen to be in an area where you touch many viewportals, this can happen easilly if you added a lot of entities. However, try to avoid these overflows at all costs!
3. It may sound logic, but if you use 'external resources' (sounds, effects, models.. etc) only use files that are in the assets, or, if you edit a map made by someone else, only the assets and the files that come with that map!

[edit] Tips

1. Make notes, comments, whatever you need to keep track of what is what in your mod, so you can come back to your work in a year and still know your way around.
2. Use a clear, logical naming scheme for your mods. This will help you keep track of your work. For instance, I could have JahMap_FFA3_v1.pk3, JahMap_FFA3_v2.pk3, etc. This keeps everything clear and also allows you to simply place any new versions in the base directory. You won't have to remove the old one, because the newest one will always be loaded last.
3. Use logical target names. Target names like t32 are hard to keep up with, notice in the boon example I used the targetname msg_MapInfo1, so I can instantly see that the involved entities are related and are used to print a message with information about the map.
4. Study other people's work. Using other maps as examples is a great way to learn. (But dont steal their ideas unless they gave you permission)

[edit] Best Practices

When modding maps, here are some good guidelines to follow. Doctors follow the Hippocratic Code, which states "Do no harm," I think that applies here as well. Some of these may be a bit subjective by their very nature.

Watch the FPS

Remember that everything you add to the map is going to effect performance. Be careful what you add, and make sure it doesn't create too much lag. Test it with other people to get an idea of how your changes effect different people with different (often older) systems. JA is a relatively older game, so many of the people playing it don't have top of the line computers. Keep that in mind.

Eye-Candy Overkill

I know how it is, you've just learned how to mod maps, so you're anxious to impress the world, and show everyone what you can do, but please try not to go overboard. Excessive use of effects and other eye-candy looks tacky and causes lag. Before adding anything, ask yourself: How it will improve the game? Do the benefits outweigh the costs? Will people still appreciate this after the "coolness" factor wears off?

Don't Interfere with Gameplay

I know they can be fun once in a while, but try to avoid adding things that will interfere with normal gameplay, like airstrikes, eruptions, passage/area blocking, etc. It is very annoying to be interrupted and killed during a duel because someone triggers an eruption. And IF you decide to add something like this anyway, give the people on the server a warning and enough time to reach safety. Otherwise it will only annoy people.

Fun For All

Don't divide people into haves and have-nots. Yes, there are some things better off reserved for clanmates and admins, but overall try to focus on things that everyone can enjoy, not just a few people. New things you add will depend on what it is you're adding, so I grant that, but you should definitely have a good reason for taking away something (or some place) that players are accustomed to having.

Something you can do, however, is to make a control room for admins, which affect things on the map availible for everyone. For example.. making a switch to make the lava on taspir safe to walk in. The lava is open for everyone, but the switch only to admins. But make the control room in a place which was normally not open to people anyway, instead of locking an area for it.

[edit] Legal Info

Some people may be confused as to the actual legality of making such modifications to base JA maps due to words like "compile/recompile" or terms like "reverse engineering" that may have been used in conversation elsewhere. This section will explain the legality with reference to the Software License and Limited Warranty provided by LucasArts. Only relevant portions of the license will be quoted below. A full copy of the license agreement can be found in the Jedi Academy INSTALL directory with the name "license.txt".

From paragraph two, sentence three of the license.txt file provided with the Jedi Academy game (relevant text in bold):

You may not: (1) copy, distribute, rent, lease or sublicense all or any portion of the Software; (2) modify or prepare derivative works of the Software; (3) transmit the Software over a network, by telephone, or electronically using any means, except in the course of your network multi-player play of the Software over authorized networks; (4) engage in matchmaking for multi-player play over unauthorized networks; (5) design or distribute unauthorized levels; or (6) reverse engineer, decompile or disassemble the software.

Addressing each bolded phrase individually:

• (2) modify or prepare derivative works of the Software

This does not apply to the map modding method described here, as the modified maps fall under the category of "New Levels" as defined by the license agreement text. This will be discussed in greater detail later.

• (5) design or distribute unauthorized levels

This does not inherently apply to the map modding process described here, so long as the conditions laid out in the "New Levels" paragraph are not violated by the author of the map modification. The process itself does not violate any of these conditions, which can be read in full in the aforementioned "license.txt" file.

• (6) reverse engineer, decompile or disassemble the software.

This does not apply to the map modding process mentioned here, as the explained method does not mention, call for, require, or otherwise endorse the decompiling of any part of the Jedi Academy game software and files. The entities data is read directly from the BSP file itself, without any reverse engineering or decompiling whatsoever. Furthermore, even though the license agreement does not explicitly forbid the recompiling of any base map, this process does not perform a recompile either. As mentioned earlier in the article, a function of the compiler is used only to fold the entities into a pre-compiled BSP file. There is absolutely no decompiling or recompiling involved in this process.

In addition to the above, the license agreement also lays out rules governing "New Levels." From paragraph nine of the license.txt file provided with the Jedi Academy game (relevant text bolded):

"New Levels" are data that modify, add to, or substitute for data in the Software, thus modifying, adding to, or replacing levels provided by LucasArts in the Software, and may also include saved games, and scenarios created using the skirmish features of the Software.

As clearly seen above, the definition of a new level, according to the official license agreement, is any modification, addition, or substitution of levels provided by LucasArts. The map modding technique described in this article is a process for doing just that: modifying levels provided by LucasArts. Base maps modified by this technique therefore fall under the category of "New Levels" as explicitly stated by the license agreement. New levels are authorized by LucasArts, so long as they adhere to the following requirements (from paragraph nine of the license.txt file):

(1) New Levels will work only with the retail version of the Software, and may not work with any demo or Original Equipment Manufacturer (generally known as "OEM") versions of the Software. (2) New Levels may not modify any COM, EXE, DLL or other executable files. (3) New Levels must not contain any illegal, scandalous, illicit, defamatory, libelous, or objectionable material (as may be determined by LucasArts in its sole discretion), or any material that infringes any trademarks, copyrights, protected works, publicity, proprietary, or other rights of any third party or of LucasArts. (4) New Levels may not include any LucasArts sound effects or music files or portions thereof. (5) New Levels must identify in every description file, on-line description, read-me, and in comments in the New Level code (if new code is added): (a) the name, address, and e-mail address of the level’s creators, and (b) the following disclaimer: "THIS LEVEL IS NOT MADE, DISTRIBUTED, OR SUPPORTED BY LUCASARTS, A DIVISION OF LUCASFILM ENTERTAINMENT COMPANY LTD. ELEMENTS TM & (C) LUCASARTS, A DIVISION OF LUCASFILM ENTERTAINMENT COMPANY LTD." (6) New Levels may not be sold, bartered, or distributed with any other product for which any charge is made (other than incidental charges for time spent on-line), but rather must be distributed free of charge at all times. (7) By distributing or permitting the distribution of any New Levels, all creators or owners of any trademark, copyright, or other right, title or interest therein grant to LucasArts an irrevocable, perpetual, royalty-free, sublicensable right to distribute or exploit the New Level by any means or media (whether now known or hereafter invented), and to create and distribute by any means or media (whether now known or hereafter invented) derivative works thereof, and to charge for the distribution of such New Level or such derivative work, with no obligation to account to any creators or owners of the New Level in any manner. (8) LucasArts may revoke your right or permission to use, distribute or make New Levels at any time and in its sole discretion.

None of the above conditions is inherently violated by any step of the map modding process described in this article. Base maps modified though this method are therefore permitted by the official Jedi Academy game license agreement from LucasArts.

Thus, making map modifications to base maps via the procedure outlined in this article is completely and fully legal.