BlockBehaviorConfig.xml and non-weapons

[ltmauve]

So, I was looking at the blockBehaviorConfig.xml file in the dev build and thinking that while the weapons part is fairly robust in customizablity, the other mechanics (power, thrust, shields) seem to be slightly more limited.

First part of the changes is for different types of blocks to contribute to the same stat (say, two types of power blocks or tank blocks) with different ratings or amounts, or possibly to contribute to two different types of stats.

Second part is to let the ship properties (power, shields, thrust) be defined in the xml file. This would allow us to create some forms of modding (like active heat sinks, thermal engines) in the config file alone.

Third part is to allow customizable cost and outputs for all block types, for example, I could have shields require a "fuel" to recharge (thus implementing the liquid armor that many people have dicussed) or have weapons require ammo. I could also have weapons generate waste heat, or have engines build up heat as well.

Fourth part is probably the most difficult part to implement, and is probably enough of a pain that Schema will now curse me to have a grey cat sit on my keyboard any time I try to make a suggestion. Allow modders to put formulas in the xml file, and have the program implement them. For example, I could change the power consumption of the laser to vary over time, or have power generators with a different scale than the xm3.4s, or almost any other mechanic that could be implemented by modifying existing game code (i.e. not FTL)

so the xml file would have a structure like this:

Spoiler: Not actual .xml. For demonstration purposes only. May not be possible without completely rewriting engine.

<Properties> these have attributes that control how they are displayed, both in build and flight mode
<Thrust>
<Mass>
<Turnx>
<Turny>
<Turnz>
<ShieldCapacity>
<ShieldRegen>
<Power> energy/second aka regen
<Energy>
<Heat> or whatever other mechanics you decide to add
</Properties>

<Ship> properties that depend on the entire ship
</Ship>

<Block Name="THRUST_ID" Grouping="Contiguous">
<Activation type="movement_keys">
<Movement direction = "movement_keys"> Other types are group_facing and ship_facing,
formula goes here i.e. "group.thrust"
</Movement>
<Cost property="energy"> cost types will cause the block/group to stop functioning if the property will go below zero or above the max value
formula goes here i.e. "-300 * group.thrust" negative cause it decreases the energy available.
</Cost>
<Passive property="thrust"> passive types modify a property but do not change it whether active or inactive.
formula goes here i.e. "group.mass * group.x * group.y * group.z * 75"
</Passive>
</Block>

<Block Controller="POWERSUPPLY_COMPUTER_ID" Name="POWERSUPPLY_ID" Grouping="Contiguous"> shields would have grouping "all"
<Activation type="hotbar_sticky"> click it on and off.
<Tweakables> this allows you to like adjust weapons and stuff
formula here that determines how many points you get per block to divide between the different tweakables.
<Range_tweak>
<Rate_tweak>
<Effect type="transfer" mechanism="beam"> transfer effects only happen when the whatever hits a target
<Distance>
formula i.e. "Range_tweak"
</Distance>
<Cooldown>
formula i.e. "200"
</Cooldown>
<Effect_Cost property="energy">
formula i.e "Rate_tweak"
</Effect_Cost>
<Transfer_Cost property="energy">
formula i.e Rate_tweak
</Transfer_Cost>
</Effect> I could put more costs here like if I want to have the powersupply have a slight overhead even when not hitting anything.
</Block>

