User Tools

Site Tools


game:george_thoughts

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
game:george_thoughts [2013/06/28 18:49] rpcgame: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://ministry.kronosaur.com/|Ministry]].
 +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://forums.kronosaur.com/viewtopic.php?f=2&t=5439&p=49689#p49690|this post]]. \\ 
 +Yes, it is intentional, but with some limitations.
 +
 +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/orange\\ 
 +Positron: yellow, with particulate texture\\ 
 +Plasma: yellow\\ 
 +Antimatter: yellow\\ 
 +Nano: various (gray/green/etc) but with complex texture\\ 
 +Graviton: purple/violet\\ 
 +Singularity: black/white/violet\\ 
 +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/antimatter and ion). If you want to create new laser styles I recommend mixing in more white (to make the beam whiter). For example, I imagine a gamma-ray laser could be white with fringes of violet/purple.\\ 
 +==== Planets for API version 14 ====
 +Taken from [[http://forums.kronosaur.com/viewtopic.php?f=5&t=5934#p53893|here]]\\ 
 +Spawning uses system macros and labels. For example, if you look at StarSystems.xml you'll see a definition for <AsteroidBeltSystem>. This is a macro used to create an asteroid belt system. The macro defines (randomly) the position of several planets. Under <Orbitals ...> you can see a reference to a "DesertPrimary" macro.
 +
 +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 "planet" attribute, which means that the label is around a planet. When the system is created we may randomly put a station here, preferring stations that want to be around a planet.
 +
 +In previous versions, the planet object itself (stDesertTerrestrial...) would ALSO have a "planet" attribute. This was useful in case you later wanted to enumerate all the planets in a system. But it turned out that some objects were being used both as planets and moons, so I couldn't put the attribute on the object itself.
 +
 +Instead, I use a special attribute +isPlanet:true; which matches only if the object is a true planet (orbiting a star).
 +
 +If you're interested in enumerating objects in the system, then here are a few tips:
 +
 +1. You can use the special attribute +scale:world; to enumerate all planets, asteroids, and moons in the star system. +scale:star; matches all stars.
 +
 +2. All worlds (defined in core) have an explicit size (in kilometers). They are split up into size classes:
 +<code>
 +                        Asteroid         < 1,000 km
 +                  sizeA      Tiny         ~ 10 km
 +                  sizeB      Small         ~ 50 km
 +                  sizeC      Medium         ~ 100 km
 +                  sizeD      Large         ~ 500 km
 +
 +                        Planetoid         ~ 2,500 km
 +                  sizeE      Small         ~ 1,000 km
 +                  sizeF      Medium         ~ 2,000   km
 +                  sizeG      Large         ~ 4,000 km
 +      
 +                        Terrestrial         ~ 10,000 km
 +                  sizeH      Small         ~ 5,000 km
 +                  sizeI      Medium         ~ 10,000 km
 +                  sizeJ      Large         ~ 20,000 km
 +
 +                        Gas Giant         ~ 100,000 km
 +                  sizeK      Small         ~ 50,000 km
 +                  sizeL      Medium         ~ 100,000 km
 +                  sizeM      Large         ~ 200,000 km
 +</code>
 +3. You can match a specific size class with +sizeClass:H; (for example) to match all sizeH worlds.
 +
 +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; Matches all size H, I, J worlds
 ++gasGiant; Matches all size K, L, M worlds.
 +
 +Hope that helps!
 +==== On Items ====
 +Taken from [[http://forums.kronosaur.com/viewtopic.php?f=5&t=6375#p56912|here]]\\ 
 +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, you need to do something like this:
 +
 +(shpInstallArmor gPlayerShip "the armor that looks like: [UNID: 0xD518FF28 count:4 flags:none]")
 +
 +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:installed installedAt:0]
 +
 +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:installed installedAt:0]")
 +
 +Unfortunately, itmCreate can't output that kind of record (it doesn't know how to set the installed flag), so you can't use it. Instead, you need to find the item on the player ship and use that. objGetItems returns a list of item records that match a specific criteria.
 +
 +(objGetItems gPlayerShip "unid:0xD518FF28;") ->
 +[UNID: 0xD518FF28 count:3 flags:none]
 +[UNID: 0xD518FF28 count:1 flags:installed installedAt:0]
 +
 +Since both records match the UNID, objGetItems returns both the installed and uninstalled. If I only want the installed item, I need the 'I' flag:
 +
 +(objGetItems gPlayerShip "unid:0xD518FF28; I") ->
 +[UNID: 0xD518FF28 count:1 flags:installed installedAt:0]
 +
 +Of course, the result is still a list, so I would need to use the '@' syntax to get the first element of the list:
 +
 +(shpEnhanceItem gPlayerShip (@ (objGetItems gPlayerShip "unid:0xD518FF28; I") 0))
 +
 +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:
 +
 +<code>
 +(objadditem gplayership (itmcreate 0xD518FF28 4) 4)
 +(shpinstallarmor gplayership (@ (objgetitems gplayership "unid:0xD518FF28; U") 0) 0)
 +(shpinstallarmor gplayership (@ (objgetitems gplayership "unid:0xD518FF28; U") 0) 1)
 +(shpinstallarmor gplayership (@ (objgetitems gplayership "unid:0xD518FF28; U") 0) 2)
 +(shpinstallarmor gplayership (@ (objgetitems gplayership "unid:0xD518FF28; U") 0) 3)
 +</code>
 +
 +Notice that the "unid:..." term ends in a semi-colon. And the "U" term doesn't need a "^".
 +
 +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 ====
 +[[/modding/shield_and_level_damage_adjustment_curves1.01|Shield and Level adjustment curves]]
  
game/george_thoughts.1372445379.txt.gz · Last modified: 2014/12/27 04:40 (external edit)