Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
DFD: 991 vs. 332, 588 vs. 328
(21.07.2010, 19:14:10)Marshall Wrote: Preventing weapons from using up ammo might be useful for dummy or basic weapons and is immediately usable. Graphics options don't offer anything to change the gameplay and are only usable by someone with time and inclination to work on new graphics.
Support 558, kill 328.

It sound like you think that graphic-related features are useless.
Graphics in my opinion are much important as gameplay.
If vehicle can have sequence, they can have stuff like secondary weapon animation and more stuff.

Support [0000328]
Kill the other
Java student.
While I understand the logic behind wanting stacking superweapons, it doesn't fit with the rest of RA2 IMO, a better solution to having a benefit from multiple superweapon structures IMO would be to have a build multiplier like factories do, so having more gives a faster charge. Stackable superweapons is like having stackable factories, where every factory has its own queue, it may be how other games play, but not RA2.
Beowulf, there is a nearly perfectly functioning workaround that only requires a little bit of extra work to pull off. Black Shadow has already presented everything necessary to get multiple stacking superweapons functioning perfectly, and with the "section templates" system there is hardly any clutter and very little work involved. If you are too damn lazy to make a few clones of a building and a superweapon, then you don't get to use multiple instances of the same superweapon. Plain and simple.

The vast majority of Ares' features either fix bugs or enable modders to do things that were previously impossible. Very few issues of mere convenience have made it into Ares' feature list, and TBH I would like it to stay that way. Modders have to put in the work for their mods too, you know. If there is a way, you simply need the will.

Anyways, for the fights:

Fight 1:

Firstly, to all of you putzes that are saying ore cannot grow or spread outside of the cell it was created in, that is dead wrong. Not only is ore able to grow and spread in the stock game (albeit at a rather unnoticeably slow rate), but this rate can also be tweaked to make ore grow and spread just like tiberium, and perhaps faster. The ability to have different ore types will add great strategic depth to the game, because you can make maps with ore as your basic resource, then something like gold as a more valuable and strategic resource and then gems as the most valuable. This would force players to make decisions, to go for the safe but worthless ore, the risky but valuable gold, or the hard-to-reach and dangerous, but incredibly valuable gems. A skilled mapmaker can make each position risky enough and vulnerable to attack but rewarding and worth the investment in protection that the player puts out for that specific resource, that is if he is able to protect it.

I think in the hands of a dedicated and hardworking modder and a skilled mapmaker, Issue #991 can make a vastly bigger difference in the outcome of a game than stackable superweapons would. And as said earlier, there is a perfectly functioning workaround for stackable superweapons that takes just a little bit of creative thinking and (ab)use of currently implemented Ares features.

EDIT: Also, issue 991 largely involves a restoration of an old TS logic. While the related coding may not be in the YR engine due to the fact that RA2/YR is based on the TS (and not FS) engine, it has been done before and if they hack the FS exe they can find the needed code.

Relatively simple, right? Maybe not the easiest thing to do but since the wheel has already been invented, the way is already paved for this to be implemented.

On the other hand, stackable superweapons is an attempt to circumvent and override a very fundamental and basic element of the game, and that is the fact that many management objects are global to that player or house, like superweapons. The request is attempting to override that fundamental, basic element and attach individual superweapons to individual buildings, and not only have the buildings manage the superweapons but then you also have to link these individually managed weapons to the global spectrum of the player/house's control structure.

Sound complicated at all? The work required to pull magic like that off vastly exceeds the amount of work needed for the modder to implement the rather simple workaround that already exists and works.

As for Fight 2:

Issue 588 is a bit of a dud. Even the original poster of the issue wanted it closed as a duplicate in favor of a different issue that has a much more sensible implementation plan in mind. That said, I support Issue #328 because I have seen many modders making use of SHP vehicles and they definitely need and deserve some attention for all the hard (and dazzling) work they have been doing.

For anyone who would say that SHP vehicle sequences wouldn't find SHP artists to care about them, that is a dead wrong assumption. In just that issue alone, 3 SHP vehicle artists have posted showing interest in this feature, and there are many more in the community who might take notice of this patch's feature and switch to ares for that reason.
Hey, just a heads up to the clutter of Superweapons clones, there is a multiple ini logic for the rulesmd.ini in Ares. So you could put this


Oh and conveniently enough, you can't clone superweapons yet, though probably will by the time stackable superweapons would be implemented.

Just a few things to keep in mind. Besides, there needs to be serious use for the feature, not just have an idiot or two (not anyone here mind you) "You balance 10 nukes, I want them in my mod!". While assuming it defaults to no, what the hell would you use this for. You could make a few Airport clones for maps, that isn't that hard. We're talking amounts that exceed 10-20 or so.

Just, by the way, no one would switch to Ares for one feature, maybe a combination of them, but not one. That said, you need one feature to have a combination of features. Though personally, no one seems to care about graphical features. Its ALL about gameplay, which I find stupid, though I don't see any mod that would take big interest in this feature, only exploit it once it is there. Which can be said about any feature.
[Image: darkstormsmall.png]
Fight 1:
I'm sorry, perhaps I missed the bit where there is a work around that will allow me to capture 3 tech airports and get 3 paradrops?
Just because it is called a "super" weapon in code does not mean it is uber-powerful, and, as stated before, balance is not relevant to a feature's inclusion.
Whilst the idea of reducing charge time is nice, it's not the same as hording 3 paradrops and having them all ready to go at once.
Given the new customisability of super weapons, I see this being a useful feature, could be useful for different types of SW implementation and different game modes. Whereas new ore tree types... I can't think of anything useful to say about them.