<Block Controller="MISSILE_COMPUTER_ID" Name="MISSILE_ID" Grouping="Contiguous">
<Activation type="hotbar_loose"> hold to keep it going
<Tweakables> this allows you to like adjust weapons and stuff
formula here that determines how many points you get per block to divide between the different tweakables.
<Range_tweak>
<Rate_tweak>
<Damage_tweak>
<Speed_tweak>
<Radius_tweak>
<Tracking_tweak>
</Tweakables>
<Effect type="attack" mechanism="missile">
<Distance>
formula for the range of the missiles
</Distance>
<Cooldown>
formula for the time between shots
</Cooldown>
<Damage>
formula for the damage
</Damage>
<Radius>
formula
</Radius>
<Tracking> types are none(0), IR(1), IFF/IR-avoid(2), IFF/IR-avoid-ally(3), IFF/IR-target(4), IFF/IR-target-ally(5), evil-seeking(6), and Lock-on(7). IR is basically the KBs, IFF/IR describes what the missiles will do to your faction, IFF/IR -ally describes what the missiles will do to you and your allies, and evil-seeking only targets hostiles.
formula
</Tracking>
<Tracking_time> only for lock-on tracking. Is constant to find time needed to aquire lock. Ignored otherwise
formula
</Tracking_time>
<Effect_Cost property="energy">
formula
</Effect_Cost>
</Effect>
<Slave name="LASER_COMPUTER_ID" ratio="1.0"> ratio determines the ratio at which maxmimum effect occurs 2.0 means there needs to be twice as many slave blocks as master blocks.
Yeah, looks a lot like a block section on its own, except the effect has no type attribute, and all forumlas reference the master formula of the same type
<Modifier name="EMP_EFFECT_COMPUTER_ID" ratio="1.0">
Looks almost exactly a normal block group
</Modifier>
</Block>

Hopefully some of you are less confused by all of this. And if you're wondering why the turn rates are properties, imagine making turning thrusters using some special block.

 

[NeonSturm]

I like it.

There could be value ranges like formula="start 0=0 linear to 10=10 asymptotic to 20=50 linear to 1000=100 end" first=block-count second=value.
For things that never change during flight, only with a 10 second delay (down-time) during construction/destruction, it would not drain too much performance to calculate these things.

But I would also like some kind of defaults or pattern to auto-generate stats.

<blocks><default><hp="100"/></default><basic><hulls><default>values - like hp - overwrite defaults from basic and blocks</default></hulls></basics></blocks>

Maybe not everything should be solved with config files, but with Lua or even Java extensions.

But repeated things or things which just insert some variable static variable numbers into pre-defined code should be easy to implement if values are not too hard-coded in different code locations.

 

[ltmauve]

True, making everything in a config file might be a bit overkill. I did a bit of research, and either there would have to be a scripting language in the config, which would probably be too hard on performance, or you would have to compile the code off of the config file, which would be a huge pain.

I don't know if it would be possible to change a function reference based on something in a config file. (So function 1 is a asymptotic function, function 2 is product of dimensions, function 3 is sum of dimensions, et. al.) If that's the case, then this does become more viable. Implementing custom functions (like time-dependant functions) is probably asking a bit much right now, but still......

Also, as for your "change the default hp of blocks" it might be possible to change the way the blockconfig file works so that a default value for properties can be implemented for each section.

 

[NeonSturm]

I don't know if it would be possible to change a function reference based on something in a config file. (So function 1 is a asymptotic function, function 2 is product of dimensions, function 3 is sum of dimensions, et. al.)

class FunctionHeader extends LinkedList{
   private int start, end, start2, end2;
   public FunctionHeader(int start, int end, int start2, int end2){ this.variables = variables; }
   public translate(int value){}
}
class Linear extends FunctionHeader || implements FunctionHeader, MaybeSomethingElse{
   public FunctionHeader(int start, int end, int start2, int end2){ /* your code here */ }
   public translate(int value){
      int range = end - start;
      int range2 = start2 - end2;
      value = value -start
      if( value > end ) return -1 || throw Exception("Too big - continue with next value range");
      return value /range *range2 + start2;
   }
}
class Compiler{
   public static FunctionHeader compile(String name, int start, int end, int start2, int end2)
   {
      switch(name){
      case "linear": return new Linear(start, end, start2, end2);
      case "linear": return new Asymptotic(start, end, start2, end2);
      case "linear": return new FunctionX(start, end, start2, end2);
      }
   }
}
class CRE || ConfigRuntimeEnvironment
{
   private FunctionHeader first;
   public addFn( String name, int start, int end, int start2, int end2 )
   {
      this.first.setNext( Compiler.compile(name, start, end, start2, end2) );
   }
   public translate( int value )
   {
      try{
         int result = -1;
         for( FunctionHeader current = this.first; current && result < 0; current = current.next){ result = current.translate( start, end, start2, end2 ); }
      }
   }
}

