Joined: 09 Mar 2008 Location: Osaka (JP)/Hong Kong/Germany
Posted: Fri Nov 06, 2015 7:46 pm Post subject:
Ideas & suggestions
Projectiles and FireAngle
I know straight-fire projectiles have been a major request by the community for a long time. I have seen some discussions on how they could be implemented by toying with Gravity (maybe making Weight a valid tag on Projectiles, and similar ideas), but - and pardon me, my understanding of the code is very limited - I believe that this would cause issues because the engine does not only have to consider the projectile trajectory at the weapon's Range, but rather, at any point between the firer AND the maximum Range.
I think that maybe it should be considered to use the pre-existing tag "FireAngle" for creating straight-fire projectiles, and also allow the creation of many more customized trajectories.
Right now, the engine allows for three ballistic trajectories - "flat" (non-functional), Arcing and Lobber. These are, essentially, three discrete firing angles that we can currently use to customize projectile trajectories.
A theoretical ballistic curve consists of three variables - the angle, the range and the ceiling height, or zenith. Two of these have to be given for the third to be calculated.
In practice, there is another physical limitation, namely the weight of the projectile, or rather, the speed that results from it - I think these physical limitations should not be considered at all for projectile trajectory calculations in Ares, because using them to calculate a trajectory would turn the Range tag into a mere unit AI rule of "start firing at this distance" and demand calculating the actual range of a weapon manually every time a modder makes a weapon. So let's disregard them for now!
Of the tags which form the mathematical basis of calculating a trajectory, we have FireAngle, and the Range (at which the weapon is fired; ie the actual distance to target).
There is no tag remotely designed to input a ceiling altitude. But using Range and FireAngle, the engine can calculate these.
If FireAngle was a per-weapon tag enabled by Projectile>Arcing=yes (or homing, but that's another story), we could put in a horizontal angle, the engine would calculate the muzzle as the highest point of the arc and "drop" the projectile onto the target in an extended curve. This behaviour would be similar to the behaviour of shells in Generals.
The FireAngle tag could also be used to create any other angle - it could create mortars with Lobber-like angles, or the regular Arcing shell (presumably a howitzer) at 45° or so.
Note that this still means that the projectile DROPS onto the target cell, as with arcing - just the curve is flatter. My understanding of the engine is very limited, but to make it move in a real "line" and explode in the horizontal probably requires different coding - although uncoupling the forced terrain from Projectile>Level could be the obvious avenue. _________________
Mao Zedong wrote:
Our mission, unfinished, may take a thousand years.
Last edited by Millennium on Sun Apr 17, 2016 2:32 am; edited 2 times in total QUICK_EDIT
That's long winded way of asking for direct shot projectile logic...
Keep in mind, FireAngle also tilts the barrel (if present) and it may sometimes be not wished for (say it was already tilted in place by hva etc)
Main issue is rather that game doesn't know to handle elevation properly for these straight shot projectiles so bound to always hit cliffs and the sort as nothing in the game tells tank to rotate barrel upwards if aiming higher ground or else re-calculate projectile path. Gravity is most viable atm to lower the curve into flatter and faster regarding arcing logic, other approaches may need more work to be viable. QUICK_EDIT
Actully, there are only 2 issues now.
One is gravity, the gravity effect on the default projectile should be removed.
The other main issue is when fired from higher position to a building on the lower elevation.
The game uses building's height=value instead of its current altitude as target.(stupid mistake.....)
Overcoming these 2 should be much more easier than adding or remaking any system.
The game already handle this very well, only except these issue. QUICK_EDIT
Joined: 09 Mar 2008 Location: Osaka (JP)/Hong Kong/Germany
Posted: Sat Nov 07, 2015 2:22 pm Post subject:
If you remove Gravity on projectiles, arcing projectiles would not be possible anymore at all - an arcing projectile would disappear somewhere into the top corner of the map instead of hitting its target.
Unless, of course, Arcing=no/ROT=0 would imply Weight=0, and all others still considered Weight.
If you meant that, it does sound like an elegant solution. However, I'm not sure if such a projectile would be able to detonate at all, since it never "connects". Especially if the target "evades", could this perhaps cause issues with the projectile simply continuing on its flight path into infinity?
If the Gravity method is implemented, I would instead propose that non-Arcing projectiles can define a Weight, so as to make them drop into the ground at certain ranges. This would require the Weight to be set precisely on each projectile to make the curve distance match or exceed the Range of the weapon that fires it, but it would circumvent projectiles that continue into infinity. _________________
Mao Zedong wrote:
Our mission, unfinished, may take a thousand years.
If you can adjust gravity it is basicly like adjusting weight of the arcing projectile. However non-arcing have no concept of weight especially missiles. QUICK_EDIT
Joined: 09 Mar 2008 Location: Osaka (JP)/Hong Kong/Germany
Posted: Sun Nov 08, 2015 4:46 pm Post subject:
I'd just prefer [Projectile]>Weight for consistency, since the functions for it already exist... [Projectile]>GravityCoefficient or whatever would maybe require new coding for just this one feature... _________________
Mao Zedong wrote:
Our mission, unfinished, may take a thousand years.
Joined: 09 Mar 2008 Location: Osaka (JP)/Hong Kong/Germany
Posted: Sun Apr 17, 2016 2:47 am Post subject:
AdjacentTo, BuildableTerrain & PowerRange
I was recently playing good old Starcraft and it gave me the idea that it might be useful to have the ability to limit what structures are required near the placement of certain structures. Rather than allowing structures to be placed near any other structure of the same player, one could limit structures to a radius around Power Plants, for example.
Second, so far, there are three cases of defining the possible terrain ranges on which a given structure may be placed - regular structures can be placed on any Buildable terrain without Overlays. WaterBound structures can be placed on water. PlaceAnywhere structures can be placed literally anywhere - half on water, half on land, inside cliffs, into other buildings... How about a more customizable system for defining what terrain structures may be placed on? BuildableTerrain on a structure would take a list of terrain, BuildableOverlay might even take a list of Overlays, that the structure has to be placed on (or which have to be present within the structure's foundations) in order for it to be placeable at a location.
Thirdly, a "Pylon" effect could be replicated in Ares (without the next for the existent complicated workarounds) by allowing structures that are defined in PoweredBy statements to have a PoweringRange - a distance in which they power the units and structures that are PoweredBy them. If the unit or structure leaves the radius or the powering building is destroyed and there are no others present, the unit or building shuts down.
PsychicStrength
Perhaps a "psychic health bar" could be implemented, which takes damage when a unit is subjected to MC? When the psychic health reaches 0, the next MC will turn the target to the attacker's side and restore the PsychicStrength to full.
PsychicStrength slowly regenerates (customizable). This could allow a standardized way of implementing mind control, hacking and even Generals' building capture.
EMPThreshold
Expanding on the above (and referring back to an idea I posted as a request elsewhere), a "health" value that acts against EMP. When the unit has taken as much EMP frames of "damage" to its EMPThreshold, it becomes paralyzed by the overrun frames that exceed the threshold.
EMPThreshold slowly regenerates (customizable).
Trade
Perhaps Harvesters could be allowed to unload at the Refinery of other players.
Perhaps units with Storage>0, but current Storage=0 which dock at their Dock structure could, when that structure has current Storage>0, be loaded with ore, and then be sent to unload at a friendly player's structure of the same type, transferring money between the two players. _________________
Mao Zedong wrote:
Our mission, unfinished, may take a thousand years.
Give all buildings BaseNormal=no and your powerplants BaseNormal=yes.
Then you can only build around powerplants.
Millennium wrote:
Trade
Perhaps Harvesters could be allowed to unload at the Refinery of other players.
they can already (at least in TS and i'm pretty sure in RA2 too) as long as the players are allied with each other. _________________ SHP Artist of Twisted Insurrection: Nod buildings
Joined: 09 Mar 2008 Location: Osaka (JP)/Hong Kong/Germany
Posted: Sun Apr 17, 2016 6:46 pm Post subject:
Lin Kuei Ominae wrote:
Millennium wrote:
AdjacentTo
Give all buildings BaseNormal=yes and your powerplants BaseNormal=yes.
Then you can only build around powerplants.
Well yes, but would it not be useful for this to be abit more customizable, so that certain factions' structures could depend on being close to certain structures, but other factions' structures could be built next to others/any? If AdjacentTo could take not only structures, but even units, one could have "builder" units, like in Generals.
Quote:
Millennium wrote:
Trade
Perhaps Harvesters could be allowed to unload at the Refinery of other players.
they can already (at least in TS and i'm pretty sure in RA2 too) as long as the players are allied with each other.
I see, I didn't know that. What I believe still stands would be loading empty Storage units when docking them with positive-Storage structures. That would allow for supply/trade routes between players and could even add a strategic element, at least to missions and game modes. _________________
Mao Zedong wrote:
Our mission, unfinished, may take a thousand years.
Would like a bounty logic to be added to the next one, I'm sure it's one of the most anticipated (most used word right amirite?) feature. _________________
ayylmao on Discord QUICK_EDIT
Joined: 09 Mar 2008 Location: Osaka (JP)/Hong Kong/Germany
Posted: Tue Apr 19, 2016 11:18 pm Post subject:
I think Bounty is being hard worked on, it was even considered for 0.B I think (I remember a convo about whether Bounty should be derived from Cost, Soylent or its own tag), but apparently it didn't get finished in time. I'm confident we can expect it the next release, though. _________________
Mao Zedong wrote:
Our mission, unfinished, may take a thousand years.
I'd love to see bounty, but it will come when it's ready I assume. I wonder if customized Ore Purefier amounts will ever make it into Ares.
Also the bug with ammo logic with infantry inside bunkers is sad... but oh well, it'll be addressed at Ares developers leisure, I'm sure. It's actually not that important, rather have bounty and other stuff
Also long ago there was talk way back around ares 0.3 "I think" but not sure if this will ever happen. But a SW that will autofire when it's icon is clicked using ai-targeting. I still would really like to see this be a thing. _________________ 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: 09 Mar 2008 Location: Osaka (JP)/Hong Kong/Germany
Posted: Thu Apr 21, 2016 8:43 am Post subject:
I think I was the one who brought up manual-control ai-target SWs back then. I would really like to see those too, but there was some hard-to-solve issue (I'm entirely incompetent with computer technology) with network connections for online play. Makes no sense to me, but again, I have no idea about these topics.
And thanks Mig for pointing out that workaround! It works for most, but not all, SW types that one might have in mind for such a setup - for example, self-targetted paradrops that are called in through clicking the icon, but will always be dropped at the firing structure - that's one thing I would like to implement but which likely will not be possible until Ares makes manual-control/AI-targeting a thing for SWs. _________________
Mao Zedong wrote:
Our mission, unfinished, may take a thousand years.
Last edited by Millennium on Mon Feb 06, 2017 3:16 am; edited 1 time in total QUICK_EDIT
Too many requests to give exhaustive answers, so i'll pick a few.
Bounty: working on it. I just have to commit it to the Ares code tonight. Will be a very simple feature, not defaulting to Cost, no multipliers. It does allow to set values different veterancy levels, though.
PowerRange: No way. Checking every building for power is just slow if not implemented correctly. And plugging this into the game, which didn't have this in mind could easily make the game slower. Same reasoning as in the long Shield discussion from December 2014. Something similar has been requested years ago, with power grids.
Customized Ore Purefier amounts: No, won't happen. I don't know where I wrote about that already. Maybe on LaunchPad, or in some older thread here. Reason is that the ore purifiers are just counted, and this count is multiplied by a global factor. The game does not go through the list of all buildings of a player to calculate a factor from the specific building types. If implemented, it could be done using the same approach as academies.
Manual AI-Targeting for SWs: I like the idea and I find it a good feature. Just wasn't in the mood to think about implementing it. It's useful though, like for having an automatic Sonar which would always find subs. _________________ QUICK_EDIT
; example: "produces" a tank platoon to be dropped at the factory or rally point
[TanksContainer]
UIName=Name:Tanks ; for the sidebar
DeployToFire=yes
DeploysInto=TanksContainerDeployed
Immune=yes
LegalTarget=no
Selectable=no
Speed=100
MovementZone=Fly
SpeedType=Wing
TankDropSpecial is a ParaDrop SW that needs to be auto-firing, hides its cameo, self-targeted, Recharge=.1 (since 0 doesn't work). Give it SW.Anim=ContainerCollapse. Load it with whatever units you want.
Joined: 09 Mar 2008 Location: Osaka (JP)/Hong Kong/Germany
Posted: Sun May 01, 2016 3:23 pm Post subject:
Remaking Tiberian Sun's method of having the engine print the name of a unit onto its cameo, rather than having the text be part of the cameo graphic itself. Mostly a convinience feature, could be used to circumvent having to re-make a cameo several times for different languages, for people who are planning for multi-language releases of their mod:
artmd.ini:
Code:
[Section]
Cameo.String=*
Cameo.TextShading=
Cameo.String could be made to take either boolean, in which case it would default to 'no' and 'yes' would take the UIName= string of the rules object with the same ID, or else it could be made to accept a string itself. I think boolean would be entirely sufficient, but maybe other people are planning for things that would warrant a string separate from UIName to be used as a cameo text - extra-long UINames that would not fit on a cameo?
Cameo.TextShading= could be used to determine the amount of darkening to underlay the lines of text with.
...Perhaps even Cameo.TextFont=!? _________________
Mao Zedong wrote:
Our mission, unfinished, may take a thousand years.
Joined: 09 Mar 2008 Location: Osaka (JP)/Hong Kong/Germany
Posted: Sun May 08, 2016 5:15 pm Post subject:
Well, I think the only thing that's missing for that to work is changing CanPassiveAcquire to override the factor that prevents DeployToFire vehicles from firing unless ordered to.
...oh, and VehicleTypes as valid Survivors... _________________
Mao Zedong wrote:
Our mission, unfinished, may take a thousand years.
Posted: Fri May 13, 2016 11:44 am Post subject:
"PowerUp1AnimDamaged=" tag
Good day. Would like to ask if it is possible to fix the "PowerUpXAnimDamaged=" tag somehow? Encountered a problem using this tag when it is not showing the damaged anim at all.
Sir dodgevipergts asked a question sometime ago about building upgrade art and ended in his question about this tag not working:
Posted: Fri May 13, 2016 11:50 am Post subject:
Re: "PowerUp1AnimDamaged=" tag
vord wrote:
Good day. Would like to ask if it is possible to fix the "PowerUpXAnimDamaged=" tag somehow? Encountered a problem using this tag when it is not showing the damaged anim at all.
Sir dodgevipergts asked a question sometime ago about building upgrade art and ended in his question about this tag not working:
Joined: 09 Mar 2008 Location: Osaka (JP)/Hong Kong/Germany
Posted: Fri May 13, 2016 1:11 pm Post subject:
Just to clarify, this is not an official idea/request thread and I doubt that it can even be predicted that Alex will be looking at it any more at all (although I'm hopeful). _________________
Mao Zedong wrote:
Our mission, unfinished, may take a thousand years.
Joined: 09 Mar 2008 Location: Osaka (JP)/Hong Kong/Germany
Posted: Fri May 13, 2016 1:43 pm Post subject:
Vord's first post was in a very politely appelative form that made me believe he might have composed it under the assumption that he was appealing to Alex directly. It was a possible misunderstanding that I wished to clear up. _________________
Mao Zedong wrote:
Our mission, unfinished, may take a thousand years.
Millennium: I am looking, but several requests are the same as on LaunchPad, or have been requested in some other threads. It just takes too much time to estimate all of them. _________________ QUICK_EDIT
Joined: 09 Mar 2008 Location: Osaka (JP)/Hong Kong/Germany
Posted: Tue Jul 19, 2016 8:19 am Post subject:
Cursor Anims
Beyond just customizing cursors for units and weapons, how about allowing Cursor statements to take an animation ID, rather than a frame call for MOUSE.SHA?
That way, we could, for example, integrate the Tiberian Sun cursors without having to massively edit YR's actual cursor file. Or use the CURTCURS and BOMBCURS files. _________________
Mao Zedong wrote:
Our mission, unfinished, may take a thousand years.
AttachEffect.SetArmorTo= [ArmorType]
TechnoTypes affected by this effect will change its armor so that it can be fired by long range Juggernaut and Specter, or some other dummy tokens _________________ Last edited by cxtian39 on Thu Jul 21, 2016 8:35 am; edited 3 times in total QUICK_EDIT
This would actually allow things like separate radar vehicles for SAM units, where the 'launcher' would only fire when the enemy aircraft is within the range of both the launcher and the radar vehicle. I'd definitely abuse that.
Joined: 09 Mar 2008 Location: Osaka (JP)/Hong Kong/Germany
Posted: Sat Feb 04, 2017 4:10 pm Post subject:
Customizable SpeedType/Land
Additional SpeedTypes and Lands, including, perhaps, the possibility of setting Land to buildings, thus allowing some units to pass over/through buildings, even if using terrestrial movement. _________________
Mao Zedong wrote:
Our mission, unfinished, may take a thousand years.
I hope don't want to pile on the pile... but been I've been curious if fraidy cat logic can be something worked into an attacheffect or something similar to (chaos gas) that causes a loss of control of a technotype, making it wander aimless in a state of panic for a duration of time. Anyways thank you <3 _________________ Delirium.. QUICK_EDIT
Joined: 09 Mar 2008 Location: Osaka (JP)/Hong Kong/Germany
Posted: Sat Jul 29, 2017 9:26 am Post subject:
I've been wondering about the same effect, though using Fraidycat didn't occur to me.
On that note:
Maybe debug.log could be created with an indication of the particular INI in which an error occured. When using #include without keeping a strict account on what you've placed in which file, it is easy to become lost when following a pointer from debug.log. _________________
Mao Zedong wrote:
Our mission, unfinished, may take a thousand years.
That's difficult to do because all #included INIs are stored in the same object. It appears to load several INIs, but when the data is parsed into buildings, anims and so on, there's only one INI in memory, and there's no trace what section and what key/value pair came from what file.
What might work is to dump the INI in the debug log, but I'm pretty sure I would have dents in my head tomorrow, because every modder protecting their mixes would jump at me. _________________ QUICK_EDIT
Worrying about ini files in protected mixes is silly, they are already in plain text within the mixes and can easily be extracted without doing anything to fix the "protected" headers just by doing string searches. People protecting mix files should know this already and not blame you if people use some of their ini rules. QUICK_EDIT
AFAIK, zlixine already released a MIX unprotector and de-encryptor. INIs aren't safe any more. Neither are all the VXLs, SHPs, and maps.
BTW, I already asked a few times, and no one gave me answer, so I will ask here: Is it possible to fix the problem with Globals not being carried over through game sessions?
Can Globals be stored in a seperate file that is always read, with the values only changeable via Notepad or map triggers? _________________ 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.
Irregardless of the whole 'protected' mix files argument, not sure how dumping the internal, 'merged' INI to the log would actually achieve much. Much less if it's the separate ones. I mean, maybe I am missing something obvious here but I can't see how that would make it easier to figure out which of all of the split INI files is culprit for a particular parsing error appearing in the log.
Maybe it's better to just learn to keep track of your own INI files and their contents or just not use the #include system at all. _________________ QUICK_EDIT
AFAIK, zlixine already released a MIX unprotector and de-encryptor. INIs aren't safe any more. Neither are all the VXLs, SHPs, and maps.
Hah no, don't spread that misinformation, zlixine could never come up with that. Try aristurtle; And Askeladd made the unprotector. _________________ "Don't beg for things; Do it yourself or you'll never get anything." QUICK_EDIT
AFAIK, zlixine already released a MIX unprotector and de-encryptor. INIs aren't safe any more. Neither are all the VXLs, SHPs, and maps.
Hah no, don't spread that misinformation, zlixine could never come up with that. Try aristurtle; And Askeladd made the unprotector.
Sorry, my mistake. He was the one who uploaded it as a usable EXE on ModDB, that's why... _________________ 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.
Joined: 09 Mar 2008 Location: Osaka (JP)/Hong Kong/Germany
Posted: Thu Aug 03, 2017 5:23 pm Post subject:
AlexB wrote:
That's difficult to do because all #included INIs are stored in the same object. It appears to load several INIs, but when the data is parsed into buildings, anims and so on, there's only one INI in memory, and there's no trace what section and what key/value pair came from what file.
What might work is to dump the INI in the debug log, but I'm pretty sure I would have dents in my head tomorrow, because every modder protecting their mixes would jump at me.
Starkku wrote:
Irregardless of the whole 'protected' mix files argument, not sure how dumping the internal, 'merged' INI to the log would actually achieve much. Much less if it's the separate ones. I mean, maybe I am missing something obvious here but I can't see how that would make it easier to figure out which of all of the split INI files is culprit for a particular parsing error appearing in the log.
Maybe it's better to just learn to keep track of your own INI files and their contents or just not use the #include system at all.
I agree that a full-INI dump is excessive for a problem that can be solved with some fastidious file-keeping. OTOH, although MIX protection is crackable now anyway, perhaps if the INI was only dumped if a parsing error occured, this could be sidestepped? If a modder removes all instances of parsing errors prior to release (which can be expected), then the INI will never be publicly readable in the log. _________________
Mao Zedong wrote:
Our mission, unfinished, may take a thousand years.
AFAIK, zlixine already released a MIX unprotector and de-encryptor. INIs aren't safe any more. Neither are all the VXLs, SHPs, and maps.
BTW, I already asked a few times, and no one gave me answer, so I will ask here: Is it possible to fix the problem with Globals not being carried over through game sessions?
Can Globals be stored in a seperate file that is always read, with the values only changeable via Notepad or map triggers?
Unless something broke it in ares, globals have always carried over correctly, but weren't being saved in the save file correctly so loading a save would loose the global state. Since save games still don't work correctly with Ares I'd say that globals not carrying over in saves is somewhat moot. QUICK_EDIT
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