Project Perfect Mod Forums
:: Home :: Get Hosted :: PPM FAQ :: Forum FAQ :: Privacy Policy :: Search :: Memberlist :: Usergroups :: Register :: Profile :: Log in to check your private messages :: Log in ::


The time now is Thu Mar 28, 2024 9:35 pm
All times are UTC + 0
Ideas & suggestions
Moderators: Ares Support Team at PPM, Global Moderators, Red Alert 2 Moderators
Post new topic   Reply to topic Page 15 of 16 [800 Posts] Mark the topic unread ::  View previous topic :: View next topic
Goto page: Previous 1, 2, 3, ..., 13, 14, 15, 16 Next
Author Message
NimoStar
Commander


Joined: 07 Nov 2012
Location: Buenos Aires

PostPosted: Sun Oct 13, 2019 11:56 pm    Post subject: Reply with quote  Mark this post and the followings unread

The gattling "workaround" doesn't allow an actual continous chargeanim, it is also pretty random and doesn't work as intended in many regards such as resetting the charge when you change targets.

Gattling logic is also pretty complex, not perfeclty documented and as such it demands a big chunk of time and testing for such a simple feature.

It's not really making a new logic just enabling the already existing one for buildings into it's use on units.

_________________

Back to top
View user's profile Send private message Visit poster's website
djohe
Cyborg Informer


Joined: 07 May 2006
Location: Sweden, Gothenburg

PostPosted: Mon Oct 14, 2019 5:16 am    Post subject: Reply with quote  Mark this post and the followings unread

NimoStar wrote:
It's not really making a new logic just enabling the already existing one for buildings into it's use on units.
In many cases it is not as simple as you think it is not to mention buildings work with shp's while vehicles use voxels normally and IsChargeTurret= with voxels do not really work outside of that logic. I know this example is not WW's RA2 but in OpenRA you can not simply use defence Tesla Coil's AttackTesla logic on vehicles without getting problems even tho one would think it would work perfectly fine. You are not alone in wanting building charge logic on vehicles and put voxels like this to good use https://ppmforums.com/viewtopic.php?t=22755 or just have a sound effect for charging.

So yeah summary: Many times things like this is harder than you make it out to be.

PS: Prism Forwarding logic for vehicles is in a even worse situation, people including me want it but it is much harder than it looks (for people that just throws suggestions/ideas out in threads like this without thinking about the difficulty of it) to implent/code. From chat with AlexB:
<AlexB> djohe: the logic would need to be reimplemented completely
<AlexB> plus the new special cases when units move out of range

Back to top
View user's profile Send private message
NimoStar
Commander


Joined: 07 Nov 2012
Location: Buenos Aires

PostPosted: Mon Oct 14, 2019 5:50 am    Post subject: Reply with quote  Mark this post and the followings unread

I know prism forwarding isn't simple at all. I said that was a kind of random idea, though it would certainly be neat (tesla/prism/laser chains, etc.)

So, let's not comnfuse things. Prism forwarding may be hard, but charging logic isn't that difficult.

But on the charge logic, it is not necessary the first implementation needs to include the voxel aspect. You could use a SHP chargeanim that works just as a muzzle anim.

Though, you are right in that making it so we can use the charging turret voxels correctly would be cool. Gattling workaround doesn't allow that that I know of.

Basically, the only "rewriting" for a basic implementation would be to make the chargeanim behave as a muzzle anim (IE move with the unit, respect FLH and have directionality)

_________________

Back to top
View user's profile Send private message Visit poster's website
Mig Eater
Defense Minister


Joined: 13 Nov 2003
Location: Eindhoven

PostPosted: Mon Oct 14, 2019 10:41 am    Post subject: Reply with quote  Mark this post and the followings unread

A pre-firing muzzle anim can again easily be done with gattling logic too. Your complaints that it's to hard & takes to much time seem really lazy...

*in grumpy old man voice* Back in my day when there was no Npatch or Ares we would spend days, weeks or even months slowly working though trial & error seeing what different logics & tags could be combined to create new effects. Now days too many people just cant be bothered to try stuff out for themselves & just ask Alex to add it to Ares >.>

_________________



Back to top
View user's profile Send private message Visit poster's website ModDB Profile ID YouTube User URL Facebook Profile URL Twitter Channel URL
djohe
Cyborg Informer


Joined: 07 May 2006
Location: Sweden, Gothenburg

PostPosted: Mon Oct 14, 2019 11:32 am    Post subject: Reply with quote  Mark this post and the followings unread

NimoStar wrote:
Basically, the only "rewriting" for a basic implementation would be to make the chargeanim behave as a muzzle anim (IE move with the unit, respect FLH and have directionality)
Mig Eater wrote:
A pre-firing muzzle anim can again easily be done with gattling logic too. Your complaints that it's to hard & takes to much time seem really lazy...
I fully agree with that this sounds like a perfect case of just using IsGattling=yes logic for this even tho I have not even tried it myself as from what I know IsGattling logic can do everthing you just said (directional muzzle anim, respect FLH, move with unit)
Also IsGattling logic also seems to have TurretCount but from what I can tell it has no effect if set above 1 sadly (will crash game at 0)(tested by copying prism tank from ra2.mix and renaming from sref to ytnk for body and turrets), it would be nice if that could be made functional for voxel turret changing for like Prism Tank / https://ppmforums.com/viewtopic.php?t=22755 with delayed charge instead of precharge.

Back to top
View user's profile Send private message
cxtian39
Commander


Joined: 11 Feb 2016

PostPosted: Mon Oct 14, 2019 4:34 pm    Post subject: Reply with quote  Mark this post and the followings unread

Making FireUp= work for vehicles might be a quick one to do or not

_________________

Back to top
View user's profile Send private message Skype Account
Mig Eater
Defense Minister


Joined: 13 Nov 2003
Location: Eindhoven

PostPosted: Mon Oct 14, 2019 5:43 pm    Post subject: Reply with quote  Mark this post and the followings unread

FireUp is connected to infantry sequences so probably not something that could easily be modified for use on vehicles.

_________________



Back to top
View user's profile Send private message Visit poster's website ModDB Profile ID YouTube User URL Facebook Profile URL Twitter Channel URL
cxtian39
Commander


Joined: 11 Feb 2016

PostPosted: Tue Oct 15, 2019 2:31 am    Post subject: Reply with quote  Mark this post and the followings unread

Could be a simpler version that doesn’t look into any sequences but just delay firing without interruption/reset of the firing frames.

Also it would be nice to have muzzle anim rotate with the firer.

_________________

Back to top
View user's profile Send private message Skype Account
NimoStar
Commander


Joined: 07 Nov 2012
Location: Buenos Aires

PostPosted: Tue Oct 22, 2019 9:15 am    Post subject: Reply with quote  Mark this post and the followings unread

Migeater, as you should know I am not a "new" modder. I have used gattling logic many times, but the fact is, there is no way to making Gattling logic behave 100% predictability, since it is constantly retargeting.

In the Tesla Tower example, a single charge is for a single fire. Retargeting makes the pre-firing anim reset.

In Gattling logic, the gattling state is preserved even when changing targets.

There is also the issue of air weapon since last time I checked Gattling integrates all weapon systems. Rangefinding. Problems with virtual weapons, verses and warheads. Lag.

It simply isn't the same bahaviour, and there is no way to replicate the actual charge fire behaviour, period.

A workaround is not a solution, and is actually the "lazy" way of things. Why does OpenRA exist? Heck, why does Ares even exist? Just use workarounds for everything. There is surely some convoluted and half-functional way to do anything...

Stealth detection? LOL, just use constant area 1 damage to reveal enemies!
Create units superweapon? Easy, it's a paradrop with invisible plane and parachute.
Make structures superweapon? Why? They are paradropped invisible vehicles that auto-deploy with deploytofire and a virtual weapon!
And if you are the developer: Why even code infantry? They can be SHP vehicles with armor "none"! That "sequence" stuff sounds very hard! Use a workaround!


Or as I have seen some people say, why even mod. Just make custom maps so they can be played online with the base game. Since that's totally the same thing.

_________________

