Differences

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

--- game:george_thoughts [2012/03/17 01:18] – external edit 127.0.0.1
+++ 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
+==== 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 ====
@@ Line 1076: / Line 1081: @@
 = "turnTo" \\
 = "attackHold" \\
+==== On Reactors ====
+This information was taken from [[http://forums.kronosaur.com/viewtopic.php?f=5&t=4711&p=43663&hilit=megawatt#p43657|this post]]. \\
+. Each fuel item has a certain number of "fuel units". For example, a Helium fuel rod has 2500 fuel units. [Look at the data= attribute on an item type to determine the number of fuel units.]
+. A reactor with 100% efficiency consumes 1 fuel unit to generate 1.5 MW of power for 1 tick. Example: A weapon is firing and drawing 15 MW. Every tick it will consume 10 fuel units (15 / 1.5 = 10). Enhanced reactors have greater than 100% efficiency and can generate more power on 1 fuel unit. Damaged reactors are the opposite.
+. A weapon rated at 10 MW draws 10 MW only while firing. If the weapon is not firing, it draws 1/10 that amount (unless otherwise specified in idlePowerUse).
+Hope that helps!
+As an aside, this whole design has helped me learn about power a little more. Now I know the difference between a space heater that draws 1 kilowatt vs. a bill in the mail that shows I've used 10 kilowatt-hours. A kilowatt is a measure of the rate at which power flows; a kilowatt-hour is a measure of the quantity of power that I've consumed.
+In the same way, power draw of devices is measured in watts (megawatts) while consumption, which is expressed in fuel units, can be converted to megawatt-hours with a simple formula:
+megawatt-hours = (1.5 * fuel-units) / (ticks-per-hour)
+Since there are 1800 ticks per hour (in game time), and since a single Helium fuel rod has 2500 fuel units, we can convert as follows:
+megawatt-hours = 1.5 * 2500 / 1800 = ~2.08
+That is, a Helium fuel rod has 2.08 megawatt-hours of power.
+And at the risk of going even further astray, note that these numbers wildly undervalue to power of nuclear energy. For example, a barrel of oil masses 139 kg and has about 1.6 megawatt-hours of power--about the same energy density as a Helium fuel rod. In contrast, 100 kg of uranium used in a fission reactor yields about 2.2 million megawatt-hours of power.
+Guess I should have done these calculations when I first came up with the values.
+To be fair, a Helium fuel rod contains all of the shielding and structure designed to contain the fuel--the fuel itself is probably much less than 100 kgs. To reach the same energy density as uranium, the actual fuel in a Helium fuel rod should mass no more than 0.1 grams.
+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:
+. You can use the special attribute +scale:world; to enumerate all planets, asteroids, and moons in the star system. +scale:star; matches all stars.
+. 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>
+. You can match a specific size class with +sizeClass:H; (for example) to match all sizeH worlds.
+. 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]]