Automatic Firing of a Unit Delivery and/or Paradrop SW

Bug #895885 reported by WoRmINaToR
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Ares
Fix Released
Wishlist
AlexB

Bug Description

Third time's the charm. Thanks to Renegade's idea (see, good things really do come out of our friendly little debates!), I think we can all agree on this proposed implementation. If you are just comming into this ongoing discussion, see these two bugs: bug:1261 bug:1272

Anyhow, what would be idea here is to have a UnitDelivery or Paradrop superweapon linked to a capturable tech building (just like the tech airport), but have the firing of the superweapon automatic, and targeted at an available cell adjacent to the firing building.

A SW.AutoFire=yes feature is already implemented in the ft-superweapons branch, it would just have to be adapted to fire only on an adjacent cell of the host building

If there are any things or potential problems that need to be ironed out with this implementation idea, feel free to post, but I think the superweapon idea is a good way to go about this.

Revision history for this message
WoRmINaToR (worminator) wrote :

Note: Obviously the SW.AutoFire= would be the base of this, but a new tag would be needed. Perhaps we could leave SW.AutoFire= as is, set that to yes, and then add a AutoFire.Adjacent= to specify how many cells away the superweapon is allowed to fire, choosing the closest cell possible for optimal results.

EDIT: Idea number two: We could add another enumeration to the SW.AITargeting= that says something to the tune of "adjacent," which would make the superweapon automatically fire at the nearest adjacent cell, making a circular check for available cells somewhat like the UnitDelivery SW.

Revision history for this message
Renegade (renegade) wrote :

As a tech building, this at least has a usage case, something it was lacking before. I still don't see much support for it, though.

I do think this could be used to implement random weather phenomena, by creating buildings like the invisible light posts, only firing lightning storm clones - a far cry from full-map ion storms, but at least another usage case.

My original alternative usage case was a vehicle that deploys to trigger an SW, like a lightning storm. (Imagine a MAD-like tank driving into your base, deploying, giant cone of light shoots into the sky, clouds form, lightning storm hits.)

As said: This is still lacking support, but at least the request is half-way sensible and has a usage case now.

Revision history for this message
Marshall (m-edward) wrote :

If this were implemented, I'd suggest some generic options such as a target option of "self" to fire the SW at the building (no need for adjacent as the SW itself takes care of finding a free cell), and "autoonly", to prevent the player from firing the weapon themselves. Possibly a "SW.ShowCameo=yes/no" option as well...

Revision history for this message
WoRmINaToR (worminator) wrote :

@Renegade: Map-wide lightning storms are easy to implement, especially on small maps.

Simply specify a Range= that covers the dimensions of your map, then tweak the frequency of lightning strikes, damage, all that fun stuff, and you got a map-wide lightning storm. Want me to show you a map in which this already works? I've got a few.

As for support, we will have to wait and see.

@Marshall: We can call the targeting type enumeration anything we want; "self," "adjacent," "foobarbaz," but the end result will be the same: the SW will fire automatically at the host building.

And why would we need "AutoOnly=" if we already have "AutoFire="? Paradrop SWs are immediately fired by the AI in most scenarios so I don't imagine it being an issue.

But of course, this might be needed in practice, because there could be a, ever-so-slight delay between the SW readying and the AI firing it.

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

There is one small problem: A super weapon does not know which building it belongs to. This is the reason why i haven't already implemented SW.AITargeting=self. If you only got one such builing with a auto-drop Unit Delivery SW, you're fine. If you got two, it's not possible to alternate between them. (And there is only one SW, not two, thus even if alternating is possible, it wouldn't help that much.)

The SW.AutoFire=yes SW is fired the very frame it becomes available. If a player is quicker than that, he deserves to fire it manually :P But for SWs like the Lightning Storm it may not fire if another LS is active or there is no appropriate target.

Revision history for this message
WoRmINaToR (worminator) wrote :

Perhaps some sort of "Primary" building function, so the player can choose which building to drop at? Can the game at least know what TechType owns the superweapon, allowing for such "primary" designation?