Back to top
View user's profile Send private message Visit poster's website
Mig Eater
Defense Minister


Joined: 13 Nov 2003
Location: Eindhoven

PostPosted: Tue Oct 22, 2019 10:01 am    Post subject: Reply with quote  Mark this post and the followings unread

Your argument is based on semantical personal opinion & nothing I say is going to change it, so I'm not going to bother dragging this on any further.

I do however find your insinuation that workarounds are "lazy" an insult to all the pioneers of this community, that as I mentioned before spent countless days trawling through the game's files in an effort to push the boundary of what is possible. If it wasn't for their work there would be no foundation of knowledge on which Ares or OpenRA could have be built upon.

_________________



Back to top
View user's profile Send private message Visit poster's website ModDB Profile ID YouTube User URL Facebook Profile URL Twitter Channel URL
4StarGeneral
General


Joined: 14 Sep 2006
Location: Limbo

PostPosted: Tue Oct 22, 2019 6:50 pm    Post subject: Reply with quote  Mark this post and the followings unread

Workarounds are only lazy when you have the skill and know-how to do it yourself. Considering very few people qualify in that regard, workarounds are not "lazy" and are justifiable use of pulling as much out of the code as we can without being able to change it.

What is lazy is dumping everything onto one person to do it all for you and complaining about workarounds that could make that person's life easier, i.e. Ares.

_________________
"Don't beg for things; Do it yourself or you'll never get anything."

Back to top
View user's profile Send private message Send e-mail YouTube User URL
RIAKTOR
Disk Thrower


Joined: 23 Nov 2013

PostPosted: Thu Nov 07, 2019 8:15 am    Post subject: Reply with quote  Mark this post and the followings unread

I suggest more than one type of money/resource. Like in TS you have tiberium and veinhole monster.

And flag for vehicles that requires operator. Without operator or other passangers this vehicle can be hijacked by enemy passangers. Like bunkers can be occupied by enemies.

Back to top
View user's profile Send private message
cxtian39
Commander


Joined: 11 Feb 2016

PostPosted: Wed Nov 13, 2019 10:50 pm    Post subject: Reply with quote  Mark this post and the followings unread

As AITargeting got expanded in 3.0, would be nice to add more targeting mode like AITargeting=Designator, that will fire at its one of its own designator.

_________________

Back to top
View user's profile Send private message Skype Account
4StarGeneral
General


Joined: 14 Sep 2006
Location: Limbo

PostPosted: Thu Nov 14, 2019 12:26 am    Post subject: Reply with quote  Mark this post and the followings unread

RIAKTOR wrote:
I suggest more than one type of money/resource. Like in TS you have tiberium and veinhole monster.

And flag for vehicles that requires operator. Without operator or other passangers this vehicle can be hijacked by enemy passangers. Like bunkers can be occupied by enemies.


I'd like an un-hardcoding of resources in general so you could be able to power as money and vice versa and make veinhole copies, but it's one of the most hardcoded things in the game, so it sounds pretty daunting to take on.

Operator logic exists though?

_________________
"Don't beg for things; Do it yourself or you'll never get anything."

Back to top
View user's profile Send private message Send e-mail YouTube User URL
Mig Eater
Defense Minister


Joined: 13 Nov 2003
Location: Eindhoven

PostPosted: Thu Nov 14, 2019 3:30 am    Post subject: Reply with quote  Mark this post and the followings unread

Currently vehicles using operator can only be "driven" by infantry from the same side/player as the vehicle. He wants the ability for other sides/enemies to be able to capture empty operator vehicles.

You could make the driver infantry also a hijacker, but you'd need to add VehicleThief.Allowed=no to every unit that doesn't require an operator to stop them being able to capture any unit though.

_________________



Back to top
View user's profile Send private message Visit poster's website ModDB Profile ID YouTube User URL Facebook Profile URL Twitter Channel URL
PussyPus
Commander


Joined: 14 Jul 2015
Location: Egypt

PostPosted: Sat Nov 16, 2019 5:21 pm    Post subject: Reply with quote  Mark this post and the followings unread

Suggestion: Expand Spy Behavior, examples like:
-Making a specific infantry with 'Spy=yes' have different behaviors from another infantry with 'Spy=yes'.

_________________
If you are a MetalHead (Heavy Metal Fan) and don't want to be a metalhead, Just remove your metal ball from your head. �:p .

Back to top
View user's profile Send private message ModDB Profile ID Skype Account
TAK02
General


Joined: 28 Jun 2015
Location: It was Damascus.

PostPosted: Sat Nov 16, 2019 5:24 pm    Post subject: Reply with quote  Mark this post and the followings unread

PussyPus wrote:
Suggestion: Expand Spy Behavior, examples like:
-Making a specific infantry with 'Spy=yes' have different behaviors from another infantry with 'Spy=yes'.

What differences should there be?

Back to top
View user's profile Send private message Send e-mail Visit poster's website ModDB Profile ID YouTube User URL Twitter Channel URL Skype Account
mtkii
Medic


Joined: 26 Mar 2005

PostPosted: Sat Nov 16, 2019 5:51 pm    Post subject: Reply with quote  Mark this post and the followings unread

It has probably been proposed before, but two idea :

1. Make FireOnce=yes applicable to vehicle, not just infantry. Also, it should work on infantry inside a OpenTopped vehicle.

2. I've seen it requested before, but having BalloonHover=yes vehicle be able to turn and face their target would be incredible.

Back to top
View user's profile Send private message Skype Account
TAK02
General


Joined: 28 Jun 2015
Location: It was Damascus.

PostPosted: Mon Nov 18, 2019 7:25 am    Post subject: Reply with quote  Mark this post and the followings unread

Idea: allow Passengers to have a specific value that allows for infinite space within.

This idea is for Chronoprisons that "devour" everything.

Like the "World Gobbler".

_________________
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. #Tongue

Back to top
View user's profile Send private message Send e-mail Visit poster's website ModDB Profile ID YouTube User URL Twitter Channel URL Skype Account
PussyPus
Commander


Joined: 14 Jul 2015
Location: Egypt

PostPosted: Mon Nov 18, 2019 3:22 pm    Post subject: Reply with quote  Mark this post and the followings unread

TAK02 wrote:
PussyPus wrote:
Suggestion: Expand Spy Behavior, examples like:
-Making a specific infantry with 'Spy=yes' have different behaviors from another infantry with 'Spy=yes'.

What differences should there be?

Example: An Allied Spy who infiltrates, for example, a Superweapon, resets its timer, but, if a different infantry with 'Spy=yes' like, for example, a Soviet Spy or Thief, doesn't reset its timer, but instead, steals its 'Support Power', However, right now, you can only edit the Superweapon itself, so any Spy in the game will have the exact same behavior.

_________________
If you are a MetalHead (Heavy Metal Fan) and don't want to be a metalhead, Just remove your metal ball from your head. �:p .

Back to top
View user's profile Send private message ModDB Profile ID Skype Account
TAK02
General


Joined: 28 Jun 2015
Location: It was Damascus.

PostPosted: Mon Nov 18, 2019 4:36 pm    Post subject: Reply with quote  Mark this post and the followings unread

Ah, so basically, you want the Spy-Effects to be moddable on a per-spy basis rather than or in addition to per-building basis.

Sounds simple enough...

_________________
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. #Tongue

Back to top
View user's profile Send private message Send e-mail Visit poster's website ModDB Profile ID YouTube User URL Twitter Channel URL Skype Account
zhaihs
Civilian


Joined: 29 Jul 2019

PostPosted: Wed Nov 20, 2019 10:24 am    Post subject: Reply with quote  Mark this post and the followings unread

a dream:

[NEWSPY]
spy=yes  ;Original Yuri's Revenge spy
Spy.Custom=yes ;SpyEffect.Custom

Back to top
View user's profile Send private message
PussyPus
Commander


Joined: 14 Jul 2015
Location: Egypt

PostPosted: Thu Nov 21, 2019 9:27 pm    Post subject: Reply with quote  Mark this post and the followings unread

zhaihs wrote:
a dream:

[NEWSPY]
spy=yes  ;Original Yuri's Revenge spy
Spy.Custom=yes ;SpyEffect.Custom

