TS Firestorm Defence

Bug #895148 reported by Bug Importer
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Ares
New
Wishlist
Unassigned

Bug Description

Bring back the good old Firestorm Defence logic

Revision history for this message
DCoder DCoder (dcoder1337) wrote :

http://forums.renegadeprojects.com/showthread.php?tid=1236

So far it doesn't play well with the solid buildings concept, basically because they are both still WIP.

Revision history for this message
Bug Importer (bug-importer) wrote :

will there be any exception?
Like if you have Lobber=yes, will it damage object behind it?
or SubjectToCills/Walls?

Revision history for this message
DCoder DCoder (dcoder1337) wrote :

[Projectile]IgnoresFirestorm=y/n;default n, just like in TS

fun fact - I'm going to have code to stop invisible/DirectDraw projectiles as well.

Revision history for this message
DCoder DCoder (dcoder1337) wrote :

This version will have a primitive but testable implementation, the proper one requires bug:424 .

Revision history for this message
Bug Importer (bug-importer) wrote :

Tested firestorm in ver 287. Triggers properly and works properly with stopping aircraft (with animation "fsair" playing etc.). It doesn't seem to stop any projectiles right now, either invisible or shp/voxel (don't know if that was resolved yet). The ones with IsLaser=yes fire through the defence but don't do damage. The AI on the other hand does not intend to attack objects behind the firestorm. On another note when you turn it on and then off the "wall" still remains and units can't pass through. Even destroying the installation doesn't help as the place remains unpassable. Sometimes I can get a unit to drive on it but it gets stuck on the firestorm section. And I do remember that in TS the firestorm wall when turned on had one fsidle animation (that one works) and another one playing in the section corners called fsdf_a (that one is not present) - is there a way to implement it? I tried SpecialAnim=fsdf_a on the [fsdf] and similar but it didn't trigger. Last question: is it possible to make the "Firestorm.Wall=yes" object behave like a Bib in visual terms? Because currently units can pass over it (before turning it on for the first time that is) but graphically they get obscured by it at some point (especially it's visible with infantry). Sorry if that's a pretty long text but I hope it helps in development.

Revision history for this message
Bug Importer (bug-importer) wrote :

Code related to this issue has just been checked in; DCoder wrote in revision 497:
Fixed issue #492 - Firestorm now works as a Type=Firestorm Super Weapon.
Fixed issue #666 - trench autoconnection wall style was broken since r317. Nobody noticed, thanks.
Also some manual updates.
Related to issue 492,666 .
SVN: http://svn.renegadeprojects.com/listing.php?repname=Ares&path=%2Ftrunk%2F&rev=497&sc=1

Revision history for this message
FS-21 (jagarni1983) wrote :

I tried Firestorm using revision 1.500 and this is what I observed:
- When you block all your entrances for your base by FS wall sections will be impossible to move from one side of the wall to another side. Is the same bug of to do a rentangle with FS walls and put a unit inside, the unit will not be able to exit.
- Units like Siege choppers, Kirovs, rocketeers, etc ignores the firestorm wall when is activated and they are instant-killed when they move across the wall section.
- You can see the health bar when you move the cursor over a wall section, this not happen in original TS Firestorm Wall section (I'm using the same code of that game to test it in Ares like I did with the Laser fence tests time ago).
- In Tiberian Sun FSIDLE.shp animation appears only in wall corners but in Ares it appears in any section of the FS wall.
- Graphically the last "tick" of the sidebar icon when the SW is 100% ready to be used ins't removed.
- Enemies should attack the target behind the activated firestorm wall if they are in range.
- If enemy units aren't in range for attack the target AI should interpret the wall as an obstacle and try another route instead of to wait until the firestorm wall is offline as now happens.
- No burned infantry death animation when InfDeath=4 in the FirestormWH (Ares reads "FirestormWarhead=FirestormWH" or is hardcoded with another thing? )

I don't see more strange things in the Fire storm SW in the current Ares revision.

EDIT:
I found a good exploit:
- Build the Fire Storm Generator building.
- Build all the required FS wall for your base.
- Build a Chrono Legionnaire
- Activate the Firestorm SW and after attack with the Chrono Legionnaire the Fire Storm Generator building until it is erased.
Now Firestorm wall activation not ends.

Revision history for this message
Bug Importer (bug-importer) wrote :

Code related to this issue has just been checked in; DCoder wrote in revision 506:
Related to issue #492 - pathfinding fixed, health bar hidden, changed FSIDLE to appear only in junctions/ends, made SW shutdown if temporally affected (this needs work). No build yet.
Related to issue 492 .
SVN: http://svn.renegadeprojects.com/listing.php?repname=Ares&path=%2Ftrunk%2F&rev=506&sc=1

Revision history for this message
Bug Importer (bug-importer) wrote :

Code related to this issue has just been checked in; DCoder wrote in revision 507:
Related to issue #492 - pathfinding fixed, health bar hidden, changed FSIDLE to appear only in junctions/ends, made SW shutdown if temporally affected (this needs work).
Related to issue 492 .
SVN: http://svn.renegadeprojects.com/listing.php?repname=Ares&path=%2Ftrunk%2F&rev=507&sc=1

Revision history for this message
FS-21 (jagarni1983) wrote :

Using the revision 1.514 I can verify that:
- Is fixed all reports about "Pathfinding".
- Is fixed "Health bar hidden".
- Is fixed "changed FSIDLE to appear only in junctions/ends".

Other bugs I found using the revision 1.500 and 1.514:
- Not works the GAFSDF_A animation when the Firestorm SW is activated (in Tiberian Sun it was declared in [General] section using the tag FirestormActiveAnim=GAFSDF_A).

- I found another bug/exploit, here are the steps:
1º) Activate the Firestorm SW.
2º) Activate the Force Shield SW.
Now the FS actions when you click in the sidebar button are inverted, I mean, if you shutdown the Firestorm SW it will be enabled and vice-versa when the SW is enabled.
If you use again the Force Shield when you can see the Firestorm SW "active" animation the FS actions will be inverted again fixing it.

