Firing off AirburstWeapon instantly crashes the game in 18.206.1222.
EDIT: Never mind, it is not as universal as I thought as some work correctly, while others do not work but don't crash either. Something definitely changed between this version and the last in regards to this, though. _________________ Last edited by Starkku on Sat Jul 28, 2018 12:22 pm; edited 1 time in total QUICK_EDIT
Also since I started using unstable ares since 18.204.602, the AI sometimes has units standing still and sort of shaking their turrets like it's uncertain of what they should do. Having some of these units also seems to slow down the game somewhat.
Also, sometimes the game stops when alt-tabbing. Doesn't always happen but it does happen. QUICK_EDIT
I'd mention this issue once again: Passenger.BySize=no transport cannot work well with abduction logic. That is, abduction will still check the size of the object. If it's exceeded the currently available slot, the abduct won't happen. However, when an actual abduction happens, it'll still follow Passenger.BySize=no and takes 1 slot. I think the condition of abduction could be changed a bit to fit in with the addition of BySize, so that we could let an abductor to abduct a certain amount of unit regardless of their sizes.
E.g. Use a unit with Passengers=6 to abduct another object that has Size=6, since the size is no more than the abductor's current slot, the abduction will happen. The unit will actually take 1 slot in the abductor, so there're 5 available slots now. However, if you're going to abduct another Size=6 unit, the abduction won't happen cause 6>5, despite it'll still take 1 slot because of Passenger.BySize=no.
Edit: Okay it's even more dumb than I expected When abducting a Size=6 unit, despite it takes 1 slot, the abduction logic will still consider it as taking 6 slots. Thus, it cannot abduct anything until unloading the current passenger. QUICK_EDIT
Thanks WoodleMyNoodle and Starkku, I apparently left experimental code in my folder when I compiled that version, and the code wasn't done. It should affect projectiles having PreImpactAnims set. Will be fixed in the next version, which I hope I can upload today. _________________ QUICK_EDIT
I uploaded a binary without the experimental code. Version number is still the same (18.206.1222, but with a new file name ending with a 'b'), even though there have been some changes. _________________ QUICK_EDIT
There's a new unstable version for the coming weekend (18.219.921), which adds a few new features (bigger ones this time), and improves upon the bad design decision that was Damage.Threshold.
I'll soon finish up the lose ends, because there's so many things already, and development goes on and on without goal. So, here's potentially the last list of new features for this release.
Minor additions
The self healing combat delay now only affects damaging attacks
Correctly separate the first pip for empty Gunner units
Initialize some uninitialized members to help diagnosing desyncs
Support Abductors with Passengers.BySize
Replaced Damage.Threshold by Damage.Delay
[Anim]Damage.Delay= (integer - frames, defaults to 0)
The delay between two applications of Animation damage. If greater than 1, the delay to the first application of damage is unspecified.
Damage.Threshold has been removed.
Optionally move the bullet when PreImpactAnim moves
[Warhead]PreImpactAnim.Moves= (boolean, defaults to no)
If yes, moves the bullet to the last location of the PreImpactAnim and sets the target to the cell containing the animation.
DeployDir per Type
[TechnoType]DeployDir= (integer - facing, defaults to [General]DeployDir)
The direction a DeployToLand unit will face when landing. Valid values range from 0 to 7.
If a DeployToLand=yes unit has no DeployingAnim and it thus doesn't matter to align the body with this animation, turning to DeployDir is skipped. This does not affect the original Siege Chopper, because it does have a DeployingAnim.
Support DeployDir on DeployToLand=no units
If a unit has a DeployingAnim, turn it in a certain direction also even if DeployToLand=no. This way, the DeployingAnim can be made to fit better and the unit will not suddenly change facings.
Convert Unit Type on Promotion
Supports only unit to unit, infantry to infantry, and aircraft to aircraft.
- Ammo is deduced if new type has less ammo
- Health is recalculated using the new Strength
- Cloakable is applied again, considering the new type
- Spotlight is reinitialized
[TechnoType]Promote.VeteranType= (TechnoType, defaults to none)
If set, the unit converts into this type when being promoted to veteran rank.
[TechnoType]Promote.EliteType= (TechnoType, defaults to none)
If set, the unit converts into this type when being promoted to elite rank.
[TechnoType]Promote.VeteranExperience= (double, defaults to 0.0)
A value added to the experience when a unit type is converted using Promote.VeteranType. Can be used to promote a unit to a rookie of another type. (Using -1.0 removes one rank, thus a unit becoming veteran gets one rank removed and essentially becomes a rookie of the converted type.)
[TechnoType]Promote.EliteExperience= (double, defaults to 0.0)
A value added to the experience when a unit type is converted using Promote.EliteType. Can be used to promote a unit to a rookie or veteran of another type. (Using -1.0 removes one rank, thus a unit becoming elite gets one rank removed and essentially becomes a veteran of the converted type.)
Note that if the unit skips the veteran rank and becomes elite immediately, Veteran settings are not applied.
Also note that this is not cascading: if a unit is promoted to elite and converts to a veteran version of another type, which in turn should convert to something else, no further conversion takes place.
Note that so many restrictions apply that it's no fun to write them down. Generally, a unit is not allowed to convert to something that has a chance to be in a situation where the new type cannot be. I.e. if an infantry unit gets bigger while inside a full transport, if the converted type is not allowed in an occupiable structure, ...
Conversion only happens between same types (vehicles, infantry, aircraft). You can't change locomotors, you shouldn't change the size if a unit can enter a transport or structure and the unit gets promoted inside, can't convert to a type that then wields a special weapon (Temporal, Mind Control, Parasite), ....
Convert Unit into Another Type on Deploy
[TechnoType]Convert.Deploy= (TechnoType, defaults to none)
The type a IsSimpleDeployer=yes unit deploys into. This converts the type after deploying is finished, that is, after the optional DeployingAnim has finished playing.
After deploying, the unit will be movable opposed to being locked in place like the Siege Chopper.
DeployToLand=yes is supported. DeployingAnim is optional, but also works for DeployToLand=no using DeployDir=.
Same restrictions as for the promotion conversions apply, except:
- changing locomotors is supported (Siege-Chopper-to-tank conversions)
- because this conversion always happens with the unit standing still and being on the map, Size and friends can be changed safely
WaterImage on Steroids
[TechnoType]Convert.Water= (TechnoType, defaults to none)
The type to convert to when a unit moves onto a beach or water cell.
[TechnoType]Convert.Land= (TechnoType, defaults to none)
The type to convert to when a unit moves onto a cell that's neither beach nor water.
Water and Land units should not define a conversion to their own type, like a water unit converting into an other water unit. _________________ QUICK_EDIT
Right here is my initial report for a unit to unit veterancy. I tested a aircraft in which I had made it develop into 3 different stages in which each stage has a different model scheme, weapons (with altered damage, ROF, range burst and speed), strength, speed, sight, abilities, rank insignia ,ammo and name. To which it seems to work nicely. here is a few pics.
Final Stage.png
Description:
Overview
Filesize:
75.45 KB
Viewed:
7148 Time(s)
Stage 1.png
Description:
No Special Scheme - normal Fighter. No Chevrons - 1 chevron.
Filesize:
169.73 KB
Viewed:
7148 Time(s)
Stage 2.png
Description:
Special Scheme - Elite Fighter. 2 Chevrons - 3 chevron.
Filesize:
172.34 KB
Viewed:
7148 Time(s)
Stage 3.png
Description:
Special "ACE" Scheme (the one with orange paint) - ACE Fighter. 4 Chevrons - Star. Also Notice naming changes.
Filesize:
176.61 KB
Viewed:
7148 Time(s)
Stage 4.png
Description:
normal and elite fighter has Ammo=2 Ace Fighter has ammo=3 Also Notice naming changes.
Joined: 05 Sep 2013 Location: LocationNotFoundException at RealLife.Location.find() at line: -1
Posted: Sat Aug 04, 2018 2:53 pm Post subject:
I didn't try many combinations of unit conversion yet, but I did a quick test to try to make a sea-wing like unit by making the Typhoon deploy into an air unit of itself. I seem to be unable to make it land in the water again (it only wants to land on... well, land), and I think it wasn't possible to deploy air units into water in YR (I mean by DeployToLand=yes)? Maybe I'm missing something for this water deployment thing, but otherwise it seems to work.
The self healing delay seems to indeed no longer initiate by repairing. I have a quick suggestion here though, maybe the minimum damage that is required to stop the self heal (I assume it is 1 now), could be set in rules? For example we set the minimum = 5, and then taking damage below 5 won't stop the self heal.
EDIT: I found a bug. I have scripted some units (Siege Choppers) on a map to deploy soon after the mission starts, and in this version these units won't deploy. They can be deployed manually, but the script won't deploy them. The previous build does not have this issue.
Also, I have tried more fancy combinations of conversion. I made a unit deploy into another unit, which then can either deploy back to the previous unit, or drive onto water and become a submarine. The submarine can then fly over land (as it can't land on water) and deploy to the first unit again. All this gave no conflicts as far as I can tell. I noticed the reload from a previous unit's shot still counts after deploying, which is great.
I tried with a fake transport as well, but as I expected that didn't work. Deploying into a fake transport with initial passengers causes IE, and such a transport can't transform itself, which is in line with the limitations described for this build. I guess allowing fake transports to convert into other units would be messy, considering the units inside would have to stop existing.
I have one suggestion for this unit conversion, and it is that after a unit has deployed, it can have a delay before it is allowed deploy again into another form. This would allow to stop units without deploy animations from jumping forth and back between deployed and undeployed versions immediately. QUICK_EDIT
Has DeployToLand been expanded to work on JumpJet InfantryTypes as well?
Been trying to implement Deploy.Convert into JumpJet infantry so that they would switch to newly created variants of themselves that act like regular infantry, but with no success thus far.
Do tell me if code is needed to show I'm talking about.
(I apologize for assuming in the first place though) QUICK_EDIT
Joined: 05 Sep 2013 Location: LocationNotFoundException at RealLife.Location.find() at line: -1
Posted: Sat Aug 04, 2018 11:56 pm Post subject:
In this latest unstable build I noticed my Magnetrons and sonic weapons(?) have changed custom beam colours, despite their rules setting being the same. Have there been any changes to those? Also, is the build version supposed to say 18.215.921 in the menu, while it is titled 18.219.921 on the download? QUICK_EDIT
Has DeployToLand been expanded to work on JumpJet InfantryTypes as well?
Been trying to implement Deploy.Convert into JumpJet infantry so that they would switch to newly created variants of themselves that act like regular infantry, but with no success thus far.
Currently Convert.Deploy only works with IsSimpleDeployer which is a VehicleType flag. _________________ QUICK_EDIT
The version should be 18.215.921, the 19 was a typo.
The transformation feature is pretty limited, but for a very simple reason: this feature would have to be somewhere down in the engine, at pretty low level. It cannot be added on top and just work.
When important corner cases are solved in a feasible way, this could be extended to other unit types. To support more feature interactions, I would have to write glue code to fix up things. This means recoding everything manually what the engine would do in other places, and this takes a lot of time.
Because everyone sees other things in this feature, and assumes everything just works perfectly as if this was a natural feature, I intend to only support a few basic things, like changing image, strength, and some more. For everything else, all bets are off. Might work, might crash.
Conversions between ships and hover and vice versa might not work. AI teams might not work, because suddenly there's a unit in a team that does not match any team member, and one member of a type that was supposed to be there is now missing. That means a team might suddenly become "incomplete" and the engine might recruit more units.
DeployToLand= is unaltered so far, thus cannot land on water. An option might be possible, but I consider this a feature request, like everything that is not very closely related to transforming.
For now, land-to-land and jumpjet-to-land-to-jumpjet are fully supported. AE will be supported soon (TypeAE-less-to-TypeAE and vice versa).
Because people asked already: There's another way to implement this feature. Ares changes the type in-place, but it would also be possible to remove the old unit and replace it with any other new unit. This would support infantry-to-vehicle, for example. But there's a downside: the new unit would not be related to the old, and thus, passengers would need to be transferred manually, tags/triggers would need to be manually transferred, teams would need to be reconstructed, same with AEs, ..., and everything attacking or otherwise referencing the old unit would need to be fixed up, ... Apparently just the same, but this would actually be worse.
@Agent Z: AI always had problems deploying Siege Choppers. Not sure whether I broke something there when doing the change to skip DeployingAnim, or when waiting for the unit turning. Does it turn to DeployDir? Does it land, but not convert? A deploy delay would be easy to do, but I'm not sure it's a good idea.
@Mig Eater: I'll check why buildings still deactivate. _________________ QUICK_EDIT
Joined: 05 Sep 2013 Location: LocationNotFoundException at RealLife.Location.find() at line: -1
Posted: Sun Aug 05, 2018 10:05 pm Post subject:
I took a closer look at the chopper, and the issue seems to be related to how triggers spawn units on the map. I made 2 choppers, one preplaced on the map, and the other spawned by action 7. The normal behaviour for the game is that the choppers deploys north after being spawned on the ground (despite Deploydir being set to 2 like normal YR), and this is what we see in the previous build. In this build, only the preplaced chopper that is recruited deploys. I changed the spawning chopper to my team, and tried to deploy it, but that was also impossible.
I had a similar issue with an artillery unit on a different map in this build (also spawned and deployed by triggers), but that one has no deploy anim, but the script tells it to face south before deploying. What happens is that the unit flashes between it's unloadingclass and normal image while rotating, and the ultimately ends up not deployed.
AlexB, here is what I tested
In first case it was simple
[LTNK]
Convert.Deploy=YTNK
IsSimpleDeployer=yes
Then, ingame I got deploy cursor over Lasher Tank, damaged and it got converted into gattling tank with same damaged health.
In second case it was
[BSUB]
Convert.Deploy=BSUBB
IsSimpleDeployer=yes
[BSUBB]
Convert.Deploy=BSUB
IsSimpleDeployer=yes
Except second boomer has HoverMissile weapon from IFV and is not cloaked. And ingame it is like I made it. Boomer which deploys into not cloaked boomer which shoots HoverMissiles and can turn back into regular boomer again. So, on naval units it works as well.
But in third case I got problem. And I need that feature working as I am searching for solution for years.
[DISKA]
Primary=DiskLaser
Convert.Deploy=DISKB
IsSimpleDeployer=yes
GroupAs=DISK
DeployToLand=yes
And they look different so I can know which has laser, which dran. Point is that I chose manualy what will be drained, what shot with laser so I can destroy reactors, defenses at wish and win from air.
And as you can see, Disk must land to transform which is obviously unwanted.
DeployToLand=yes is must here or Disk will behave like nighthawk, it will always stay on ground unless moves or fires.
Otherwice it works very well. Dark disk drains targets, while blue one shoots laser at everything. Only landing to deploy is big issue here. Also because of thatthere is no deploy cursor over water which means that I always must have clear ground, just like Siege Chopper.
So, please if you can fix this so flying units can immediatelly transforms into another flying units without need to land. _________________ PPM Halloween Season 2021 QUICK_EDIT
Joined: 05 Sep 2013 Location: LocationNotFoundException at RealLife.Location.find() at line: -1
Posted: Fri Aug 10, 2018 5:37 pm Post subject:
I have found some bugs related to the deploy conversion:
1. Sometimes when an unit receives a deploy command while moving, it will try to stop and do so, but while doing so it will flash rapidly between the two forms. This could be an issue if there were different conversions happening for the next unit too.
2. When exiting a tank bunker, it will do something similar as the above (the forth and back flashing), and it might ultimately change to deployed form when it finishes exiting the tank bunker.
Just now I observed these bugs with a four-form unit that can loop the forms, and in these two cases it does indeed loop them, and the resulting form is practically random. QUICK_EDIT
Thanks for all the reports; I still have to go though then (in particular the type-change looping and the deploy issues). There's a new build (18.224.868) which fixes a few things and adds minor featues.
Minor additions
Reset the AttachEffect on the type when changing unit type
PreImpactAnim was broken... again (but to my defense, it was a different bug :p)
Anim damage should actually work now with delays greater than 1
Another attempt to fix PoweredBy shutting down buildings during buildup
Fixed some debug lines in the log
Support deploying DeployToLand=no units that are not on the ground (like Jumpjets)
Also reset the ROTs when converting types
Better support for simple-deploying hover units
DeployToLand=yes hover units will land smoothly now. DeployDir is suported if the unit has a DeployingAnim.
For now, will not be able to deploy on water or beach cells.
Remove Veterancy when Driver is Killed
[Warhead]KillDriver.RemoveVeterancy= (bool, defaults to no)
Whether a unit will revert to rookie rank when the driver is killed and the unit changes owner. _________________ QUICK_EDIT
Haven't had a computer for months so I can't test but can someone tell me if unit to unit veterancy carries on experience onto the new unit? E.g. conscript kills well over his value and would be taken to elite, if there are 3 stages, and the first just transforms him to another unit, would the remaining experience still take him further... if that makes sense? _________________
ayylmao on Discord QUICK_EDIT
Experience carries over. Check out Promote.EliteExperience, which you can use to manipulate experience on the new value after a conversion.
If you mean to apply two or more of those conversions at the same time then: no, a unit cannot be converted in one go over a second stage into a third. I had code for that, but it's ugly, could allow for cycles that would cause freezes, ... If this is needed, it can be added back later. _________________ QUICK_EDIT
A quick update (18.227.645), also to use the latest compiler that has just been released.
Minor additions
Fixed Damage.Delay
Insignia Frame setting
[TechnoType]InsigniaFrame= (integer - frame index, defaults to -1)
[TechnoType]InsigniaFrame.Rookie= (integer - frame index, defaults to -1)
[TechnoType]InsigniaFrame.Veteran= (integer - frame index, defaults to -1)
[TechnoType]InsigniaFrame.Elite= (integer - frame index, defaults to -1)
The frame used from the insignia shape. Set to -1 to use the default frame index.
The default frame index is determined by the following mechanism:
If custom Insignia is set, 0. Otherwise, 14 for Veteran and 15 for Elite. _________________ QUICK_EDIT
It seems that a vehicle converting into another vehicle that spawns things crashes the game, but doing it the other way around does not (including converting back).
Fired a warhead with a looping anim that has Damage.Delay=30, the anim killed infantry. Fired the same warhead while the old anim was still looping, and once the first one ended, infantry could safely enter the second and stay there without receiving any damage.
Then, once it ran out and I fired the warhead again, infantry again received damage.
Did it several times with same results. QUICK_EDIT
OmegaBolt: That's not possible. A unit gets a helper object for Parasite, Mind-Control, or Temporals once created. If you change the type from one that doesn't need them to one that does, those objects are not set up and the game will crash. The other way around works: objects are set up, just unused.
It's kinda like forgetting Spawns=yes on a unit with Spawner weapon.
mevitar: I'm not sure how that can happen. Anims are independent of each other. Maybe it's about how anims manage their owners (badly and inefficiently). Will take a look, thanks. _________________ QUICK_EDIT
PreImpactAnim.Moves works as expect, Airburst&ShrapnelWeapon gets carried to the new location. I set AirburstWeapon=itself and create this infinite bouncing weapon, it also spawns ShrapnelWeapon when impacting trees/units
https://www.moddb.com/media/iframe/1991397
cxtian39: I'll have to check whether this also happens with the original game or not.
KALAPS S8:Not all logics are supported. I will document this as a small list of things that are supported, which will only be maybe 5 items or so like Strenght and Ammo change and so on, to not be bothered by all those tiny details that might fail...
A unit cannot end up in a place where the new stage cannot be. InitialPayload is exactly that: initial payload added when the unit is created. What do you think is considered "initial" if the unit changes its type after having been created already?
What are you intending with NoManualUnload and Convert.Deploy? _________________ QUICK_EDIT
Damage.Delay definitely makes things unreliable now, it didnt do this with Threshold or earlier versions of Delay as far as I noticed. Sometimes it the animation weapon isn't fired by an anim at all. QUICK_EDIT
I can change back and forth implementations between one that is slow but deterministic (not yet done), fast and indeterministic (current), and hard to use but deterministic (previous one). I don't see how the benefits of all could be possible without any downsides. Time for another episode of idiotic insights!
Here's the reasons for the current design of Animation Damage:
Previously, Damage was added every frame, with the threshold preventing it to fire until this value is reached. This meant that you couldn't do 100 damage every 15 frames, but 6.6667 damage every frame with a threshold of 100. That wasn't intuitive, but it started accumulating damage when the anim was created and fired exactly (see floating points below) 15 frames later. If two anims were created five frames apart, they would deal damage five frames apart.
Currently, the feature does not add Damage every frame, but only after a delay, with a "randomish" starting value so not all animations of the same type fire at exactly the same frames. This means that the anim might not fire at all if its runtime is shorter than the delay. (As documented, the delay is X, but the first damage is not necessarily dealt immediately or after X-1 frames. Iow: pick any range of X frames, and damage will be dealt exactly once, guaranteed.) This is the same logic used for many other things in the game like trailer and firestorm anims, and spawning particles (with the same guarantee).
Ares does not expand animation objects. Making damage deterministic and easy to use would require this, because the actual creation frame is needed for the logic to deterministically fire. This would affect all animations of all animation types though, whether they have damage or not. And that's something I'm trying to avoid.
The game originally did not have this problem: it added damage every frame, and it fired once damage was 1 or greater. That is, it was unintuitive if Damage was to be applied every Y frames (and then it would only allow either Y hitpoint every frame or 1 hitpoint every Y frames), but it was at least deterministic.
I could try to divide damage by delay behind the covers, still accumulate damage every frame, but then we're in the floating point wonderworld where 2 / 0.2 is 9 with a remainder of 0.2. If you think that's better...? _________________ QUICK_EDIT
This means that the anim might not fire at all if its runtime is shorter than the delay.
That's not the issue here though, as far as I see. Not sure what you changed between versions, but on 18.224.868 Damge.Delay was working for me and on 18.227.645 it isn't. Some animations it doesn't work at all, and some it seems random, maybe dependent on another animation of its type existing but several can still appear and work so its not quite what mevitar said. For example, one weapon I have 2 animations instances works at the same time, but the 3rd and 4th instances don't work at all. QUICK_EDIT
I gave a skirmish AI an out-of-map dummy structure to restrict it from training certain units or building certain defenses via Prerequisite.Negative, but it only worked for the units. Is it possible to make AIs obey the negative prerequisite system for structures as well? QUICK_EDIT
If you want to stop the AI from building a structure on a specific map then you can just add that building's section to the map code along with the tag AIBuildThis=no. _________________
We can place a PlaceAnyWhere=yes building via superweapon at any location even overlapping other buildings.
By using this trick, you can combine multiple superweapons into one or upgrade a superweapon without reseting its charge time.
It works well except during multiplayer game. It often crashes the game when one of the overlaped buildings destroyed.
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