Oh, yes, something like that. Very Happy

_________________
If you are a MetalHead (Heavy Metal Fan) and don't want to be a metalhead, Just remove your metal ball from your head. �:p .

Back to top
View user's profile Send private message ModDB Profile ID Skype Account
LEGO
Vehicle Driver


Joined: 30 Oct 2008

PostPosted: Tue Nov 26, 2019 9:59 am    Post subject: Reply with quote  Mark this post and the followings unread

Please consider expand AttachEffect to include effects on:
Unit’s Reload rate (for ammo limited units, of course) , range of weapons, unit GuardRange, and unit sight.
And, it would be nice if AE can optionally affect units in an OpenTop transport.

Back to top
View user's profile Send private message
KALAPS S8
Grenadier


Joined: 02 Aug 2012

PostPosted: Wed Nov 27, 2019 12:40 pm    Post subject: Reply with quote  Mark this post and the followings unread

Make it possible shift InitialPayload for Promote.VeteranType (instead transfer passanger)

Back to top
View user's profile Send private message
PussyPus
Commander


Joined: 14 Jul 2015
Location: Egypt

PostPosted: Sun Dec 01, 2019 1:47 pm    Post subject: Reply with quote  Mark this post and the followings unread

Another Suggestion: Silent Killer
A flag that is added to a Weapon, What it should do is when you kill an InfantryType with any object with Primary and/or Secondary, The killed InfantryType won't play the DieSound, here is an example:
Code:
[SNIPE]
Primary=AWP

[AWP]
InfantrySilentKiller=yes

_________________
If you are a MetalHead (Heavy Metal Fan) and don't want to be a metalhead, Just remove your metal ball from your head. �:p .

Back to top
View user's profile Send private message ModDB Profile ID Skype Account
AlexB
Commander


Joined: 31 May 2010
Location: Germany

PostPosted: Sun Dec 01, 2019 7:36 pm    Post subject: Reply with quote  Mark this post and the followings unread

PussyPus: Have a look at Override DieSound and DieVoice per warhead.

cxtian39: I'm planning to add a designator targeting mode for SWs, but it's surprisingly difficult to code efficiently.

Regarding custom custom spy effects: Also only doable in a very inefficient way, kinda like defining paradrops or ArmorTypes. Either each Infantry Type would need to load a new tag for every existing BuildingType like SpyEffect.GACNST.ResetRadar=yes or something similar, or each BuildingType would need to load all those tags for each InfantryType, like SpyEffect.NEWSPY.ResetRadar=yes. In any case, it would read thousands of tags, whose values need to be stored. And all this for a rather minor addition.

_________________

Back to top
View user's profile Send private message
matt7785
Civilian


Joined: 20 Jul 2007

PostPosted: Tue Dec 03, 2019 2:21 am    Post subject: Reply with quote  Mark this post and the followings unread

AlexB: I have a request for a small change to the Ares code directly and wanted to post here to see if there were any issues before submitting a pull request on github. In https://github.com/Ares-Developers/YRpp/blob/master/AITriggerTypeClass.h I want to change lines 125 - 145 from

Code:
sprintf_s(buffer, size, "%s = %s,%s,%s,%d,%d,%s,%s,%lf,%lf,%lf,%u,%d,%d,%u,%s,%u,%u,%u\n",
         this->ID,
         this->Name,
         Team1Name,
         HouseName,
         this->TechLevel,
         this->ConditionType,
         ConditionName,
         ConditionString,
         this->Weight_Current,
         this->Weight_Minimum,
         this->Weight_Maximum,
         this->IsForSkirmish,
         0,
         this->SideIndex,
         this->IsForBaseDefense,
         Team2Name,
         this->Enabled_Easy,
         this->Enabled_Normal,
         this->Enabled_Hard
      );


To:

Code:
sprintf_s(buffer, size, "%s = %s,%s,%s,%d,%d,%s,%s,%lf,%lf,%lf,%u,%d,%d,%u,%s,%u,%u,%u,%d,%d,%d\n",
         this->ID,
         this->Name,
         Team1Name,
         HouseName,
         this->TechLevel,
         this->ConditionType,
         ConditionName,
         ConditionString,
         this->Weight_Current,
         this->Weight_Minimum,
         this->Weight_Maximum,
         this->IsForSkirmish,
         0,
         this->SideIndex,
         this->IsForBaseDefense,
         Team2Name,
         this->Enabled_Easy,
         this->Enabled_Normal,
         this->Enabled_Hard,
         this->TimesExecuted,
         this->TimesCompleted,
         this->unknown_10C
      );


I believe this change will cause the variables 'TimesExecuted', 'TimesCompleted', and 'unknown_10C', to be written to the debug.log file when the 'Type Data Dump' keyboard command is pressed. The reason I want to do this is because I'm working on a program to keep the updated trigger weight probabilities from one game to the next and I want more data about how they are calculated.

I'd also like Ares to automatically dump this data to debug.log at the end of each game. I can find the code to do that too if you want.

Let me know if this code causes problems or doesn't work how I think it does, I haven't been able to compile it and test it because I don't have the Aresbuilder program.

Back to top
View user's profile Send private message
DaubertMotion
Soldier


Joined: 17 Dec 2015

PostPosted: Sat Dec 07, 2019 2:54 am    Post subject: Reply with quote  Mark this post and the followings unread

Is mirage logic limited to vehicles?  Suppose I wanted a pillbox that disguised as a tree - can this be done?

Back to top
View user's profile Send private message
WoodleMyNoodle
Cyborg Soldier


Joined: 09 Apr 2018

PostPosted: Tue Dec 10, 2019 2:27 pm    Post subject: Reply with quote  Mark this post and the followings unread

A few things I'd like of which some have already been requested already:
1. A warhead tag that allows you to apply certain tags to a unit for a limited amount of time.

Example:
- Warhead.ApplyTag=FraidyCat
- Warhead.ApplyTag=ImmuneToPsionics
- Warhead.ApplyDuration=100

2. Critcal hit chance
3. Unit & Building shields
4. Tag to apply the warhead every single time a parasite does damage. (Allowing it to apply an attacheffect / EMP with every hit)
5. Warhead tag to make it able to remove attacheffects
6. Warhead tag to make it immune to attacheffect removers
7. Tag for warheads to have the radar jamming feature + Customizable durations
8. Tag to make a unit passive heal its passengers.
9. Excluding units from tech repair/heal
10. Drain weapons not be necessarily vertical

Back to top
View user's profile Send private message
PussyPus
Commander


Joined: 14 Jul 2015
Location: Egypt

PostPosted: Tue Dec 10, 2019 5:15 pm    Post subject: Reply with quote  Mark this post and the followings unread

WoodleMyNoodle wrote:
A few things I'd like of which some have already been requested already:
1. A warhead tag that allows you to apply certain tags to a unit for a limited amount of time.

Example:
- Warhead.ApplyTag=FraidyCat
- Warhead.ApplyTag=ImmuneToPsionics
- Warhead.ApplyDuration=100

2. Critcal hit chance
3. Unit & Building shields
4. Tag to apply the warhead every single time a parasite does damage. (Allowing it to apply an attacheffect / EMP with every hit)
5. Warhead tag to make it able to remove attacheffects
6. Warhead tag to make it immune to attacheffect removers
7. Tag for warheads to have the radar jamming feature + Customizable durations
8. Tag to make a unit passive heal its passengers.
9. Excluding units from tech repair/heal
10. Drain weapons not be necessarily vertical

All of these requests aren't as bad as i think...
A warhead flag that allows a unit to cause another unit/structure to apply some certain flags, Not a bad idea, but, you mean something like this?

[ChaosWH]
AttachFlag.Cond02=ImmuneToPsionics

[SAFlame]
AttachFlag.Cond04=FraidyCat

[RepairMechanical]
AttachFlag.Cond07=UnitsGainSelfHeal

AttachFlag.Cond##= Where (##) are numbers between 0 to 32 (depends on how many boolean flags work in-game), Conditions that is added to the flag must be a flag that have boolean (yes or no/true or false).