Although I must say, for my personal usage case, I was never intending on having more than one of the same type of self-auto-firing-reinforcement SW on the map at once.

Revision history for this message
Renegade (renegade) wrote :

Worm: I really don't care about map-wide hacks right now. I only brought it up because we have multiple other requests for custom and random storms, so arguing that that usage case isn't relevant is perfectly alright.

Revision history for this message
WoRmINaToR (worminator) wrote :

Note to my above post: A "primary SW building" function would require a BuildingType flag... Superweapon.DesignatePrimary=?

The only potential issue I can see at the moment is if someone wants to put a superweapon like this on a production structure, but it might be possible to work around by either modifying the "primary" designation logic or using some other system.

Perhaps we could add a special Ares key command that triggers some kind of look-alike of the "primary" designation, without actually affecting the current implementation?

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

That would be a quite complex addition for something of dubious value.

Revision history for this message
Renegade (renegade) wrote :

Why not just skip the implementation details for a moment and go to the really interesting question: Should we implement this?

I don't see any community support other than yourself, and yours is the only "real world" usage case, too. Mine are all hypothetical.

So far, it looks like you're the only one who wants this, for one particular use in your own mod.

Revision history for this message
WoRmINaToR (worminator) wrote :

So far, you, I, and Alex have been the only people who have even bothered to post on any of the issues in this tracker in the last week or so.

I have no idea why this unprecedented lack of activity is occurring, but I say we should give this time before we make any hasty decisions to close it due to lack of posters; the lack of support is more because of the lack of activity here.

As for complexity, I really have no idea what the best course of action should be here. If we decide to at least keep this idea alive for awhile, there is an open table for implementation ideas. My personal musings do not, by any means, have to be the set implementation plans, they are just putting ideas on the table.

EDIT: For that matter, I honestly don't care if there is any ability to choose between a "primary" superweapon building. If you can just say "fire this at the first building I captured that hosts this superweapon" that's fine for me. No need for any hacky choosing-the-building logic especially because I will personally never have more than one building of this type on a map at once.

But of course, it's a bit too early for that. If this gains any support THEN we can talk serious about implementation.

I say give it 2 months; if nobody bothers to voice their opinion about it in 2 months then this can be suspended. If nobody cares then whatever, I can (resentfully) settle for regular paradrops.

Revision history for this message
Renegade (renegade) wrote :

"Hasty". After going through two previous issues.
Either way...I say no, let's not give it two months.

That's not what the whole concept of quicker vetting was about. There is absolutely no reason to wait two months. If the issue can't even interest people while it's at the top of the first page and freshly being discussed, why would we wait and see if it's more interesting to people once no one has talked in it for a month and it's on page 2 at the bottom?

Feel free to go around and link your issue on the forums, PPM, Twitter, wherever to get more people interested in the discussion, but we'll most certainly not let this rot for two months if it's quite clear after a week that no one gives a shit.

We'll certainly give it another day or two if nothing happens, or even a week if someone else actually starts talking, but two months are totally out of the question.

If you take issue with the fact that we don't intentionally keep data corpses around, feel free to complain in http://forums.renegadeprojects.com/showthread.php?tid=1629 . But if it's obvious the fate of this request is clear, we'll update it accordingly, no matter how old it is.

Revision history for this message
Blade (nadia-xy) wrote :

I'm inclined to support this basically because I like the idea of having different ways for a squad of units to be provided to the player. I can imagine this was similar to how WW intended the mutant commandos reinforcements to work in TS and it is how the fremen reinforcements were implemented in Dune2k.

Revision history for this message
RandomNutjob (randomnutjob) wrote :

I back this, obviously anyone sensible will implement this at intervals which doesn't make it too bias/pointless

It would add a variant "paradrop"/reinforcement option so why not

Revision history for this message
WoRmINaToR (worminator) wrote :

{quote}obviously anyone sensible will implement this at intervals which doesn't make it too bias/pointless{/quote}

Finally, someone who understands my point of view!

Ooh, thought of another usage case...

