Post reply

Warning: this topic has not been posted in for at least 120 days.
Unless you're sure you want to reply, please consider starting a new topic.

Note: this post will not display until it's been approved by a moderator.

Name:
Email:
Subject:
Message icon:

shortcuts: hit alt+s to submit/post or alt+p to preview

Please read the rules before you post!


Topic Summary

Posted by: Pete_Keller
« on: November 20, 2007, 10:41:10 PM »

Quote from: "Randy"
Code: [Select]
Base Tech Table:
  Laser Focal Size = 1-30 where 10cm = 1
  Laser Wavelength = 31-60 where Infrared = 31
  Capacitor recharge rate = 61-90 where rate 1 = 61

Doing this is rather dangerous long term as it puts severe problems into the system if you ever run into the end of a block (ie want to add a 31st laser focal size).

You need to have a slightly different structure:
Code: [Select]
Base Tech Table:
  TechTypeID where laser = 15
  BaseTechType =1-x (unique for each TechTypeID; lasers need 1-3)
     1=Focal Size, 2 = Wavelength, 3 =  Capacitor Recharge Rate  
  BaseTechLevel = 1-x
Thus a fully level 1 laser would have 3 records:

Code: [Select]
TechTypeID | BaseTechType | BaseTechLevel
    15           1              1         (for focal size 10cm)
    15           2              1         (for wavelength)
    15           3              1         (for capacitor rate)
 

To lin to a specific component, you really only need a similar table but use SDComponentID instead of TechTypeID. Add TechTypeID to the ShipDesignComponents table. Gives the flexibility and removes artificial hard limits.

  If you've ever coded using line numbers (basic... ewww!), you know what these kinds of limits do to ya when you hit one... :shock:


Randy,  have you looked in the database?  The way it is set up, it has a tech type ID column which would be used to select the subcomponents of the tech you are building.

If you get 31 Laser Focal Sizes (which I am not expecting), you would just grab another set of 30 later in the database.  I only wanted him to put them put them in order to make it easier to visually search for data in the database.

Pete
Posted by: ocie
« on: November 16, 2007, 02:39:56 PM »

I like the idea, could be used to slide a stealth scout onto a system and gather OOB and such before an attack :roll:
Posted by: Randy
« on: November 16, 2007, 09:16:17 AM »

Code: [Select]
Base Tech Table:
  Laser Focal Size = 1-30 where 10cm = 1
  Laser Wavelength = 31-60 where Infrared = 31
  Capacitor recharge rate = 61-90 where rate 1 = 61

Doing this is rather dangerous long term as it puts severe problems into the system if you ever run into the end of a block (ie want to add a 31st laser focal size).

You need to have a slightly different structure:
Code: [Select]
Base Tech Table:
  TechTypeID where laser = 15
  BaseTechType =1-x (unique for each TechTypeID; lasers need 1-3)
     1=Focal Size, 2 = Wavelength, 3 =  Capacitor Recharge Rate  
  BaseTechLevel = 1-x
Thus a fully level 1 laser would have 3 records:

Code: [Select]
TechTypeID | BaseTechType | BaseTechLevel
    15           1              1         (for focal size 10cm)
    15           2              1         (for wavelength)
    15           3              1         (for capacitor rate)
 


To lin to a specific component, you really only need a similar table but use SDComponentID instead of TechTypeID. Add TechTypeID to the ShipDesignComponents table. Gives the flexibility and removes artificial hard limits.

  If you've ever coded using line numbers (basic... ewww!), you know what these kinds of limits do to ya when you hit one... :shock:
Posted by: Pete_Keller
« on: November 11, 2007, 08:27:04 AM »

Quote from: "SteveAlt"
If I implement this, I will have to start tracking which background techs go into each ship component, which is quite a lot of work but worth it in the long run. I also need to spend some time deciding the chances of learning technical information and what factors are involved in that chance.

Comments and suggestions welcome

Steve


Steve, I was going to suggest (today) that you split the ships systems off from the base technology in the database, and hold a list of the components used in the table (Currently Engines uses 7 base technologies, so create your table with 20 technology slots -- this allows almost 200% expansion without redesigning the database).  

Then you renumber all the base tech (once) so that for example Laser Wavelength would be 1-30, and we currently use 1-12 (this gives us 50% expansion without having numbers scattered everywhere).  Once you renumber the base tech systems. you never re-use a number.  If you change the tech for sensors, like you just did, you stop using the old tech numbers, and start using new numbers.  This would allow a scriptwriter like me to migrate tech from one version to another.

I am going to use Laser in this example:
Code: [Select]
Base Tech Table:
  Laser Focal Size = 1-30 where 10cm = 1
  Laser Wavelength = 31-60 where Infrared = 31
  Capacitor recharge rate = 61-90 where rate 1 = 61

Researched tech table: (A new table)
  ID = auto increment
  RaceID = 12 (my race) -- note no gameID needed since each race is only in one game.
  TechTypeID = 106 (Laser - from current table)
  BaseTech1 = 1 (10CM Laser Focal Size)
  BaseTech2 = 31 (Infrared Wavelength)
  BaseTech3 = 61 (Cap recharge Rate 1)
  BaseTech4-BaseTech20 = Null (or zero)
  Dev = 300 (again from current table)


On further review of the database, add the fields I listed above to the ShipDesignComponents table and use it to track the data.

Pete
Posted by: sloanjh
« on: November 10, 2007, 07:37:43 PM »

Three comments:

I agree with everything Erik said, especially about the nifty political manuevering.

If you're going to go into getting research points from observations (I really like that idea too, btw), then I would advocate passive sensors being able to gather data too.  After all, EM emissions spectrum gives lots of information - think about EC-121, submarines getting acoustic signatures, and Russian trawlers.  If you cut the probability of a particular type of sensor acquiring information from what you were planning for actives (i.e. you need all sensor types to get the same level of information), then this also makes such intelligence gathering more expensive.  You might also put a threshold on signal strength (e.g. greater than 10x detection level) before it's possible to acquire information.

I also like the concept of requiring the data be transmitted as you put in your last paragraph.

Johh
Posted by: Erik L
« on: November 10, 2007, 06:51:57 PM »

Regarding the identifying races by their ships.

I think that they should be identifiable. You would just need to store who built the ship, and who owns it. This brings up some potentially interesting political maneuvers.

Race A buys ships from Race B. Race C is attacked by AB ships. Race A claims no knowledge of said attacks if asked, since the ships were not theirs. If Race B encounters Race C later on, Race C would be inclined to shoot first and talk later in this situation.

Of course, if Race A starts to refit the ships, then I would say they start to take on characteristics of Race A as opposed to Race B.
Posted by: SteveAlt
« on: November 10, 2007, 06:01:43 PM »

I am considering some changes that are mainly behind the scenes but will have some impact on tactical intelligence. I thought I would run them by the board to get some feedback first. At the moment this is just thinking out loud.

Currently, you can create