Example of condition flags are as follows:
Spoiler (click here to read it):
0 - ImmuneToRadiation
3 - Immune
6 - NotHuman
12 - Spy
15 - ProtectedDriver
16 - OmniCrusher
30 - Cloakable
32 - Bounty

So... Is it possible or not?

_________________
If you are a MetalHead (Heavy Metal Fan) and don't want to be a metalhead, Just remove your metal ball from your head. �:p .

Back to top
View user's profile Send private message ModDB Profile ID Skype Account
WoodleMyNoodle
Cyborg Soldier


Joined: 09 Apr 2018

PostPosted: Tue Dec 10, 2019 5:29 pm    Post subject: Reply with quote  Mark this post and the followings unread

It would definitely be nice to have a timer attached to it so there's more room to play with it.

I saw that the Chinese version of Ares was able to make units immune to psionics for a limited amount of time, hence why I requested it here.
Should be doable.

Back to top
View user's profile Send private message
PussyPus
Commander


Joined: 14 Jul 2015
Location: Egypt

PostPosted: Tue Dec 10, 2019 7:02 pm    Post subject: Reply with quote  Mark this post and the followings unread

What about the multi-turret placement logic from C&C 3? Where Nod owns 3 laser turrets connected with the main hub/core, Is it possible?

_________________
If you are a MetalHead (Heavy Metal Fan) and don't want to be a metalhead, Just remove your metal ball from your head. �:p .

Back to top
View user's profile Send private message ModDB Profile ID Skype Account
Mig Eater
Defense Minister


Joined: 13 Nov 2003
Location: Eindhoven

PostPosted: Wed Dec 11, 2019 12:44 am    Post subject: Reply with quote  Mark this post and the followings unread

WoodleMyNoodle wrote:
2. Critcal hit chance


You can already do this by making weapons slightly inaccurate with a low BallisticScatter along with a small CellSpread & PercentAtMax. Doing this will randomize the amount of damage a unit will take. Along with this you can also attach an airburst weapon with a 0 spread, which means that the extra airburst stage will only do damage if it's a direct hit.

I use this in my mod to make artillery "stun" units with an AttachEffect if they get a direct hit.

_________________



Back to top
View user's profile Send private message Visit poster's website ModDB Profile ID YouTube User URL Facebook Profile URL Twitter Channel URL
wardeathfun
Commander


Joined: 01 Feb 2007
Location: Las Vegas, Nevada, USA

PostPosted: Wed Dec 11, 2019 12:51 am    Post subject: Reply with quote  Mark this post and the followings unread

Am I crazy by the way when I say an older version of Ares gave us the ability to make barracks also act as cloning vats? I could have sworn I got it working last time I was modding and was shocked it didn't work. I was surprised to learn there was a bug on it xD

Back to top
View user's profile Send private message Send e-mail Visit poster's website
m7
Commander


Joined: 17 Apr 2009

PostPosted: Wed Dec 11, 2019 3:47 am    Post subject: Reply with quote  Mark this post and the followings unread

Quote:
2. Critcal hit chance


In addition to Mig's method, you could also use EMEffect=yes on the weapon's warhead and attach extra damage to particular animations listed on AnimList to give random bursts of additional damage.

Back to top
View user's profile Send private message
cxtian39
Commander


Joined: 11 Feb 2016

PostPosted: Wed Dec 11, 2019 4:33 am    Post subject: Reply with quote  Mark this post and the followings unread

m7 wrote:
Quote:
2. Critcal hit chance


In addition to Mig's method, you could also use EMEffect=yes on the weapon's warhead and attach extra damage to particular animations listed on AnimList to give random bursts of additional damage.
That’s not the perfect approach as it potentially mess up experience. A better approach should be AE on a unit that launches a weapon with EMEffect, and those random animations give random AE that has different Firepower/ROF/Armor/etc multipliers. This approach gives experience.

_________________

Back to top
View user's profile Send private message Skype Account
WoodleMyNoodle
Cyborg Soldier


Joined: 09 Apr 2018

PostPosted: Thu Dec 12, 2019 4:18 am    Post subject: Reply with quote  Mark this post and the followings unread

I was also curious if Permanently Mindcontrolled units could also give the Mindcontroller experience using Experience.MindControlSelfModifier=.

As currently only the victim gets experience, unless it's not a permanent mind control.

Back to top
View user's profile Send private message
EliteGoatBoy
Medic


Joined: 03 May 2016

PostPosted: Mon Dec 23, 2019 2:55 am    Post subject: Reply with quote  Mark this post and the followings unread

A few silly ideas in my mind, though I need to see if people are interested in turning them into blueprint requests.
As for some of the posts I've made before, I feel really bad posting in the first place as it makes me feel like I'm making unreasonable requests towards AlexB and the rest of the ARES contributors. If you find any of these interesting or would like to explain why/how are they feasible or not, it would be much appreciated. All feedback and criticism is welcome and appreciated.

1. Making the AlternateTheaterArt work on projectiles.
Implementing this on projectiles would allow for consistency for those deciding to keep the parasite behavior on attack dogs.

2. (Bug?) Units with a non-permanent mind control weapon, currently mind controlling a unit and acquire a permanent mind controlling weapon upon promotion cannot auto-acquire enemy units for mind-control. From my limited knowledge of how the game works, I'm going to assume the reason this happens is that a link between the controller and the controlled unit is still present, which prevents the unit from auto-acquiring a new target for mind-control. This makes the controller vulnerable unless manual targetting (player input) is involved. It could be fixed by either removing the link checking if the current mind-control weapon is permanent or turn the original mind controlled victim into a permanent mind-controlled victim.

3. (Bug) Weapons with IsRadEruption=yes are still green and do not follow the new Beam.Color= tag.

4. Navy SEALS and Tanya have Cheering animations when swimming, but no WetCheer= flags exist. Extremely minor and unimportant.

5. Tech Hospitals provide automatic healing for InfantryTypes through the InfantryGainSelfHeal, SelfHealInfantryFrames, SelfHealInfantryAmount tags. Tech Machine Shops provide automatic repairs (healing) for UnitTypes through the use of UnitsGainSelfHeal, SelfHealUnitFrames, SelfHealUnitAmount tags. Why not have some of these for BuildingTypes through tags such as BuildingGainSelfHeal, SelfHealBuildingFrames, SelfHealBuildingAmount? (Unsure if UnitsGainSelfHeal affects AircraftTypes)

6. Optional FireUp2, WetAttack2 for infantry units that use secondary weapons that default to FireUp and WetAttack respectively if not defined.

7. PenetratesBunker works one of two ways. If set to yes, then the weapon on which this flag is on will only affect the vehicle inside of the Tank Bunker. Otherwise, it will damage the building first. Two additional flags could allow weapons to damage both.

Code:
[WeaponType]?PenetratesBunker.UnitDamage= (double - percentage)
The percentage of the damage dealt to the vehicle inside of the tank bunker. Defaults to 100%, requires vehicle inside of the tank bunker.

[WeaponType]?PenetratesBunker.BunkerDamage= (double - percentage)
The percentage of the damage dealt to the vehicle inside of the tank bunker. Defaults to 0%, 100% if no vehicle is inside the tank bunker.

Tank Bunker here refers to a BuildingType with Bunker=yes


8. More customizable Permanent Mind Control on weapons with permanent mind control, more specifically, adding some of the tags from the Type=PsychicDominator SuperWeapon.

Code:
[Warhead]?MindControl.PermaControlAnim= (Animation)
The Animation displayed above units being mind-controlled by the Dominator permanently. Defaults to [CombatDamage]?PermaControlledAnimationType.

[Warhead]?MindControl.PermaCaptureMindControlled= (boolean)
Defines whether this warhead can capture units that are mind-controlled already. Otherwise already mind-controlled units are ignored. Defaults to yes.

[Warhead]?MindControl.CapturePermaMindControlled= (boolean)
Defines whether this warhead can capture units that are permanently mind-controlled already. Otherwise already permanently mind-controlled units are ignored. Defaults to yes.