When the "any techtype to any techtype deployment" issue is implemented, I can use this for an officer who has authority to call in reinforcements. I can have him deploy into a building with such a paradrop SW, and then the reinforcements will come to him after a 1 minute delay, during which he cannot move or attack.

Nifty thought eh? :D

Revision history for this message
Renegade (renegade) wrote :

Alright, since this seems to have gathered a bit of support, I'll suspend it for future scheduling, in accordance with http://forums.renegadeprojects.com/showthread.php?tid=1637 .

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

Code related to this issue has just been checked in!
Author: AlexB
Location: ft-superweapons, r847
Commit contains DLL: Yes
Revision comment:
Fixed issue 300: Super weapons are prevented from firing if the player can't afford them. New tags added to support UseChargeDrain super weapons. Features requested in the comments: If SW needs money, the tool tip shows the amount like units do. Insufficient Funds event is played (customizable).
Fixed issue 312: Individual charge to drain ratio for super weapons.
Fixed issue 424: SuperClass::Launch has bee rewritten. No testing needed. If the SWs work, so does SuperClass::Launch. Needs some more docs for the other devs.
Related to issue 1256: Added logging for the problem described in the comments. The original problem is fixed, though.
Fixed issue 1268: Lightning storms can be fired everywhere. New tag added to define who is affected by the radar outage.
Fixed issue 1273: Added two new AITargeting modes: self targets the first building you own that can fire this SW, base fires into your own base. Requests from Marshall in the comments section have been implemented, too. See below.

Generally: Some more SW-related tags have been added, like EVA events in case you don't have enough funds to fire an SW and the Impatient event in case you click a SW that's not ready. You can show a text message in case of insufficient funds. You can disallow the manual launch of SWs now, so for example the player can never click the Lightning Storm icon and get a targeting cursor in case there is an LS active already. Auto-fire super weapons can be set to show no cameo icon in the sidebar.

Charge/Drain SWs now support Money and they can be made unstoppable once fired. An UseChargeDrain SW draining Money will stop and reset once the player doesn't have enough money any more.

Note: Text.On has been renamed to Text.Active.

Documentation updated.
SVN: http://svn.renegadeprojects.com/Ares/847

Revision history for this message
WoRmINaToR (worminator) wrote :

Looks like no need to wait for scheduling, here it is!!!

Will be testing as soon as possible, looking forward to nice results!

Revision history for this message
WoRmINaToR (worminator) wrote :

Unfortunately, after a brief test run, I can conclude that SW.AITargetingType=Self will cause the superweapon to never fire automatically. Other, already implemented targeting types still work. base has not yet been tested.

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

SW.AITargetingType or SW.AITargeting? Only the latter one exists.

Revision history for this message
WoRmINaToR (worminator) wrote :

That's what I meant, sorry.

But still, SW.AITargeting=Self does not work; all the other ones fire correctly, but this one does not fire at all.

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

Can't reproduce this. My nuke just hit its silo, as it should with this tag. Can you post the SW section?

Revision history for this message
WoRmINaToR (worminator) wrote :

Yeah, sure.

I would like to point out however that this is being used with a ParaDrop superweapon, not a LS or a nuke or whatever, so that might make a difference.

EDIT: It may also be relevant that this superweapon is being provided by a capturable tech airport, which is NOT built by the player and never can be.

I have not tested this on buildable superweapon buildings.

Anyhow, here's all the relevant code:

[TankDropSpecial]
UIName=Name:Para
Name=Paratrooper Drop
IsPowered=false
RechargeVoice=
ChargingVoice=
ImpatientVoice=
SuspendVoice=
RechargeTime=2
Type=ParaDrop
Action=Custom
SidebarImage=PARAICON
ShowTimer=no
DisableableFromShell=no
Text.Hold=SWT:OnHold
Text.Ready=SWT:Launch
Text.Preparing=SWT:Preparing
SW.AutoFire=yes
SW.AITargeting=Self -----> I tested SW.AITargeting=ParaDrop and it worked normally without any other changes, so this seems to be the issue
ParaDrop.Types=ISGTNK
ParaDrop.Num=1
ParaDrop.Aircraft=PDPLANE
Cursor.Frame=339
Cursor.Count=5
Cursor.Interval=15
Cursor.MiniFrame=339
Cursor.MiniCount=-1
Cursor.HotSpot=Center,Middle
NoCursor.Frame=309
NoCursor.Count=5
NoCursor.Interval=15
NoCursor.MiniFrame=309
NoCursor.MiniCount=-1
NoCursor.HotSpot=Center,Middle

