https://bugs.launchpad.net/ares/+bug/894947 ;this is actually feature request for normal aircraft take off...VK devised such using hunter seeker style flight control in NP previously.
Darkstorm: The game can't know about kennels. It only has one build queue and Ares makes it appear as two with the BuiltAt feature. Expanding this is a too big task with too little benefit.
Apollo: Some of them are already done but not yet included. For example, the wrench on cloaked buildings was something I coded in 2011 and it was included in the power toggle changes I intended to include in this release but ripped out again because of the Ranged/ProjectileRange stuff. The EMP cannon needs some more refinement. Incidentally I started working on the particle system stuff some days ago, but more for fun's sake than productively. Firestorm changes would warrant an own branch, because there are so many things I'd like to expand, like finally including customizable animations that were done in 2010 and 2011 already (not by me, I have to look up who it actually was).
I want to finalize the feature set of 0.7 soon (this month), so it is essentially done. Even if I didn't do much of the stuff I intended to do, it's not a small release. I'm still considering the rubble expansion. _________________ QUICK_EDIT
Oh well, I wasn't sure how BuiltAt worked. The ExplicitOnly tag just seems useless to me if it still has to be attached to the existing queue, but there are probably more important features.
(You should still consider it in the future, even if it is low priority and a lot of work, it would seem to be a glaring problem with an existing feature.) QUICK_EDIT
Joined: 22 Nov 2010 Location: Iszkaszentgyorgy, Hungary
Posted: Sun May 18, 2014 6:21 pm Post subject:
How would you differ the units in the queue?
I am using BuildAt to separate my jumpjets at 2 of my sides (their warfacto had no upper-door anim at first) but other warfactories can build all the jumpjets.
Instead of setting BuiltAt on all of my units, I only had to set it on my jumpjets. Along with ExplicitOnly on my pure-helipads. The feature was more than helpful.
And you can't really mix splitted queues, except if you come up with some supercomplex tagging system and even that would be asking for trouble.
EDIT: In a less way OT: got this crash from one of my testers and I have no idea about the cause. Looking at the stack, I guess it's Ares but I have no idea what could have done it. http://www.speedyshare.com/ZXEBX/snapshot-20140517-164227.rar _________________ "If you didn't get angry and mad and frustrated, that means you don't care about the end result, and are doing something wrong." - Greg Kroah-Hartman
=======================
Past C&C projects: Attacque Supérior (2010-2019); Valiant Shades (2019-2021)
=======================
WeiDU mods: Random Graion Tweaks | Graion's Soundsets
Maintainance: Extra Expanded Enhanced Encounters! | BGEESpawn
Contributions: EE Fixpack | Enhanced Edition Trilogy | DSotSC (Trilogy) | UB_IWD | SotSC & a lot more... QUICK_EDIT
It goes back to using drones instead of infantry like I was wanting to do (as mentioned in my earlier post). If you are building tanks, you can't build your drones. Unlike another faction that could build infantry and tanks. Of course I could work around this by making the drones infantry types, but that raises issues of its own.
I'm not much of a programmer, so I'm not going to presume to know how much work it is to implement it. It just seemed like a problem with the feature.
Would it be easier to do what I suggested initially? Which is change the naval and waterbound tags where waterbound would determine if the structure is to be placed on water or not and naval would just determine targeting and what goes into the naval yard's queue. Of course this isn't quite up to the professionalism that Ares has going for it, but it would enable a second vehicle yard with a few caveats. QUICK_EDIT
Also Known As: ZivDero Joined: 23 Jul 2013 Location: Russia
Posted: Fri May 30, 2014 5:07 am Post subject:
How about buildings that have to be placed on a specific overlay/terrain type/lat/2-3 lats (beaches water-beach-clear) _________________
DarkVen9109 wrote:
What in the name of insanity is this? I FRICKING LOVE THIS LOGICCCC!!!!!!!!!!!!OOOOOOOOHEEAWWWWWWWWWWWYAAAAAAAAAAAAAAAAAWWWWWW PEW PEW PEW PEW BOOM BOOM BOOM!! Nice I love this!!!! Ferriswheel bomb, Dive bomb. New Logic discovered thanks to Kenosis
A probably huge request... but something for the Psychic Tower. You know how they had an unused Controlling Active Animation?
Art Tags
ControlAnim=
ControlAnimDamaged=
ControlZAdjust=
ControlAnimPowered=n
ControlAnimPoweredLight=
Rules Tags
IsController=; Should this Building use the Controller Active Animation instead of regular one?
Shouldn't there also be animations for how many things are controlled? like one "rod" lights up for one person controlled? And the tags to go with it? _________________ MIdAS - Turning wages into beer since 2002 QUICK_EDIT
I guess. But Westwood didn't even finish that bit. You'll have to make one for all 4 Missing Versions (1 Glowing Rod to 4 Glowing Rods) _________________ ~ Excelsior ~ QUICK_EDIT
After a long time, there's a new binary. It doesn't offer that much new, and I'm inclined to stop coding and start documenting before more feature requests are piled here. As I got no more confirmations in the last few weeks, I assume that's ok.
Maybe I'll add a few other minor features like the one related to particle systems, because this would be testable quickly. On the other requests: There are so many mentioned here that are useful in edge cases only, or quite complex to implement with little gain. Can't think about them all.
I'm planning for an Ares release in the next month. I'll start checking confirmed features soon. Depending on how long that will take, it might be mid month and not end of month.
Prevent units from scattering when attacked with warhead
[Warhead]PreventScatter= (boolean, defaults to no)
Whether units should not scatter when attacked with this warhead even if they have the ability to.
Consider civilian units enemies
[TechnoType]CivilianEnemy= (boolean, defaults to no)
Whether this unit is considered an enemy when auto-acquiring a target. Enabling this prevents a unit of this type to be considered neutral in multiplayer matches.
Auto-repelling civilian enemies
[CombatDamage]AutoRepel= (boolean, defaults to no)
Whether AI players will consider civilian units attacking allied objects as enemy when auto-acquiring targets. This makes units nearby help protect against an offender. Otherwise, only the attacked unit retaliates.
[CombatDamage]PlayerAutoRepel= (boolean, defaults to no)
Whether human players will consider civilian units attacking allied objects as enemy when auto-acquiring targets. This makes units nearby help protect against an offender. Otherwise, only the attacked unit retaliates.
Assorted stuff
Win and Lose theme swapped. The correct one will play now.
KillDriver.KillBelowPercent=1.0 should always kill the driver
Many internal changes and a few optimizations (changes to PCX tags, AE, Ripples, Radar Jammers, Ivan Bombs, Waves, E-Bolts, Alpha Lights, Paradrops)
Found something that might be a reason for sensors staying on after units die. Uncertain though. Was in a related place, but it's difficult to test.
Someone know how use the unstable version, because before ares 0.6, i have already use unstable and all has work almost perfectly.
But this version "14.150.1265" not work at all for me.
I copy ares.dll ares.dll.inj and ares.mix and i launch RunAres.bat, i receive a box with thats :
Code:
Log file failed to open. Error code = D
C:\Wesstwood\AR2\debug\debug.log
And when i open the log file, its write thats
Code:
Initialized Ares version: 14.93.403
Ares requires a CPU with SSE support. Available.
Optimizing list of CD drives for NoCD mode.
only thats.
But if i replace all unstable files by the files from ares 0.6, thats work correctly.
Joined: 22 Nov 2010 Location: Iszkaszentgyorgy, Hungary
Posted: Sat May 31, 2014 10:42 am Post subject:
Cool, Alex, PreventScatter is much more than welcome. Good job, I'll check these tonight. _________________ "If you didn't get angry and mad and frustrated, that means you don't care about the end result, and are doing something wrong." - Greg Kroah-Hartman
=======================
Past C&C projects: Attacque Supérior (2010-2019); Valiant Shades (2019-2021)
=======================
WeiDU mods: Random Graion Tweaks | Graion's Soundsets
Maintainance: Extra Expanded Enhanced Encounters! | BGEESpawn
Contributions: EE Fixpack | Enhanced Edition Trilogy | DSotSC (Trilogy) | UB_IWD | SotSC & a lot more... QUICK_EDIT
[Warhead]PreventScatter= (boolean, defaults to no)
[TechnoType]CivilianEnemy= (boolean, defaults to no)
[CombatDamage]AutoRepel= (boolean, defaults to no)
[CombatDamage]PlayerAutoRepel= (boolean, defaults to no)
All these tags seem to work beautifully (and I guess they work on animation warheads?). The big issue for me was AE heals etc causing units to scatter and this DOES seem to fix it.
With CivilianEnemy they are targeted as normal combat units. AutoRepel and PlayerAutoRepel work so if a friendly unit is attacked by a civilian everyone returns fire. QUICK_EDIT
Any news for the red laser line during Airstrike sir? (can be recolored or removed?)
Also if it's ok, just want to share the tags sir Alex posted in this topic collected in a text format as of his latest update with a UDL attempt for Notepad++.
Open Notepad++, go to Language>Define your language... then Import... and select the AresDoc.xml and open.
Close the window and open Docu.atxt in npp.
Sorry if this is unnecessary at all. Thanks again.
Initialized Ares version: 14.93.403
Ares requires a CPU with SSE support. Available.
Optimizing list of CD drives for NoCD mode.
You don't have write access to the debug.log file or folder. Close all programs that have this file open and try to launch syringe.exe as admin. If it's just the file permssions, you can delete the debug file. It should be created with write permissions on the next launch.
Airstrike laser colors: Neither the laser color nor the glow effect will be customizable in 0.7.
Next binary will arrive soon. The current one contains some experimental code for a class the game and Ares use in many places, as well as some other stuff which actually breaks the CivilianEnemy coding. Also, some Prism Forwarding code rework might get in, to get rid of many unnecessary checks. One new bugfix I'm planning is for infantry constantly uncloaking when on an attack mission. After this, there shouldn't be much more to add to 0.7, and the RC phase can begin. _________________ QUICK_EDIT
Don't know what you mean by broken CivilianEnemy code, but currently I am experiencing behaviour where units that themselves have CivilianEnemy set to yes, will, when under player control (maybe AI as well), auto-acquire any neutral units, regardless of if they have CivilianEnemy set. I don't think that should happen. _________________ QUICK_EDIT
Customizable DamageParticleSystems
Ares adds two new tags that allow particle systems other than the ones with BehavesLike=Smoke or Spark. This does not mean they are supported now and behave properly, but just that they can be spawned.
[TechnoType]DamageSmokeParticleSystems= (list of ParticleSystems, defaults to all DamageParticleEffects with BehavesLike=Smoke set)
Defines a list of ParticleSystems to randomly spawn from when an object is damaged into yellow or red health. You have to use this if you want to use ParticleSystems with BehavesLike= set to other values than Smoke.
[TechnoType]DamageSparkParticleSystems= (list of ParticleSystems, defaults to all DamageParticleEffects with BehavesLike=Spark set)
Defines a list of ParticleSystems to randomly spawn from when an object is in yellow or red health. You have to use this if you want to use ParticleSystems with BehavesLike= set to other values than Spark.
Damage Sparks untied from Infantry with Cyborg=yes
[TechnoType]DamageSparks= (boolean, defaults to yes for infantry with Cyborg=yes, to no otherwise)
Defines whether an object of this type should spawn spark particle systems defined by DamageParticleSystems=.
Assorted stuff:
CivilianEnemy tag is now used from the victim, not the firer.
Fix for infantry constantly uncloaking when it has an attack order. Now the infantry unit only uncloaks when it is close enough to the target, just like vehicles.
MakeInfantryOwner expanded to InfantryExplode, FlamingInfantry, InfantryElectrocuted, InfantryNuked, InfantryVirus, InfantryMutate, and InfantryBrute.
Reverse Engineering spy effect and Prism Forwarding received some internal changes.
deathreaperz: Like this as in graphics, or this as in music themes? It has been available for over a month now.
---
There are some issues (actually, it's almost half of all issues) that still need to be confirmed. It's all the issues with either Beta Available or Fix Committed. Some features have been tested only partially, or they have been confirmed in chat (which I don't track and thus don't count). Some features have been reported not working, or with limitations, but not confirmed after fixing them.
Activity has decreased, what I somehow expected, as there are fewer new toys to play with because of the nearing release. I expect another drop in activity once the world cup starts in less than a week. So, this will be the deadline for testing, because I don't want to be the only one working when all others are having fun. What's not tested will not be in the release.
There will be one more binary, which will try to make the TeamRetaliate a bit more useful as in not retaliating against aircraft/ConsideredAircraft, not against parasites, and not switching targets all the time (though I'm not sure it works the way I want it to work. The AV tag is not that useful though it should work exactly as in FS, because it only affects Auto-Targeting. The limpet mine has some special behavior, as it does not allow the player to select a target. My plan is to add a new tag for that, but not for 0.7. Maybe I'll change AV to not being usable against vehicles at all, and not giving an attack cursor.
---
edit: New binary is there, behavior of AV changed from just preventing auto-targeting to not being able to fire at VehicleTypes. TeamRetaliate changed, maybe it works better now than it did. Thursday I'll check which features are confirmed, and then that will be it. _________________ QUICK_EDIT
I can confirm the multiplayer score screens, I've completely disabled/messed up the campaigns in my mod tho so I'm unable to test their score screens.
BallisticScatter is working ok, well other than needing a CellSpread but that's a separate issue.
There are several more that I need to dubble check & some other new features that I plan to add soon too, I'll post my results in a few days. _________________
Joined: 22 Nov 2010 Location: Iszkaszentgyorgy, Hungary
Posted: Sun Jun 08, 2014 11:13 am Post subject:
I'll also send a report soon. Custom Airstrike voices certainly work, so does Smoke.Chance (haven't used the other smoke tags yet, but I think I will, since I changed that art as well IIRC). _________________ "If you didn't get angry and mad and frustrated, that means you don't care about the end result, and are doing something wrong." - Greg Kroah-Hartman
=======================
Past C&C projects: Attacque Supérior (2010-2019); Valiant Shades (2019-2021)
=======================
WeiDU mods: Random Graion Tweaks | Graion's Soundsets
Maintainance: Extra Expanded Enhanced Encounters! | BGEESpawn
Contributions: EE Fixpack | Enhanced Edition Trilogy | DSotSC (Trilogy) | UB_IWD | SotSC & a lot more... QUICK_EDIT
Took the liberty to confirm TeamRetaliates= DropPodTrailer= though. _________________ "Don't beg for things; Do it yourself or you'll never get anything." QUICK_EDIT
How bout RefinerySmokeLinkedTo and RefinerySmokeLinkedBy
;example
[GAOREP]
RefinerySmokeLinkedBy=PROC ; gs especially GAREFN
RefinerySmokeLinkOffsetOne= xxx,xxx,xxx ; need to be coordinated
RefinerySmokeLinkFrames=50
RefinerySmokeLinkParticleSystem=SmallOreSys ; SmallGreySSys ;TEMP _________________
Quote:
Humans were born for two things: to pray and be productive.
Customizable DamageParticleSystems
Ares adds two new tags that allow particle systems other than the ones with BehavesLike=Smoke or Spark. This does not mean they are supported now and behave properly, but just that they can be spawned.
[TechnoType]DamageSmokeParticleSystems= (list of ParticleSystems, defaults to all DamageParticleEffects with BehavesLike=Smoke set)
Defines a list of ParticleSystems to randomly spawn from when an object is damaged into yellow or red health. You have to use this if you want to use ParticleSystems with BehavesLike= set to other values than Smoke.
[TechnoType]DamageSparkParticleSystems= (list of ParticleSystems, defaults to all DamageParticleEffects with BehavesLike=Spark set)
Defines a list of ParticleSystems to randomly spawn from when an object is in yellow or red health. You have to use this if you want to use ParticleSystems with BehavesLike= set to other values than Spark.
Will the code like this works???
DamageParticleSystems=SparkSys,SmallGreySSys
DamageSparkParticleSystems=SparkSys _________________
Quote:
Humans were born for two things: to pray and be productive.
Looking good so far. Eight issues remain (it just looks like more because some features have a blueprint and a bug report).
Mig Eater: Thanks! The single player score backgrounds and themes are the ones that still need confirmation, but I guess focus is on multiplayer modes.
deathreaperz: Please, no new feature requests here. Put them on the tracker at LaunchPad. The SmallGreySSys should be used as smoke system, but the SparkSys will only work as smoke system if you use the new tag. Or: It will only be used as spark system if you enable DamageSparks=yes.
4StarGeneral: Thanks for confirming! For you it's about the same as for deathreaperz: You'll have to use the new tags to enable fire and gas particle systems. DamageSparks should work like this. Could you set DamageSparkParticleSystems=SparkSys? If you didn't change the spark tags, that should work or something is wrong. _________________ QUICK_EDIT
Oh... the tag is spelled DamageSparksParticleSystems in code, but I documented it as DamageSparkParticleSystems. Sorry about that. _________________ QUICK_EDIT
I set it to both DamageSparkParticleSystems=SparkSys, and DamageSparksParticleSystems=SparkSys, neither one seems to work on infantry with DamageSparks=yes. Maybe it just isn't read by #included rules files, I'll continue testing. _________________ "Don't beg for things; Do it yourself or you'll never get anything." QUICK_EDIT
BallisticScatter is working ok, well other than needing a CellSpread but that's a separate issue.
Maybe the real problem is on Inaccurate=yes. It changes target cell and prevents Arcing projectile from reaching the original target.
Thus most of the shots can't deal damage without large enough CellSpread and PercentAtMax.(In original game, FlakTrackGun uses a warhead with CellSpread=1 and PercentAtMax=1 to ensure damage)
I think this should be fixed to make a correct ballisticscatter effect.
scatter1.png
Description:
Inaccurate Arcing:Center of scatter radius is not at the original target cell.
>Inaccurate Arcing:Center of scatter radius is not at the original target cell.
> Inaccurate Arcing in TS. Shots scatter around target.
A some sort of math problem in projectile's arc because of different cell size?
Some residual tags cause projectile to miss. VeryHigh= for example can hit any target that close enough, but always miss a distant target, or even CirclingMissle bug _________________ Gangster is a Project Perfect Wuj (c)Aro QUICK_EDIT
AlexB, how to add tags in [General]DamageSparks=(bool)
so ARES users that wanted to enable sparks like me wont add DamageSparks=yes each units _________________
Quote:
Humans were born for two things: to pray and be productive.
Last edited by deathreaperz on Mon Jun 09, 2014 10:15 am; edited 1 time in total QUICK_EDIT
RehteA, also reference: Confirmed. Uploaded a new binary which will apply AV only to VehicleTypes on ground level. I'm not sure whether this solves the problem or whether I should also check ConsiderAircraft here. Feels a bit strange to have aircraft-like VehicleTypes on the ground though. What about Naval=yes?
Regarding Scatter: If that is an original problem, I won't fix it this late in the release process, as Ares 0.7 is nearing completion. _________________ QUICK_EDIT
Uploaded a new binary which will apply AV only to VehicleTypes on ground level. I'm not sure whether this solves the problem or whether I should also check ConsiderAircraft here. Feels a bit strange to have aircraft-like VehicleTypes on the ground though. What about Naval=yes?
I also found that in previous binary, adding AV=yes to projectile can also fix it .
Does AV= be "no" by default while AG=no?
About new binary, a simple test:
add AV=no to AAHeatSeeker2 (with AA=yes and AG=yes)
Result:
can't attack ground vehicle
can't attack ship
can't attack SHAD on the land
can attack SHAD in the air
can attack aircraft type and infantries(including jumpjets) QUICK_EDIT
AV defaults to AG. The key feature of AV should be that it works like it always did if not set. It should not affect firing at paratroopers at all, if they aren't VehicleTypes.
I made a quick test with requiring Naval=no and ConsideredAircraft=no. This fixes about the unwanted stuff like ships or landed SHAD not being attackable.
Next binary upload will have to wait for later, but if there are no objections, this will get in for sure. _________________ QUICK_EDIT
Side specific;
loading theme
win/lose score themes
grfxtxt.shp image
They are working for skirmish games, but as mentioned before I'm unable to test in the campaigns.
IsPassable & DamageSparks works too.
I'm unable to get a gas particle system to work with Damage(Smoke/Spark)ParticleSystems. TBH I'm unsure how it exactly works tho, so would be grateful for some example code. _________________
Mig Eater: There's no special code in place that supports all types of particle systems. I removed the selection of Smoke or Spark systems, but didn't enhance it so everything works as it could. Not all types can be used in a meaningful way. The fire stream particle system for example will just point up (to the origin, it seems).
Some ParticleSystems require a particle to be spawned manually. This includes the barrel particles and also gas clouds. The latter are kinda special, as they use a global particle system, thus yet another way to create particles.
Furthermore, the smore and spark systems have no owner, thus the use cases are limited. Maybe this will be expanded later, if it is requested.
deathreaperz: VirusCloud1 and PsychCloud are [Particles], but the tags require [ParticleSystems]. _________________ QUICK_EDIT
The old tag served two purposes: it defined both Smoke and Spark particle systems. Like "DamageParticleSystems=SparkSys,SmokeSys" was valid and behaved well. When it was used, it picked only one kind or the other.
Now, all particle system kinds are allowed, and a smoke system can also be used as spark system. Thus, just given the single original tag, both use cases would now use both particle systems. This is a change of behavior, and generally unwanted. That's why the new tags had to come in. They default to the old behavior if not set, and if set, they will allow every type. In other words: If you use a new tag, Ares assumes you knew what you were doing, it can accept all input without a second guess.
----
Regarding the name of the tag: DamageSparkParticleSystems or DamageSparksParticleSystem? I'm planning to rename three tags before release: DropPods.Minimum, Maximum and Veterancy to SW.Minimum, Maximum and Veterancy, because they could be applied more generally, and I'm not sure what the damage spark thing should be. Thoughts? Better have dedicated tags for them? _________________ QUICK_EDIT
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