Edit: Actually, it is Java, not Java-Script, but the editor here does not show an option to syntax-highlight Java and JavaScript is the closest match.

I just wrote what was floating through my mind. Header = from C++. I didn't know any better names and am too lazy - the example is what matters

 

[ltmauve]

I wasn't talking about creating new functions using the config, which is what this seems to be doing. What I was talking about was having a few predetermined functions that take variables already set up and have the config file determine where the program jumps when it wants to determine the value of a group. These would also take of variable calls for the user. Not full do-whatever, but still much better.

 

[NeonSturm]

If name is linear, the program will use the code from "class Linear implements FunctionHeader", else it will use "class Asymptotic implements FunctionHeader".

And you can use all functions defined in FunctionHeader - thus "classReference.translate(int value) -> int value" and set allowed [start to end] -> [start2 to end2] or repeat with the next segment (which can itself be either asymptotic or linear).

CRE's private FunctionHeader first : first = first element of a linked list of "value in [start to end] -> [start2 to end2] | (-1 : use next element of linked list)"

to me (at least) it is obvious that you need one CRE instance for either "original shield capacity -> new shield capacity"
CRE (config runtime environment) has a translate which goes through all FunctionHeader instances in first.next.next.next until it gets result > -1... not the final implemention though as it not continues on errors as I see now. My fault

 

[ltmauve]

So, I still think that using predetermined functions with different inputs (Linear, scaling 30, offset -10) would probably be the most best way to efficiently implement this using the config. (Once we have an API we can use then we could probably directly write functions) Then you could have a separate call for various time-dependent functions that would alter the values based on the time since the whatever was activated.

 

[NeonSturm]

Did you heard of infix functions (= operators)?
I know Java does not make much use of them, but in Haskell "f a b" == "a `f` b". Concrete examples: "2 == (5 `between` 7)".

It is not more difficult to implement, just (maybe) more difficult to leave your current way of thinking.
But "element1, e2, e3 and e4" in english would be "[e0, e1, e2, e3]" in Java. It will be closer to the language most peoples are used to.

With

• formula="start 0=0 linear to 10=10 asymptotic to 20=50 linear to 1000=100 end"
• first="block-count"
• second="value"

think of separators:

1. "start code end" -> "code"
2. "a:b f to c:d" -> start "a", start2 "b", function "f", end "c", end2 "d"
   • Segments in-between a,b,f,c,d as delimiters.

It is an easy pattern-matching. Why should we force peoples to write code?
The important thing which I mind is: consistence.

Just give "start" and "end" a higher precedence compared to "to" ":"...
Java Compiler = Stone Age #2

 

[ltmauve]

That's probably extremely hard on the code, and still doesn't implement the functionality that is wanted. What I was saying is that you change the location in the code that the JVM goes to when it runs the evaluation of a group/entity. Along with a few constants, you could get any sort of static behavior.
Implementing time-varying formulas is something that should also be done, but cannot be done with either of the plausible solutions that we put up here.
I'm not saying that people have to code, but simply letting people choose from the predetermined functions would allow a great deal of customizibility without slowing the engine at all.

#thiswouldbeeasierifeitherofusknewanythingabouttheengine

 

[NeonSturm]

http://learnyouahaskell.com/

They did it.
What makes it hard to understand?

Variable number of parameters and returns I think.

I started to be confused (for a few minutes) after I saw what they wrote about "Just" and "Maybe". But that is advanced stuff