Posts: 119
Threads: 12
Joined: 3 Apr 2011
Reputation:
I've been quiet a while trying to get a feel for whats what, and I've decided to be the cheerleader/coordinator/coder (tenuously, that last) for issue 000634. It seems to be fairly popular and fairly complex, and needing lots of consensus about what it should look like. I want to try to tackle it, but obviously I'm gonna need a lot of help. The main idea I'm following is at the Bugtracker.
So the first question: How should we divide the units into lists? The big idea I've heard floated about is centered around tech level. For example, making separate tech levels for light vehicles, heavy vehicles etc. By separating them into different lists within rulesmd.ini, I'm hoping we can get the game to allow different tech lists to build simultaneously, kinda like the war factory and naval yard units. Faster unit production is always a good thing.
The other interesting idea (IMO) I had was to also separate buildings into different lists and have different MCV options. If there were different levels of MCV's available (IE outpost, FOB, Complex, etc), it could make gameplay more nuanced and engaging. Getting an AI to recognize and utilize the new options would be a chore, but I figure we can cross that bridge when we get to it.
Even if no one likes the idea, cares, etc, I think it would be good to consider this issue just on the basis of ideas generation. Let me know what ya'll think!
FormerAres Documentation Manager
Nobody here but us trees...
Graion Dilach Wrote:Worm, you know this guy is an American lawyer of some sort. Good one!
Posts: 156
Threads: 17
Joined: 9 Jun 2007
Reputation:
Have you read DCoder's comments on the issue? The feature is going to be done, just not as you seem to want it. The way you want it is quite a bit too complex. The way it's going to be done is to just force specific units to only come out of certain factories (specified on the unit). Separating them into different lists and stuff like you've described would be much too complex at the moment.
"The present is theirs. The future, for which I really worked, is mine."
- Nikola Tesla
"My - y - my - your - my vision has permutated. My - y - my - your - my plans have followed a path unpredicted by the union of Nod and GDI. Your - my - our - our directives must be reassessed." - Kane/ CABAL
Posts: 317
Threads: 25
Joined: 2 May 2010
Reputation:
02.06.2011, 18:35:18
(This post was last modified: 02.06.2011, 18:39:05 by Graion Dilach.)
You said you look over the Factory tag. But in the end it seems you didn't get the point with it.
There are 4 variations of TechnoTypes (buildable objects), AircraftTypes, VehicleTypes, InfantryTypes and BuildingTypes. Jumpjet and naval units doesn't have their own types.
If you say.. Factory=InfantryType, you defined the object as a barracks and it will produce all infantry in the game if their prerequisites are met.
The only option I could think about to get 634's big part fixed would be defining new values to Factory=... however since Factory reads types, you have to bring new TechnoTypes in. And here comes the problem... you can't define a new subTechnoTypeClass along with new subTechnoClass... if you rethink it. How should it be called, which one should it clone, etc.
Probably a way could be that masking the TechnoType into phantom Types (I mean, defining somewhere that GhostType=InfantryType and listing all GhostTypes in InfantryTypes) could be a starting point, but still, it's hard to do that masking for the factories while keeping the other logics intact.
My two cents.
EDIT: I just reread your comment... Factory defines which list it produces. So at the produced objects... not their tags defines their factory, instead the list where they're listed.
Posts: 1 773
Threads: 140
Joined: 22 Nov 2004
Reputation:
Uhhhh.
(Graion: There are factors other than Factory= that determine what object can be built from what structure. E.g. Naval= ...)
It is not complex to let each object define what buildings can produce it. The challenge is letting different buildings have independent production queues producing objects in parallel. The AI already suffers from a shitty case of this, because its poor little brain plans all VehicleTypes in the same queue, which means navy and ground forces don't get built at the same time.
Posts: 119
Threads: 12
Joined: 3 Apr 2011
Reputation:
03.06.2011, 05:10:28
(This post was last modified: 03.06.2011, 05:11:35 by Steel Mirage.)
And thats exactly the feature that I really want try to get into. Its the one thing that RA2YR doesn't have that I really really want, and if you want it, ya have to go and get it right?
@Tesla: I want to be clear about this: I mean to avoid insulting anyone at all costs. That said, just forcing units to come out of one building or another seems to be a half ass solution, and the feeling I get from reading the forums and bugtracker posts is that this community seems to be allergic to half-ass solutions. Like Npatch. Yeah, what I'm talking about would take a while, but its not like there's a deadline or anything. Uh, right? This is me hoping there's not a deadline...
@GD: I think you said what I was saying, just in a totally different way. As far as keeping the logics intact... I think it might be worthwhile to revamp a lot of the logic and just create completely new TechnoTypes. I realize that what I just said might be a lot like proposing to propel monkeys into space on methane, but if its possible, it might make a lot of other things a lot easier down the line. If its possible being the operative phrase. But defining new TechnoTypes and all that jazz would be a team effort. I wouldn't want that to be done arbitrarily. EDIT: Sweet mustache, man :-D
@DCoder: I was thinking lets get the feature working and then worry about the AI down the road... I have only a very fuzzy picture of how the AI works anyways, so...
FormerAres Documentation Manager
Nobody here but us trees...
Graion Dilach Wrote:Worm, you know this guy is an American lawyer of some sort. Good one!
Posts: 1 773
Threads: 140
Joined: 22 Nov 2004
Reputation:
Posts: 119
Threads: 12
Joined: 3 Apr 2011
Reputation:
03.06.2011, 07:07:34
(This post was last modified: 03.06.2011, 07:09:29 by Steel Mirage.)
Heh, thanks? I dunno, it looks like real pie in the sky stuff from my point of view too, and I can understand if ya'll are looking at me like "Whoa, this dude is nuts."
FormerAres Documentation Manager
Nobody here but us trees...
Graion Dilach Wrote:Worm, you know this guy is an American lawyer of some sort. Good one!
Posts: 120
Threads: 14
Joined: 18 May 2010
Reputation:
I think you should go for it. You can always drop out if its to complicated, or just make a replacement for the kennel hack(i.e no parallel building units).
Java student.
Posts: 119
Threads: 12
Joined: 3 Apr 2011
Reputation:
Thanks for the encouragement! My new question, as stated in the Bugtracker, is if I do work on this in just the standard rulesmd.ini, and everything else is being done in C++, would it be just as big a pain to translate it over? And if so, would it even be helpful?
FormerAres Documentation Manager
Nobody here but us trees...
Graion Dilach Wrote:Worm, you know this guy is an American lawyer of some sort. Good one!
Posts: 317
Threads: 25
Joined: 2 May 2010
Reputation:
Ehhhhh.... not really.
INIs are read by the C++ (YR) code, if no C++ (YR) code is attached to a tag, then it won't do anything.
Posts: 1 773
Threads: 140
Joined: 22 Nov 2004
Reputation:
(See, questions like that are a good sign you're in over your head.)
Posts: 119
Threads: 12
Joined: 3 Apr 2011
Reputation:
Yep, agreed. Damn. Gotta learn how to swim.
At least it'll be good practice. Hopefully...
FormerAres Documentation Manager
Nobody here but us trees...
Graion Dilach Wrote:Worm, you know this guy is an American lawyer of some sort. Good one!
|