Difference between revisions of "Talk:Bomb Settings"

Latest revision as of 16:25, 22 September 2005

Smong: Can anyone confirm that a bouncing bomb loses it's bbombdamagepercent damage modifier when it has used its last bounce? After the last bounce the graphic changes to a non-bouncing bomb.

Smong: After brief testing I think the bbombdamagepercent is retained even when the bouncing bomb's image becomes like a normal bomb. Also when you close bomb, or point blank shoot, you take normal damage, nothing extra.

New Format

Requesting comments on the datatype thingy I did. --Cyan~Fire

Smong: I think it does help passers by. Maybe just use Type instead of Datatype. (Also a minor nitpick, I would put a fullstop outside of a pair of brackets).

Pests: Wish I could help but that kind of info isnt parsable :)

Smong: You can do a best guess type. Some types you will just have to put 'undocumented', but the keys containing these words belong to certain types:

• pixel - pixels
• time, delay - 1/100th second
• percent - 1/10th percent
• energy, damage - energy
• speed - pixels per 10 seconds
• disable, reliable, allow - boolean
• radius - map tiles
• message - string

You will have to give priorities, like percent must be searched for before damage. Also there will be some errors, like the Continuum only setting All:Radius is in pixels not tiles. When it comes into pasting the output into the edit box you can then change any errors or types marked as undocumented. Some won't have types, like kill points multipliers.

I think it'll be easier and less error-prone just to do it manually. That way, SS oldies like me (haha) can use their knowledge. Oh, and I don't think "type" is quite as good a word as "datatype", personally. --Cyan~Fire

Smong: Now I think 'Unit' is a more appropriate word. At least use 'Setting type', you don't need to be as vague and posh as 'Datatype'.

JitterTime

Smong: Anyone have a formula for this? Seems the larger it is the bigger the amplitude of the jitter is. Also bombs that explode further away have a smaller jitter.

Lots of bombs

"If your settings allow a lot of bombs to be flying around at once, lowering the value of this setting can improve frame rates."

But didn't Snrrrub show that SS limits the amount of weapons processed? I'm assuming Continuum emulates this? --Cyan~Fire

That is true, however common sense is also needed. I've found that graphical operations can be expensive. 200 bombs all on screen at the same time may have some effect on lower end machines. Also as a side note, if there's loads of bombs flying around then it might be a super zone which will use a lot of bandwidth. Even if the bomb fire delay is the same as send position delay, analysis of a connection shows the client sends plain position and weapon packets, where weapon packets only are needed since they also contain a position. --Smong

• Just want to throw this in here. I know people are often confused when there are a massive amount of weapon graphics (ie: bullets, bombs, bursts, etc.) that the stop showing up. The reason for this is that all the slots of available graphics are currently in-use and are not drawn. CypherJF

You serious? I'd think it would rather draw ships than bombs. And I see your logic, Smong, but I really don't think it's necessary these days, especially since Snrrrub found it took longer to calculate weapon positions than to draw them. I'd say the main reason for this setting would be for the MERC Samurai close-range bomb effect, but leaving that comment there is no big deal, I just wanted to point that out. :-P --Cyan~Fire