[Warhead]?MindControl.CaptureImmuneToPsionics= (boolean)
Defines whether this warhead can capture units that usually aren’t mind-controllable. Setting this to yes ignores the ImmuneToPsionics tag on its victims. Defaults to no.


Again, these are merely suggestions and ideas that I'm putting out for the community in the hope of getting feedback so I can muster up the courage to blueprint them.

Last edited by EliteGoatBoy on Tue Dec 24, 2019 5:19 am; edited 1 time in total

Back to top
View user's profile Send private message
MRMIdAS
Energy Commando


Joined: 17 Jul 2008

PostPosted: Tue Dec 24, 2019 4:13 am    Post subject: Reply with quote  Mark this post and the followings unread

EliteGoatBoy wrote:

1. Making the NewTheater= tag work on InfantryType and Projectile art entries. AlternateArcticArt= although working is limited to the SNOW theater.
Prerequisite.RequiredTheaters= can be used as pseudo-workaround, but as stated in the ARES documentation, it becomes a bit of a hassle for the AI.

Rather than making it work as it does with building art:
Code:
[GACNST] -> GTCNST for TEMPERATE \ GACNST for ARCTIC \ GUCNST for URBAN \ ... \ GGCNST for default or alternate art not found


The optimal way would be one that combines both AlternateArcticArt and NewTheater methods:
Code:
[SEAL] -> SEALT for Temperate \ SEALA for Arctic \ SEALU for URBAN \ ... \ SEAL for default or alternate art not found


Implementing this on projectiles would allow for consistency for those keeping the parasite behavior on attack dogs.


AlternateTheaterArt=yes is a thing.

_________________
MIdAS - Turning wages into beer since 2002

Back to top
View user's profile Send private message
EliteGoatBoy
Medic


Joined: 03 May 2016

PostPosted: Tue Dec 24, 2019 5:16 am    Post subject: Reply with quote  Mark this post and the followings unread

Could have sworn it wasn't. Ignoring the infantry part, it still can't be applied to projectiles, correct?

Back to top
View user's profile Send private message
WoodleMyNoodle
Cyborg Soldier


Joined: 09 Apr 2018

PostPosted: Wed Dec 25, 2019 2:40 pm    Post subject: Reply with quote  Mark this post and the followings unread

A ConvertTo= on a warhead would be amazing. (Weapons forcing units to convert to a unit of the same type)

Back to top
View user's profile Send private message
TAK02
General


Joined: 28 Jun 2015
Location: It was Damascus.

PostPosted: Mon Dec 30, 2019 9:01 am    Post subject: Reply with quote  Mark this post and the followings unread

I'm sure this has probably been asked already, but I've recently learned not to take guesses and ask instead if I can't test it myself.

Is there any chance Factory= can support at least a BuildingType and AircraftType OR InfantryType OR UnitType and actually get that combination to work properly?

I'm thinking something akin to the TT Defense Crawler that could pump out units (infantry and/or tanks) and can also build structures when deployed.

Or maybe a CY that can call for Aircraft like in TS (and in RA2 if you fix it properly) when all Helipads are full. Maybe have that CY reload aircraft too #Tongue

It'd be nice if a CY could build infantry and tanks simultaneously and build buildings #Tongue

(A work-around would be to have the "crawler" be a Helipad/Barracks/WF/whatever that gives SWs that spawn the buildings, but then you can spawn two non-defense structures, say both a PP and a Ref, at the same time.
Same if you do it the other way around: a CY with unit-spawning SWs allows "pumping out" a Tank and Miner or a Trooper and Engi simultaneously)

Back to top
View user's profile Send private message Send e-mail Visit poster's website ModDB Profile ID YouTube User URL Twitter Channel URL Skype Account
DaubertMotion
Soldier


Joined: 17 Dec 2015

PostPosted: Sat Jan 18, 2020 9:14 pm    Post subject: Reply with quote  Mark this post and the followings unread

I'm thinking about how to make a "Firebase" in the spirit of the Zero Hour one.  So I know that garrisoned structures cannot have a turret or a weapon, so I'm wondering what my alternatives are.

1) I make the turret a single shp with the cannon in the center and four infantry at the corners.  All five rotate in place and face 32 directions.  So its technically one turret, but it looks like one cannon and 4 infantry.  I then make the cannon the primary weapon with a minimum firing distance and then have the infantry be the secondary weapon with a range up to the minimum firing distance.  Its a simple solution that doesn't require any additional logic, but it can't use both weapons at once, and it can only target one unit at a time.

2) Ares adds logic that a unit/structure can fire both its primary and secondary at the same time?  And can target different things?  Might work best with an omnidirectional type weapon and one tied to a turret.  So picture a boat with a tesla coil at one end and a sentry gun on the other.  Primary is tied to the turret and secondary is not.  Or the M3 Lee from WW2 (small cannon in turret and large cannon in chassis).  For my firebase, I could make it look like a garrisoned bunker with a turret on top.  Cannon is tied to turret, but secondary is omnidirectional machine gun fire.

3) I'm not that familiar with TS but I remember the component towers.  I'm don't exactly recall how adding the upgrade-turret worked, but if it's technically a different building, that could mean the base of the structure is garrison-able and the turret upgrade is a separate building with that can be the turret.  Or that can be the ares logic - a building tag like BuiltOn=[BuildingType] where a structure can only be built on top of another structure?  I'm probably reaching with that one.

I'm also pondering how to add mines like Chinese building upgrade in Generals.

Speaking of TS place-on-building upgrades.  If a building has a passable bib (which I think ares got rid of so structures wouldn't take damage) could a mine upgrade work so that enemy units that drive/walk on the bib take damage?  Although, if ore/tiberium is spawned via a weapon, I could probably clone&modify that type of logic so that a building can spawn mines around it.

Back to top
View user's profile Send private message
silverwind
Cyborg Firebomber


Joined: 11 Jun 2016

PostPosted: Sat Jan 18, 2020 9:30 pm    Post subject: Reply with quote  Mark this post and the followings unread


Back to top
View user's profile Send private message
Mig Eater
Defense Minister


Joined: 13 Nov 2003
Location: Eindhoven

PostPosted: Tue Jan 21, 2020 9:37 am    Post subject: Reply with quote  Mark this post and the followings unread

1) The minimum/max range of a weapon isn't taken into account when choosing what weapon to use.

3) A building upgrade with a weapon will just replace the weapon on the existing building with the one in the upgrade.

_________________



Back to top
View user's profile Send private message Visit poster's website ModDB Profile ID YouTube User URL Facebook Profile URL Twitter Channel URL
Millennium
Commander


Joined: 09 Mar 2008
Location: Osaka (JP)/Hong Kong/Germany

PostPosted: Thu Jan 23, 2020 7:48 pm    Post subject: Reply with quote  Mark this post and the followings unread

List Appension
I just learned that using "+=" entries in headed lists appends the RHS entry to the list, even when no unique string is used in the LHS. I had intended to request such a feature as part of a more general appendability extension awhile ago, and I'm now recalling other details of that would-be request:
would it be possible to allow a prefix for IDs in flag lists that allow more than one entry, thus allowing these lists to be appended, rather than overwritten, in #included INIs? An example would be the "BaseUnit" list, which allows more than one entry, but re-stating this list in an #included INI will overwrite, rather than append the list. Introducing such a prefix, e.g. also "+", would mean that, say, stating "BaseUnit+=ZMCV" in an #included INI file would make the entire BaseUnit array "BaseUnit=AMCV,SMCV,PCV,ZMCV" (provided no other changes). As an extension to this, a removing prefix could also be considered, e.g. stating "BaseUnit-=PCV" in an INI loaded after rulesmd would remove the Yuri MCV from the BaseUnit array, even if it is included in rulesmd. In cases where there is no prefix, the intended reading would be that the following entry overwrites the previous stating of the same entry.

Customizable RadialFireSegments
Using the "RadialFireSegments" entry, we are capable of defining the angles at which a given unit will fire sequentially, with the first angle at which it will fire being 180° sinistral, and the last one being 180° dextral. Entry "OmniFire" causes a unit to fire even when not facing its target (and prevents it from making an effort to do so), but it will fire at its target.