Everything else worked completely fine; Since it didn't automatically fire I got a chance to fire it myself and the functions for the paradrop weapon work just fine, and my inputs work properly as well. When I changed SW.AITargetingType to the previously-implemented ParaDrop, it automatically fired just as it should at the weakest point in the enemy base.

EDIT 2: I test ran this with it buildable as well as capturable; in neither scenarios did it work.

However, all this code DOES work properly with the Nuke launcher, as you said; it seems just the ParaDrop SW is getting this bug. I will test later on some other SW types and see if they work or don't, but ParaDrop definitely does not.

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

With this very code (ok, I changed ISGTNK to SREF) I got a fully working paradrop, auto firing at my construction yard. To which building type did you attach it? I'll update the SW branch soon, adding some logging for this and another issue.

Revision history for this message
WoRmINaToR (worminator) wrote :

I added this to a tech building, [CAAIRP]. The code for CAAIRP has not been changed in my mod IIRC from the original one in the game. I just changed its superweapon from ParaDropSpecial to TankDropSpecial.

EDITAGE: Okay, I found the problem. Insignificant=yes buildings are not considered in this scan.

Whether or not you consider that a problem with this issue, or a problem of the other recent "limiting Insignificant" issue, is up to you. I would personally recommend this be fixed within this issue, but someone might want to use Insignificant=yes for a clone building where they don't want the SW to fire at that building.

In any case, this DOES work as intended despite that small quirk. You can close this as fixed or fix the quirk, I honestly don't care. As it is right now, I can use it just fine and it fulfills all my needs.

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

Code related to this issue has just been checked in!
Author: AlexB
Location: ft-superweapons, r848
Commit contains DLL: Yes
Revision comment:
Related to issue #1256: Logging added to all Nuke-relevant functions to show what's going wrong.
Related to issue #1273: Logging added for SW.AITargeting=self.
SVN: http://svn.renegadeprojects.com/Ares/848

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

Great. That's timing. I just looked up how Insignificant works in this case. It affects the list of building the game uses to find an appropriate silo; Insignificant=yes buildings are not put into that list, thus it will not find any building to consider as "self".

Ok, I'll consult the other coders about their plans on Insignificant. For me this looks like intended behavior, as insignificant buildings wouldn't provide SWs in the first place or they'd stop being insignificant.

Revision history for this message
WoRmINaToR (worminator) wrote :

I wouldn't consider a paradrop to be a superweapon.

And tech buildings need to be insignificant, otherwise they keep players alive when they have lost everything else.

Revision history for this message
Blade (nadia-xy) wrote :

I disagree, a techbuilding with a superweapon still poses a threat that could in theory allow them to still win against a very lax opponent. A powerplant could keep a player alive with much less offensive potential and you certainly wouldn't mark them insignificant!

Revision history for this message
Renegade (renegade) wrote :

...especially if said tech building regularly spawns units.

Revision history for this message
WoRmINaToR (worminator) wrote :

fair enough.

Revision history for this message
mevitar (mevitar) wrote :

I didn't take a look into the coding, so I don't know for sure, but if the list AlexB mentioned is the same list the game checks to see if the player has any buildings left, then making buildings with Insignificant=yes added to that list would make having the tag almost pointless. After all, the purpose of it is that the building will NOT be in that list, so it won't count as a player-owned object.

Revision history for this message
WoRmINaToR (worminator) wrote :

thus the decision to not mess with it.

Revision history for this message
MasterHaosis (masterhaosis) wrote :

