Template talk:ShipBox

Where does this "Battery units" come from? Also, other data like turning speed, acceleration, max speed, energy regeneration, etc may have a place in such a box. FYI: The exact numbers can be found in the source code (src/sc2code/ships/*/*.c, right at the start). — SvdB 03:22, 4 Oct 2005 (CEST)

I usually get "Battery units" the same way I get the crew complement: by looking at the Melee ship window. I thought about including the other data (as found in the Star Control I ship databank image), but I didn't know how to find such data (until your info about the source code, that is). Sounds like a great idea. --Phoenix (t) 14:36, 4 Oct 2005 (CEST)

Found it. It's the MAX_ENERGY constant in the .c file. Should I rename "battery units" to something else, like "energy banks" or something? --Phoenix (t) 15:32, 4 Oct 2005 (CEST)

I don't know if it's necessary to include the "Member of" field. Imho, that's a description of the race more than it is of the ship, and that info can be found on the respective race page. Also, it might look better to put the primary and secondary weapons above the the battery and crew numbers. --Fyzixfighter 17:41, 12 Nov 2005 (CET)

Yeah, you're right, I'll remove it. BTW, remember that this is a "young" template—don't apply it to any ships (other than Scout) until we've finalised the template. --Phoenix (t) 19:05, 14 Nov 2005 (CET)

Recent changes

While I do like including more information in a quick coherent fashion, and the 3DO images are a nice addition for the SC2-unique ships, this infobox is too dominating and distracting on most of the pages. Perhaps it would be better to change it to a footer infobox - leaving the databank/icon image in the upperleft like it was before, and then grouping the technical info and 3do image on the bottom in a template. One more reason that I think this would be more advantageous is that there are some things such as the delays and increment that are not easily discernable by the average reader - more reason to move it to the bottom; most people when reading a sentence, paragraph, or paper, if they get confused at the start, won't be able to read/understand the rest (one of the biggest mistakes in common scientific papers). I've got some ideas of how to make it work so after I'm done taking data at work in a few hours, I'll set up some mock-ups of what I'm thinking. Until then, patience young poot worm. --Fyzixfighter 23:01, 5 June 2007 (CEST)

I agree; the infoboxes are too imposing. Setting a maximum width might help; it would at least cause some of the lines to be broken. Also, when the 3DO image is included, the ship icon looks seems superfluous to me, and just makes the whole look bad, because of the low resolution of the icon.

In addition, if you upload an image, please include some description, including where the images came from. And TFB don't have the copyright on the 3DO videos, so we should watch what we publish here; I think this use falls under the quotation right that Dutch law has, but ianal. — SvdB 00:32, 6 June 2007 (CEST)

Hmm...I hadn't considered the copyright implications. I've made a mock-up of a horizontal footer shipbox at user:Fyzixfighter/Sandbox/Scout if anyone wants to look and comment. --Fyzixfighter 07:36, 8 June 2007 (CEST)

I like the footer. Its increased size also means that you can add battery consumption to the primary and secondary also (and ship mass, which should be under Navigation, and which would be "inertialess" for the Skiff and the Probe). Valaggar 13:07, 8 June 2007 (CEST)

My only concern is that we don't need to and we shouldn't include every single attribute, but those that are interesting and easily interpretable - for example, energy consumptions are easily understood, but the delay attributes aren't imo (ie what does a higher delay mean in terms of gameplay?). I'd much prefer if we could express these as rates. The same could probably be said about the speed increment - is this essentially the un-maxed acceleration? In a way, I think these boxes should give someone considering using the ship in melee a quick quantitative analysis (similar to the databank images, but with hard numbers and other data like mass). While the argument could be made that the databank images do just this, we don't have such images for the SC2-unique ships so this kind of shipbox allows us a uniform presentation of information similar to the SC1 databank images for all ships. Also, if we expand the # of attributes, the box will probably need to be organized a bit better so it doesn't become white-space dominated.

If the delay/increment thing is what you don't like, we can use "acceleration per second". The formula for average acceleration per second would be:

Average_Acceleration=(Thrust_Increment*Frame_Rate)/(Thrust_Delay+1)

I don't know, however, the frame rate; if SvdB would be nice enough to provide it...

Also, I don't know the unit of measurement used for thrust in the code - doesn't seem to be 320x200-size pixels per frame.

(re databank-like rates) You know, besides the SC1 ships already having the approximative stats in their databank image (which would lead to a non-uniformity which would be a bit non-beautiful), slight differences can be important: a Cruiser cannot run from a Dreadnought because the Dreadnought is slightly faster. Valaggar 08:55, 9 June 2007 (CEST)

The frame rate is 35 FPS, apparently, as the Table of bio types page indicates: "every frame that the lander is in contact with the creature (35 times per second)". The fragment has been added by SvdB.

So the formula should be: Average_Acceleration=(Thrust_Increment*35)/(Thrust_Delay+1) Valaggar 18:06, 11 June 2007 (CEST)

Actually I'm perfectly fine expressing it in units per frames. And as I understand it, this is the acceleration (not acceleration per second - sorry, I TA'd too many freshman physics courses and I'm a bit of a stickler for physics terms), ie the speed value of the ship increases by Thrust_Increment every Thrust_Delay+1 frames, right? I'm guessing that the same applies to the turn rate and energy regeneration. I think it's nice to leave the the acceleration as a ratio (##/##) conveying as much information as possible succinctly, though I'm not sure if it really makes that much of a difference if we express it otherwise as a decimal. The same could be said for the energy regeneration, which probably uses a similar equation based on Flagship Energy Management. Though the turn rate could be expressed as simply a decimal since the turn increments are all the same. Anyone know how they calculate the "Turn rate" of the Flagship that shows up in the Outfitting screen at the starbase? Just to let you know, I'll probably be changing the ShipBox to a footer here soon, as that seems to be something we can agree on - we can then continue to work out the exact layout and design. Objections? --Fyzixfighter 18:36, 11 June 2007 (CEST)

No objections. As to the "acceleration per second" - it's actually "thrust per second" (i.e. velocity change per second, i.e. acceleration) - I got a bit confused. Anyway, indeed frames are better than seconds, so Average_Acceleration=Thrust_Increment/(Thrust_Delay+1), since with seconds we end of with some large numbers (e.g. 2240) for maximum speeds...

A decimal form would be better than a ratio, I'd say, since it is easier to comprehend at a glance and to compare with other values; the delays are not that significant. It also looks tidy and neat with ratios, but the problem is when you try to figure out whether the Cruiser or the Dreadnought accelerates faster.

Energy regeneration is also based on increments and delays, so the average energy regeneration would be Average_Batt_Regen=Regen_Increment/(Regen_Delay+1). Here, the delay is significant only in the case of the Drone, where a note could explain that.

By the way, you made a mistake in calculating the turn rate of the Scout - it's 16, since it's TURN_WAIT is 0.

As to the weapon range - speed is also important (and whether the weapon is homing or not). Range is MISSILE_SPEED*MISSILE_LIFE. Weapon damage is applicable only to some weapons, the others should simply get a N/A (and salvos can be represented as damage (projectile quantity) - a Jugger would have "1 (salvo of 6 projectiles)"). Such cases are too rare to warrant a separate "salvo" entry. As to the effect of the N/A damage weapons... there are the Primary and Secondary sections of the article. Valaggar 21:11, 11 June 2007 (CEST)

Hmm, then maybe the data I'm drawing my numbers from is a little outdated - it has the shofixti's TURN_WAIT as 1. Though I'm not a programmer-code junkie, so I've been depending on others to extract the information from the code. After I get off work today I'll do an empirical comparison with a Skiff. Yeah, it's sometimes hard to get ones head around the differences between acceleration and speed. It is possible for a ship to have a higher acceleration but lower top speed, and visa versa. So the fact that a Cruiser is slower than the Dreadnought comes from their top speed numbers and not these acceleration values, though the Cruiser also has a smaller acceleration (0.6 vs 0.86). I'll play with it and see which (decimal or ratio) looks better - the decimal would solve the expression of units problem (no frame(s)). Heck, we could even give the number of frames required to reach the top speed - but maybe that's a little overboard. Again, I'll see if I can do some empirical comparisons to confirm these numbers later this evening.

As for the weapon damage, range, speed info, I'd much rather keep that in the sections of the article to keep from bloating this infobox - the information is also in the List of weapons page, which is linked to from the footer, and we could easily link to the appropriate section in the articles from within the footer. Given the strange combat physics and way projectile velocity is calculated, I'd rather not include the range or speed information, because I know that someone will come along and start arguing that the range is different when firing forward/backwards...and I really going through that argument so many times. But even without that, the strange physics makes those numbers less useful imho. Anyways, I'll try and get to some of this and change over in a few hours after I get off work (I probably shouldn't be posting even now, but all I'm doing is taking some preliminary data and I've nothing else to do while I wait :-/). --Fyzixfighter 23:52, 11 June 2007 (CEST)

UPDATE: Just did a quick, super-melee comparison of a skiff and a scout. The scout turns about once for every two rotations of the skiff, so I think the TURN_WAIT=1 is correct for the scout, assuming the skiff's is 0. --Fyzixfighter 01:56, 12 June 2007 (CEST)

New footer form

Well, might as well start a new section. Alright, so I changed the old shipbox over to the footer design, and fixed those pages on which it was currently being used. I think I got most of the data correct, but it's late and so I might have mis-keyed something. I tried to empirically confirm the energy costs, and some of the turn rates. --Fyzixfighter 08:23, 12 June 2007 (CEST)

Ah, the Shofixti's TURN_WAIT was 1. I was looking at the Pkunk Fury instead of the Scout... Typical.

As to acceleration/speed - yes, I knew those things, the example wasn't the best one - but slight acceleration differences really also matter in Super Melee, since the ships could spawn near each other and the speed that could be immediately achieved would be more important than the speed that will be reached after a certain amount of time. Also, ships with a greater acceleration (it doesn't matter whether this is because THRUST_WAIT is small or because THRUST_INCREMENT is large) are more adept at using gravity whips, since the amount of time a ship can spend in a gravity well while thrusting is limited, and it is important to be able to capitalize on that short interval (in which your maximum speed is greater), so comparison between the various acceleration values suddenly becomes much more important.

Regarding weapon range and speed - I agree, it's too irregular (and, considering that maybe SCTrue3 will be released at some point in the future, and that its ships could contain even more irregularities, linking to the relevant sections works best).

So, for short, I like the new footer; the only touch I'd make would be to make "frame" link to a game mechanics page containing the FPS; I'd make a simple "frame rate" page for now, which will be integrated in a larger game mechanics page I'm planning to create in the future. Valaggar 12:48, 12 June 2007 (CEST)

Also, the fire rates of the primary and secondary should be added too. Valaggar 16:10, 12 June 2007 (CEST)

I'll see what I can do with adding in the firing rates - it might take a bit of re-engineering the layout, but I think it's tenable. My only qualm with the links to explanations of the various units is with the link to world units. World units is a measurement of distance, which should appear in the max speed but not in the acceleration as we have it now. Comparing it to units we know and love, acceleration can be given in units of m/s^2 or (m/s)/s, and what we have (units/frame) is analogous to the latter, ie units of speed per unit time. So the acceleration isn't in world units per frame, but in speed units per frame. I would hazard a guess that speed is probably measured in something like world units per frame, but I don't what the scale factor would be - max speed in world units per frame being scale*Max_Speed. Alternatively, we could change the acceleration units to world units/frames^2, but again only if we know what the scale factor is for going from max speed to world units/frame. --Fyzixfighter 19:46, 12 June 2007 (CEST)

Speed is measured in world units per frame, yes. Valaggar 20:43, 12 June 2007 (CEST)

So there's not scale factor to go from the max_speed value to world units/frame? That is, max_speed is already in the correct units? --Fyzixfighter 21:21, 12 June 2007 (CEST)

Yes, it is. Valaggar 11:08, 13 June 2007 (CEST)

copyright issue

I just noticed that someone brought up a related topic over on the forums[1], which gives us the creators of these videos (http://www.pcagraphics.com/). I don't know if a "fair use" argument is valid or is compatible with the creative commons license we use, though I'm sure someone could email them and ask them about it. In the mean time, it might be a good idea to remove the video snapshots from the pages until we get a definite answer. --Fyzixfighter 08:12, 23 June 2007 (CEST)

Well, since there is no new information, I think that it's safer and more ethical to use images that we know are not copyright infringements. I think the *icon.1 images would work the best. Now that I have brief moment of spare time, I'm going to go ahead and implement the change. --Fyzixfighter 03:17, 31 July 2007 (CEST)

Looks and sounds neat and nice to me. Well done. Valaggar 15:44, 2 August 2007 (CEST)