2025-07-20 10:07 CEST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0004448Spring engineGeneralpublic2014-06-21 16:45
ReporterGoogle_Frog 
Assigned Tocleanrock 
PrioritynormalSeveritymajorReproducibilityalways
StatusresolvedResolutionfixed 
Product Version97.0.1+git 
Target Version98.0Fixed in Version 
Summary0004448: Constructors no longer fire while building
DescriptionThis is a game design decision. This change breaks my game.

"Better yet they should fire while doing everything and the game designer can decide if firing should be blocked within the unit script. That is assuming there are easy callins for actions such as reclaiming." ~ GoogleFrog http://springrts.com/mantis/view.php?id=2420

Make nothing block firing and then let the game creators return false in AimWeapon. It is much much easier for a game creator to stop a unit from firing than it is to hack in some firing behaviour. Stopping firing is a simple script change, adding firing involves rewriting all the engine behaviour or adding fake units.
TagsNo tags attached.
Checked infolog.txt for Errors
Attached Files

-Relationships
related to 0002420resolvedcleanrock Fix constructor fire-while-working consistency 
+Relationships

-Notes

~0013302

cleanrock (reporter)

Last edited: 2014-06-19 14:41

View 2 revisions

@spring_devs,
Can we remove calls to TempHoldFire completely and let games handle blocking fire if they want ?
Imo, the current behaviour after my commit is better(more consistent) than it was before but if we can let games decide this its even better.

~0013305

Kloot (developer)

"assuming there are easy callins for actions such as reclaiming"

No.

The best solution would therefore be to add an AllowBuilderHoldFire(action) Lua callin and make TempHoldFire defer to that.

In the meantime, consistency > inconvience.

~0013306

FLOZi (reporter)

StartBuilding and check current active order.

Being consistently convenient is better than consistently inconvenient.

~0013307

Kloot (developer)

"StartBuilding and check current active order."

1) doesn't prevent the engine from letting builders try to attack anyway --> inelegant
2) forces "block all weapons" boilerplate crap to be added in every constructor script
3) changes existing expected behavior by removing the TempHoldFire's

~0013308

KingRaptor (reporter)

Would a modrules tag for "allow shooting while building" be sufficient?

~0013309

abma (administrator)

Last edited: 2014-06-21 06:50

View 5 revisions

can this be controlled inside the callin AllowWeaponTarget? if so, tempholdfire could be removed?!

~0013310

silentwings (reporter)

Last edited: 2014-06-21 10:54

View 2 revisions

I am with KR here - if this has to be implemented the cleanest way is with a unitdef tag. I can't see much scope for wanting to change "does constructor fire while building/etc" on the fly.

~0013311

cleanrock (reporter)

https://github.com/spring/spring/commit/5a82d75
I don't want to set this ticket fixed until possible corrections are done.

~0013313

cleanrock (reporter)

Should be fixed now.
Kloot added performance optimizations in https://github.com/spring/spring/commit/283af7b
+Notes

-Issue History
Date Modified Username Field Change
2014-06-19 14:33 Google_Frog New Issue
2014-06-19 14:41 cleanrock Note Added: 0013302
2014-06-19 14:41 cleanrock Note Edited: 0013302 View Revisions
2014-06-19 20:46 abma Relationship added related to 0002420
2014-06-19 23:10 Kloot Note Added: 0013305
2014-06-20 00:41 FLOZi Note Added: 0013306
2014-06-20 02:06 Kloot Note Added: 0013307
2014-06-21 04:58 KingRaptor Note Added: 0013308
2014-06-21 06:42 abma Target Version => 98.0
2014-06-21 06:47 abma Note Added: 0013309
2014-06-21 06:47 abma Note Edited: 0013309 View Revisions
2014-06-21 06:47 abma Note Edited: 0013309 View Revisions
2014-06-21 06:49 abma Note Edited: 0013309 View Revisions
2014-06-21 06:50 abma Note Edited: 0013309 View Revisions
2014-06-21 10:52 silentwings Note Added: 0013310
2014-06-21 10:54 silentwings Note Edited: 0013310 View Revisions
2014-06-21 11:27 cleanrock Note Added: 0013311
2014-06-21 16:43 cleanrock Note Added: 0013313
2014-06-21 16:43 cleanrock Status new => closed
2014-06-21 16:43 cleanrock Assigned To => cleanrock
2014-06-21 16:43 cleanrock Resolution open => fixed
2014-06-21 16:44 cleanrock Status closed => feedback
2014-06-21 16:44 cleanrock Resolution fixed => reopened
2014-06-21 16:45 cleanrock Status feedback => resolved
2014-06-21 16:45 cleanrock Resolution reopened => fixed
+Issue History