WoRmINaToR, good job man! I know you are probably angry at me because I did not support you here. Well, after my request got closed, I simply left because I had a mod to work, and my exams, college so I did not have time to stay here and watch my immediately closed requests. I did not know that Renegade and Dcoder will reopen my request, and you had lot of discussion there. I missed my request, I missed your second based on my one, and now I missed third one based again on previous ones. I came back last night to see what is going on here... And shame for me, what more to say, its shame and I feel ashamed. I simply did not know that they will reopen it. Somebody should at least find me at Revora in my mod's thread where I am the most active. But not matter its my fault.
However, small note to Rebegade: Man, you did a good job, and I am thankful for you because you and Worminator spent lot of time in my request, when sadly and ironically I wasnot present. But in all time you missed just one point. You were constantly using (misunderstood), and repeating same thing about my Desolator example. You were repeat how its pointless building to spawn desolator on each 1000 frames and such... But my point was a building which spawns ANY infantry at ANY period to fime, which modder should set himself. For example, in my own case I would make building to spawn a Alien infantry which is basic soldier and costs 300$ at five minutes. So if game lasts 30 minutes you would get 30 minutes: 5 minutes= 6 aliens per minute. Even in case that you can immediately build that building at start of game. Its not unbalanced. Plus you told how 8 players and 8 spawn buildings make game to lag. in this case 8 Alien players x 6 aliens = 48 spawned Aliens for 30 minutes. In case that players do not fight each other and do not lose those spawned units, so I do not see how this can cause game to lag.

Now to back on this one request.
WoRminator wanted system which is in Generals/Zero Hour known as Tech Reinforcements Pad. I know how it works cause I am modder of Generals as well.
It is connected with houses via object creation list, and superweapon, so it will automatically in each two minutes call plane, plane will come, drop tank via parachute at that bulding, and tank will immediatelly move to free ground.
basically each faction and country of USA, CHina and GLA has their own OCL definied (Object Creation List section), so if you are GLA you will get Scorpion Tank, CHina gets Battle master and USa gets Crusader. In ZH sides gets various units too...
But if its not unbalanced in generals, thus it exist still, so I do not see how this can be unbalanced here.
WoRmINaToR's request is basically same as mine, except he wanted tech building to spawn a tank/infantry via paradrop from plane at free cell, I wanted to create building which will just spawn infantry/vehicle at free cells without plane and parachute. Just to exit from building or appear near it thats all. Similiar request, same base idea.

Revision history for this message
WoRmINaToR (worminator) wrote :

MasterHaosis, you don't have to vouch for this issue anymore. And I'm not mad it all. It was my issue (adapted from yours) and I got what I needed.

In case you didn't notice, this feature actually has been implemented already, and is fully functional. If you want to use it, go ahead, it's ready for you. Just make a custom Paradrop or UnitDelivery or whatever kind of SW you want, add a cost if you please, add SW.AutoFire=yes and SW.AITargeting=Self, and you're good to go. I tested it and it works out great.

If you were busy and missed it all, oh well, big deal. It's over with, it got implemented and it works, no more discussion is needed.

Take it easy man, don't beat yourself up about it. It's all good.

Revision history for this message
MasterHaosis (masterhaosis) wrote :

WORMINATOR!!!!! Hey man nice to see you!
Well I am thankful that if works. Well I will not be at home few days, so I will not have time to test it, however I will visit this site. Well where can I download it to see how it works?
haha, infantry producer first charm. Automatic unit spawn system was second, and this one is third, best solution.

Revision history for this message
Renegade (renegade) wrote :

MasterHaosis: It will be in Ares 0.2.

Revision history for this message
MasterHaosis (masterhaosis) wrote :

OK, so it will not be downloadable here Edited: FFS people. ?
Anyway, Renegade where can I assign as tester?

Revision history for this message
Renegade (renegade) wrote :

It will be in Ares 0.2.
And I'm not sure you'd qualify as a tester.

Revision history for this message
MasterHaosis (masterhaosis) wrote :

What do I need?
And what does mean ,,FFS people?" I did not wrote that.
However, I am using that fs_superweapons currently. Thanks to it I have that plasma storms and enhanced superweapons. I like that.

Revision history for this message
WoRmINaToR (worminator) wrote :

