Just copy paste and search. It's not that hard to do instead of an overly complicated system AlexB would have to set up to save some keyboard commands. We can already have separate rules to relieve the clutter, it's a great system. As for file size, it's text, it doesn't take up much space. Default rulesmd.ini is 726kb it's really really small. Got 3 of the same tank? use comments to divide it. _________________ "Don't beg for things; Do it yourself or you'll never get anything." QUICK_EDIT
I don't understand the obsession with splitting rules.ini at all, it's easy enough to spend some time grouping like items to any schema you prefer, and anything you can't quickly scroll to can be searched in seconds. _________________ http://www.moddb.com/mods/scorched-earth-ra2-mod-with-smart-ai QUICK_EDIT
Joined: 09 Mar 2008 Location: Osaka (JP)/Hong Kong/Germany
Posted: Thu Mar 08, 2018 3:54 pm Post subject:
RehteA wrote:
How about a code reusement mechanism based on INI itself?
eg. We have
Code:
[A]
A Code
[B]
<A>
B Code
before INI parsing, replace '<A>' with all content below [A] :
Code:
[B]
A Code
B Code
If we also have [C] :
Code:
[C]
<B>
C Code
then the final INI for game to parse will be:
Code:
[C]
A Code
B Code
C Code
Of course, following patterns should not be allowed:
Code:
[A]
<A>
Code:
[A]
<B>
[B]
<A>
Isn't this homologous to the Prototype tag, just using a different notation? Because as far as INIs themselves go, we already have something like that, working via the read-order of the INIs (define MTNK to have 400 HP in the first INI in the list, if you re-define it to have 450 HP in an INI that is further down in the list, the second value will be applied in-game, while any other definitions will remain untouched). _________________
Mao Zedong wrote:
Our mission, unfinished, may take a thousand years.
Last edited by Millennium on Sun Mar 11, 2018 2:38 pm; edited 1 time in total QUICK_EDIT
OccupyWeaponSecondary has been something I've been wondering if at all possible. (been trying to stick Flak Troopers into buildings while retaining usefulness) QUICK_EDIT
Joined: 09 Mar 2008 Location: Osaka (JP)/Hong Kong/Germany
Posted: Sun Mar 11, 2018 2:44 pm Post subject:
I think it would be useful to do an overhaul of the tags that define OpenTopped/OccupyWeapon. For example, OpenToppedWeaponN/OccupyWeaponN, or let OpenToppedWeapon and OccupyWeapon accept arrays of the WeaponNs of the type. Of course, the question then arises of how one would define exclusions from the list of "normally-useable" weapons of the type - while OpenToppedWeapon is always a weapon that the type can also fundamentally browse to when not inside a transport, that is perhaps not desireable, and OccupyWeapon is always a weapon that is decidedly not available to a type outside a building. Perhaps another tag or list can be introduced to define weapons that can be used "in the open", or that can remove weapons from the array of weapons a type can use "in the open". _________________
Mao Zedong wrote:
Our mission, unfinished, may take a thousand years.
I suppose an OpenToppedWeapon would be useful, but I think OccupyWeapon is something that can be left alone, as it's useful enough as it is. Don't forget AlexB is currently a one-man-band for Ares development right now and overhauling a system that actually works as intended and well, seems a bit extreme. _________________ "Don't beg for things; Do it yourself or you'll never get anything." QUICK_EDIT
I agree with 4Star on this, it's just from my personal wish list. I still remember when I was younger and clamoring over new Tiberium types. I could probably create a flak weapon that is both air and land. The problem is balancing it because the flak weapon for ground units does 20 damage and air units is 8. I guess 15 would suffice. QUICK_EDIT
This would make your Damage=20 weapon do 8 damage to Aircraft with Air/LightAir/MediumAir/HeavyAir. _________________ "Don't beg for things; Do it yourself or you'll never get anything." QUICK_EDIT
UnitType->ShowTurretInsideTransport=yes
When this unit type is inside a transport, its turret is still shown. TurretOffset is respected.
TurretOffset2=
move the turret "box" left or right instead of forward or backward
Currently UnitType fires inside opentopped is using its own FLH's rather than the transport's AlternateFLH's. Just need a small visual effect to get multi-turret working. _________________
Prerequisite.Negative already works with Alternate Prerequisites, though. Just use the alternative one (like PROC for the Yuri Slave Miner). QUICK_EDIT
Regarding a prototype tag for INI parsing: There has been a request for that already.
I don't know what exactly prevented the coders before me to finish this. It might be because of the sometimes strange rules that apply when one section tries to inherit from a section that has not yet been defined. Or when #include files are involved. Or whether the order keys are copied over is indeterminate and thus might cause desyncs. Or something else.
I worked on this to keep it up to date with the advances in other areas of Ares, but I cannot guarantee that it works as you expect. Try for yourself, not officially supported:
Code:
; Has to go before the first section inheriting from this
[CivilanStructureBase]
TechLevel=-1
CanBeOccupied=yes
...
[CAPPM]:[CivilanStructureBase]
Name=Banshee's House
[CATAXSCAM]:[CivilanStructureBase]
Name=Church of Yurology
Note: This is a text copy and paste. Not context sensitive. If you inherit an Image= tag, it will just use it unchecked. If you inherit from an empty section (like one that hasn't yet been defined), you'll get a warning in debug.log. _________________ QUICK_EDIT
Inherit works pretty flawlessly for me, just make sure that anything that inherits is after the thing it inherits from.
My custom MCV code that is declared in an included file
Wait, this inheritance works? Why can't I find anything on it in the documentation then? It looks like it's one of the features that'd make the front page on the Ares DLL magazine _________________ 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.
One of the more existing tags I've been wondering if its possible to make UnloadingClass work as well for non-Harvesters. I.E: using the alternate Image when the unit is a Transport (I.E: An APC has its back open when ordered to deploy) _________________ ~ Excelsior ~ QUICK_EDIT
(I.E: An APC has its back open when ordered to deploy)
Then it never closes, when does it close its back could be a trick question here, especially when you order troops to get in... if loading/unloading is interrupted (player control, troops are killed, etc) it needs to detect it in order close the door earlier or not even open the door at all. _________________
It'll only use the unloading class when ordered to undeploy. Noticed how units try to face a certain direction when unloading. The Unit will revert back to its normal image when no other passengers are attempting to enter.
For something close I guess you could try to refer to the way it acted in Red Alert 1 with the APC,Transports _________________ ~ Excelsior ~ QUICK_EDIT
He's just clarifying that it's not the urban area option he's/she's talking about.
And as for urbanisation, it'll probably have to be enforced on the urban theatre. G-E already listed the reasons.
And if I may add on the request: newurban or at least lunar IF possible. _________________ 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.
Bollocks, it's impossible, need a whole new UI to fit it in.
Incase you didn't realize, that was sarcasm. I would like to see New Urban and Desert as well, desert and lunar don't even have cliffs to deal with, though urban areas wouldn't work on lunar so I could see that being a problem. Though if this is a difficult feature to implement, I'm more partial to the many easier ones first. _________________ "Don't beg for things; Do it yourself or you'll never get anything." QUICK_EDIT
Joined: 09 Mar 2008 Location: Osaka (JP)/Hong Kong/Germany
Posted: Thu Mar 22, 2018 5:32 pm Post subject:
How about expanding the SecretLab function to pick not just between units, but also between sets of units that become available together if the whole set is picked, and which cannot be picked without picking the rest of the set (unless elsewhere defined), akin to the EBFD UnitGroupTypes?
E.g.
Code:
SecretTypes=(DESO, YURI),SREF
may pick to make either Desolator AND Yuri available, OR the Prism Tank and nothing else.
Alternatively, the following notation may be used:
Code:
SecretTypes1=DESO,YURI
SecretTypes2=SREF
_________________
Mao Zedong wrote:
Our mission, unfinished, may take a thousand years.
With the recent addition of SW Iron Curtain targeting as applicable to Iron Curtain related scripts in the newest unstable build, it got me thinking about one AI issue that's existed for as long as the game itself.
For any unit with anti-air abilities, they will prioritize AircraftTypes over any other targets if in any sort of hunt mode (being released from EMP, chaos, mind control, almost being erased by Chrono Legionnaires, fire sale, etc). This also includes any teamtype whose current script action is 0,1 (attack, all). This feature is most annoying with teamtypes, where they should be targeting everything, but will immediately stray away from their current target if any aircraft are on the map. For example, if AI Siege Choppers are in hunt mode, they will attack everything as they should, but if say an enemy Spy Plane spawns on the complete opposite side of the map, they will leave their current target to chase down the spy plane.
I'm not sure how this feature can be altered, seeing as it may be useful for some people in its current state. I was thinking of maybe having a key under TeamTypes like "IgnoreAircraft = yes/no" meaning that even if the team's unit can target aircraft, they will not attack anything in the air unless fired upon, but this can be toggled on and off for any TeamType. Maybe it could globally default to no, and modders can just add the key in for any team they want to have it set to "yes" on.
I personally find this very annoying when my AI is using super units, but they suddenly leave the battle to attack some random aircraft instead, so making this an optional feature would be amazing. _________________ Tiberium Uprising (a few missions for TS): http://www.ppmsite.com/forum/viewtopic.php?t=31029 QUICK_EDIT
1. Can we please have a ROF attach effect. Would be a good alternative to gatling logic.
2. While on the topic of attach effect, can we have a attach effect cap as well, e.g.; AttachEffect.ROF.Cap=50% and a code that only affects the unit firing.
3. And can we have infantry/units properly alternating between NoAmmoWeapon and reloading when inside transport/garrison when using OpenTransportWeapon=-1 (decide normally, rather than have a selected weapon)
4. Lastly, can we un-hard code the garrison code so that weapon range is set to individual infantry inside rather than just a flat number i.e.; OccupyWeaponRange=, something similar to OpenTopped where the infantry can fire at their own weapon range. _________________
ayylmao on Discord QUICK_EDIT
1. Having ROF as an AE would be a useful buff, but as an alternative to gatling logic it seams a bit pointless. Why cant you just use a gatling system?
2. By default an attach effect cant go past the percentage set, unless you use AttachEffect.Cumulative=yes. I presume you want a secondary cap to help recreate the gatling logic tho, which again why bother? To make an attach effect only effect the unit firing it use an AreaFire weapon with a low CellSpread (0.5 etc). You can also use custom armor types to limit it further if need be.
I'd much rather see AE expanded so it can also work with aircraft. _________________
1. I use NoAmmoWeapon on my units to replicate a straight fire bullet that does no damage while the invisible weapon does the damage, so I can't get it to work with gatling logic by default reason I do this is because my straight fire bullet does not hit targets closer than 1 cell - and I like the aesthetics of it too much to go back to invisible bullets.
2. I've noticed that anything under .75 cellspread does not spread to the unit firing, haven't tested on infantry but that's the case on tanks, this is sometimes enough to trigger the effect on nearby units, custom armors also taken into consideration of course. _________________
ayylmao on Discord QUICK_EDIT
Is there any statement or update regarding the ancient request of allowing a unit production to result in a unit selected randomly from a list? The example used in the request was the implementation of the Technical in Generals, which shows up in (art-only) variations when produced. QUICK_EDIT
Random artwork for units has been asked for a few times in the past. IIRC it was not pursued because getting such a feature to also work with NoSpawnAlt=, WaterImage= & PassengerTurret= etc would be a nightmare.
AlexB wrote:
It would. Either you restrict it to "only one of those on a single unit" or you would need to define a matrix of tags and filenames. Some things might work, like passenger turret and water image body voxel.
But as there's only two meaningful voxels (body and turret), modders would find out about the pigeonhole principle pretty quickly.
_________________ "Don't beg for things; Do it yourself or you'll never get anything." QUICK_EDIT
Posted: Mon Apr 09, 2018 11:38 am Post subject:
Suggest Inheritance feaure
This feature helps moder to edit INI file faster, not for game play
I like special syntax += for Techno ID generating of Ares, so I think this feature is another good one
This can give AI trouble. If you specify UnitA in TF and AI tries to produce it but UnitB comes out...
Perhaps AI should completely ignore this and you can just randomize your TFs _________________
Hey! Not sure if it's possible, but it would be great to have a transport vehicle (Or any vehicle) being able to heal its passengers.
Or auto-healing inf to continue healing themselves in transports.. _________________ 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.
One Mental Omega player experimented with expanded unit descriptions, and despite the concerns previously expressed by AlexB that this kind of tooltips requires implementation of an additional special smaller font I think it actually looks fine. So I'm back with the same suggestion: add a second UIName= text box (Extra) in addition to the main one, say UINameExtra=, which would be used for larger tooltips that include something else than just unit's price and name. This allows for some brief descriptions, whih would be handy because not every mod can afford a website or a manual to list everything you need to know about the unit. This is intended to work under the following principes:
- By default there are limits on how many characters and words you can put into the tooltip, the tooltip box is also limited by the widht of the sidebar - the Extra should have these limits expanded. Definitely the character limit should be increased 2-3 times, and text box widht can either be expanded (provided it can be rendered ontop of BOTH sidebar and the battlefield itself that is) or limited to screen horizontal resolution - it is modmaker's responsibility to not write everything into a single line.
- Unit's name and price should stay in the main text box that is UIName=
- The top edge of Extra box should be attached to the bottom of the main tooltip text box, like this:
- the Extra text box should be displayed only when you hover the cursor over sidebar elements (cameos), never for unit on the battlefield
- the Extra text box should be affected by Tooltips checkbox in the settings menu
- the Extra text box should not be displayed if UINameExtra is not present in unit's code (not sure if possible though) to prevent MISSING: or empty text boxes, or should default to some null value.
Alternatively, if adding a new text box with alignment properties mentioned above is not possible, there can be a different solution:
- Make UIName= box only display above units in the game, like a usual tooltip, NEVER over the cameo buttons
- Add UINameSidebar= box that is essentially the same UIName= but is only displayed above cameos and UI elements. Thus, there is one tooltip type for buttons and one for battlefield, not two separate boxes as the first idea suggests.
- Expand UINameSidebar width and character limits to allow longer tooltips
- Make UINameSidebar default to UIName if not specified otherwise
Making UIName box display owner's nickname in multiplayer (while making it possible to not be displayed for AI owners by map/general settings) would be a very handy addition as well, unless it messes up the Disguise system (spes displaying real owner's name)
I really don't like the look of a 2nd textbox being larger than the first tbh. I feel like it should all be in one box with a higher limit, like 255 or something. Separate cameo and battlefield tooltips seems reasonable though. Otherwise I think it's up to the mod creator to make a PDF or web page describing all the units like people have done in the past.
I'd say that's what tutorial missions are for, but 'ain't nobody got time for dat.' _________________ "Don't beg for things; Do it yourself or you'll never get anything." QUICK_EDIT
I really don't like the look of a 2nd textbox being larger than the first tbh.
Yeah, and I'm not even sure how it is supposed to be aligned - the original text box is aligned to sidebar border, but where the 0,0 point for this one would be? Might be even more complicated than I initially thought. Then the second variant of my idea would be better, and I think even easier to implement.
Though characters limit is not the only problem: the reason why I asked for textbox maximal width to be increased is this:
Ah that is a problem, but understandable oversight considering no original unit name is that long and ww's coding isn't the best considering they wouldn't align the text box to the left for some reason... _________________ "Don't beg for things; Do it yourself or you'll never get anything." QUICK_EDIT
Too much text. I would just use little icon on cameo. i.e. bullet icon for anti-inf, misl icon for AP, bomb icon for anti-sturct, etc _________________
Disclaimer: I'm not requesting you to do this at all, AlexB.
Would it be even remotely possible to revamp the game's resolution via ares injection DLL as far as the forced 1024x768 or 800x600 that most of the graphics are at? Like would it be possible to let the game read higher resolution splashes, pause menu, and stuff like that? I realize we have a launcher now with CNCNet, but it still uses the engine's original splash screen and ingame menu functions, so I was hoping maybe in the future that would be a possible change. Granted this engine is very old now and revamping the resolution might seem silly, but as a graphics person it's something I would put work in for. _________________ "Don't beg for things; Do it yourself or you'll never get anything." QUICK_EDIT
Inherit works pretty flawlessly for me, just make sure that anything that inherits is after the thing it inherits from.
My custom MCV code that is declared in an included file
Disclaimer: I'm not requesting you to do this at all, AlexB.
Would it be even remotely possible to revamp the game's resolution via ares injection DLL as far as the forced 1024x768 or 800x600 that most of the graphics are at? Like would it be possible to let the game read higher resolution splashes, pause menu, and stuff like that? I realize we have a launcher now with CNCNet, but it still uses the engine's original splash screen and ingame menu functions, so I was hoping maybe in the future that would be a possible change. Granted this engine is very old now and revamping the resolution might seem silly, but as a graphics person it's something I would put work in for.
It's pretty easy, me and dkeeton actually unhardcoded the loadscreen, menu and score screen resolutions, but the art shows in center of screen and all else is black so its a hacky way to go about it.
For a proper implementation however i think the sprites should scale with the res. _________________ Tiberian Dawn, Red Alert, Tiberian Sun ,Red Alert 2,Renegade, Command & Conquer 3,Tiberium and Tiberium Wars and Westwood related image & video archive
https://picasaweb.google.com/113361105083292812413?noredirect=1
Skype live:tomsons26
Don't forget to state who are you otherwise i'll ignore the invite QUICK_EDIT
Option to turn off NCO when a certain building is built.
[BuildingType]->NewConstructionOption=no
Usage: Let's say I want to let player build at most 5 nuclear silos, so I make 5 copies of the buildings as well as super weapons and play with prerequisite. Silo 2 needs silo 1, and silo 1 has neq prerq of itself and etc.
The problem here is if you build silo 1, silo 1 disappears from the sidebar and silo 2 becomes available and NCO is triggered, while in player's view there is no new construction option.
Multiple instances of same type of super weapon
Add an option for super weapon that if a player owns N buildings that provide this super weapon then that player gets N super weapons of this type. _________________
Multiple instances of same type of super weapon
Add an option for super weapon that if a player owns N buildings that provide this super weapon then that player gets N super weapons of this type.
I already asked Alex about this.
AlexB wrote:
because the game has one SW per type, and they are always global and unconnected to buildings This would have to be changed completely. I don't think that's gonna happen.
_________________ 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.
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