- I'm uploading a litle image of the sidebar about the bug report of "Graphically the last "tick" of the sidebar icon when the SW is 100% ready to be used ins't removed.". The "tick" that I said is that green part between the "e" and the "a" of the screenshot (I don't know how this is called in english sorry).

Revision history for this message
FS-21 (jagarni1983) wrote :

I found another bug and the bug is similar to the last that I reported about the Force Shield SW but only is necessary to destroy the firestorm generator building while the FS is active.

Revision history for this message
Bug Importer (bug-importer) wrote :

Code related to this issue has just been checked in; DCoder wrote in revision 521:
Related to issue #492 - Firestorm shuts down if generator is lost/frozen. Note that Temporal freezing/releasing the generator will restart the charge cycle, not sure if that's okay.
Fixed issue #904 - Ivan Bombs can no longer be attached to non-Technoes (previously you could attach them to CellClass which is not a descendant of ObjectClass and thus garbage its data).
Related to issue 492,904 .
SVN: http://svn.renegadeprojects.com/listing.php?repname=Ares&path=%2Ftrunk%2F&rev=521&sc=1

Revision history for this message
SovietWarrior (sovietwarrior) wrote :

is it not works the GAFSDF_A or just hides it by itself art? I have notised that FSIDLE is been drawn under the sections

Revision history for this message
DCoder DCoder (dcoder1337) wrote :

The active anim is not hooked up yet. I don't remember how it worked in TS 100% so I keep implementing it bit by bit, when someone points out what's missing.

Revision history for this message
Bug Importer (bug-importer) wrote :

Code related to this issue has just been checked in!
Author: DCoder
Location: issue-492-firestorm, r722
Revision comment:
Related to issue #492 - changed Firestorm to use [CombatDamage]FirestormWarhead= .
Related to issue 492 .
SVN: http://svn.renegadeprojects.com/Ares/722

Revision history for this message
YR M0ddEr (yr-m0dder) wrote :

Tested in firestorm branch, r726

Firestorm wall dont block any projectile, direct drawing or not.

I am using AGs mod Red Ares, I modified his firestorm wall section, I took out FirestormWall=yes(he had that tag and Firestorm.Wall=yes). It wont work.

I surrounded my c-yard with fire storm wall section, activated the superweapon, fire at the c-yard, and it took the damage, no projectiel was stopped.

Revision history for this message
DCoder DCoder (dcoder1337) wrote :
Revision history for this message
Chanterier (speederyr) wrote :

Me and Alien had played an online game once, where we had two firestorm defenses. Funny thing was that sometimes, when he activated his firestorm mine was actually triggered and vice versa. Only one firestorm could work at the time.

Revision history for this message
Krozalid (krozalid) wrote :

Tested this with the firestorm branch and everything works fine and all animations play correctly. But there is one bug with the gafsdf_a animation. It doesn't appear when you place a newly built section after you activated the sw but if you turn off the sw and activate it again, everything is just fine.
Edit: Forgot to mention something. There was something about the map loading. It took a whole lot longer to load even a small map than the newest trunk revision.

Revision history for this message
cranium (cranium) wrote :

Is it normal for Firewall sections to only be placed one piece at a time?, For instance, when you place a wall corner and then place another "say 4 cells away" it joins the walls together to make one wall section. I dont seem to be able to do this with the firestorm.wall= sections.

Revision history for this message
YR M0ddEr (yr-m0dder) wrote :

^^Add GuardRange= to the building. Oh and it must be 1x1.

Revision history for this message
cranium (cranium) wrote :

heh, I already added it, but, somehow I spelled it Guardrange=. Forgot to capitalize the "R". Thanks YR MOddEr.

Revision history for this message
AlexB (alexander-b) wrote :

Btw: The last slice not being removed reported by FS-21 here should be fixed in the SW-branch already.

Revision history for this message
FS-21 (jagarni1983) wrote :

Yes, as you said "The last slice" was fixed. I confirm it.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Related blueprints

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.