Posted: Tue Dec 08, 2020 8:46 pm Post subject:
Ares 3.0 released
What nobody expected to happen any more has happened: Ares 3.0 has been released, after an almost infinitely prolonged RC phase where new issues popped up constantly.
But now here it is, together with many super weapon and mission making additions that allow for more possibilities, like super weapons being available only once or three times, or being charged initially, or being usable by AI only. The culling effect used by squids can be applied to any weapon now, and harvester and refinery related settings can be customized per type.
There's more new features, better support for selling units on service depots, a mechanism to ignore certain buildings when deciding whether a player has been defeated in short games, and a way to clone units as different types - as well as many new fixes and improvements.
EDIT: my [ParamTypes] in FAData.ini has 49=Voxel Anim,23 and Starrku's new list says 49=Waypoint,17,2 .
Is this a side-effect of using E1 Elite's patched FA2 1.02?
EDIT2: where to get the Ares FA2ext.dll for [ScriptsRA2] ? _________________ One and only developer of the Command & Conquer Dune "C&C D" mod.
m7 wrote:
I tend to release things I create so that assets are never lost to hard drive problems, accidental deletion, or me having to pretend to care about rippers taking things from my project when it is done.
can you make it so i can have walls that bind to objects like they did in tiberian sun for gates and component towers, tho? _________________ visit my moddb profile for .shp downloads and stuff QUICK_EDIT
Nice work, just in time for Christmas. The set/disable EVA trigger was much needed.
Bugs that still persist/are worth mentioning:
Large air vehicles cause IE when crashing above structures on certain Win10 PCs
Advanced Rubble preventing the owner from losing (game won't end) if tied to a buildup/sell animation mid destruction
Advanced Rubble makes Engineers get stuck in WF unit bays, preventing unit production until the Engineer is killed
Ore growth related crash, appears to be slope/cliff related
Transport + Abduct + previous command bug - units unloaded from a transport that has abducted them will sometimes go back to their last given order, which means they would also attempt to reenter the transport if that was their last order
MC + previous command, units continue doing what they were told after being MCd, including attacking allies _________________
ayylmao on Discord QUICK_EDIT
EDIT: my [ParamTypes] in FAData.ini has 49=Voxel Anim,23 and Starrku's new list says 49=Waypoint,17,2 .
Is this a side-effect of using E1 Elite's patched FA2 1.02?
Use the latest FA2 patch and if you are changing FAData.ini, merge rather than overwrite. In the patch, it is 49=Voxel Anim,0 (not 23) and the Ares waypoint param was shifted to 50 and its dependency changed accordingly. QUICK_EDIT
You asked me to remind you of this so I will.
AttachEffect.RecreateOnCapture=(bool) so anims can change teams.
Also, I'd like to request some fixes around the the isLocomotor logic.
For example, changing it to the teleport locomotor, including some other locomotors will cause units to be unselectable and unable to have their locomotor changed again after teleportation or after moving.
Allowing isLocomotor weapons to work with different locomotors will open up a path to quite some cool features/units
Transport + Abduct + previous command bug - units unloaded from a transport that has abducted them will sometimes go back to their last given order, which means they would also attempt to reenter the transport if that was their last order
This isn't just abduction, but also happens when Chronosphere is used on a unit that is on the move (funny, i can't find that one on the bugtracker, i was sure i reported it... ).
This might mean there is an issue within the locomotors themselves, in which case i doubt it will be fixed anytime soon (if at all). I still remember the last time Alex tried to fix a bug within locomotor code, and he seemed pretty traumatized by it (i was the one reporting him the bugs that kept popping up with each "fix" :p ). QUICK_EDIT
Also Known As: evanb90 Joined: 20 Feb 2005 Location: o kawaii koto
Posted: Thu Dec 10, 2020 5:22 am Post subject:
Beautiful. Seeing those 3 bugfixes made my day. _________________ YR modder/artist, DOOM mapper, aka evanb90
Project Lead Developer, New-Star Strike (2014-)
Former Project Lead DeveloperStar Strike (2005-2012), Z-Mod (2006-2007), RA1.5 (2008-2013), The Cold War (2006-2007) QUICK_EDIT
The ForceFire/Retaliate/PassiveAcquire in Warhead Versus only work with given ArmorType(s), while they don't affect deratives at all.
That can't be right. They work.
Code:
[ArmorTypes]
DesoArmor=flak ;;so Deso's don't auto-target selves and fail.
HarvArmor=medium ;;so Deso's don't auto-target Harvies and fail.
[RadBeamWarhead]
Versus.DesoArmor.ForceFire=yes
;;These are here so that Desos don't go 'try to kill each-other and fail'
Versus.DesoArmor.Retaliate=no
Versus.DesoArmor.PassiveAcquire=no
Versus.HarvArmor.ForceFire=yes
;;These prevent Desos from wasting time on RadImmune Harvies (and getting killed by a civilian!)
Versus.HarvArmor.Retaliate=no
Versus.HarvArmor.PassiveAcquire=no
Though non-human house units do auto-target sometimes, like when they're human controllable and you use Attack-Move/Ctrl+Shift+LMB.
Maybe it's always been broken for AI/non-human houses? QUICK_EDIT
Joined: 04 Mar 2015 Location: Notso "The Finale" Airship
Posted: Sun Dec 13, 2020 1:36 pm Post subject:
TAK02 wrote:
Mikesari Itten wrote:
The ForceFire/Retaliate/PassiveAcquire in Warhead Versus only work with given ArmorType(s), while they don't affect deratives at all.
That can't be right. They work.
Code:
[ArmorTypes]
DesoArmor=flak ;;so Deso's don't auto-target selves and fail.
HarvArmor=medium ;;so Deso's don't auto-target Harvies and fail.
[RadBeamWarhead]
Versus.DesoArmor.ForceFire=yes
;;These are here so that Desos don't go 'try to kill each-other and fail'
Versus.DesoArmor.Retaliate=no
Versus.DesoArmor.PassiveAcquire=no
Versus.HarvArmor.ForceFire=yes
;;These prevent Desos from wasting time on RadImmune Harvies (and getting killed by a civilian!)
Versus.HarvArmor.Retaliate=no
Versus.HarvArmor.PassiveAcquire=no
Though non-human house units do auto-target sometimes, like when they're human controllable and you use Attack-Move/Ctrl+Shift+LMB.
Maybe it's always been broken for AI/non-human houses?
Also Known As: evanb90 Joined: 20 Feb 2005 Location: o kawaii koto
Posted: Sun Dec 13, 2020 4:35 pm Post subject:
I believe this is by design.
When you put armors in [ArmorTypes], you're doing 2 things: Declaring the new armor type, and defining the default Verses= value for that armor type, that's it.
By putting someTank=light in [ArmorTypes], it means that absent a Versus.someTank=xx% statement in the warhead, the game will default to the value given for the 'light' armor type. _________________ YR modder/artist, DOOM mapper, aka evanb90
Project Lead Developer, New-Star Strike (2014-)
Former Project Lead DeveloperStar Strike (2005-2012), Z-Mod (2006-2007), RA1.5 (2008-2013), The Cold War (2006-2007) QUICK_EDIT
Joined: 04 Mar 2015 Location: Notso "The Finale" Airship
Posted: Mon Dec 14, 2020 2:55 am Post subject:
EVA-251 wrote:
I believe this is by design.
When you put armors in [ArmorTypes], you're doing 2 things: Declaring the new armor type, and defining the default Verses= value for that armor type, that's it.
By putting someTank=light in [ArmorTypes], it means that absent a Versus.someTank=xx% statement in the warhead, the game will default to the value given for the 'light' armor type.
To be honest, I think so too. But so design is not convenient. So I wonder if there can be a new tag to apply these three tags to derivative ArmorTypes. QUICK_EDIT
Also Known As: evanb90 Joined: 20 Feb 2005 Location: o kawaii koto
Posted: Mon Dec 14, 2020 1:57 pm Post subject:
Would that not be of limited value? In the long run, such a tag would save 2 lines of code (if per warhead) or 3 lines (if global) for each instance. _________________ YR modder/artist, DOOM mapper, aka evanb90
Project Lead Developer, New-Star Strike (2014-)
Former Project Lead DeveloperStar Strike (2005-2012), Z-Mod (2006-2007), RA1.5 (2008-2013), The Cold War (2006-2007) QUICK_EDIT
Also Known As: evanb90 Joined: 20 Feb 2005 Location: o kawaii koto
Posted: Mon Dec 14, 2020 4:05 pm Post subject:
Inheritance isn't even mentioned in the documentation for Ares. It has only been briefly discussed in a few posts on this forum, to the best of my knowledge
And if I remember what AlexB said about it, there's a reason it isn't mentioned in the documentation. _________________ YR modder/artist, DOOM mapper, aka evanb90
Project Lead Developer, New-Star Strike (2014-)
Former Project Lead DeveloperStar Strike (2005-2012), Z-Mod (2006-2007), RA1.5 (2008-2013), The Cold War (2006-2007) QUICK_EDIT
IsTrain not loading InfantryTypes has been a bug since at least Ares 0.9, I didn't go below that in testing because it started crashing. But I suspect no one has brought it up because trains are awful to deal with. _________________ "Don't beg for things; Do it yourself or you'll never get anything." QUICK_EDIT
Currently, upon infiltration, the player who infiltrates can get a superweapon.
However, since superweapons are very flexible, it would be nice to be able to give the one that got infiltrated a super weapon as well.
Nice work, just in time for Christmas. The set/disable EVA trigger was much needed.
Bugs that still persist/are worth mentioning:
Large air vehicles cause IE when crashing above structures on certain Win10 PCs
Advanced Rubble preventing the owner from losing (game won't end) if tied to a buildup/sell animation mid destruction
Advanced Rubble makes Engineers get stuck in WF unit bays, preventing unit production until the Engineer is killed
Ore growth related crash, appears to be slope/cliff related
Transport + Abduct + previous command bug - units unloaded from a transport that has abducted them will sometimes go back to their last given order, which means they would also attempt to reenter the transport if that was their last order
MC + previous command, units continue doing what they were told after being MCd, including attacking allies
Adding to the list:
- Designator SW targeting does not work in SP missions (AI Targeting + AutoFire)
- CarriesCrate=yes is broken
- Latest FA2Ext.dll crashes on certain events and actions e.g. "building exists" or "create building type at waypoint"
- Inhibitor tag does not persist through death anim, thus breaks any SW using it while the target infantry is playing its death anim
06/01 EDIT:
Let's add more to this evergrowing list:
- Permanent Mindcontrol is broken, logic ignores versus/verses if used on airburst weapons
- Light.Enabled=no is broken or needs clarification, lightning storm clone still changes lighting despite tag. -1 on other tags do not help either
- Entering vehicles into a friendly tunnel cause them to disappear forever (infantry still work though) _________________
ayylmao on Discord QUICK_EDIT
It has been 4 months since release, is there any feedback on fixes to come? There's quite a lot of bugs considering this is a "stable" release.
We also need to address the elephant in the room, being that Ares is still closed-source and we're hitting a lot of walls as Ares' code is preventing new features/hooks from developing further.
We appreciate the effort after all these years, but if free time is an issue, please just release the source and move on? The recent spike of new contributors and interest in creating new features clearly shows the need for this. _________________
ayylmao on Discord QUICK_EDIT
XxpeddyxX, I agree with that but man, I believe that he won't read it.
Guys, you have to contact AlexB somewhere else... its pointless here as he rarely comes here, maybe once or twice per year, if you are lucky. Give him link here, and he will reply. Most likely. _________________ PPM Halloween Season 2021 QUICK_EDIT
I strongly suggest Ares should add a Reverse/Neg Designators feature.
ARES has a designator feature for superweapons to be allowed to put in the designator range. I think Ares should add a reverse designator (or negative designator) for owner's superweapons not to be allowed to put inside some user's own or allies' units' neg-designator range.
INI code below:
[SomeTechnoType]
NegDesignatorRange=0 <int,double>
[SomeSuperWeaponType]
SW.NegDesignators=none <some technotypes, maybe including shieldtypes>
NegDesignatorsAccepts=allies <allies,own> QUICK_EDIT
Ares already added Inhibitors which work as "negative designators", you cant specifically limit them to only owned/allied units though.
You can use SW.RangeMinimum= to put a limit on how close the SW can be used to the building that fires it. Depending on what type of SW it is you can also use AffectsAllies= or AffectsOwner= to limit the effect/damage of a SW too. _________________
Joined: 01 Feb 2007 Location: Las Vegas, Nevada, USA
Posted: Thu May 12, 2022 4:52 am Post subject:
I don't think inhibitors is not what he's asking, he is asking for the opposite of designators that can work on friendly weapons. There is a copy of Ares before the latest, a prototype build, that implements friendly inhibitors and unfriendly designators, but to my knowledge this was just for that build and it does not include the latest features from the latest release (including some fixes for tunnels). You're gonna have to decide which is more important basically. I have no clue where I originally got it and don't care enough to look anymore, so here it is mirrored. I would love to hear if I am wrong and the latest Ares does secretly work with these tags and it's just not documented, I haven't tried myself but I doubt it.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You can download files in this forum
Ares 3.0 released
