Noticed a bug with an older Ares, and can't confirmyet if it's been fixed with the last one:
It involves using TogglePower on a building with an ActiveAnim while you're out of / low on power before that building got placed.
Simply deactivating and then re-activating the building in question causes the ActiveAnim to play.
Nice way to decieve yourself and others, I say QUICK_EDIT
Alex, you did an amazing job again, thank you! The most long-awaited feature for me was the unit transformation combined with veterancy.
Now I have a question about vehicles (IFV in this case).
I've made a change on the IFV, now it can disguise itself but not automatically like Mirage Tanks do. To achieve this, it has to have a spy in it, and its weapon changes to TankMakeupKit. If it's done, you'll have an attack cursor on any tree or rock, and you can disguise the IFV manually when you click on the target.
We know that if a disguised vehicle starts moving, the disguise will stop. Not like when I deploy the IFV, it remains disguised even if the spy isn't in it.
So the question is: Can we expect a tag in the future to stop disguise when a passenger exits from the disguised vehicle like the Japanese transport from RA3? QUICK_EDIT
Alex, you did an amazing job again, thank you! The most long-awaited feature for me was the unit transformation combined with veterancy.
Now I have a question about vehicles (IFV in this case).
I've made a change on the IFV, now it can disguise itself but not automatically like Mirage Tanks do. To achieve this, it has to have a spy in it, and its weapon changes to TankMakeupKit. If it's done, you'll have an attack cursor on any tree or rock, and you can disguise the IFV manually when you click on the target.
We know that if a disguised vehicle starts moving, the disguise will stop. Not like when I deploy the IFV, it remains disguised even if the spy isn't in it.
So the question is: Can we expect a tag in the future to stop disguise when a passenger exits from the disguised vehicle like the Japanese transport from RA3?
I think the default behavior is better Effectively turning the IFV into an AA mirage tank
If the IFV loses disguise on unload, it will be less useful (maybe not useful at all, a fake tree cannot attack is no different than a real tree) _________________
Alex, you did an amazing job again, thank you! The most long-awaited feature for me was the unit transformation combined with veterancy.
Now I have a question about vehicles (IFV in this case).
I've made a change on the IFV, now it can disguise itself but not automatically like Mirage Tanks do. To achieve this, it has to have a spy in it, and its weapon changes to TankMakeupKit. If it's done, you'll have an attack cursor on any tree or rock, and you can disguise the IFV manually when you click on the target.
We know that if a disguised vehicle starts moving, the disguise will stop. Not like when I deploy the IFV, it remains disguised even if the spy isn't in it.
So the question is: Can we expect a tag in the future to stop disguise when a passenger exits from the disguised vehicle like the Japanese transport from RA3?
Thanks! I can try to look into this for the next version. There's more in this area that could benefit from an overhaul anyhow.
cxtian39 wrote:
Lightning Storm with different SW.Group values still can't activate at the same time
What gave you the impression that it does? _________________ QUICK_EDIT
Feature Request:
Swimming amphibious infantries (Seal, Tanya, etc) to be able to enter from water in amphibious and other water-only naval vehicles that have 'Passengers' string added to their rules code, and of course to be able to exit from them also in water.
Bug Report:
If the player with mind-control capture unit that is VEHICLE THIEF, and put it in NightHawk helicopter transport, after exiting from it captured VEHICLE THIEF is still movable and under control by the player but visual mind-control link doesn't exist anymore and when the VEHICLE THIEF is put in some vehicle that vehicle is not captured by the player who mind-controls the VEHICLE THIEF, but it is captured from the original owner of the VEHICLE THIEF. QUICK_EDIT
Swimming amphibious infantries (Seal, Tanya, etc) to be able to enter from water in amphibious and other water-only naval vehicles that have 'Passengers' string added to their rules code, and of course to be able to exit from them also in water.
Currently (I think) some people use Infantry as InitialPayload whose MovementZone is "invalid" as Passengers for Amphibious Transports that have multiple weapons.
(Infantry in InitialPayload have MovementZone and SpeedType set so they can't pass land, only water which in turn no transport can currently unload on)
Your feature request would break that exploit.
Unless there's a way to tell the game explicitly what InfantryTypes are not allowed to be ejected even when their MovementZone and SpeedType conditions are met... QUICK_EDIT
There's Ares feature that disables passenger unloading altogether so relying on exploits like that wouldn't be necessary in the first place. _________________ QUICK_EDIT
You are right about braking logic with Amphibious Transports, but when we are talking about water-only / naval-only vehicles, only SEAL and Tanya as infantries who are amphibious from realistic point of view can enter in submarine or in ship and unload from them.
So if there is logic this units can enter in water/navy only vehicles and nothing will brake.
Actually will be quite fun if jumpjet infantry can land on ship and when player unload the ship, jumpjet to take off from the ship.
Also this passengers similar as pilot and passengers case from airplanes to be able to be saved (get-out) from destroyed submarine/ship or in the case with jumpjet, that unit(s) to take off from destroyed ship. QUICK_EDIT
Lightning Storm with different SW.Group values still can't activate at the same time
What gave you the impression that it does?
Ares Documentation wrote:
[SuperWeapon]?SW.Group= (integer)
Distinguish multiple super weapons of the same type. Defaults to 0.
This is kind of vague. Without further information it's hard to interpret what it actually does. So I thought it may distinguish different lightning storms. _________________
Would it be possible to make a unit "unmovable"?
For example:
-Unmovable=true
or
-PreventMoveCommand=true
-> Changes cursor to select cursor instead of move cursor, thus you can't give move commands.
I know it sounds weird, but combining this with the convert.deploy, allows you to bypass the issue with units not being able to deploy on slopes.
And bypass other issues that simpledeployer gives.
Currently, without this, the unit tries to move towards the position you clicked whilst deployed, hence it will move 1pixel and deploy upon deploy command towards where you told it to move by accident. QUICK_EDIT
I'm just throwing this out there, but wouldn't Speed=0 work? _________________ "Don't beg for things; Do it yourself or you'll never get anything." QUICK_EDIT
I'm just throwing this out there, but wouldn't Speed=0 work?
Nope, this still allows you to give movement orders to the units, but since they cannot properly move they instead get 'stuck' in trying to move so things like (un)deploying become impossible afterwards.
There's no workaround for this that does not come with a number of issues. _________________ QUICK_EDIT
I'm just throwing this out there, but wouldn't Speed=0 work?
Nope, this still allows you to give movement orders to the units, but since they cannot properly move they instead get 'stuck' in trying to move so things like (un)deploying become impossible afterwards.
There's no workaround for this that does not come with a number of issues.
Spawned=yes + Speed=0 work.
Can't move and can't take move command. _________________
Units might get stuck if pathfinding sees the deployed unit as a blocked cell that could be pushed out of the way. I'm not sure what the best solution would be. Allowing to deploy a unit into a building even on slopes might open a can of worms.
cxtian39 wrote:
AlexB wrote:
cxtian39 wrote:
Lightning Storm with different SW.Group values still can't activate at the same time
What gave you the impression that it does?
Ares Documentation wrote:
[SuperWeapon]?SW.Group= (integer)
Distinguish multiple super weapons of the same type. Defaults to 0.
This is kind of vague. Without further information it's hard to interpret what it actually does. So I thought it may distinguish different lightning storms.
Fair enough. Sorry for my condescending response. I concur that SW.Group is badly documented and I'll rework it. _________________ QUICK_EDIT
I don't like tags that clearly could have meaning for other SWs (equivalent meaning, not just similar) have special names. For example, DropPod.Veterancy for example really should have been SW.Veterancy, because UnitDelivery and ParaDrops could use the same thing for their units also.
SW.Group has such generic name, because it might apply to the Chronosphere and the related team script analoguously to the Iron Curtain, and once I find the time, I'll expand this, too. And who knows what other team scripts might use it later on. _________________ QUICK_EDIT
Oof, how did I not know this.
Could you perhaps provide a link so I can read up on it?
I did a quick google search, but I didn't really see much of interest.
Thanks in advance. QUICK_EDIT
Oof, how did I not know this.
Could you perhaps provide a link so I can read up on it?
I did a quick google search, but I didn't really see much of interest.
Thanks in advance.
https://ppmforums.com/viewtopic.php?p=573857
Just come out and it's still freshly hot!
Request facings for AE just like AlphaImage
Request Infantry-like AE: [Animation]>Sequence=
Request SHP-based Unit-like AE: [Animation]>WalkFrames=, etc
They should act as if they are part of the attached infantry/unit, ie. the infantry attacks, the AE plays its attacking sequence too. _________________
How do you refer to AEs they don’t have names or anything referrable.
I think AEs deserve their own section and an AttachEffectTypes list. _________________
Then another good addition might be AttachEffect.Type=a unique ID so you can group AE's together, as right now its just the warhead that delivered it AFAIK.
Then you could have AttachEffect.RemoveTypes=list of type IDs. QUICK_EDIT
That contradicts negative AEs. We do want the two same AEs with pos and neg duration so that they can weaken each other like Psychedelic and EMP.
The dilemma is, if they have different duration, they have to be different AE, haha?
The old structure can't work this out I guess.
Please rewrite the whole AE system _________________
That contradicts negative AEs. We do want the two same AEs with pos and neg duration so that they can weaken each other like Psychedelic and EMP.
The dilemma is, if they have different duration, they have to be different AE, haha?
Uh what? Why? I don't understand how it contradicts "negative AEs". As for the duration, the solution is simple: if its cumulative add them together, if not then set the value to the longest duration, as is done with other time based effects. QUICK_EDIT
That contradicts negative AEs. We do want the two same AEs with pos and neg duration so that they can weaken each other like Psychedelic and EMP.
The dilemma is, if they have different duration, they have to be different AE, haha?
Uh what? Why? I don't understand how it contradicts "negative AEs". As for the duration, the solution is simple: if its cumulative add them together, if not then set the value to the longest duration, as is done with other time based effects.
Duration is unique for every AE types if it's unique. You can't do 2 warheads with the same type of AE but different duration.
I still don't remotely understand your point. Of course you could do different durations if they're the same type. That's how EMP, psychedelic, sonar, weapons disabling etc works. QUICK_EDIT
But theres no reason why that would have to be the case. That's why I suggested a type tag, so you could link AEs together for the purpose of removal or not overlapping. I don't know why this is hard to understand lol. The other special effects already do it. QUICK_EDIT
I also have another question, would it perhaps be possible to expand on the Saboteur logic?
I don't want the saboteur to actually destroy the building upon entering. I basically want it to fire a weapon once after an x period of time.(after entering the building)
For example:
[TechnoType]
Saboteur=yes
Saboteur.Weapon=
Another suggestion would be adding an AIAdjacencyBonus=
Which is similar to the AINavalYardAdacency, but applicable to all buildings.
Also, some expansion on the overload count & overload damage would be very useful. If it were possible to make it a non-public tag so we can have different values for different units, it would be great. QUICK_EDIT
Would be most useful for AnimToInfantry transformations that are meant to be positive for the player. Infantry screaming in agony as they're being given better equipment sends the wrong message. QUICK_EDIT
I support that.
Also, it would be wise if tag could be added to infantry type to prevent it from changing direction randomly. Infantry do that always, but we have some ,,special" infantry which are not meant to be regular troops (driving boats, bikes, aliens, robots/drones etc...) _________________
AI picks power plants respecting the prerequisites of the structure (fix by FS-21)
It seems AIs would still build the basic power plants regardless of the prerequisites. Is this intentional so that the AIs always have at least one type of power plant to build? Last edited by Fortranm on Sun Nov 18, 2018 4:49 pm; edited 1 time in total QUICK_EDIT
AI picks power plants respecting the prerequisites of the structure (fix by FS-21)
It seems AIs would still build the basic power plants regardless of the prerequisites. Is this intentional so that the AIs always have at least one type of power plant to build?
AI uses the first building for that side in BuildPower (or its Ares equivalent) to build its first powerplant. The bug was regarding prereq of NodAdvancedPower that is Sov Nuke Reactor in few Ares versions, that is fixed now. QUICK_EDIT
Hello to all! I am a new user. Question to Alex. What is the possibility that you will restore the weed system with the subsequent use of super weapons? QUICK_EDIT
Animations on building structures:
https://ppmforums.com/viewtopic.php?t=45277
(Welding sparks, scaffolding, workers, etc. ; useful for vainilla, required for RA3-like or Generals-like construction system)
Another suggestion:
Making unit-specific Grinders.
For example, a Grinder with a list of which units it can grind.
For flavor and usability cases this is very important. For example you could have a "cow farm" that regularly spawns cows. Then you could have a Slaughterhouse that can grind cows into resources... but should not grind tanks or infantry!
In a more exotic case, you could have aliens mind-controlling human civilians to turn into food. Again, they should not be able to grind vehicles or themselves...
Etc. etc., this would lend itself for very interesting mission mechanics.
"Grinder.grinds=unit1,unit2,unit3..."
Other unit types would not get the enter cursor on the grinder.
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