game:george_thoughts
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
game:george_thoughts [2013/06/28 18:49] – rpc | game:george_thoughts [2016/01/06 20:43] (current) – Added link to new page. xephyr | ||
---|---|---|---|
Line 1: | Line 1: | ||
Collection of unsorted information posted by George Moromisato on the inner workings of Transcendence | Collection of unsorted information posted by George Moromisato on the inner workings of Transcendence | ||
+ | |||
+ | ==== Records from the Ministry ==== | ||
+ | |||
+ | George will sometimes post some highly detailed stuff on[[http:// | ||
+ | See the [[ministry_notes]] page | ||
==== On the next version ==== | ==== On the next version ==== | ||
Line 1106: | Line 1111: | ||
p.s.: Let me know if I screwed-up the arithmetic. | p.s.: Let me know if I screwed-up the arithmetic. | ||
+ | ==== Laser Color ==== | ||
+ | This information was taken from [[http:// | ||
+ | Yes, it is intentional, | ||
+ | |||
+ | In general I wanted each damage type to have a unique look: | ||
+ | |||
+ | Lasers: red, green, or purple (in ascending order of strength)\\ | ||
+ | Kinetic: gray\\ | ||
+ | Particle: green, with particulate texture\\ | ||
+ | Blast: flame\\ | ||
+ | Ion: cyan\\ | ||
+ | Thermo: flame/ | ||
+ | Positron: yellow, with particulate texture\\ | ||
+ | Plasma: yellow\\ | ||
+ | Antimatter: yellow\\ | ||
+ | Nano: various (gray/ | ||
+ | Graviton: purple/ | ||
+ | Singularity: | ||
+ | Dark Acid: teal\\ | ||
+ | Dark Steel: gray-green\\ | ||
+ | Dark Lightning: blue\\ | ||
+ | Dark Fire: red\\ | ||
+ | \\ | ||
+ | For lasers, we should probably avoid yellow and blue (to avoid confusion with positron/ | ||
+ | ==== Planets for API version 14 ==== | ||
+ | Taken from [[http:// | ||
+ | Spawning uses system macros and labels. For example, if you look at StarSystems.xml you'll see a definition for < | ||
+ | |||
+ | If you look at the definition of the DesertPrimary macro (in Worlds.xml) you'll see that it places two things: a planet (stDesertTerrestrialSizeH) and a label. | ||
+ | |||
+ | A label is a point in space that may hold a station (friendly or enemy). This particular label has certain attributes, including the " | ||
+ | |||
+ | In previous versions, the planet object itself (stDesertTerrestrial...) would ALSO have a " | ||
+ | |||
+ | Instead, I use a special attribute +isPlanet: | ||
+ | |||
+ | If you're interested in enumerating objects in the system, then here are a few tips: | ||
+ | |||
+ | 1. You can use the special attribute +scale: | ||
+ | |||
+ | 2. All worlds (defined in core) have an explicit size (in kilometers). They are split up into size classes: | ||
+ | < | ||
+ | Asteroid | ||
+ | sizeA Tiny ~ 10 km | ||
+ | sizeB Small ~ 50 km | ||
+ | sizeC Medium | ||
+ | sizeD Large ~ 500 km | ||
+ | |||
+ | Planetoid | ||
+ | sizeE Small ~ 1,000 km | ||
+ | sizeF Medium | ||
+ | sizeG Large ~ 4,000 km | ||
+ | | ||
+ | Terrestrial | ||
+ | sizeH Small ~ 5,000 km | ||
+ | sizeI Medium | ||
+ | sizeJ Large ~ 20,000 km | ||
+ | |||
+ | Gas Giant ~ 100,000 km | ||
+ | sizeK Small ~ 50,000 km | ||
+ | sizeL Medium | ||
+ | sizeM Large ~ 200,000 km | ||
+ | </ | ||
+ | 3. You can match a specific size class with +sizeClass: | ||
+ | |||
+ | 4. You can use normal attributes to match sets of classes: | ||
+ | |||
+ | +asteroid; Matches all size A, B, C, D worlds | ||
+ | +planetoid; Matches all size E, F, G worlds | ||
+ | +terrestrial; | ||
+ | +gasGiant; Matches all size K, L, M worlds. | ||
+ | |||
+ | Hope that helps! | ||
+ | ==== On Items ==== | ||
+ | Taken from [[http:// | ||
+ | The most important thing to remember about items (armor, devices, etc.) is that you can only manipulate them by value not by reference. What does that means? Here is a quick tutorial: | ||
+ | |||
+ | When you call a function like: | ||
+ | |||
+ | (objAddItem gPlayerShip (itmcreate 0xD518FF28 4) 4) | ||
+ | |||
+ | you add a single item record to the player ship. The player ship's inventory will look like this: | ||
+ | |||
+ | Player Ship Inventory: | ||
+ | [UNID: 0xD518FF28 count:4 flags:none] | ||
+ | |||
+ | First, notice that even though you've created 4 armor segments there is only a single record. The record itself has a count of 4, which is how we keep track. This is done for efficiency. Otherwise, if you pick up 1000 rounds of ammo we would have 1000 records, which is too expensive. | ||
+ | |||
+ | Next, notice that there is no ID field! The fact that there is no ID field means that you can't refer to the record by ID. So how do you refer to the armor segments? How do you, for example, install them? | ||
+ | |||
+ | You need to install them by describing exactly the items that you want to install. You have to refer to them by value. Effectively, | ||
+ | |||
+ | (shpInstallArmor gPlayerShip "the armor that looks like: [UNID: 0xD518FF28 count:4 flags: | ||
+ | |||
+ | Of course, the above won't work, but the function itmCreate essentially is a way of creating records of that form. So the following works: | ||
+ | |||
+ | (shpInstallArmor gPlayerShip (itmCreate 0xD518FF28 1) 0) | ||
+ | |||
+ | Indeed, the output of itmCreate is a record structure. Under the covers: | ||
+ | |||
+ | (itmCreate 0xD518FF28 1) -> [UNID: 0xD518FF28 count:1 flags:none] | ||
+ | |||
+ | After you do this, you will end up with inventory that looks like this: | ||
+ | |||
+ | Player Ship Inventory: | ||
+ | [UNID: 0xD518FF28 count:3 flags:none] | ||
+ | [UNID: 0xD518FF28 count:1 flags: | ||
+ | |||
+ | Notice that the act of installing armor changes the record! Because the record has changed, you can't refer to it by the original name. For example, suppose I wanted to enhance the armor I just installed. I might naively try this: | ||
+ | |||
+ | (shpEnhanceItem gPlayerShip (itmCreate 0xD518FF28 1)) | ||
+ | |||
+ | Which armor segment would get enhanced? Because the installed armor has changed (because it is installed), I can't use the same code to refer to it anymore. I need to do something like: | ||
+ | |||
+ | (shpEnhanceItem gPlayerShip "the armor that looks like: [UNID: 0xD518FF28 count:1 flags: | ||
+ | |||
+ | Unfortunately, | ||
+ | |||
+ | (objGetItems gPlayerShip " | ||
+ | [UNID: 0xD518FF28 count:3 flags:none] | ||
+ | [UNID: 0xD518FF28 count:1 flags: | ||
+ | |||
+ | Since both records match the UNID, objGetItems returns both the installed and uninstalled. If I only want the installed item, I need the ' | ||
+ | |||
+ | (objGetItems gPlayerShip " | ||
+ | [UNID: 0xD518FF28 count:1 flags: | ||
+ | |||
+ | Of course, the result is still a list, so I would need to use the ' | ||
+ | |||
+ | (shpEnhanceItem gPlayerShip (@ (objGetItems gPlayerShip " | ||
+ | |||
+ | objGetItems is a way to find the item record that you want to refer to. So with that (long) tutorial out of the way, we can talk about your code. | ||
+ | |||
+ | In your first example, there is a small bug in the criteria for objGetItems. Your code should be something like: | ||
+ | |||
+ | < | ||
+ | (objadditem gplayership (itmcreate 0xD518FF28 4) 4) | ||
+ | (shpinstallarmor gplayership (@ (objgetitems gplayership " | ||
+ | (shpinstallarmor gplayership (@ (objgetitems gplayership " | ||
+ | (shpinstallarmor gplayership (@ (objgetitems gplayership " | ||
+ | (shpinstallarmor gplayership (@ (objgetitems gplayership " | ||
+ | </ | ||
+ | |||
+ | Notice that the " | ||
+ | |||
+ | But your second example works just as well because you've described the item perfectly. The second method would get into problems if the item were enhanced, damaged, installed, or had data associated with it. In those cases, you need to use the objGetItems syntax. | ||
+ | |||
+ | Also, many functions return the item record after modification. For example, objSetItemData returns the newly modified item record and you can use the result to refer to the item in subsequent calls. | ||
+ | ==== Shield and Level Adjustment curves ==== | ||
+ | [[/ | ||
game/george_thoughts.1372445379.txt.gz · Last modified: 2014/12/27 04:40 (external edit)