Talk:Bomb Settings - Revision history

Cyan~Fire: /* Lots of bombs */

2005-09-22T20:25:01Z

‎Lots of bombs

CypherJF: /* Lots of bombs */

2005-09-22T12:20:57Z

‎Lots of bombs

Smong: /* Lots of bombs */

2005-09-22T10:22:10Z

‎Lots of bombs

Cyan~Fire: /* Lots of bombs */ sig, sorry

2005-09-20T03:11:01Z

‎Lots of bombs: sig, sorry

Cyan~Fire: Lots of bombs

2005-09-20T03:10:48Z

Lots of bombs

Smong: typo (bried -> brief)

2005-02-26T12:36:18Z

typo (bried -> brief)

Cyan~Fire: JitterTime

2005-02-26T05:20:38Z

JitterTime

Cyan~Fire: moved Talk:BBombDamagePercent in here

2005-02-26T04:28:53Z

moved Talk:BBombDamagePercent in here

Smong: /* New Format */ i like 'unit'

2005-01-19T11:05:18Z

‎New Format: i like 'unit'

Cyan~Fire: /* New Format */

2005-01-18T21:30:31Z

‎New Format

← Older revision		Revision as of 20:25, 22 September 2005
Line 38:		Line 38:

	* 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. [[User:CypherJF\|CypherJF]]		* 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. [[User:CypherJF\|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 --[[User:Cyan~Fire\|Cyan~Fire]]

← Older revision		Revision as of 12:20, 22 September 2005
Line 36:		Line 36:

	: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. --[[User:Smong\|Smong]]		: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. --[[User:Smong\|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. [[User:CypherJF\|CypherJF]]

← Older revision		Revision as of 10:22, 22 September 2005
Line 34:		Line 34:

	But didn't Snrrrub show that SS limits the amount of weapons processed? I'm assuming Continuum emulates this? --[[User:Cyan~Fire\|Cyan~Fire]]		But didn't Snrrrub show that SS limits the amount of weapons processed? I'm assuming Continuum emulates this? --[[User:Cyan~Fire\|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. --[[User:Smong\|Smong]]

← Older revision		Revision as of 03:11, 20 September 2005
Line 33:		Line 33:
	"If your settings allow a lot of bombs to be flying around at once, lowering the value of this setting can improve frame rates."		"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?	+	But didn't Snrrrub show that SS limits the amount of weapons processed? I'm assuming Continuum emulates this? --[[User:Cyan~Fire\|Cyan~Fire]]

← Older revision		Revision as of 03:10, 20 September 2005
Line 28:		Line 28:

	[[User:Smong\|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.		[[User:Smong\|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?

@@ Line 1: / Line 1: @@
 [[User:Smong|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.
-[[User:Smong|Smong]]: After bried 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.
+[[User:Smong|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 ==

← Older revision		Revision as of 05:20, 26 February 2005
Line 24:		Line 24:

	[[User:Smong\|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'.		[[User:Smong\|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 ==
		+
		+	[[User:Smong\|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.

← Older revision		Revision as of 04:28, 26 February 2005
Line 1:		Line 1:
		+	[[User:Smong\|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.
		+
		+	[[User:Smong\|Smong]]: After bried 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 ==		== New Format ==
	Requesting comments on the datatype thingy I did. --[[User:Cyan~Fire\|Cyan~Fire]]		Requesting comments on the datatype thingy I did. --[[User:Cyan~Fire\|Cyan~Fire]]

← Older revision		Revision as of 11:05, 19 January 2005
Line 18:		Line 18:

	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. --[[User:Cyan~Fire\|Cyan~Fire]]		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. --[[User:Cyan~Fire\|Cyan~Fire]]
		+
		+	[[User:Smong\|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'.

← Older revision		Revision as of 21:30, 18 January 2005
Line 17:		Line 17:
	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.		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. --[[User:Cyan~Fire\|Cyan~Fire]]	+	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. --[[User:Cyan~Fire\|Cyan~Fire]]