Gen/ZH has "AcceptableAimDelta", which, to my understanding, allows the unit to fire if the target is within an circular sector, with the central angle determined by the entry. "OmniFire" can be modelled as a full-circle (360°) "AcceptableAimDelta". On the other hand, while "RadialFireSegments" permits a unit to fire within a circular section of 180°, it also does not alter the facing behaviour of the unit (it will still attempt to face its target), and the trajectory will be between the unit and a point on the limit of the circular section, with the angle depending on the current effective RadialFireSegment. "RadialFireSegments" also takes precedence over "OmniFire" insofar as projectile trajectory is concerned, but "OmniFire" takes precedence insofar as the angles at which the unit is permitted to fire is concerned.

I would like to propose several interpolations from these behaviours:

  • "AcceptableAimDelta" as a general case of "OmniFire"; at minimum, this flag would take a number that determines an angle mirrored at the unit's facing, determining the sinistral and dextral areas in which a target can be located without the unit requiring to turn in order to fire at it. An extended version could take a double-entry list, determining the sinistral and dextral angles separately. A luxury version of this feature would take the form of a list in which several angles can be defined (by defining the angle, from 0° (the unit's facing), at which a circular section begins in which firing is permitted, and another angle at which this circular section ends. If multiple angles could be listed, this would provide a highly customizable way of imitating "RadialFireSegments" without the feature of automatically cycling through the segments.
  • Likewise, the feature of the unit firing into pre-determined directions could be untied from the feature of the "RadialFireSegments". This potentially needs a complicated "translation" between the angle at which the unit finds its current target, and the angle at which it will fire in response. The highly specialized case of sequentially moving through all RadialFireSegments in response to firing at a target either straight ahead or anywhere around the unit (with OmniFire), which is the default behaviour of RadialFireSegments, could be made a special case.
  • The interpolation of the features "attempts to face the target" and "can fire at the target even when not facing it" can be discarded because of practical irrelevance; if the unit has to face the target before it can fire, stating that it can fire at the target from other angles is nonsensical.


Regarding the feature of defining numerous circular sections in which the unit will fire, it would even principally be possible to model the projectile feature "Inaccurate" by allowing a random, rather than sequential, distribution of fire between these segments.

Extension of RetargetAccuracy
Another approach of inaccuracy would be a generalization and further customizability of RetargetAccuracy; generalization in the sense that it could be extended to not only be applicable to projectiles created by Splits/AirburstWeapons, but to any projectile. "Inaccurate" and "RetargetAccuracy" could become a single "Inaccuracy" (or "Accuracy") tag, which determines whether a given projectile will target the same target as the object whose weapon created the projectile. The logic according to which this re-targeting occurs is incomprehensible to me, but there appears to be a range limit. A highly useful feature extension for "RetargetAccuracy" would be a way to define a distance from the target within which a projectile may pick a different target. Once this is implemented, functional difference to "Inaccurate" tag becomes minimal. However, "RetargetAccuracy" projectiles also prefer targeting objects over empty cells. This may in itself not be preferred, which is why it may be opportune to request that the targeting preferences of retargeting projectiles be made customizable. This can be done at different degrees of sophistication: a simple approach might allow the differentiation between objects and anything else, e.g. by introducing "RetargetAccuracy.Objects" as a sub-set of "RetargetAccuracy", which would allow defining a chance, within the chance of "RetargetAccuracy", that the projectile would target an object over an empty cell, with the projectile targeting an empty cell (or anything, including objects, at equal probability) if this chance does not kick in. This very low degree of sophistication, in combination with a RetargetAccuracy.Range would, on its own, make "Inaccurate" modellable in "RetargetAccuracy", except applying to homing projectiles spawned by Splits, rather than to ballistic projectiles fired by a unit's weapon. In short, features that would extend "RetargetAccuracy" would allow it to completely model, and subsume, the functionality of "Inaccurate". Additional degrees of sophistication could differentiate things like "RetargetAccuracy.ENEMY", "RetargetAccuracy.FRIEND", "RetargetAccuracy.WALL", "RetargetAccuracy.AIR" and whatnot.

Once allowed for weapon-fired projectiles and not simply Splits projectiles, there is an additional unification possible with "DistributedFire", which could simply be modelled by "RetargetAccuracy.UNIT=100%" and "RetargetRange" equal to the firing weapon's Range.


Unification of SubjectTo*, FireStorm, IronCurtain, Shield
I've finally bashed these stream-of-consciousness musings into a somewhat coherent form. I do not advise anyone to read them, except Alex, who might find some useful feature or other in here.

Spoiler (click here to read it):

There have been repeated requests for the introduction of a "shield" system in Ares. These requests, though made under this same term, have generally taken two forms: one for a "personal shield" that surrounds a single unit ("feature 1a" in the following), one for a shield that surrounds an area, either projected around an object, possibly mobile (I think that these requests are for something like the shield projected by the Force Shield Generator of War Front: Turning Point), or cast upon a location (all of these subsumed under "feature 1b" in the following). Shield requests usually went above and beyond the mere request of making an object more resistant to damage, which can be achieved with AE, also including the feature of being capable of taking only a limited amount of damage. As there is no value added to gameplay by a shield that in itself is essentially nothing but an extension to the Strength of the object (otherwise, this would be sufficiently served with AttachEffect.Armor), people who are not requesting the introduction of a Shield feature merely for the visual effect of displaying a separate, possibly heterochromatic, Strength bar, a shield animation and impact animations for absorbed damage will likely request that the Strength provided by the Shield behave in some way distinct from the Strength of the unit itself; perhaps it should regenerate, perhaps it should not be able (or be able) to be repaired or healed by means by which the unit itself can (or cannot) be repaired, perhaps it should have vulnerabilities distinct from those of the unit itself. Finally, “shield” may simply be a short-hand wording for Strength increases that are bestowed by certain external sources, which may or may not have the features described above; if there are no other features involved, such is equivalent to “Beyond-MaxHP Healing”, in which case it is now equivalent to the ArmorMult AttachEffect, and thus no concern anymore for requesting.

To be sure, what feature 1a and b do is simply re-route damage otherwise taken by the shielded object(s) to a different health pool. That said, there is a different idea of "shield" that is sometimes meant by requests, a shield which offers protection to things in a "bubble", with incoming projectiles detonating when entering the area (henceforth called "feature 2"), not only interacting with projectiles intended for the position at which it interacts with them, but it will also block projectiles that are headed somewhere else entirely and are simply cruising over the FireStorm Wall Segment on their way to their proper destination.

I would like to propose that these requested features, the FireStorm effect, currently restricted to be invoked by SWs to apply to soft-coded objects, and "SubjectTo*" are special cases of a generalized, parsimonious handling for these at first glance entirely distinct features that also offers some interesting interpolation. Finally, possibly IronCurtain/ForceShield and "PenetratesBunkers" can be tied up into this.

A non-area version of such a shield, that is, one that simply detonates projectiles entering the area of an object does not make sense for personal protection: after all, anything targeted at that object would detonate anyway, and if it didn't, that would be an advantage! However, in fact, a non-area version of the "bubble shield" already exists in vanilla TS and Ares, which is the "FireStorm" effect, and the advantage is clearly demonstrable: such a shield protects whatever is behind the shielded object (in the case of FireStorm, the shielded object itself does not even take damage, but it is possibly advantageous even if it does; to be sure "feature 2" here refers only to the feature of FireStorm to make projectiles detonate in a cell in which they otherwise would not). Customizability of feature 2 can be conceived as allowing to define an area (perhaps by radius, but perhaps also by more complex foundations) in which, when the effect is invoked upon the object, collision of projectiles is activated. Possibly, this could take the form:

Code:

[FireStormSpecial]
Name=FireStorm Defense
FireStorm.Radius=3 ; When this SW is active, the radius in which projectiles will be destroyed around buildings eligible for it.


or

Code:

[GAFSDS]
Name=FireStorm Defense Section
FireStorm.Radius=3 ; When FireStorm is active, the radius around this building in which incoming projectiles will be destroyed.


