Would be cool to customize spies so that they can do some, but not all of the new features. So you could implement a unit that only steals money(ra1 Thief) or maybe steals money, shuts down power, but doesn't steal plans/grant veterancy (zh saboteur). QUICK_EDIT
I think allowing abductors to abduct allied units would be pretty useful.
For example, it would allow the possibility to "load" allied units from a distance. Or for example allow an aerial unit that normally doesn't deploy to ground to load units.
Also, Damage.Deployed on TechnoType would also be great. So you can make it depending on the infantry rather than the warhead.
Also, being able to attach an animation using attacheffect, not using the duration would be amazing. (Also. support for animations with next: would be great) QUICK_EDIT
Sorry for bump, but do we have a way of making a map-wide Gap Generator?
I was think of something like player "losing communication" with far off units when not having a radar built in certain scenarios; like the moon mission. QUICK_EDIT
A gap generator can have a radius of up to 127 cells, which should be able to cover a small map. Several mods use invisible dummy gap generators on maps in order to simulate the "Fog of War" effect. _________________
The only problem is that if you also have units/buildings with an extra large +11 sight radius, the shroud can glitch out & not be rendered properly when the unit/building is destroyed & the gap gen has to quickly re-shroud a large area. _________________
I've noticed that buildings with a custom palette don't darken like normal ones when stuff like Lightning Storms happen. is there any way to get them to darken, or let the game know to use that behavior, as most of the custom palettes I've seen are just edits of the existing palettes. _________________ MIdAS - Turning wages into beer since 2002 QUICK_EDIT
It's a known limitation of the custom palette feature. IIRC it was implemented by hacking/extending the existing custom pal in the game, which also didn't support lighting changes. So adding lighting effects might require completely redoing the custom pal logic. _________________
Opentopped and tank bunkers were coded "correctly" imo, garrisoned buildings are whack af. Who thought of giving them a single global tag for range... >_> _________________
ayylmao on Discord QUICK_EDIT
There are 4 different types of [Tiberiums] in RA2 & each one can have different artwork & values. Only 2 are used for Ore & Gems, the remaining 2 are just copes of ore & can be reused for whatever you like. You can also make dummy drills (0x0 buildings etc) that can spawn any type of ore/tib via debris. _________________
Last edited by Mig Eater on Thu May 14, 2020 11:27 pm; edited 1 time in total QUICK_EDIT
Do you know where can I find such tutorial for the dummy building ?
For the other types of ORE. the problem is the the drills or tib trees. But I guess the whole dummy building tutorial can do.
Also,My last question would is how to integrate it in FinalYr ? I mean the other Ore/Gem types ? specifically the whole paint ore/gem overlay. QUICK_EDIT
You could check out TI or DTA, the spreader buildings.
It's basically a dummy building with an ActiveAnim, which spawns art.ini debris via TrailerAnim. The art.ini debris in turn spawning the tiberium via
TiberiumSpawnType=GEM01 ;gems [Cruentus]
TiberiumSpawnType=TIB01 ;ore [Riparius]
TiberiumSpawnType=TIB2_01 ;unused in RA2. this is [Vinifera]
TiberiumSpawnType=TIB3_01 ;unused in RA2. this is [Aboreus]
FinalAlert has them already in the bottom Overlay & Special dropdownbox, though it's stupid and calls them all Ore. Only the first 20 are Ore, the following 20 Ore are actually Vinifera and the last 20 Ore are actually Aboreus.
No clue how to add them to the left treeview. Though maybe E1 Elite patched them already in the latest version _________________ SHP Artist of Twisted Insurrection: Nod buildings
Also Known As: evanb90 Joined: 20 Feb 2005 Location: o kawaii koto
Posted: Thu May 14, 2020 11:18 pm Post subject:
XxpeddyxX wrote:
Opentopped and tank bunkers were coded "correctly" imo, garrisoned buildings are whack af. Who thought of giving them a single global tag for range... >_>
The whole system is messed up. Not just range.
Basically, it seems the occupants fire sequentially at the building's target. If an occupant can't attack the target for whatever reason (AA= setting on projectile, Verses= on warhead, etc), the whole building stops attacking once it's that guy's turn to attack.
My guess is that in some stage of development, they ran into this issue with range. Maybe before they added UCM1Carbine/etc, where Para has Range=6 and M1Carbine has Range=4.
Having it so occupants that can't attack are simply skipped would be nice. _________________ YR modder/artist, DOOM mapper, aka evanb90
Project Lead Developer, New-Star Strike (2014-)
Former Project Lead DeveloperStar Strike (2005-2012), Z-Mod (2006-2007), RA1.5 (2008-2013), The Cold War (2006-2007) QUICK_EDIT
Joined: 09 Mar 2008 Location: Osaka (JP)/Hong Kong/Germany
Posted: Thu Jul 02, 2020 2:48 pm Post subject:
Give greater .ini control over projectile trajectories/re-implement dummied-out projectile behaviour tags (Dropping, Level, Floater, etc).
Dropping, inoperable and unused since (inclusive) TS. What it is *supposed* to do is to attach a parachute (and hence regulate FallSpeed) to a projetile. What is actually *does* since TS is to instantly 'kill' the projectile upon being created. The "instant-detonation" makes for interesting features, but this can now be achieved by ProjectileRange.
A feature to give projectiles parachutes would be useful. Of course, a generally more customizable projectile fall rate would solve the issue as well, combined with AttachEffect being valid for projectiles for a parachute animation to be attached.
MaxEC for projectiles to allow more customizable projectile detonation than ProjectileRange?
A way to define ProjectileRange as "distance from the target" rather than "distance from the firer", perhaps by using negative sign?
Voxel projectiles are hard-coded to face downward initially. This prevents voxel-based projectiles to be fired down cliffs, from hovering units, or with CourseLockDuration. This hard-coded feature should be restored to be customizable through the Vertical tag. Potentially it could be made even more customizable through an InitialVector=n tag, where n is an angle, like FireAngle.
The "Level" tag creates a projectile which flies straight, but will be tied to travelling on water. The enforced terrain part should be removed from this tag, which would make it create a regular straight-fire projectile.
* The "Floater" tag has no discernible effect in either TS or RA2, but according to the commentary, its intended effect was pretty much like the "Level" tag, except that it is set on weapons instead of projectiles.
* The "Vertical" tag is new in RA2, but has no positive effect apparently - the Kirov's projectile is hardcoded (via the voxel's initial vector described above) to behave the way it does. This tag should be made useful by making it customize the initial vector for both voxel and SHP projectiles.
* Maybe some more exotic tags, such as BallisticHeilightHeight (ceiling height of the ballistic arc), AscentRate, DescentRate, etc would provide even greater degree of flexibility for customizing trajectories. Looking at the behaviour settings for spawned missiles might provide inspiration in this respect. This could obviously be tied in with the often-requested straight-fire projectile feature.
Bouncy/Elasticity
_________________
Mao Zedong wrote:
Our mission, unfinished, may take a thousand years.
In order to convert an advanced rubble building back into the complete structure you need to make an engineer enter it. The health/strength of the building doesn't matter, so SelfHealing or ClickRepairable etc wont have the same effect.
A tag like Rubble.Repair.Time= that will make the building automatically convert itself after a set time. Or maybe Rubble.Repair.Strength= which would convert the building back once it had a certain amount of health, which then could be controlled SelfHealing or ClickRepairable. _________________
Joined: 09 Mar 2008 Location: Osaka (JP)/Hong Kong/Germany
Posted: Mon Aug 24, 2020 12:39 pm Post subject:
It wouldn't add any additional functionality, but how about changing [#include] to read all INIs that start on a certain prefix? The introduction to vanilla rules(md).ini gives some hints about a feature that would have allowed multiple INIs with names starting on "rule", followed by a single character, to be parsed. I couldn't get this feature to work, but maybe I'm just doing it wrong. This system could be repaired (if there are still remnants of it), and expanded to work like #include, with alphanumerical load order taking the place of the #include list order. Ex.: a file named "rulesinfantry.ini", containing infantry sections, would be loaded after "rules.ini", overriding the content.
On another note, another expansion to #include, which would be to add or subtract from list tags, rather than overwrite them.
E.g.:
rulesmd.ini:
Code:
[#include]
1=moonraker.ini
[moonraker]
Prerequisite=factory
moonraker.ini:
Code:
[moonraker]
+Prerequisite=radar
Here, moonraker.ini would add "radar" to the Prerequisite list specified by rulesmd.ini, rather than replace "factory" with "radar". Different syntaxes for this are conceivable, e.g. using "+Prerequisite" and "-Prerequisite" as separate list tags, or using "+" or "-" as a prefix or suffix to the list items themselves, i.e.: "Prerequisite=+radar,-factory" would add "radar" to the Prerequisite list specified by the file last loaded that defined the object, and remove "factory" from that list. A more parsimonious syntax for this function may be found, I've not given it much thought. "Prerequisite" might not be the most useful place to stick this on, I'm more thinking of thinking of things like the AnimToInfantry and BaseUnit lists, which would have to be re-defined completely in every file that adds anything to them, which will override the entries from files further up in the load order. And that might lead to compatibility issues when a user runs plug-and-play INIs created without coordination (which is the greatest potential #include has, in my opinion). Not sure I'm being comprehensible here, feel free to ask. _________________
Mao Zedong wrote:
Our mission, unfinished, may take a thousand years.
It would be visible/play for all of Nod (Soviets), and for YuriCountry2
To expand upon this, perhaps allows coders to add a tag that allows the coder to decide if the track is still accessible to other sides or countries but doesn't autoplay for them that way you can play other faction music manually but it does not auto play. QUICK_EDIT
I would also like the addition of
NumberOfWaitingPoints to building Technotypes as a flag that tells harvester AI to find another refinery in the event that the waitingpoints are filled.
[GAREFN]
NumberOfWaitingPoints=3 ;This tells the harvesters that aren't the first three queued for the refinery to find a different refinery. However they will try to get in line if there are only 2 harvesters queued for example.
If the value is set to -1 - which would be the default if this flag isn't set - then it would allow harvesters to do basegame dogpiling behavior. If it is set to 0, then Harvesters will not autoacquire the refinery as a dropoff point and only dropoff on demand by the player.
I genuinely would like to see this appear in the game, so mods with harvesters like MO's Minermites don't dogpile refineries and make life a living logistical hell for the player.
Also @wardeathfun, I concur with your expansion to my proposed music logic, and would love to see that also expanded onto the logic, we can call it PseudoSide, and PseudoCountry, wherein it's available to be played but never autoplayed. This would be useful in MO for sure.
Joined: 09 Mar 2008 Location: Osaka (JP)/Hong Kong/Germany
Posted: Mon Sep 28, 2020 11:55 am Post subject:
wardeathfun wrote:
Perhaps a spy effect to temporarily disable the building he's entered in? Similar to power down, but applicable to radars, defenses, etc.
So far, effect of Spy/Infiltrate on buildings is customizable by using the SpyEffect.* settings. If there was a spy-specific setting, which would take precedence? The Spy setting or the building setting? I suggest that there should be a list that determines the interaction. This list could be on either the Spy or the building, but it's decidedly less awkward to have it on the Spy, rather than the building. E.g.:
This would make the Barracks be disabled by a Soviet Spy, but would make an Allied Spy steal tech. Of course, units could be listed in multiple effects to cause multiple effects when infiltrating.
This would make the spy disable radar, but steal tech from barracks and factory. Again, the same building could be listed multiple times for multiple effects.
Another extension of infiltrate might be something like a weapon effect being invoked by infiltration on the building. This could would expand SpyEffect by numerous options, including some that have been requested. E.g. SpyEffect invoking an EMP weapon upon the building he infiltrates would effectively match the effect of disabling the building. Other possible options would be "partial C4", dealing damage to the building, but not destroying it, or adding an AttachEffect to it. _________________
Mao Zedong wrote:
Our mission, unfinished, may take a thousand years.
I'd like to suggest a simpler, albeit less powerful, alternative to that:
Expanding the existing SpyEffect tags to InfantryTypes.
By default, everything would be enabled for Agents, so the flags would serve as disabling overrides.
For example:
[SPY]
Agent=yes
SpyEffect.ResetRadar=no
SpyEffect.ResetSuperweapons=no
SpyEffect.StolenTechIndex=1,2,3,4,5,13,14,15,17,18,22,23 ;defaults to -1, which means anything
How this could work is that a spy effect would only be granted if both the spy and the building have the respective flags (or indexes, or SW IDs) enabled. By default, everything is enabled for agents, but not for buildings.
With that same logic SpyEffect.Custom would serve to enable or disable the new spy effects per individual spies. As said before, they'd only be enabled if both the SPY and the Building have the same values.
SpyEffect.Custom = yes ; the default value for Agent=yes infantry. Enables al spy effects unless disabled by other flags
SpyEffect.Custom = no ; this spy doesn't work with the new effects. The effect is the same as setting SpyEffect.Custom = no on the target building.
[NEWSPY]
Agent=yes
SpyEffect.Custom=no
This one works exactly like the Ra2 Spy, even if the buildings have custom spy effects. This one will be QUICK_EDIT
Joined: 01 Feb 2007 Location: Las Vegas, Nevada, USA
Posted: Fri Oct 02, 2020 8:38 pm Post subject:
Had this thought about what I wanted before and thought I'd share. Enjoy the ramble
The ability to give users stolen tech at the start of game. Merely list under country technotypes what stolen tech they start with. This is great because not only would this make stolen tech a more punishing part of the game stealing a player's tech they might rely on (you could steal prism tank technology, for example, if you were to make prism tanks stolen tech but give all allied countries it by default), but it could be expanded upon.
This means that units with stolen tech prerequisites can be immediately satisfied as long the tech owning structures are not spied and the player's chosen country starts with it by default. We could probably also benefit from this being passed on other spy effects too like infantry/vehicle/structure/aircraft veterancy.
The next idea would be to give structures, superweapons, and units a prerequisite to function. Having it so a superweapon requires a stolen tech to be owned and having a stolen tech to fire can be incredibly useful to define differently because, perhaps, some superweapons need a special kind of "ammo" only your enemy has (wanna fire the soviet nuclear missile? Better infiltrate their nuclear missile silo). Additionally, robot tanks might function as long you have the "decryption" to control them, and last the ability to disable one's radar by merely stealing radar tech from the player.
It could be then further expanded to have time limits, meaning stolen tech doesn't have to be permanently taken. Have it so both the player stealing tech has a time limit for how long they can use it and the robbed player has a time limit for how long it's lost, both by default is -1. This then means players can steal someone's radar, disabling them, and it's up to the modder to decide if the player absolutely needs to build a new radar, wait a few moments, or they will never have radar again until they steal the tech.
To make this wishlist more obnoxious, I suggest also a new list type for spies. This way, each "agent" can have different sets of abilities against different sets of structures without any absolutes on them. Perhaps nuclear reactors requires a higher level of spies to infiltrate them, perhaps the timer is different for each agent. Give each structure a "SpyIndex.Vulnerable" or "SpyIndex.Abilities" to each spy. If nothing is listed in Vulnerable, it is assume it's, by default, vulnerable to all spy related tags listed on the structure or spy. SpyIndex.Vulnerable=none means none, SpyIndex.Vulnerable=SpyAbilityTypes means it is only vulnerable to those spies. Likewise, spies have a similar thing where it lists what abilities it has:
[Americans]
OwnedStolenTech.Index=25,30;can both build GASPYSAT as well power it
[GASPYSAT]
SpyEffect.Vulnerable=JAMESBOND
Prerequisite.StolenTechs=25; if James Bond or MI6 enters, it will no longer be buildable
Powered.StolenTechs=30; only James Bond can make the structure no longer functional
;Jamesbond infantry type
[JAMESBOND]
SpyIndex.Abilities=MI6,JAMESBOND; this means he reveals production, resets radar, resets superweapons, and 2,4,7,25,30 stolen tech QUICK_EDIT
give structures, superweapons, and units a prerequisite to function.
have time limits, meaning stolen tech doesn't have to be permanently taken.
This can already be done by using the SpyEffect.SuperWeapon= along with an instant auto-firing SW that spawns a dummy invisible building, that then can act as the "prerequisite" & after a set time destroy itself. _________________
Also Known As: martx Joined: 28 Oct 2016 Location: PH
Posted: Mon Oct 05, 2020 4:22 am Post subject:
ExtraVoxelTurretLight or something of the sort.
I use ExtraUnitLight=0.4 to make vehicles slightly brighter, which apparently doesn't cover voxel turrets of buildings. I use a TS vpl and it darkens the look of turrets like the sentry gun and flak cannon too much. _________________ all my posts before 2020 were made by a 13 year-old, forgive these if you see any, thank you QUICK_EDIT
Joined: 09 Mar 2008 Location: Osaka (JP)/Hong Kong/Germany
Posted: Fri Oct 30, 2020 7:11 pm Post subject:
A thought on resource systems; perhaps we can introduce customizable range of resources:
Code:
[ResourceTypes]
x=Tiberium
y=Gold
z=Wood
Another interesting extension would be the "Battery" superweapon that is a generalization that we can extrapolate from the way "Power" works. Power is generated and if the source disappears, all power also goes away. We also know that power that is not consumed does not "stack": excess power simply goes away too. This could be modelled by considering Power as a resource with a "decay timer" of 0 frames for unused units of the resource. Ore/Tiberium on the other hand never decays; it just keeps stacking when not used up by a running production process, SW or upkeep. We could think about other resources having different values than "0" and "infinite". Perhaps resources could have a decay timer of, say, 1000 frames, disappearing after 1000 frames. We could also think about ways to modify these attributes in-game: the "Battery" SW cut pre-release from TS would be something like this, giving Power an infinite decay timer while charging. A further generalization may be "storage space" for any amount of the resource not used up at a given frame. If the storage is 0, the surplus resources just disappear, and something like a Battery could provide for some Power not to go away. This way, "decay timer"/Battery could be unified with Silos.
(Didn't really think this through, there might be some principal problems with the idea.) _________________
Mao Zedong wrote:
Our mission, unfinished, may take a thousand years.
Would like to see the Power generator seperated from the building's strength status, powerplants that generates a fixed amount of power no matter how severely damaged it is, like in TW/KW and RA3. QUICK_EDIT
AttachEffects maybe for "weapon ranges" (for similar GZH's Search&Destroy bonus) I can easly do "HoldTheLine" and "Bombardement" with AEs. It is about only coding...
But for weapon ranges, it is a bit more complex,I think....Without breaking the game balance, everybody could do it easily.
At first,I thought AttachEffect.WeaponRangeBonus= integer (1 or 2 for balance is good enough.)But right below is far better...
Maybe the new code could be like :
AttachEffect.ChangeWeaponTo= Any Weapon from the [WeaponsList]
I like this idea much more.Since "duration " is also customizable.we could decide the affect will be temporal or eternal ? What do you think ?
Waow!!! With this, game engine allows to do global upgrades like in C&CGZH even including the existing units on the battlefield.
Like the idea of the mod RiseOfTheEast, an auto fired immune HunterSeeker unit that effects the whole battlefield with the AlternatePrerequsite and AlternateNegativePrerequsite feedback , this could be wonderful.I think you catch the idea. _________________ drugstore-catalog.com Last edited by maestro21 on Fri Nov 06, 2020 1:58 pm; edited 3 times in total QUICK_EDIT
Joined: 09 Mar 2008 Location: Osaka (JP)/Hong Kong/Germany
Posted: Fri Nov 06, 2020 1:36 pm Post subject:
maestro21 wrote:
AttachEffect.ChangeWeaponTo= Any Weapon from the [WeaponsList]
[...]
Waow!!! With this, game engine allows to do global upgrades like in C&CGZH even including the existing units on the battlefield.
I think (and I'm not sure I suggested this before), I think an AttachEffect/ProtoType hybrid would be a generalized method for this. The AttachEffect would apply a ProtoType (not really "proto", since it would have a higher load order than the unit it is applied to), e.g.:
If "Harmlesser" weapon is fired at a unit, the "Harmlessing" warhead applies the type "HARMLESS_UNIT" as an AE. The type itself does not have any definitions other than the "BubbleGun" weapon in this example, overriding the weapons of the unit hit with the warhead. Depending on the definitions in the type that the AE applies, any change conceivable in the game engine could be applied, in principle.
This could be tied to a weapon, but could also conceivably be used to apply unit upgrades to existing units in the battlefield via map-wide GenericWarhead SW.
Disclaimer:
I can foresee that here are some possible issues with this involving potentially-infinite lists. Right now, this only appears to be the case with Prerequisite.Lists; there can be a (virtually) unlimited number of alternate prerequisite lists on a unit, and while it's in principle possible to simply define an arbitrary number of Prerequisite.Lists on the type defined in AttachEffect.Type to override any and all of the presumably rather limited number of Prerequisite.Lists defined by a sane modder on a given unit, I'd prefer a solution on a theoretical level. For Prerequisite.Lists, this is, of course inconsequential: since we apply the AttachEffect.Type to units that already exist, what you do to the Prerequisite of their type has no influence. However, the WeaponX system is a potential instance of this problem if it ever gets expanded, and there might be other instances of this issue that are escaping my notice. A possible theoretical solution would be a tag that works like an intra-type prototyping, forcing all iterations of a certain tag to default to a certain value; e.g. Prerequisite.ListDefault=FACTORY or WeaponDefault=Minigun forcing all PrerequisiteLists or WeaponX statements to default to these values. I've not really thought this through though. _________________
Mao Zedong wrote:
Our mission, unfinished, may take a thousand years.
Epic failure of me again. When I started to write this in excite, I totally forgot about Secondaries ( weapons) or WeaponX instead of Primary=* ... So, it is definetly stays a dream which can never exist. _________________ drugstore-catalog.com QUICK_EDIT
Request/Suggestion: Make TiberiumToSpawn from Firestorm work again.
You can spawn different type of Tib/ore with TiberiumSpawnType= on debris, so make a dummy tib tree with a weapon that spawns invisible debris around itself. _________________
Request/Suggestion: "Recall all Harvesters"; all harvesters look for nearest Refinery to dump ore at. Maybe "force" Slaves to unload at Slave Miner too?
Feature from Emperor: Battle for Dune, and affects even if a harvie is being ferried by its Carryall (will head to Refinery as soon as it lands). QUICK_EDIT
I would love to see upgrade become possible. I mean to make changes in the unit such as GI1 and GI2 once upgraded GI1 will be taken out and all GI1 in the map will be changed to GI2 and now you can produce only GI2. Something like this. Oh oh! BTW I wish we could customize separate radsite would be nice. I don't want to change the original but add a different one in.
Oh last thing. MakeInfantry is awesome howabout MakeVehicle too?
UnitDelivery can have some more tags add in like in Generals, Such as Create_On_Area, Create_Outside_Map, Create_on_Air so unit such as a group of something can travelling to battlefield or appear on spot like original or create on air if it's airborne unit etc... Pretty neat right? QUICK_EDIT
A tag that changes the cost of a unit/building based on how many you own, something like Cost.UnitMulit=. It would be an alternative to BuildLimit= etc where instead of a hard cap the price would grow making it more economically difficult to buy.
This could already be done with buildings by using lot of clones with increasing cost & Prerequisite.Negative= but it's currently not possible with units. _________________
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