Automatic Firing of a Unit Delivery and/or Paradrop SW
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.
WoRmINaToR (worminator) wrote : | #1 |
Renegade (renegade) wrote : | #2 |
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.
Marshall (m-edward) wrote : | #3 |
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=
WoRmINaToR (worminator) wrote : | #4 |
@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.
AlexB (alexander-b) wrote : | #5 |
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=
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.
WoRmINaToR (worminator) wrote : | #6 |
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-
Renegade (renegade) wrote : | #7 |
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.
WoRmINaToR (worminator) wrote : | #8 |
Note to my above post: A "primary SW building" function would require a BuildingType flag... Superweapon.
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?
AlexB (alexander-b) wrote : | #9 |
That would be a quite complex addition for something of dubious value.
Renegade (renegade) wrote : | #10 |
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.
WoRmINaToR (worminator) wrote : | #11 |
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-
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.
Renegade (renegade) wrote : | #12 |
"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://
Blade (nadia-xy) wrote : | #13 |
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.
RandomNutjob (randomnutjob) wrote : | #14 |
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"
WoRmINaToR (worminator) wrote : | #15 |
{quote}obviously anyone sensible will implement this at intervals which doesn't make it too bias/pointless{
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
Renegade (renegade) wrote : | #16 |
Alright, since this seems to have gathered a bit of support, I'll suspend it for future scheduling, in accordance with http://
Bug Importer (bug-importer) wrote : | #17 |
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://
WoRmINaToR (worminator) wrote : | #18 |
Looks like no need to wait for scheduling, here it is!!!
Will be testing as soon as possible, looking forward to nice results!
WoRmINaToR (worminator) wrote : | #19 |
Unfortunately, after a brief test run, I can conclude that SW.AITargetingT
AlexB (alexander-b) wrote : | #20 |
SW.AITargetingType or SW.AITargeting? Only the latter one exists.
WoRmINaToR (worminator) wrote : | #21 |
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.
AlexB (alexander-b) wrote : | #22 |
Can't reproduce this. My nuke just hit its silo, as it should with this tag. Can you post the SW section?
WoRmINaToR (worminator) wrote : | #23 |
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=
ShowTimer=no
DisableableFrom
Text.Hold=
Text.Ready=
Text.Preparing=
SW.AutoFire=yes
SW.AITargeting=Self -----> I tested SW.AITargeting=
ParaDrop.
ParaDrop.Num=1
ParaDrop.
Cursor.Frame=339
Cursor.Count=5
Cursor.Interval=15
Cursor.
Cursor.MiniCount=-1
Cursor.
NoCursor.Frame=309
NoCursor.Count=5
NoCursor.
NoCursor.
NoCursor.
NoCursor.
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-
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.
AlexB (alexander-b) wrote : | #24 |
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.
WoRmINaToR (worminator) wrote : | #25 |
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.
Bug Importer (bug-importer) wrote : | #26 |
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=
SVN: http://
AlexB (alexander-b) wrote : | #27 |
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.
WoRmINaToR (worminator) wrote : | #28 |
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.
Blade (nadia-xy) wrote : | #29 |
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!
Renegade (renegade) wrote : | #30 |
...especially if said tech building regularly spawns units.
WoRmINaToR (worminator) wrote : | #31 |
fair enough.
mevitar (mevitar) wrote : | #32 |
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.
WoRmINaToR (worminator) wrote : | #33 |
thus the decision to not mess with it.
MasterHaosis (masterhaosis) wrote : | #34 |
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.
WoRmINaToR (worminator) wrote : | #35 |
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=
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.
MasterHaosis (masterhaosis) wrote : | #36 |
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.
Renegade (renegade) wrote : | #37 |
MasterHaosis: It will be in Ares 0.2.
MasterHaosis (masterhaosis) wrote : | #38 |
OK, so it will not be downloadable here Edited: FFS people. ?
Anyway, Renegade where can I assign as tester?
Renegade (renegade) wrote : | #39 |
It will be in Ares 0.2.
And I'm not sure you'd qualify as a tester.
MasterHaosis (masterhaosis) wrote : | #40 |
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.
WoRmINaToR (worminator) wrote : | #41 |
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.
MasterHaosis (masterhaosis) wrote : | #42 |
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://
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://
Do not worry about that cursor link, its just another testing Action. It is happening with original one Action=
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!
AlexB (alexander-b) wrote : | #43 |
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.
MasterHaosis (masterhaosis) wrote : | #44 |
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://
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
AlexB (alexander-b) wrote : | #45 |
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.
MasterHaosis (masterhaosis) wrote : | #46 |
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?
DCoder DCoder (dcoder1337) wrote : | #47 |
When it's ready.
MasterHaosis (masterhaosis) wrote : | #48 |
Oh I forgot. On stupid questions you always get stupid answers.
WoRmINaToR (worminator) wrote : | #49 |
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.
Professor_Tesla (professor-tesla) wrote : | #50 |
Based on recent tests, I can say that all of the tags for this feature work (SW.AutoFire, SW.AITargeting, SW.ShowCameo).
WoRmINaToR (worminator) wrote : | #51 |
Good, then this issue can be closed because two testers confirm this works and no further discussion is really necessary.
DCoder DCoder (dcoder1337) wrote : | #52 |
It was a stupid question though ...
Closed.
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.