Posted: Sun Sep 15, 2013 10:35 pm Post subject:
My plan for Ares 0.5
With Ares 0.4 just out, it's time to think about the next release (scheduled to be released this year). Because I piled up a rather big set of features after the release of 0.2 a year ago, I'd really like to finally include the stuff already done.
I had about 100 so called commits (addition of features or changes) ready after 0.2 and included about half of them in 0.3 and 0.4 already. Most of them internal changes and minor things. The big ones are yet to come, and I'll group them, to make testing more focused.
The first thing will be cloak stuff. Stuff like customizable cloak sounds (with the possibility to differentiate between cloaking and uncloaking), cloaking hover units and all that. (After doing the cleanup for 0.4, I started working on that this morning and I was done before noon. Just to give you a sense of how fast things can go if they are already done.)
There will be like two or three separate TS feature groups (the TS stuff is too big to be just one group). I thought about tiberium (damage, heal, explosive), tiberium2 (storage, spill), ... thinking about it, three groups isn't enough. Point is there's lots of stuff here. I prefer to do the first tiberium group next, because then I don't have to reorder stuff that relies on stuff not there yet (but I know reasons have never stopped the community).
Then there's the group of fixes, like the C4 veteran ability not working, and optimizations, like smoke animation lookup (same as already done for the custom missiles).
And, of course, the miscellaneous features that make a modder's life easier, but don't really fit into a group.
I'd like to squeeze in as many new features as possible (but fixes have priority). I'll start working on the next group when the features of the current group are confirmed working. Cloak stuff comes first. The question is: what to do after the cloak stuff? Which are the features you can't wait for?
[TechnoType]CloakSound= and [TechnoType]DecloakSound= added, defaulting to [AudioVisual]CloakSound.
When a CloakStop=yes unit is turning, it will uncloak also. Originally it wouldn't, but it would look strange when the unit is still moving and suddenly starts to cloak because it is stopping to turn.
Apart from all that cloaking should still work, of course.
When all of these are confirmed, I'd look into the next group.
Sorry for all the formatting. There was so much formatting I had to make the important things stand out. _________________ Last edited by AlexB on Sat Dec 21, 2013 11:41 pm; edited 1 time in total QUICK_EDIT
Can you do weapons that can fire at the same time? or ammo on a per weapon basis rather than a per unit? That's what I've been dying for since Ares got going. _________________ KGR | AT
AZUR
Discord: theastronomer1836
Steam QUICK_EDIT
Posted: Sun Sep 15, 2013 11:25 pm Post subject:
Re: My plan for Ares 0.5
Cloak changes & additions seem pretty solid. I did some preliminary testing and posted my results on three of those bug reports linked in the original post, said features appear to be working as intended. Of course hard to say at this point that they won't break under some special circumstances, but one can hope that this won't happen.
AlexB wrote:
The question is: what to do after the cloak stuff? Which are the features you can't wait for?
I personally wouldn't mind seeing 0.5 contents being built from the features you have already worked upon since 0.2, bugfixes and misc. small things. Out of the features you might've already worked on in the TS feature sets, I'd like to see currently incomplete Firestorm Wall logic finished and an implementation of TS EMPulseCannon superweapon. On the subject of bugfixes, I would like to see atleast the following bugs, amongst others fixed at some point (not necessarily in 0.5), from highest to lowest in terms of how I perceive them priority-wise.
First one has very high abuse potential, especially if weapons with high burst number exist in a mod. Ammo can be used to prevent this in some cases but not always. Second is technically a visual issue but due to it's nature it has very much gameplay-affecting ramifications. Third one is purely aesthetical thus I listed it last. Not that all of those need to be fixed in 0.5, just wanted to bring some attention to these issues. _________________ QUICK_EDIT
looking for a three weapon set up; front gun, torpedoes and anti aircraft with the proper firing places. _________________ I am authorized to send out the TMP Studio, PM ME IF YOU WANT IT And check this out, these were sent to me for help with terrain and zdata help along with TMP Studio/Builder
I actually thought in terms of the feature groups mentioned above, not completely new features; well, should have made that more clear. My bad. I've looked into the old TS features thread, which is now almost a year old. I think at least half of the TS features should get included, and I'm sorry this took so long. If testing gets as quickly done as for the current group (most things are rather deterministic and can be reproduced easier than some random cloak situation), I'm sure there's still time for them.
FurryQueen: At least the per-weapon ammo seems to be hard to get right. Each unit has one ammo counter. I did a quick check and it looks like it's used in over 100 places. Another problem is that it has different purposes, like ammo, paradrop, armory and hospital. To get this right is rather difficult.
Starkku: Yes, those are pesky. I'll see what I can do.
Nikademis: I don't think that will happen anytime soon. There's more to it than just adding Tertiary=. _________________ QUICK_EDIT
I know I asked Graion a while back "after 0.3 was released", and he said it was taking a back seat to attach affect.
Given that Attach Affect is now complete in 0.4? Has their been any word in continuing the testing for Bounty? Or possible inclusion of it in 0.5?
Thanks. _________________ Grab my Map Logic Expansion Pack 5.2 here!
Adds random weather patterns into maps.
More disabled navalyards.
Preplaced Neutral buildings.
Additional new features.
Joined: 22 Nov 2010 Location: Iszkaszentgyorgy, Hungary
Posted: Mon Sep 16, 2013 7:33 am Post subject:
These are Alex's plans, and Bounty is under my management. But yeah, you're at the right direction. I'd include Bounty in 0.5 too but considering that I overloaded myself with the current uni semester, I won't promise anything.
Alex, how hard does it seem to get flying units properly cloaked and detected? (Jumpjet and aircrafts) _________________ "If you didn't get angry and mad and frustrated, that means you don't care about the end result, and are doing something wrong." - Greg Kroah-Hartman
=======================
Past C&C projects: Attacque Supérior (2010-2019); Valiant Shades (2019-2021)
=======================
WeiDU mods: Random Graion Tweaks | Graion's Soundsets
Maintainance: Extra Expanded Enhanced Encounters! | BGEESpawn
Contributions: EE Fixpack | Enhanced Edition Trilogy | DSotSC (Trilogy) | UB_IWD | SotSC & a lot more... QUICK_EDIT
Naively I'd say: by removing the HoverHeight check. But this might cause different problems, like not being able to fire. Units decloak when in attack range, which an aircraft will most likely have left already before it is fully uncloaked. _________________ QUICK_EDIT
I know it's not in any of your feature groups but how difficult would it be to add custom pallets to terrain objects, overlays & terrain tiles? I dream of adding snow caped mountain ranges & volcanic lava flows to the temperate theater, sadly there just isn't enough colours to work with :/ _________________
Beuatiful read I just have, Alex! For me it not that important which group will come first - I need them all. Starkku's wish list is also nice. But I think Burst is need its own group targeted 0.6, because this is not an only about Stop command, but also:
If target dies Burst shot won't be count and it weapon can fire again.(I mean, cmon, Mammoth MK II just "pew pew pew" group of infantry of any size almost instantly)
And it also have weird desync with FLH if I attach particles to weapon. Particles will appear at left while projectile fires from right spot and vice versa. (tho it might be usefull for somekind dual lasers weapon)
I am also want to suggest, If you go at "Cloak" could you also take a look on "Sensors"?
PS. This Four had their own blueprints back in a days, with better explanation of issues then I can provide.
But I can not find them now. I might just blind. _________________ Gangster is a Project Perfect Wuj (c)Aro QUICK_EDIT
I'll probably start a similar topic with my aims (without target versions) tonight/tomorrow. _________________ "If you didn't get angry and mad and frustrated, that means you don't care about the end result, and are doing something wrong." - Greg Kroah-Hartman
=======================
Past C&C projects: Attacque Supérior (2010-2019); Valiant Shades (2019-2021)
=======================
WeiDU mods: Random Graion Tweaks | Graion's Soundsets
Maintainance: Extra Expanded Enhanced Encounters! | BGEESpawn
Contributions: EE Fixpack | Enhanced Edition Trilogy | DSotSC (Trilogy) | UB_IWD | SotSC & a lot more... QUICK_EDIT
I might be wrong about RA2, but in TS, RA1 and TD, the muzzle anim from point 5) is in the wrong FLH place too.
e.g. mammoth tank and heavy tank have bullet starting and muzzle flash on opposite sides. _________________ SHP Artist of Twisted Insurrection: Nod buildings
Features I'd like to see in 0.5 (or at some point) would be...
Autodeploy fix
Vehicle to vehicle deploy
Custom FactoryTypes
These would probably be my top 3 feature requests, and they would benefit me massively, but i don't know what other think about these features Last edited by dodgevipergts on Mon Sep 16, 2013 7:50 pm; edited 2 times in total QUICK_EDIT
Joined: 22 Nov 2010 Location: Iszkaszentgyorgy, Hungary
Posted: Mon Sep 16, 2013 7:45 pm Post subject:
dodgevipergts wrote:
Autodeploy fix
Custom FactoryTypes
What autodeploy fix? And BuiltAt shall be enough for custom factories.
Vehicle to vehicle deploy actually makes sense. _________________ "If you didn't get angry and mad and frustrated, that means you don't care about the end result, and are doing something wrong." - Greg Kroah-Hartman
=======================
Past C&C projects: Attacque Supérior (2010-2019); Valiant Shades (2019-2021)
=======================
WeiDU mods: Random Graion Tweaks | Graion's Soundsets
Maintainance: Extra Expanded Enhanced Encounters! | BGEESpawn
Contributions: EE Fixpack | Enhanced Edition Trilogy | DSotSC (Trilogy) | UB_IWD | SotSC & a lot more... QUICK_EDIT
Graion: I tested, and BalloonHover units can be made to cloak, same with Aircraft, but there is indeed a firing problem (plane has to spend the time while it uncloaks).
Gangster: The plan was to include Sensors, but I counted it as TS feature, not as cloak.
Glukv48: No different stealth types for now. The game only keeps track of cloak or no cloak. Too many things would have to be changed. _________________ QUICK_EDIT
Joined: 22 Nov 2010 Location: Iszkaszentgyorgy, Hungary
Posted: Mon Sep 16, 2013 10:04 pm Post subject:
Mhm, hmmm... well, with CloakingStages=1 that might cause no issues. I haven't seen test results but can imagine places where that could be intended. The final word is yours tho.
Either way, a DecloakSound in AudioVisual would be nice, considering that Dune2000 already used two sounds for that... _________________ "If you didn't get angry and mad and frustrated, that means you don't care about the end result, and are doing something wrong." - Greg Kroah-Hartman
=======================
Past C&C projects: Attacque Supérior (2010-2019); Valiant Shades (2019-2021)
=======================
WeiDU mods: Random Graion Tweaks | Graion's Soundsets
Maintainance: Extra Expanded Enhanced Encounters! | BGEESpawn
Contributions: EE Fixpack | Enhanced Edition Trilogy | DSotSC (Trilogy) | UB_IWD | SotSC & a lot more... QUICK_EDIT
I'd say that since Sensors are related to cloak, fix/add that first, possibly with the "basic" tiberium stuff.
And not related to current progress, but to the ammo thing: how about adding logic for weapons (or objects, whatever might fit more) to disable usage of ammo for a certain weapon, or make the object use more ammo when firing it? Just an idea, i'll post a full blueprint for it later (i don't want to request new stuff here ). QUICK_EDIT
New version is there. I'm lazy, so I'll just paste the changelog here:
---
SensorArray fixes
Buildings with SensorArray=yes use SensorsSight= to detect stealth and subterranean units, as in Tiberian Sun.
SensorArrays were not supposed to be powered, to change owner (by capture or mind-control), and weren't updated for temporal weapons. All of this should work now as one would expect.
The bug that the sensor effect would stay active even if the array was destroyed is fixed. It was because SensorsSight was used to activate the effect, while CloakRadiusInCells was used to remove it. If the latter was smaller, the bug happened.
The logic was also changed to not add the same array more than once (same for removal).
Newly added EVA events, which should be self-explanatory: EVA_CloakedUnitDetected and EVA_SubterraneanUnitDetected.
---
Implemented a global decloak sound
[AudioVisual]DecloakSound= (soundmd entry, defaults to [AudioVisual]CloakSound=)
This is used as default value for the techno-specific DecloakSound=.
---
Cloak now affects units regardless of their flying height
Moved the height check to the cloak generator handling. Thus, units self-cloak just fine, but cloak generators will not reach uncloakable units above HoverHeight.
This way, the game does not second-guess units being allowed to cloak (either by Cloakable=yes or by veterancy).
---
Customizable cloak height
[General]CloakHeight= (integer, defaults to [General]HoverHeight=)
The height under which units are affected by cloak generators. Units moving above this height will not be affected (though they can still self-cloak). Yuri's Revenge original value is 0.
-------- end of list
Summary
SensorArray should work. Note that SensorsSight is used instead of CloakRadiusInThisTagNameIsTooLong.
If you want BalloonHover units to be cloaked by generators, set CloakHeight to a higher value. To not cloak hover units (original behavior), set it to 0.
You can now change the decloak sound for all units in one go.
If units can self-cloak, they will. Even aircraft and BalloonHover units.
From my point of view this concludes the cloak stuff.
---
edit: Well, not quite. This should also fix another bug I didn't see: Spawned aircraft also supporting Cloakable.
And, while we're at it: What should happen to self-cloakable Powered=yes buildings in low power situations? Uncloak or stay cloaked? I'd make it customizable, but I still need a default value here. I think something like Cloak.NeedsPower would be possible, defaulting to no to not break older codes. Thoughts? _________________ QUICK_EDIT
I think something like Cloak.NeedsPower would be possible, defaulting to no to not break older codes. Thoughts?
Default to no, as that's how it currently works. Altough on a side note, how does powered unit logic and cloak interact at the moment? Do they lose the cloak when the building they're connected to is destroyed and so on?
The new changes look pretty interesting, will be testing them out later today. _________________ QUICK_EDIT
Implementation is rather simple: If a unit is deactivated, by whatever means (low power, no control center, EMP, no operator), it cannot cloak and thus will uncloak. _________________ QUICK_EDIT
SensorArray doesn't reveal subterrainan enemy health bar, thus its exact possition stays unsen for player. Radar events helps but not much.
Also, can it be made to EVA_CloakedUnitDetected and EVA_SubterraneanUnitDetected sound reports have a bit longer delay, but radar events more frequent?
I have also noticed a visual bug with buildings.
Once MSA deployed, only active animations will be seen. Bug will gone if you refresh screen. (SA1.png)
Once MSA repacked, buildings stay seen but not an active animation. Bug will gone if you refresh screen. (SA2.png)
SA2.png
Description:
Filesize:
239.61 KB
Viewed:
11035 Time(s)
SA1.png
Description:
Filesize:
128.77 KB
Viewed:
11035 Time(s)
_________________ Gangster is a Project Perfect Wuj (c)Aro QUICK_EDIT
My main request (although probably a big one) for Ares at this point is the option to separate the ROFs for primary and secondary weapons. Essentially, a system where I could have a unit fire its secondary DeployFire weapon with an ROF of 1000 but allow the unit to continue firing its main weapon while its secondary "ability" charges back up.
Also, on a much smaller note, the bug that sometimes causes units with DeployFire logic to randomly switch which weapon they are firing at the ground (first fires their secondary, then starts shooting with primary, and vice versa) screws up a lot of my favorite unit ideas.
Should I file blueprints/bugs for these or is this thread enough? _________________ New name: Sir Prize. I've switched to a new account to update to the name I've been using everywhere else for the last several years. QUICK_EDIT
I guess i saw a different unit, because i thought that i saw Sensor Array revealing underground Devil's Tongues... But then, that was very long ago.
DeployFire bug is easily fixed by adding MinimumRange=1 to the primary weapon. It will no longer try to use it on deploy (if what you want is a secondary with AreaFire=yes, or similar).
Also, i just noticed, flying units (including jumpjets) still can't use cloak detection. QUICK_EDIT
Perhaps subterranean unit detection could be marked with an animation that's visible on the ground like with units behind an object. _________________ mentalomega.com QUICK_EDIT
Also, i just noticed, flying units (including jumpjets) still can't use cloak detection.
Edit: You are apparently talking about Sensors=yes. I did not immediately realized this, all that is written below applies to Cloakable=yes
In fact, it works, but with certain restrictions.
After as a unit removes cloak, he needs to be on the ground to restore power cloak. This applies to all air units, including AircraftTypes.
I do not think that's a mistake. This is a feature that is not configurable. If and do something with these, only so that it was customizable.
Edit 2: This is fixed in 13,260,385. But I would like to fix it could be turned off (at least for all units). QUICK_EDIT
Detected submerged units should display health bar
Buildings are redrawn when Senor Array is enabled/disabled
Parasites will not exit cloaking units any more
---
[BuildingType]Cloakable.Powered= (boolean, defaults to no)
Whether this building will uncloak in low-power situations. Otherwise the building will stay cloaked.
---
Prevent objects from being cloaked
This can be used to create Tiberium Wars stealth generators like the Disruption Tower.
[TechnoType]Cloakable.Allowed= (boolean, defaults to yes)
If set to no, this object is not allowed to be cloaked (neither through self-cloak nor through Cloak Generators).
--- end of list
Gangster: I tell the game that a certain event like stealth detection occured. The game then decides how often/when radar events and sounds are to be displayed. I don't want to change that.
Worminator: I won't touch the weapon code. It does not distinguish between weapons, and unhardcoding that would take way too long. Blueprints are always better, because I won't look up all the old stuff again when the next version is in focus.
mevitar and MigEater: I don't plan to change flying sensors. YR doesn't update that stuff (and not accidentally), which looks like a design decision. Fast moving units with large sensor radii would be a possible cause of lag. I'm not touching that now. _________________ QUICK_EDIT
Detected submerged units should display health bar
Buildings are redrawn when Senor Array is enabled/disabled
This two works as they should, it seems! I might do more tests today.
AlexB wrote:
Gangster: I tell the game that a certain event like stealth detection occured. The game then decides how often/when radar events and sounds are to be displayed. I don't want to change that.
Okay then.
You made it exact same way as in TS, I can't complan, but...
But can it be made to not react on Buildings and, maybe, unarmed vehicles. It might needs more brainstorming, so let me explane my point: If it constantly repeat reports when then the real threat is coming up towards to me its okay.
But what if I just want to observe enemy's base with my sneaky MSA. This way nothing realy serious happen but EVA keep talking and talking... annoyng, really. _________________ Gangster is a Project Perfect Wuj (c)Aro QUICK_EDIT
Unarmed, like a Harvester stealing your precious ore? Like harmless Vehicle Thieves and Spies? Like a Radar Jammer, Mine Layer or MAD Tank? Like an APC full of Terrorists? Like an MCV that deploys next to your base, but you won't get a message because the ConYard is a building?
Seriously: Yes, I can add a TechnoType tag that changes this, and mutes EVA and the Radar Events (that would make a good band name). _________________ QUICK_EDIT
Maybe there could be a threat rating threshold for EVA/radar alerts.
Also what about making CloakingStages a per-unit tag also? The reason being is if you want a unit to cloak super-quickly, CloakingSpeed only helps up to a point. It still has to cycle through the stages and takes a second whereas CloakingSpeed=1 and CloakingStages=1 would be an instant decloak. QUICK_EDIT
CloakingStages could also be deglobalized if CloakingSpeed isn't enough, but that is something for tomorrow. Then it is enough cloak for now, because I also want to include the other things already finished.
edit Sept 19: new binary.
Cloak crate bonus will be replaced with money if a Cloakable.Allowed=no unit collects them.
SensorArrays will use SensorsSight for radial indicator
[TechnoType]SensorArray.Warn= (boolean, defaults to yes)
Whether EVA warnings and radar events are generated if an object of this type is detected. This does not hide the object from the sensor array.
[TechnoType]Cloakable.Stages= (int, defaults to [General]CloakingStages=)
edit Sept 20: new binary.
[InfantryType]Cloakable.Deployed= (boolean, defaults to no)
Whether this infantry is only allowed to self-cloak when deployed. Requires Deployer=yes and Cloakable=yes. _________________ QUICK_EDIT
Bumping double post. Apparently, edits aren't that discoverable.
That stuff in the post above could need some confirmations. I'll have to think about CloakStop and BalloonHover units a bit more, then I hope I can finally move to the Tiberium features. _________________ QUICK_EDIT
SensorArrays will use SensorsSight
SensorArray.Warn=
Cloakable.Stages=
havn't seen any flaws with this so far.
EDIT:
Cloakable.Allowed= is okay and was usefull to fix cloaked garrisoned building bug
Cloakable.Allowed=no never recives Cloack crate. _________________ Gangster is a Project Perfect Wuj (c)Aro QUICK_EDIT
Perhaps subterranean unit detection could be marked with an animation that's visible on the ground like with units behind an object.
I was going to suggest this.
Use the hidden object indicator already present in the game to mark subterranean units.
Use the same indicator on detected stealth units, but leave the unit graphics as transparent, same as the unit owner's cloaked view.
Detected submerged naval units should be represented the same way, as displaying health bars is just a bit odd and not that good looking in game.
This would make identifying subterranean and enemy cloaked units a breeze in the heat of battle. I suggest these as they seem the most user friendly options in the aspect of game play experience. QUICK_EDIT
I'm done with the cloak features for now, and I don't want to add anything more before all the features already done are included. I'll look at the open issues tomorrow and then work on a different group of features. _________________ QUICK_EDIT
I can't order a force fire on my own\allied\enemy units cloaked ( with self cloak or stealth generator) BUT seen by any way: Allied view or short time revival while taking damage (no idea if it also happen with use of sonar pulse SW) unless I have a unit with SensorsSight >0 near by.
EDIT:
nvm, I've thought it's bug but this is a usual for vanila YR. _________________ Gangster is a Project Perfect Wuj (c)Aro QUICK_EDIT
Enough cloak for now. As promised, now the first set of features from Tiberian Sun. There's a new ft-tiberium branch, called Tiberian Fun on the unstable binaries page. It contains some stuff explained below.
Tiberium Heal
[General]TiberiumHealEnabled= (boolean, defaults to no): Whether tiberium heals units that can heal on tiberium. This has to be enabled to make tiberium heal work.
The feature works the same way as in Tiberian Sun.
[General]TiberiumHeal= (double - minutes, defaults to 68/60 = ~1.13333, once every 68 seconds) The interval between healing steps being applied.
[TechnoType]TiberiumHeal= (boolean) Can this techno heal if standing on a cell containing Tiberium? Defaults to no.
The health restored depends on the type; see IRepairStep and RepairStep.
Ares also supports the TIBERIUM_HEAL veteran ability, which can override [TechnoType]TiberiumHeal=.
When technos that have TiberiumHeal=yes are destroyed, they leave behind a random amount of tiberium. The veteran abilities are not considered here, and it will not leave tiberium.
Tiberium Damage
Tiberium damage known from Tiberian Sun, but not limited to infantry types.
The damage delivered when entering this cell is a 10th of the tiberium's Power= value, but at least 1.
[General]TiberiumDamageEnabled= (boolean, defaults to no): Whether tiberium damages units that are not tiberium proof.
[TechnoType]TiberiumProof= (boolean) Whether the unit is immune to tiberium damage. TiberiumProof defaults to no for InfantryTypes, otherwise to yes. This is congruent with Tiberian Sun's original behavior.
This feature also supports the veteran ability TIBERIUM_PROOF.
Tiberium Spill
Harvesters and Refineries can be made to lose tiberium on destruction.
[TechnoType]TiberiumSpill= (boolean, defaults to no): Whether this object will spill its currently stored Tiberium on destruction. Requires Storage > 0.
The current implementation (lifted from Tiberian Sun) can spill up to 9 'bails', depending on Storage currently used. Harvesting units won't spill more than they can hold.
Tiberium Explosive
Units loaded with tiberium can be made to explode. This uses the tiberium's Power= value as in Tiberian Sun, but instead of using C4Warhead Ares requires a new warhead which defines a CellSpread. Tiberian Sun uses a hardcoded CellSpread=1.5.
[CombatDamage]TiberiumExplosive= (boolean, defaults to no) Whether tiberium inside of harvester units explode using TiberiumExplosiveWarhead when destroyed.
[CombatDamage]TiberiumExplosiveWarhead= (warhead) The warhead to use to deliver a damage that depends from the amount of loaded tiberium types and their Power= value.
Storage
Storage on buildings works like in Tiberian Sun, but it has to be enabled for each refinery building. If not enabled, resources are converted to credits as in Red Alert 2.
[BuildingType]Refinery.UseStorage= (boolean, defaults to no): Whether the building will store the tiberium instead of converting it to money directly. Tiberium that is converted does not require storage space.
Bonus money created by ore purifiers are always stored on the bank account instead of in the silos. This is because the bonus is calculated in tiberium bails, which would count against Storage. When the silo is destroyed, this bonus money would be placed on the map, which would create tiberium out of nothing.
EVA_SilosNeeded is played whenever the game feels like it.
Visceroids
If TiberiumDeathToVisceroid=yes, all infantry that die due to tiberium damage have a chance to be transformed into a small visceroid defined by [General]SmallVisceroid=. Implementation is the same as in Tiberian Sun, except for a check for whether SmallVisceroid is defined and a check for whether the unit could be placed on the map successfully.
When two units with SmallVisceroid=yes meet, they will merge into a large visceroid defined by [General]LargeVisceroid.
Despite its long time usage, TiberiumTransmogrify does not do anything. Not even in TS. Now it does.
[General]TiberiumTransmogrify= (integer - percent, defaults to 0): Chance of which an infantry unit dying due to tiberium damage transforms into a small visceroid.
Considerations
Extending Tiberium damage would allow for customizable warhead, damage and delay per tiberium type.
Transmogrify could be made customizable for infantry types, which would allow to create immutable infantry as well as changing the odds for visceroids to appear.
TiberiumHeal=yes units leaving behind Tiberium when destroyed could be made optional.
Until then, have fun! _________________ QUICK_EDIT
This one work very well. infantry and vehicles got healed and leave a tiberium patches after been destroyed.
Tiberium Damage
Here might be some math error? small values for Power= doesn't cause or cause very small unnoticeble effect. I could not made my infanty die on field with original TS Power= values. Large numers are working but since Power= also used on Tiberium Explosive it not a good idea rize it that much. I have had to rize Power= of both green and blue tiberium form 4 to 100\70 to 1750 to have a infantry damage effect similar to original TS.
It also might be good idea to add TiberiumDamageCoefficient= to control either it be a 1\10 of Power= or 1.0 or else
Tiberium Spill
Works. Harvesters, Refineries and silos are spill tiberium
Tiberium Explosive
Working. But again it coherent too much with Tiberium Damage right now. I have had to rize Power= of both green and blue tiberium form 4 to 100\70 to 1750 to have a infantry damage effect similar to original TS and then, explosion power of harvester full of tiberium was way too much.
Storage
Works. both Refinery and silos. But logic definitely requre at least working pipscales (and support for refinery and silo fill animation if possible)
EVA_SilosNeeded seems like not working. Never heard EVA reports when i was had not enough storage place.
Visceroids
TiberiumDeathToVisceroid=yes
not sure where this must be placed. I tried both [General] and [TechnoType] but could not get a Visceroid spawned. even with TiberiumTransmogrify = 100
Considerations
Quote:
Extending Tiberium damage would allow for customizable warhead, damage and delay per tiberium type.
Transmogrify could be made customizable for infantry types, which would allow to create immutable infantry as well as changing the odds for visceroids to appear.
TiberiumHeal=yes units leaving behind Tiberium when destroyed could be made optional.
Nice!
PS
Do you have any plans on re-enabling\fixing ChainReaction= and Explodes= tags for tiberium overlays?
Explodes= tag working but it doesn't respect TiberiumStrength= right now, while ChainReaction= is ingored at all. Also IIRC it uses BarrelExplode= for explosion animation and C4Warhead= for warhead, it be a good idea to unwire this to TiberiumExplodeAnim= and TiberiumWarhead= (or reuse TiberiumExplosiveWarhead= again)?
Tiberium pip colour controls? _________________ Gangster is a Project Perfect Wuj (c)Aro Last edited by Gangster on Thu Sep 26, 2013 6:18 am; edited 5 times in total QUICK_EDIT
Tiberium damage is applied when units enter a cell, not repeatedly like Tiberium Heal. So for Power=4 and 70, infantry should get damage of 1 and 7 once.
TiberiumDeathToVisceroid=yes goes under the [Basic] section, it should be on by default. Did you set [General]SmallVisceroid= to a vaild VehicleType?
The crash happens because the game wants to play the building's Special anim, but it doesn't exist or isn't set up correctly (both versions, normal and damaged).
I haven't looked into Pips and ChainReaction yet. The latter might still work, but with the same problem that made a new TiberiumExplosiveWarhead tag necessary (the hardcoded CellSpread that YR does not support any more).
Thanks for the test results so far. Gotta look up some more stuff, then I'll answer the rest. _________________ QUICK_EDIT
Tiberium damage is applied when units enter a cell, not repeatedly like Tiberium Heal. So for Power=4 and 70, infantry should get damage of 1 and 7 once.
Yes I know it should, but I carfuly tested it. I made my infantry run constantly here and there on tiberum field for decent amount of time. it and none of them was hurt with Power= 4 and 70. >.<
I hope someone else will be able to test this too.
AlexB wrote:
TiberiumDeathToVisceroid=yes goes under the [Basic] section, it should be on by default. Did you set [General]SmallVisceroid= to a vaild VehicleType?
Ah so it map specific. It was no by default, but toggle it yes havn't work either. And yes, I did have everything set up before start testing:
Code:
...
SmallVisceroid=VISC_SML
...
; Small Visceroid
[VISC_SML]
UIName=Name:VISC_SML
Name=Baby Visceroid
Nominal=yes
Insignificant=yes
Image=VISSML
Strength=200
Category=Civilian
Armor=light
TechLevel=-1
Sight=0
Speed=5
;Owner=Civilian
AllowedToStartInMultiplayer=no
Cost=1
Points=50
ROT=16
Explosion=TWLT070,S_BANG48,S_BRNL58,S_CLSN58,S_TUMU60
MaxDebris=0
TiberiumHeal=yes
Locomotor={4A582741-9839-11d1-B709-00A024DDAFD1}
MovementZone=Normal
SmallVisceroid=yes
ThreatPosed=0 ; This value MUST be 0 for all building addons
ImmuneToVeins=yes
WalkRate=2
OmniCrushResistant=yes
SensorArray.Warn=no
AlexB wrote:
The crash happens because the game wants to play the building's Special anim, but it doesn't exist or isn't set up correctly (both versions, normal and damaged).
Thank you. I ll check my code then.
AlexB wrote:
I haven't looked into Pips and ChainReaction yet. The latter might still work, but with the same problem that made a new TiberiumExplosiveWarhead tag necessary (the hardcoded CellSpread that YR does not support any more).
Again, thanks to you. Glad to be helpfull _________________ Gangster is a Project Perfect Wuj (c)Aro QUICK_EDIT
Good day sir! Any news about customizable airstrike laser lines, the color of its painted target and called airstrike voice? Thank you very much for everything! _________________
Lin Kuei Ominae wrote:
Why is the picture so blurred? Do you converted it from pcx to jpg to bmp to jpg to tif to jpg to gif to jpg to png?
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