phobos-developers / phobos Goto Github PK

Hover Units such as the Hover Transports, and Jumpjet units such as the Nighthawk do not autoacquire ore/tiberium when designated as harvesters, and the AI player will not deploy a hover MCV (Not tested with Jumpjet.)

A fix would be appreciated for the Ore/Tiberium acquisition and Hover MCV deployment logic for both player/AI, and AI respectively. (AI doesn't order Hover MCV to deploy at start of game.)

This is nature from basegame, and is not a bug directly in phobos, but it seems to be a Westwood development oversight.

Maybe even support for Generals-esque helicopter harvies, where they have a voxel animation for harvesting, which could also be used for harvesters on the ground too to allow recreation of the RA1 Harvester "ground-pound" anim for all harvies.

Generals-esque logic as in:
LandToCollectOre=no
(Only applicable to units using Jumpjet logic)
HarvestAnim=USHELIHORE
(So jumpjet harvies aren't jumping jellybeans while harvesting)

where voxel animation USHELIHORE is used as the unit anim.

Jumpjet units don't show pips for Tiberium for some reason. (Pls fix, Westwood silly!)
Hover units have not been tested for this.

(Infantry Harvester Section)
Putting Harvester=yes on an InfantryType will allow the unit to function as a harvester, without being Enslaved.
add FreeInfantry and FreeInfantry.Amount as well, which acts like FreeUnit but for InfantryTypes, with its latter brother command being selfexplanatory.

Fog of War exists in code YR, but was disabled due to not working correctly. CNCNet Client spawner allows to force enable FoW, however this causes several issues:

• Units are still visible under the FoW,
• Structures under the FoW (mostly high civilian buildings) render incorrectly, usually with transparent triangles, This also happens when the top of a building is visible, but the foundation is not,
• Structures under the FoW cannot be properly targeted (units issue move command instead of attack/garrison/repair), unless the cursor is on the top edge of the top foundation cell.
• Jumpjet units and aircraft provide vision only when moving or landed (possibly shroud uncovering check is not tied to ground cells, but FoW refresh is?),
• Jumpjet and aircraft have a global vision range specified in rules->[General]->AircraftFogReveal, could be deglobalised to work with unit sight,
• High fog refresh rate (set in rules->[AudioVisual]->FogRate) causes flickering and effectively makes air units provide no vision,
• On the other hand, low fog refresh rate causes units to leave a decaying trail of vision behind them (this happens with any unit, but for slow units disappears very quickly, might be additionally linked to movement-into-two-cells issue?),
• Temporary drawing glitches, similar to ones that rarely happen with uncovered shroud in vanilla YR (black outline of cell remains until we scroll away and back, or black gradient around "old" vision that quickly disappears)
• Possibly more yet unknown bugs caused by Ares' new features

Muzzle flash is displayed correctly, but the laser is not (or rather, it is mirrored).
for example
PrimaryFireFLH=170,100,120

The weapon of the tank has a Burst=2
Muzzle flash is displayed in the required coordinate 170, 100, 120 and the laser is mirrored to 170, -100, 120

Allow dual line trails on art.ini entries, e.g. aircraft where the center is still drawn at the center of the voxel/shape but the linetrails can be customised to a specific lateral offset, like FLH works:

[VXL]
UseLineTrail=yes
LineTrailColor=216,216,255  ; SJM
LineTrailColorDecrement=9  ; SJM
; New tags
DualLineTrail=yes
DualLineTrail.Offset=100

Custom linetrail thickness allows for a SAGE engine look to linetrails, e.g. on a rocket. Line trail width would be based on value:

[VXL]
UseLineTrail=yes
LineTrailColor=216,216,255  ; SJM
LineTrailColorDecrement=9  ; SJM
; New tag
LineTrail.Thickness=3

This would draw the 2 line trails at the end of both wings, rather than the center.

As of now, infantry and pad-bound aircraft TechnoTypes cannot use IsGattling=yes and all of its additions. I propose to extend the Gattling weapon logic to work with all unit TechnoTypes, not only vehicles and defences. For infantry, no special changes to this logic would be necessary. For pad-bound aircraft, Gattling logic would need to take limited, cant-reload-in-flight ammo into consideration.

Would it be possible to have the game load a separate AI file based on Gametype? so in your "MPXX.ini" you have "AIFile=" which overrides the standard AI and makes it load the new one. It'd make Unholy Alliance playable against computer players possible without cloning buildings, which would be nice.

Apparently Ares grays out the PowerUp if there's no suitable building is present (need confirmation on this behavior). Of course, it wouldn't include the new PowersUp.Buildings tag, so that situation needs to be dealt with.

Allow MakeInfantryOwner= to designate infantry owning house invoked by animations apart from InfDeathAnim, DeathAnims, InfantryExplode, FlamingInfantry, InfantryElectrocuted, InfantryHeadPop, InfantryNuked, InfantryVirus, InfantryMutate, InfantryBrute and map triggers.

Expected use-case would be applying MakeInfantry logic on ivan deathbombs which current environment would always gain the resulted infantry to the Neutral side instead.

GapCells when set to an integer above 0 will allow a warhead to inflict gap generator logic in the cells the warhead is detonated in. Uses Big Gap targeting flags. Defaults to 0 for all warheads.

Practical use would be a Gap Generator smokescreen or superweapon that shrouds an area.

[GapWH]
CellSpread=3
GapCells=3
BigGap.Affects=Enemy

Maybe GapCells could be a child of BigGap logic, so syntax would become BigGap.GapCells=integer.

The custom icon works on other renderers, but not CnC-DDraw. I remember talking with Kerbiter about this, and i've heard no confirmation or anything that it has been patched in Phobos yet. So i'm reposting it here to keep it fresh on everybody's minds.

Synchronize emitter units with spawning level, like Promote.IncludePassengers.

Promote.IncludeSpawn=yes/no ; is it allowed to synchronize the transmitter with the spawn.
Promote.IncludeAirstrike=yes/no ; Allow air raid to synchronize with Summoner level.

Self-explanatory. As of now, VeteranRatio is defined in rules in [General] section and applies to all TechnoTypes. Allowing modders to specify VeteranRatio for each unit (while retaining the global value for compatability) could give much more control over veterancy related balance issues.

My current tag propositions is as follows (in uimd.ini):

[MenuBackground]
UsePCXBackgrounds=yes ; is that even needed?
Alignment.Horizontal=left ; can be left, right or centet
Alignment.Vertical=top ; can be top, bottom or center

This is a suggestion

Allow a technotype to ignore the opentopped conditions.
The conditions are OpenToppedRangeBonus, OpenToppedDamageMultiplier, and OpenToppedWarpDistance

The new logic should work as follows:
If the Opentopped Technotype has any of these flags declared on it, it will use the value declared on the Technotype, rather than as listed in [CombatDamage]. Obviously the unit will need OpenTopped=yes, and [CombatDamage]'s values will be used by default.

However if you make new flags that override the opentopped bonuses, then i'd be down for those too!

1. Allows you to display or change the color of the Airstrike line and The same color is displayed on the vehicles.

Line=yes/no ;It means whether the red standard line is displayed.
LineColor=rgb ;line color.
LineTargetDisplay=yes/no ;Show target tag.
LineTargetColor=rgb ;Target color.

2. Whether the solid projectile is allowed to fly to the target in a straight line (like ROT = 1).

LinearProjectile=yes/no ;(ROT = 1).
LinearSubjectToCliffs=yes/no ;It means whether the solid projectile can directly ignore the cliff instead of exploding after hitting it.
LinearSubjectToWalls=yes/no ;It means whether to ignore the wall directly instead of exploding after hitting the wall.

This request is to implement an option, possibly under [TechnoType] that allows the user to see all tech and units that are available, although blocked by technology/prerequisite walls. This would show the cameo greyed out.
e.g.

[APOC]
TechLevel=8
AlwaysDisplayAvailability=yes

The Apocalypse Tank would show in the sidebar as greyed out, until a Battle Lab is built, but since Battle Labs are TechLevel=6, if the map does not allow tech levels above 6, it would still remain greyed out.

Similar to how tech locks work in C&C3

[NukeSpecial]
AlwaysDisplayAvailability=yes

Because the Nuke Missile Superweapon it tied to [NAMISL] which is TechLevel=10, the nuclear missile would be greyed out all the way through to TechLevel 10, until a Nuke Silo is built.

There is working game logic from TS that lets walls bind to gates and component towers, using the tags

GDIGateOne=  
GDIGateTwo=  
WallTower=  

But retardedly, they are all hardcoded to GAWALL. Unhardcoding these tags would open up possibilities for some pretty sweet graphics in RA2, for example the comp tower/ gate/ wall set that ive already made. I bet 3 conyards this won't get implemented

Component towers themselves are also hardcoded to that WallTower= entry, which means there can only be 1 comp tower type at any 1 time. That would also be cool to have fixed but whatever.

Currently, upon infiltration, the player who infiltrates can get a superweapon.
However, since superweapons are very flexible, it would be nice to be able to give the one that got infiltrated a super weapon as well.

Tag: SpyEffect.SuperWeapon.Owner=self | enemies

So, while using the ARES logic of transports coming "Pre Loaded" (ala the Chinese troop crawler in Generals) I've come across the problem of units that kill these vehicles gaining too much veterancy, as I've obviously had to tweak the value of the vehicle to account for the troops inside.

SO! I'm requesting a value for the amount of veterancy a unit receives for destroying the unit in question.

This could also be used to make a unit more valuable the more they are promoted, with Veteran and Elite values as well.

Would require structuring of current feature list and expanding it with screenshots, gifs etc. that would double as a promo material in future.

Since Designators can only be used on Self and Ally, to improve gameplay I suggest these:

[SuperWeapon]►SW.NegDesignators= (list of TechnoTypes)
List of enemy units and structures eligible for designating the target location. An empty list requires no negative designator. Defaults to none.
[SuperWeapon]►SW.AnyNegDesignator= (boolean)
Whether any enemy unit or structure is considered a valid negative designator for this super weapon. Overrides SW.NegDesignators. Defaults to no.
The negative designator range can be customized for each TechnoType individually.

[TechnoType]►NegDesignatorRange= (integer - cells)
Range in cells around the enemy unit or structure that becomes targetable by super weapons requiring this object as negative designator. Defaults to [TechnoType]►Sight.

Example:
[RadarJammerSpecial]
...
SW.NegDesignators=GAAIRC,NARADR
...

[GAAIRC]
NegDesignatorRange=1

Request to implement the Tiberian Sun aircraft waypoint mode, where any aircraft is allowed to follow a waypoint path and take commands on it, such as guard area. In TS, once the aircraft ammo is depleted they go back and refill, then return to their waypoint path.

No particular tag I can think of.

I hope these tags can be customized for TechnoTypes so that can give various Chrono ability.

ChronoDelay=
ChronoReinfDelay=
ChronoDistanceFactor=
ChronoTrigger=
ChronoMinimumDelay=
ChronoRangeMinimum=
WarpIn=
WarpOut=
WarpAway=

In INI files, allow to alias portions of text with shorter keywords, like with #define preprocessor directive in C language family. Possible merits: significant reduction of time spent copy-pasting (or, worse, typing by hand) INI fields as well as reduction of errors/typos caused by doing so. Additionally, this feature could be combined with [#include] section already existing in Ares, letting modders create pseudo-header files with their custom definitions. Hypothetical usage:

At the start of rulesmd.ini:

[#define:GenAllVehicleVoices]
VoiceSelect=GenAllVehicleSelect
VoiceMove=GenAllVehicleMove
VoiceAttack=GenAllVehicleAttackCommand
VoiceFeedback=
DieSound=GenVehicleDie
MoveSound=GrizzlyTankMoveStart
CrushSound=TankCrush

Somewhere else:

[MTNK]
...
Cost=700
Points=25
GenAllVehicleVoices
MovementZone=Normal
...

Currently the vanilla tag value isn't accounted when checking if this upgrade is applicable to a building.

As of now, units with INI key Lobber=yes "overshoot" their targets (projectiles land behind targets) if said targets are on higher elevetion. I propose to introduce a flag (i.e. IsAccurateLobber=true|false) that would disable/enable this penalty.

Is it possible to have custom palettes behave like other buildings? maybe a tag? like "darkens=" which makes the game think its the same as a regular building SHP and it just shifts down the palette when a lightning storm happens?

ChronoDelay=60 ChronoReinfDelay=180 ChronoDistanceFactor=48 ChronoTrigger=yes ChronoMinimumDelay=16 ChronoRangeMinimum=0
Can be used on the unit
If the unit does not write Chrono code, it will read [General] by default

Introduce INI key (name suggestion: Stationary=true/false) that allows any unit (or at least vehicles) to permanently exhibit behaviour identical / similar to what vehicles with IsSimpleDeployer=true when deployed (they don't accept movement commands, never move on their own accord but can fire weapons, acquire targets, deploy etc).

Primary use-case would likely be to combine with Ares' Convert.Deploy to simulate regular IsSimpleDeployer with much greater control over the deployed state's properties. May also be useful with certain dummy units, map objects etc.

Vanilla RA2 bug - having non-zero CellSpread on a warhead with Temporal=yes results in an Internal Error.

Red Alert 2 has not developed multithreading until now. If multithreading can support RA2. What a good thing that is. If multithreading can be achieved, can it be made into a separate patch. Some players are just playing, not creating RA2

The logic of the laser track is different from the laser. They are more like the laser cannon of a sci-fi battleship. The width and length of the laser track can be set (it does not hit directly like a laser, more like a linear projectile of a laser image), color
LaserTrack=yes/no LaserTrack.Width LaserTrack.Length LaserTrack.Colour It will be affected by the projectile option

LaserTrack=yes
LaserTrack.Width=1
LaserTrack.Length=1
LaserTrack.Colour=255,255,0

Picture effects can be achieved [it can imitate the trajectory of bullets], and the game lighting has little effect on it

https://blueprints.launchpad.net/ares/+spec/sidebar-gdi-positions

Currently there's little control over sidebar positions as they're hardcoded. Solving issue above would give additional degree of freedom for modders and artists by lifting constraints on button coords for sidebar (at least by being able to specify another set of hardcoded button pos.)

[Side]►Sidebar.GDIPositions=(boolean)
GDI hardcode positions buttons on the sidebar. They are located above and have larger dimensions. Achieve a similar result by editing SHP - I could not. I want to have the same positions buttons for others sides.
What would bring some clarity. In the screenshot: [NOD]Sidebar.MixFileIndex=1
As you can see - the buttons are not in their places.

An idea for a feature that allows one to replicate the Chrono Vortex visual effect.

Pixel Offest map defines coordinates of the pixel which colour should be used as a base colour to draw a pixel of the vortex animation. In theory, it can be warping, displacement, blast waves -- anything, but I'll stick to the name everyone recognizes with less explanation.

The Pixel Offest map should be stored as a regular SHP, so it can be animated.
As SHP is limited to 256-colour palette, there are two approaches possible.

Approach 1: definitely not the one you'll go with.
Two maps for two axes, horizontal and vertical offsets stored separately. Colour index in palette serves as the offset data. With 256-colour palette possible offset values are -128 to +127. For certain effects you can also use an offest scaling multiplier which, evidently, will multiply the offset from the map. Too expensive in terms of processing, but it should let you understand the reason for the stuff going further.

Approach 2: a bit faster one.
One map for two axes, just as in Normal maps in 3D modelling. 256-palette limits offset to -8 to +7 range for each of them (i.e. 4 bits per axis). Scaling is limited to 100%, 200% and 400% (might be larger, but this makes no sense). With 200% scaling applied we can use the fast calculation of the average colour value of 2x2 pixels square (4x4 for 400%) by adding together the colour values of those pixels by channels and then bit-shifting the results by 2 bits per channel (4 bits per channel for 400%).

What features should it also have?
It would be nice to just slap it on transparent animations with a flag in artmd.ini code of that animations.

Anything to start the investigation?
Ion Cannon ripple effect seems to have some sort of 'displacement' behaviour, @tomsons26 also noted "the ripple code is the closest to vortex".

Possible problems?

• What if renderer addresses the pixel out of map bounds?
• It might possibly need a separate 1-bit map to show the pixels in the animation affected, or a colour in the palette reserved for transparency so we don't end up having warping rectangles when scaling. (-8; -8) would fit nicely for this as the farthest offset (and less reachable position), but it's binary 1000 1000 in signed ints, isn't it?
• My crappy explanations :)

Add a tag which allows this infantry to enter a friendly vehicle (think reverse hijacker), then transfer veterancy over to that unit. If the unit is destroyed the pilot comes out with the unit's veterancy level.

If veterancy transfer is difficult, the pilot should then just add a single stage of veterancy, like a veteracy crate would.

e.g. IsPilot=yes

TLDR: Generals Pilot

In light of a recent question raised in the channel,
I come up with this request for some further customization on Ares Bounty Logic in hope of enriching the feature's interactiveness while still respecting the original Bounty.Value= tag.

[TechnoType]►Bounty.Multiplier= (float - multiplier)
The amount rewarded as bounty for this type is multiplied by this value to either increase, decrease, or nullify the effect.
Support values range from -1.0 to reverse the effect to 1.0 to not apply the effect. 0.0 nullifies the bonus. Defaults to 1.0.

Expected use-case of a negative value would be applying such logic on some mercenary units player can hire mid-game and have to pay for their services.

How sidebar tooltip strings are broken to multiple lines seems to change depending on if ExtendedToolTips is set to true or false under [ToolTips] in uimd.ini. Original behaviour (ExtendedToolTips=false) is fairly zealous with its line-breaking whereas the extended tooltips appear to have a much. much higher threshold for applying line breaks, which seems to cause problems with longer words and/or strings. This seems to apply to both UIName and UIDescription strings, although the difference in line-breaking behaviour can currently only be observed in case of the former for obvious reasons.

An example: left-hand side is with extended tooltips disabled, right-hand side is with extended tooltips enabled.

Almost self-explanatory. If a unit were killed by a warhead with SuppressDeathSound set to yes, the unit will play no death sound. This can be lucrative in situations where a new death sound, other sound cue, or no sound is necessary.

[Mutate]
SuppressDeathSound=yes

In the event you have the genetic mutator set to use the warhead Mutate, the Infantry would not play their death sound. So no more blobs of GIs screaming in agony, and now only Brute sound!

PseudoOrganic would default to no for InfantryTypes, PseudoOrganic would allow InfantryTypes to be treated as if they were VehicleTypes in the context of Locomotor beams (IsLocomotor), Iron Curtain logic, and Chronosphere logic.

[E1]
PseudoOrganic=yes

The G.I. would be able to become invulnerable, be picked up, and teleported without killing him. But he would still heal.

PseudoOrgan when no, will maintain default InfantryType logic when the 3 aforementioned types of logics are concerned, and either be not affected (IsLocomotor) or just die a horrible death.

Currently, you can have unique units for any side but Crew= remains tied to the faction itself.

Vanilla Crew= e.g.:

[GDI]
Crew=E1

[ThirdSide]
Crew=INIT

Phobos could allow sides to have custom Crew, for a more exclusive/unique feel to factions e.g.:

[YuriCountry]
Crew=MILITANT

[PsiCorps]
Crew=INIT

This is more of a bugfix, since in vanilla YR and with Ares, artmd.ini animations with warheads are always treated as conventional.

Make it so the warhead defined has the final say on the matter as in Cerebral Cascade there is a hilarious bug where all bullet casings make massive splashes regardless of how many anims I set to the warhead with conventional=no, this caused me an hour of frustration learning that this logic works as such.

Sometimes when a detector unit dies they can still detect stealth where they die, would be nice to see this one fixed.

Ballon hovers with capability taking passengers such as the vanilla nighthawk always attempt to land at the end of every flight or after destroying a target while hovering.

This behaviour greatly limited the effectivness of these units to do anything other than a sole transport and I would like to request for having such behaviour on air transport units (and carryalls if possible) to be lifted.

RadDurationMultiple=1 RadApplicationDelay=16 RadLevelMax=500 RadLevelDelay=90 RadLightDelay=90 RadLevelFactor=0.2 RadLightFactor=0.1 RadTintFactor=1.0 RadColor=0,255,0 RadSiteWarhead=RadSite
Used for weapons, no code is read by default [General]

As of now, infantry units with Deployer=yes will use their Primary weapon when mobile and Secondary weapon when deployed. I propose to introduce a flag (i.e. DeployFireAll) that would allow them to use both Primary and Secondary weapons when deployed.

If you mind control an enemy unit that deploys into a building that grants access to superweapons, the superweapons won't become available when you deploy the unit. This appears to be only an issue when transfering the mind-control link from a vehicle to building, as access to superweapons is granted as expected if such building is mind-controlled directly. Likewise, before the fix that allows mind-control link to be transfered on deploy, access to superweapons was granted as expected as the building ownership was also permanently transfered.

Font file with new characters added
Many Chinese characters are not supported
This is a language that contains a lot of Chinese game.fnt
Hope to add new characters
FNT.zip

Add a new tag that makes a unit powered by... power, instead of a building e.g. Robot Tank:

Powered.Unit=

PoweredUnit= exists already

This request is for the extension of the Ares DeactivateDimEMP= tag, or rather create a new one that affects structures. It may be easier to mimic ExtraUnitLight but at a structure level.

This tag would cause the structure's light to be reduced by the value/percentage.

e.g. the building below is powered=yes and has the following tag, whenever it is power toggled, EMP'd or power is low, its light would be reduced to 50%, similar to EMP'd units and disabled Robot Tanks.

[TechnoType]
DeactivateBuildingEMP=0.5; Reduces disabled, EMP'd and/or low powered structure light by 50%