Den
He's That Guy
Posts: 4,294,967,295
|
Post by Den on May 11, 2014 16:03:06 GMT -5
fire_rate is number of rounds per second. Multiply by 60 for rounds per minute. Or to get the time between shots, 1 divided by fire_rate.
stat_rof is just for that dumb bar in the weapon selection menu.
|
|
|
Post by LoE Impact on May 11, 2014 16:19:54 GMT -5
sweet thanks!
|
|
Will
True Bro
K/D below 1.0
Posts: 1,309
|
Post by Will on May 12, 2014 11:53:15 GMT -5
|
|
Den
He's That Guy
Posts: 4,294,967,295
|
Post by Den on May 12, 2014 13:03:43 GMT -5
IS DUMB DUMB BAR BARDUMB
|
|
mannon
True Bro
wordy bastard PSN:mannonc Steam:mannonc XB:BADmannon
Posts: 15,371
|
Post by mannon on May 12, 2014 14:23:34 GMT -5
The Arc cannon is a different story, the near value and far value are actually how the weapon charges. The developers were lazy I guess. Actually I wouldn't call it lazy. If you have a weapon that performs in a different manner where the effects normally attributed to those variables do not apply, but you do need some variables for it's other effects (well I guess these are more like constants, but meh) it seems like it makes sense to reuse the same fields for those values. I suppose that it might be a bit less transparent unless well commented, but then I always think in terms of building tables out of all these values and I wouldn't want to create whole new columns of data for a single weapon when I could just re-purpose some fields with a different effect. Of course you run into the whole efficiency vs transparency argument when it comes to coding and technically transparency should win out 9 times out of 10 for "good coding" since the idea is that you write and comment your code not for yourself, but for some inevitable future employee you'll never meet that will have to work with it with little direction or documentation. So I can see why you'd say it's lazy. Personally I like it better than creating whole new fields for it, though. heh
|
|
Den
He's That Guy
Posts: 4,294,967,295
|
Post by Den on May 12, 2014 15:30:50 GMT -5
That's not lazy. Those weapon scripts are basically just a string of variables that are called upon by other parts of the system. The system needs all of those variables to be present and declaring something or else the program will probably get fussy and "YO WHERE'S DAMAGE_NEAR_VALUE WHAT THE HELL IS THIS I CAN'T WORK LIKE THIS". Even if they were to make something like "damage_min_charge" and "damage_max_charge" just for the Arc Cannon, those files would still need to have something after near_value and far_value. If everything in a program isn't accounted for, things get messy real quick.
Instead of making hard code in the form of more unique variables to do things that only one or a few elements in the game makes use of (for things like the Arc Cannon damage charge, or the Abilities that use the magazine and rate of fire variables), using existing variables and tweaking their behavior with a simple script that can be easily modified is very good coding.
Hard coded things bad. Modular systems good.
|
|
mannon
True Bro
wordy bastard PSN:mannonc Steam:mannonc XB:BADmannon
Posts: 15,371
|
Post by mannon on May 12, 2014 16:22:44 GMT -5
I'm not really a programmer myself, but Den's explanation of the modular approach sounds right to me. Glad to see there's justification for it in programming as well. I'm more of a database and table guy, but I'd do it the same way as well. I'm always trying to standardize my data as logically as possible.
|
|
mannon
True Bro
wordy bastard PSN:mannonc Steam:mannonc XB:BADmannon
Posts: 15,371
|
Post by mannon on May 14, 2014 2:20:30 GMT -5
I did throw a chart together based on the spreadsheet above. I didn't bother bringing it up as it's quite incomplete with no secondaries, amped variants, or attachment modifications. Also it's a bit of a hot mess so I don't really like it. It's hard to read, but I wanted to see all the base primaries on one chart just because. Sorry if it gives you aids, but I figured I might as well post it just because...
|
|
Gamma
True Bro
Posts: 127
|
Post by Gamma on Aug 9, 2015 14:41:46 GMT -5
The base forward running speed of a Pilot is 180.6 units per second, or about 7.7 MPH. The base Sprint speed of Pilots is 269.85 units per second, or 11.5 MPH. Consecutive wall running speeds up the player gradually, allowing him to reach a maximum of almost twice his sprint speed. About 22 to 23 MPH. By "base forward running speed", is Den referring to sprinting on the ground (opposed to initial wall-run), or the max walking speed? As run and sprint are often used interchangeably.
|
|
Gamma
True Bro
Posts: 127
|
Post by Gamma on Aug 10, 2015 17:26:19 GMT -5
"run" and "sprint" tend to be used synonymously. Base sprint/run were mentioned with different speeds. I thought perhaps "base forward run" could be sprinting on the ground, and "base sprint" could be initial wall run.
I know, it's a silly question, but I like to be certain.
|
|