Fight 2:
I never said graphics features are useless, just that gameplay features are far more useful.
Ever wondered what the hell is going on?
Believe me friend you're not the only one.

Check out Launch Base for RA2/YR -
Also home to the Purple Alert mod, 1.002 UMP, and the YR Playlist Manager.
1) I support #322, because I could make more use of a stackable superweapon than new trees. I've already planned the implemention of such a super weapon with complete design, so this feature will shorten my to-do list, which is great for me. Smile
I don't care which feature comes from game X. If it's from TS, Generals, whatever - does it matter? You should pick what suits to you (or your modification) instead of focusing to implement all game X features into Ares.

2) I support #588, because I have also planned this to implement for a piece of units. I think it's more useful than the graphic thingie because gameplay -> graphics. After all, I'm not very good at creating SHPs or VXLs.
Too all who may call me an "anti-graphic-feature-whore" now, super detailed animations and shiny graphics are nice, but aren't required, it's the gameplay that matters (e.g. Starcraft).
1) both is very hard choice for me 991 is one logic that need for my personal project and i have no business with 332 at all however when i look on both and take time to consider i think 332 will be more useful for most people than 991 because most people in community still make unit mod more than Total conversion and not all total conversion need 991 finally i consider to kill 991 support 332. however both is very good logic.

2) it's 328 for sure! because it's what i fighting for. 588 is very good logic but when you creation the mod how many unit that you need to use this? for me it's only 3 that's the most i think, but 328 can be for for whole. everyone may not artist but i can say this logic is the key to future for Ra2YR modding, it's not just improve graphic but "it make vehicle unit can do anything that infantry can" how about deploy like infantry , jumpjet without facing attack problem like infantry , swim like infantry ,idle when stand still like them etc... all it need just good art to make it happen, it may not useful for new unit mod but this's the future of TC mod.

Support 328 and Kill 588

for me Graphic is first impression it's the first thing i can sense and make game worth to playing [and lead me to play it], gameplay good or not it still need graphic to fill it. i can't say what is more important but both should work together that will be the best. keep them balance.
I know balance shouldn't be consideration but this feature has so much balance issues that it is unlikely to be used. While I can't say that for sure, I really can't think of much use for this unless it was used for a terribly weak superweapon or tech airports.
[Image: darkstormsmall.png]
That link in the comments on #991 just took me waaaaaay back. *weeps* Good ol' times.

Fight 1

I have been linked trying to do exactly what #991 wants in its it is obvious I have a certain interest in the topic.
That doesn't mean I'm not giving #332 a fair chance, of course.
In fact, I find the reasoning behind it rather convincing, not the least because of the Soviet Nuke Silo.
For all the other SWs, you could come up with explanations - there's only one weather to control, you can't warp spacetime from two different locations or the universe will explode, stuff like that. However, for Nuke Silos, it simply makes no sense: You have two silos. You have two missiles. Why do you only get to use one?
Marsh's paradrop example was also very good - if you have three airports, which, each individually, can provide a paradrop, why can two of them not provide two paradrops? It makes no sense, logically. It is most obviously a game design decision.

To me, it comes down to effect. Stackable SWs make sense. They're a simple, clear, straight-forward request with logical reasoning behind it. It's a wonderful request.
But it just doesn't do much.
I guess I see it like this: #991 enables you to add something new to the game. #332 only allows you to add more of the same. A third resource can change the dynamics of the game completely. A second nuke is...a second nuke. Just like the first one, just one more.

So while I love #332 as a request (I wish they were all like that), I'm simply drawn to #991.

Kill: #332
Support: #991

Fight 2

The first thing I thought about when seeing #588 was ammo on weapons and how it'd enable the exact same thing, essentially. Turns out Worm is right, and the original requester did indeed request #588 to be closed. That's what happens when we have hundreds of issues - stuff like that goes by unnoticed.

And if you look closely at #328, you'll see that it recently gained an implementation-branch.

Therefore, I guess it's easiest to just close #588 as requested and take #328 out of rotation.

Kill: #588
Support: #328
Forum Rules

(01.06.2011, 05:43:25)kenosis Wrote: Oh damn don't be disgraced again!

(25.06.2011, 20:42:59)Nighthawk Wrote: The proverbial bearded omni-bug may be dead, but the containment campaign is still being waged in the desert.
Fight 1
I'm also in favor of the new Tiberium/ore tree types. Not because it's easier to do but because the stackable super weapons are just another SW issue, and there's still one big issue to make them clonable at all. If they aren't clonable it would still be possible to allow them to stack but cloning is the more important feature here.

Stacking makes sense. You could set BuildLimit on the SW building to limit the number of SWs of a specific type. You could only allow the weaker ones to stack. You could make the stronger ones weaker. BuildLimit=1 and Capturable=yes for more strategic depth. There are millions of ways to balance them.

There should be one icon for each type of SW, and it should show the status of the one that's charged most. If there are multiple ready ones, maybe there could be a small number drawn in the corner or something.

But for now, it's not stacking time. By the time clones work, the world will be a different one and this issue certainly will get implemented some day.

Fight 2
SHP sequences got quite a following here. And indeed it should get implemented.

As above.
Forum Rules

(01.06.2011, 05:43:25)kenosis Wrote: Oh damn don't be disgraced again!

(25.06.2011, 20:42:59)Nighthawk Wrote: The proverbial bearded omni-bug may be dead, but the containment campaign is still being waged in the desert.

Users browsing this thread: 1 Guest(s)