Possibly, a SW could even invoke such an effect on no object in particular, defining a cell/area on its own. The only "object-like" feature of this area would be that things could collide with it (possibly, this could be generalized by UnitDelivery and allowing ObjectTypes to exist in "incompleteness" to a larger degree than currently possible).
It is also possible to imagine feature 2 to be handled as an object in itself, existing at the same location as the objects upon which the effect is centered. Presumably, it should be traversible by your own units, but customizability of this feature follows almost on its own.

"SubjectTo*" and "IgnoresFirestorm" flags both handle whether a projectile will detonate when entering a cell occupied by an entity of the type "*" (walls, cliffs, buildings), or a cell in which FireStorm is active.

In this context, I would like to bring up a tag particular to Gen/ZH which points towards a more customizable implementation that might be usable here; this is "CollidesWith=". This tag allows to define per-projectile groups of other objects that it cannot pass through if it meets them on its way to its target (it has no effect on its collision with the target, which it always collides with), and the projectile would detonate when meeting any of the objects in the list. To my understanding, it is restricted to hard-coded categories that concern permutations of different attributes (for example, WALLS and ENEMIES). There is no advantage, of course, if this were implemented in Ares without making the list more extensive, or fine-grained, but it might serve as one possible implementation of a more customizable collision system. Alternatively, a generalization of terminology pre-existing in RA2, the SubjectTox tag, could take this function, although only "SubjectToWalls", "SubjectToCliffs", "SubjectToBuildings" have the function of outright collision, where "x" would be a variable to be replaced by terms. Such terms could be the IDs of ObjectTypes in themselves, but I would suggest to make it possible to create a "[CollisionSets]" list, which in themselves would take the form of equations, the LHS being a string and the RHS being a list of ObjectType IDs. Filling the LHS string into a "CollidesWith" (or "SubjectTo.x") would make the projectile in question collide with objects of these types. However, this is somewhat made redundant by the existence of the prototyping feature, so perhaps it can be foregone in favour of simply listing ObjectTypes, rather than pre-defining sets, as prototyping allows to import a list of types from another projectile without re-stating them anyway. As FireStorm not only destroys projectiles, but also units, consider expanding at least the collision with shields to units, just as "IgnoresFirestorm" is a valid TechnoType tag. If feature 2 shields exist as "incomplete objects", projectiles could be defined to collide with some of them, and not with others. Traversibility by units, likewise, could be generalized in this way: essentially, a "shield" as an object completely traversible, except to projectiles. Whatever features of traversibility already exist in Ares (such as "ImpassableRows" could be customized according to being impassable to what, or it could be envisioned as separate objects overlaying each other and sharing their stats, but not their passability - though at that point, what is an object?)

How should a situation be handled when there are several objects at the same position which are eligible for collision with a number of these? What occurs in one interaction may have influence on the course of other interactions. I am thinking in particular of the case of a unit and its shield existing on the same cell; naturally, projectiles should be collisive with both the shield and the unit itself, but with the latter only if there is no shield present. I propose that objects be given a "CollisionLevel" tag that instantiates the following functionality: if two objects exist on the same cell, they may only collide if there does not exist a collidable that can collide with one or the other and has a higher CollisionLevel.

Take the following example:
Code:

[TypeA]
CollidesWith=Bullet
CollisionLevel=1

[TypeAShield]
CollidesWith=Bullet
CollisionLevel=10

[Bullet]
CollidesWith=
CollisionLevel=1



This would mean that [Bullet] can only collide with [TypeA] if [TypeAShield] does not exist at the same position, because despite both being collidable with [Bullet], [TypeAShield] has a higher CollisionLevel.

It is possible to tie the tags that define interactions into the ObjectType rules sections themselves. While this would require the least change to code, it would allow for the possibility of sections definining contradictions:

Code:

[TypeA]
CollidesWith=TypeB

[TypeB]
CollidesWith=TypeC


One might say that this is of no relevance, that the list simply gets extended by each mention, even if the listings are not congruent. Another solution would be to define "collisions" independently, e.g.:  
Code:

[Collisions]
1 = TypeA,TypeB,CollisionLevel
2 = TypeB,TypeC,CollisionLevel


This could even be further generalized to allow more than two instances of a type being required to exist in a cell in order for the collision to occur, or even CollisionType to define the results (ordinary, to destroy the object, which, in the case of projectiles, cause the warhead to detonate, but possibly this could be overruled by a CollisionType statement).

The drawback to defining CollisionLevel within this list is that, again, conflicting statements can be encoded in this way if there are several collisions defined to have the same priority, leading to aequivocation. Of course, this is not a drawback incremental over the method of defining CollisionLevels within the ObjectType sections, since in those sections, too, collisions with aequivalent priorities can be defined.

Note that such CollidesWith does not have to be transitive, though it is necessarily symmetric; this is perhaps also not desireable. While it is certainly possible to model a projectile detonation by means of brt damage dealt to both involved objects, with only the projectile being vulnerable to that damage, thus avoiding the unfortunate implication of a perfectly symmetrical “detonate” type of collision, I think it is most auspicious towards the community to avoid, to the greatest degree that one is willing to invest time and effort, the narrowing of customizability.

("SubjectToElevation", of course, does something entirely different, and may be disregarded here.)

? All of these tags also involve alterations to AI, though these are customizable in the of "SubjectToBuildings" via "SolidLevel", and in the case of "SubjectToWalls" by whether the unit in question can destroy the intervening wall. It has been noted in this regard that "SolidLevel", the projectile tag, allows to control a unit's AI independently of whether it can actually destroy its obstacle, whereas there is no comparable tag for SubjectToWalls: the AI and targeting of a unit that is incapable of firing over a wall will decide to shoot anyway (destroying the wall) only if it can damage it, whereas it will be unable to target beyond a wall if it is unable to destroy the wall. Cliffs are never destructible, so there is no phenomenal difference between SubjectToCliffs=yes projectiles genereally not permitting weapons to be fired across cliffs, or whether a check, as in SubjectToWalls=yes, is included–either would return that firing across a cliff is unpermitted. In my estimation, it is possible to generalize SolidLevel (currently a projectile tag) and the purely Warhead-based consideration of whether to shoot at obstaclous walls, namely that SolidLevel could be generalized to not only work for SubjectToBuilding, but also for SubjectToWalls (and SubjectToCliffs, but, again, there would be no observable difference) in that it is a modifier to ratio of damage to obstacle strength that causes a unit to consider an obstacle as something to be avoided, or something to be destroyed. In particular, a unit that finds itself unable to destroy an obstacle can be considered as needing an infinite amount of hits in order to destroy that obstacle. In this case, for SubjectToWalls, the unit will abstain from firing upon the obstacle and will either move around it or, if such a path cannot be found, will be unable to fire or target behind the obstacle. If the unit finds itself capable of destroying the wall with less than infinite attacks, it will attempt to do so. I would propose for this consideration to be the default of SolidLevel, rather than the curret “0”. If this new default is adopted, it will allow SolidLevel tag to be generalized onto the behaviour against Wall obstacles without causing change, or else that the behaviour against walls be defaulted to work against buildings in the same way: if it can be destroyed, it will be considered destructible obstacle, unless SolidLevel dictates otherwise. Considering FireStorm and other collidables, we have a similar issue: there is no AI component in FireStorm that makes units defer from firing weapons to whose projectiles “IgnoresFirestorm” does not apply if there is FireStorm active in the line of fire, and prompts it to attempt to maneuver into a clear line of fire.

"SubjectToTrenches" has a functionality that already eerily similar to feature 1: it does not cause a projectile to detonate, but instead causes damage to be "passed on" to the occupants of a building, when it would ordinarily be dealt to the building, if the projectile is set to detonate on the building anyway by virtue of being targeted at its position.