Just DO NOT tell anyone else in the public about that testing version. It was my careless mistake to give you that in the first place, we(I) don't want that testing version being leaked because people in the community might find bugs and bash the Ares testers about it.

Keep your testing version of Ares a secret for now, alright? You can say "thanks to the in-development Ares patch, I can make new and interesting superweapons!!" but please don't release any version of your mod with this testing version of Ares. In fact, don't even acknowledge the existence of this testing version.

Revision history for this message
MasterHaosis (masterhaosis) wrote :

WoRmINaToR , you gave somebody else man, I did not get that link from you. Another person gave me in PM in Revora. I am talking with many people there. As far I know you are not there, or not active, I am sure that I havent seen you there, so you did not send me link. You gave link to wrong guy if you meant me. Also I did not know it is for testers, nobody told me about that however.
Also, since I saw it, I am only using this version, I havent tried others because they are all separated, I cannot just switching to all of them. I chose one, and I am using it's codes now. And it works fine. Except one thing.
This ION cannon tutorial featuring Ares http://www.ppmsite.com/forum/viewtopic.php?t=28181
is not working with this version. I did everything what he says, and copied all codes, setting all and checking several times, and simply IOn cannon is not working. When I click to fire at enemy, cameo is going to charge like superweapon is fired, but nothing happens.
http://i25.servimg.com/u/f25/11/75/26/39/bug10.jpg
Do not worry about that cursor link, its just another testing Action. It is happening with original one Action=AttackSupport
As you can see from that screenshot, I still have that MultiplierLines in superweapon, like when it is ready, but actually it recharges in tab. So I cannot fire it. It also do not waste money, like other superweapons with Money.Amount= set.
And be sure that I am not going to spread any link of it, and I am not even near finishing my mod. haha when I finish it, then Ares 0.4 will be released hahahaha!

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

If you are using the beta build, you might have missed the Generic Warhead SW does use SW.Warhead and SW.Damage by now. Then, it should work fine, too.

Revision history for this message
MasterHaosis (masterhaosis) wrote :

ALEXB!!!!!!! Working now... Yeah, I missed new tags in this version.
Now works fine, however I have to work on damage cause it destroyed even construction yard in one shoot
http://i25.servimg.com/u/f25/11/75/26/39/bug210.jpg
But you guys have separation versions, it would be awesome if you would upload one with merged features and update it, so checking out new features would be much easier. ....I can always find something useful. hehe

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

There will be a dll with all features from the branches merged. It will be called Ares 0.2. Having branches is the best way to develop several features at the same time and it doesn't keep testers from verifying everything is working as intended. Merging the branches would defeat that purpose and take a considerable amount of time with no benefit.

Revision history for this message
MasterHaosis (masterhaosis) wrote :

Yes, true that, but if I wanted to see and test all of new features, I have separately to download each version. You have few of them, and I have to see them each time. I am using superweapons build more than two weeks. If I want to see Chrono Prison system, I have to download that version, but my enhanced superweapons wont work. And if I want for example to test veterancy, then I would lose Chrono Prison. All in one (updated versions) would kick asses. But yeah, it is not good idea for you coders. Will Ares 0.2 come soon?

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

When it's ready.

Revision history for this message
MasterHaosis (masterhaosis) wrote :

Oh I forgot. On stupid questions you always get stupid answers.

Revision history for this message
WoRmINaToR (worminator) wrote :

That was not a stupid answer. We honestly can't tell you exactly when it's ready. Setting due dates for releases puts unnecessary pressure on the coders. When we feel it's ready for release, we will tell the public. Until then, sit tight and wait for our word.

Revision history for this message
Professor_Tesla (professor-tesla) wrote :

Based on recent tests, I can say that all of the tags for this feature work (SW.AutoFire, SW.AITargeting, SW.ShowCameo).

Revision history for this message
WoRmINaToR (worminator) wrote :

Good, then this issue can be closed because two testers confirm this works and no further discussion is really necessary.

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

It was a stupid question though ...

Closed.

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

Other bug subscribers

Remote bug watches

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