Using feature 1a (a personalized shield), we can create all the features of Iron Curtain: it is an infinite-strength shield applied to just one object. There is no feature 2 (i.e. no collisiveness caused by Iron Curtain). We can consider that the shield invoked upon objects by a single instance of IronCurtain is the “same shield” for all of these objects, just as the FireStorm shield is the “same shield” over all objects over which it is invoked, or we can consider an instance of IronCurtain to invoke personal shields over a number of objects that just happen to be reduced by damage that is constant over all of them, and thus expire at the same time; there is no predictive difference between the two in this case. However, we run into issues of modeling the expiration of the timer in the facile way of using DoT to revoke it, as if the value that is reduced by damage and over time is truly infinite, then naturally, IronCurtain does not expire after any length of time, and non-parsimonious handling via a separate duration is needed.
A ghetto solution that does not depend on the existing timer settings might look to model IronCurtain as a shield with a very high, but not infinite strength; so high that any amount of damage that could reasonably or irreasonably be expected to be dealt to it during even up to the second-to-last tick of its existence would be insufficient to deplete it, with the exception of a certain damage-over-time that it is subject to and that reduces its massive health by the quotient of itself and the intended duration, in ticks, every tick. Since we already have existing timer settings for IronCurtain, such a truncation would of course be misplaced. What is really of interest here is the generalization of modeling the expiration of a timer and the taking of damage in such a way that one influences the other; this is pioneered in FireStorm, but perhaps considering both Timer and Strength to be just different iterations of a Strength values that could both pend upon the same Strength, as is the case for FireStorm, or could be separated into distinct values, is a valuable perspective for the customizability of shields. By extension, the general approach of allowing different Strength values (by way of saying, different values whose reaching of zero would cause expiration, or some other state transition) that interact with outside sources that alter them, rather than one with damage and one with a timer would perhaps be interesting for more than just shields; perhaps it is interesting to consider a unit that can be dealt five missile hits or 20 bullet hits before it is destroyed, but hitting it with the one does not reduce the number of times it has to be hit with the other, pathing players towards using particular means of damage (a similar effect could be achieved, I suppose, by cumulative damage reduction against certain kinds of damage by other kinds of damage). Conversely, using ArmorTypes on shields themselves, we can also make different damage types successive to each other: a shielded unit (or a shielded shield, or a shield-inside-a-shield-inside-a-shield-etc.) would be vulnerable to some types of damage, whereas the shield would be vulnerable to others. Using this approach, Iron Curtain could be a low-health shield with a DoT effect of a warhead that can damage it, whereas it would take no damage from any other source of damage. As a generalization of "SubjectToTrenches", a projectile tag would determine whether a given detonation would damage the shield at all, or bypass it to whatever it is shielding. This points us to another generalization, namely the difference between damage nullification and "damage pass"; this does not matter for vanilla RA2: since there is never one object in the special relation of "being shielded" by another object, brt damage that is not passed into net damage just becomes nullified and does nothing. But "SubjectToTrenches" reveals a different aspect that such "not-taken" damage could have; namely, the building doesn't take it, as if it was immune to damage, but something else takes it instead. Generalization of "Verses=" would be from the feature of nullifying a share of damage to a feature of passing a share of damage on to some other object. Consequently, "SubjectToTrenches" would allow the definition of a percentage of damage to be taken by the occupants of a building. Consequently, a projectile capable of dealing damage through shields could also define the share of damage that it dealt to the shield. Conversely, the percentage could be modified (only or additionally) by a value on the building or shield itself as well.

It is quite easy to represent the FireStorm in a model combining feature 1a and feature 2, that is, as having HP and causing a certain location to become "collisive", excepting one factor: it can be represented as a finite-strength shield that is under the effect of damage-over-time (each tick reducing its strength by its strength divided by the number of ticks it is intended to last), while also being able to take damage. The factor that we are not yet able to represent is that this shield is withdrawn from all objects it is on at the same time, irrespective of the object to which the damage had been dealt that it absorbed and that reduced its duration. It is illustrative in another regard: we think of a “shield” invoked upon objects to be roughly spherical or circular: objects in a circle or sphere share a single shield and consequently, shield protection is withdrawn from all of these at once. However, FireStorm is invoked over many objects simultaneously and the "FireStorm.Radius" feature suggested above simply defines, for lack of a good way of defining placement per rules coding, the area in which a collision mode is activated. Where such an area is located, and how many there are, on a map, is still up to the events happening in the game itself. To be sure, in order to model the FireStorm feature, the player is able to place many FireStorm.Radius=1 (i.e. "just on its own cell") sections, which each would be an "object" by virtue of being disjoined from the other areas. At this point, it becomes impossible to avoid dissolution of the idea of an "object": while we might be able to concede to having multiple impassable areas disjoined from each other be a single object (e.g. via making certain parts of the foundation impassable, and others passable), here, even the positioning of these entities is not pre-coded, but depends entirely on in-game events (unlike the case of the parts of a BuildingType's foundation), and, if it is possible to construct additional objects of the type while the FireStorm is active, different parts of the same object come into being at different times. And yet, all these objects should share a single health pool, in order to be revoked at the same time. A generalized feature that allows the sharing of HP between objects for this purpose would allow it to be implemented, and could possibly be extended to apply to objects which are not "incomplete", but ordinary, movable, buildable, objects. I have no idea how such a HP-sharing feature may be implemented, though. Perhaps a "damage sharing groups" list could be created. This is precisely what is implied by feature 1b between different instances of the "same" shield, and it is what is implied by the feature of allowing customizable damage sharing between shield and shielded object.

_________________
Mao Zedong wrote:

Our mission, unfinished, may take a thousand years.  

Back to top
View user's profile Send private message
Mig Eater
Defense Minister


Joined: 13 Nov 2003
Location: Eindhoven

PostPosted: Thu Feb 27, 2020 2:37 pm    Post subject: Reply with quote  Mark this post and the followings unread

Something I suggested many, many years ago but got lost in the crowd...

CloakFull= enables cloaking ability to a unit/building that has full pips, this could be used for:

  • Units with ammo that will only cloak when fully reloaded.
  • Harvesters that will cloak after filling up with tib/ore.
  • Transports that will cloak after being filled with units.
  • Units that require an operator/driver to cloak.
  • Aircraft carriers that will de-cloak when their planes are attacking.  

_________________



Back to top
View user's profile Send private message Visit poster's website ModDB Profile ID YouTube User URL Facebook Profile URL Twitter Channel URL
Lin Kuei Ominae
Seth


Joined: 16 Aug 2006
Location: Germany

PostPosted: Thu Feb 27, 2020 4:01 pm    Post subject: Reply with quote  Mark this post and the followings unread

The Firestorm Charge logic isn't part of RA2 or Ares yet, right?
Might be a nice addition as well and could work well with CloakFull too.

_________________
SHP Artist of Twisted Insurrection:  Nod buildings

Public SHPs
X-Mech Calendar (28 Mechs for GDI and Nod)
5 GDI, 5 Nod, 1 Mutant, 1 Scrin unit, 1 GDI building

Tools
Image Shaper______TMP Shop______C&C Executable Modifier

Back to top
View user's profile Send private message
Mig Eater
Defense Minister


Joined: 13 Nov 2003
Location: Eindhoven

PostPosted: Thu Feb 27, 2020 4:19 pm    Post subject: Reply with quote  Mark this post and the followings unread

Ares has made it so you can make a weapon use up multiple ammo pips (or even none) when fired, which can be used to recreate Firestorm's charge logic.

So you could make a stealth tank that has a primary weapon that doesn't use up any ammo & a secondary weapon that needs multiple ammo pips. Once fully charged you'd then have to chose between being cloaked or unleashing a powerfully blast etc.

Edit: You could also make the secondary an AOE attach effect that will cloak friendly units around the stealth tank when fired, so it could share it's cloaking ability for a short time at the expense of revealing itself.

_________________



Back to top
View user's profile Send private message Visit poster's website ModDB Profile ID YouTube User URL Facebook Profile URL Twitter Channel URL
Display posts from previous:   
Post new topic   Reply to topic Page 15 of 16 [800 Posts] Goto page: Previous 1, 2, 3, ..., 13, 14, 15, 16 Next
Mark the topic unread ::  View previous topic :: View next topic
 
Share on TwitterShare on FacebookShare on Google+Share on DiggShare on RedditShare on PInterestShare on Del.icio.usShare on Stumble Upon
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


Powered by phpBB © phpBB Group

[ Time: 0.2862s ][ Queries: 11 (0.0367s) ][ Debug on ]