I certainly wouldn't like to allow players the ability to change out of bBansNonStateReligions simply through traits or vice versa. I mean maybe.. just maybe with lvl 4 spiritual, but even then it'd be ridiculous powerful and I generally just don't like the idea. I think i'd prefer to just leave it in DH & civplayer8's hands.
Team Projects Committed
- Thread starter Thunderbrd
- Start date
I certainly wouldn't like to allow players the ability to change out of bBansNonStateReligions simply through traits or vice versa. I mean maybe.. just maybe with lvl 4 spiritual, but even then it'd be ridiculous powerful and I generally just don't like the idea. I think i'd prefer to just leave it in DH & civplayer8's hands.
@Thunderbrd:
You said last fall that you were willing to be more open and complete in explaining your development plans, and that you would break up projects into smaller and more frequent commits. This has turned out to be completely false, and I am quite unhappy about that. There needs to be some change to how you develop stuff or some of us may leave and not come back. And you may become a team of one developing a dead mod.
@JosEPh: I think that the Religious disabling is intended for the Wonders and not for the base buildings.
- How many times have we complained about all of this new stuff being added without AI support (and with all sorts of minor bugs)? These huge updates slow down development of the mod with all of the problems they create and divert all of our attentions from more important stuff.
- That XML naming isn't even the same as what the other XML naming is! The naming convention for terrain and feature based promotion modifiers is <Terrain*something*> or <Feature*something*>, not something crazy like <TerrainWorkRateModifierChangeTypes>.
I can't even tweak something small around here without you going and taking it over, changing something that worked fine just so that it looked good to you in the Code Editor. - This gigantic update is another example of what I see as going wrong with C2C. As AIAndy said, the work here being done is roughshod and unilateral. From what I can tell you simply decide you are going to do something big and don't tell any of us about it (because we may disagree or have better ways of doing it, and you don't seem to want to hear that), then commit it all in a huge update every couple of months which takes many hours of our time after that to get bugfixed, or doesn't even get bugfixed at all until your next massive commit. This leads to you basically having de facto control of the entire mod's development by virtue of the scale of your changes, and the fact you don't allow any input from the rest of us. I am really steamed about this,
You said last fall that you were willing to be more open and complete in explaining your development plans, and that you would break up projects into smaller and more frequent commits. This has turned out to be completely false, and I am quite unhappy about that. There needs to be some change to how you develop stuff or some of us may leave and not come back. And you may become a team of one developing a dead mod.
@JosEPh: I think that the Religious disabling is intended for the Wonders and not for the base buildings.
Thunderbrd
C2C War Dog
When I began working on this I was working on just the added traits tags. I get your point that basically you made in the other thread on effects on how many of these kinds of tags overlap and yet the architecture doesn't actually have much of a connection between the two from the beginning of their implementation and all but that's pretty much 1) the way its always been done in civ modding and 2) all I would understand how to do. I'm far more concerned about making progress in the game design than I am about making sure the program is made in the most efficient manner. I can understand that's frustrating from a professional grade programmer's point of view but consider that ALL who modded this dll before c2c had this mentality as well and I can really only learn from examples as I see them as speaking of coding usually is still greek to me.
Anyhow, when I went about listing the tags themselves for development it wasn't really much of a project... just some added traits tags. Doesn't take much to do those. Then I go through and do all of them at once in the xml, then all at once in the infos h & cpp then all at once in the coding wherever they need to be included in the game process, then all at once in the text display segment. (At the moment there's no AI needed for those but it will have a method installed eventually there too.)
The rest is absolutely reactive to discussions taking place online during the design of those. It's also more time-effective that if I get further trait tag ideas during an assembly line process like that to back up to the start to add the beginning of the next tag to the rest of the group being developed and step through those steps until I reach where I"m at with the rest of them. Keeping notes on which has been done at which step I then just go down the list and knock out each tag at each stage of development. None are ready for being committed until all are completed. Developing one tag at a time is just... exhausting.
So as I'm working on those, in a couple places I find that the process of the tag requires some new tags in other areas, like civics for example. This took place when implementing the bAllReligionsActive tag - Note: this process was completely discussed on the forum before implementing. So it wasn't like I was hiding the fact that this was going into production... even when stated outright in numerous places most of the team would ignore what was said anyhow.
It also took place with the capture project which was an afternoon's reaction to some discussion on that matter.
When I start getting into civics, buildings, specialists, I have no idea how to implement the AI stage but I figure... I'll have to learn it anyhow so I'll take these up to the point where that's all that's left and within a few weeks thereafter should be able to have that sewn up and walk away from this project as a whole considering from front to back ALL of this, with the exception of some of the traits tags, were done for the benefit of the rest of the team and not for personal project goals.
The clammoring for particular effects grew loud enough and had been so repeatedly asked for that came up during this process that I added some things I would not normally have interrupted myself to add - the happiness/health/specialist/yield stuff mostly.
So at this point the unready for committing project I started with has now grown to become lumped in with a number of projects that interrupted completion of that one. Why never a commit in there? Because the initial project wasn't completed to the point that we didn't have dead tags implemented. And I simply don't see the point of opening up a branch and taking the modding time I have to make progress towards getting what I'm working on complete to commit to a confusing side registry. I wouldn't have a clue how to make this a useful function in the first place.
Because that's the only case I could foresee as it's the only one that's been discussed and thus was all I was considering. After it started to come together it did occur to me that there was perhaps other ways this might be useful but since each method would have to selectively eliminate its own tags and I did NOT want to have to have a class setup in the xml to have to define the tags there that do and do not have effect then go through and bracket out each individual tag and its application... maybe that's the better way to go but I was 3/4 of the way through the project before I considered it. By then, I did know you'd probably feel this way once you took a look but figured if you had a better idea on how to more generically implement this concept you'd make sure to enforce that I rewrite everything on it again and by then it was pretty much done as implemented anyhow... So yeah, I'm prepared to discuss how it could be restructured.
However, although I've been accused of 'hiding this project until it was complete' where were you when DH and I were discussing this mechanism?
What I don't understand about the use of such feature branches is how it would be able to merge with the care required to make sure it doesn't inadvertently create bugs in poorly merging. There's a number of places in the dll where the order of the things listed is important right? So we develop this and invest tons of time committing half-completed code to a side project (which is really confusing how to do in the first place) then when it's time to say - ok its ready - which I'm not sure how to compile for a test run from such a side project - then decide to merge all that work back into the core - which then conflicts with the things that have been done since the branch began... It just sounds like a mess of hours spent on even more frustrating experiences than the debugging I just did on the project.
Separate working copies could work if I get interrupted in projects in the future though... I just hate merging and having to merge my own project into my own project seems so inefficient. But it admittedly is only inefficient if there are no problems with a given project and the last few weekends could've been made much easier if I had taken this approach.
I get the overall gist of what you're saying and am considering that perhaps the most important thing I need to do in the future is to not be so tangential and not allow myself to pick up side projects while involved in programming something as it is. I did resist a lot more coming into the picture here but with what I did allow to intrude on what I was doing I did so because I did not want to shelve those projects but rather get them done ASAP. If I do allow such an intrusion into the project I am working on in the future I'll just copy myself another repository and do it there and commit it there then allow it to be another part of what I must merge with before my first project is complete.
The banning side is not the default.
For the core non-DL traits, I'd actually nerf spiritual a bit to counter the effect some and give it one cause for all religions to be active. And there's a negative trait or two that scream for bBansNonStateReligions.
So... wait... you say commit in small chunks but make sure everything committed is flawless before it becomes committed? I did address a lot of ai issues in this but I also admit there's a couple months more programming to finish that side - months for me because I don't know much of what I'm doing there. Months because its going to take careful discussion with more knowledgeable programmers in the AI dept before I do anything there effectively and upset the mod. Bad AI work can be as bad as NO AI work. So that's one last thing to do here (aside from a minor bug or two... which is a hell of a lot better than some of what I've seen you commit recently that I have not had the rude audacity to try to call you out on like I'm somehow so self righteous that I believe myself so perfect that such bugs could never be committed by myself.)
So there's a little work left to be done. Is it not better to register the project, allow players to test it and give feedback, allow the other modders to look it over and find what they feel are flaws in approach or gaps overlooked and point them out, rather than just talking a bunch of words on a forum that nobody cares to read or comment on?
I knew you wouldn't like there being what you would feel were added words that you'd find unnecessary in the renaming there. Apparently to you it is not necessary to try to keep things clear for those who come behind you.That XML naming isn't even the same as what the other XML naming is! The naming convention for terrain and feature based promotion modifiers is <Terrain*something*> or <Feature*something*>, not something crazy like <TerrainWorkRateModifierChangeTypes>.
Terrain - ok we're good so far right? We're talking about terrains.
WorkRate - ok, we're talking about the workrate of the worker when working that terrain.
Modifier - ok, we're talking about a percentage rather than a flat rate adjustment.
Change - this means its a promotion tag that will be merged with a similar tag from the unit side that simply does not utilize this term. If the term change is not on a promotion tag, then we can assume it's not intended to combine with a platform base value from the unit side.
Types - Ah... we're specifying which types of terrains are modified by the integer in the tag structure.
Not all tags are denoted this way, no. There is a host of tags that utilize less considered naming conventions that should've been named differently from the beginning and the tags you were basing yours on were among them. This is not to be accusing but an attempt to share what I do know. But since you feel your job here is to criticize other modders because none can live up to your level of perfection, I suppose I should not have attempted to share what I've worked out on tag naming with you.
I'm struggling to understand what you mean by unilateral. Are you saying it was simply too many projects at once? I'd agree there and have discussed how I will try to approach that. Roughshod? Sure there's some work around the edges still to do but I felt it was necessary to commit so that others might be able to point out how to do that work correctly before proceeding into territory I was unsure of.
Aside from the traits tags, all of this was a reaction to a request. So how can I be accused of not telling anyone about it when someone had to tell me about it to get me to do it in the first place? Perhaps if you weren't ignoring my posts you'd know what was taking place?
Sounds to me like YOU feel as if YOU have to share control of the mod and that's what's disturbing to you here.
The Traits tags was the original project, was MY project I was working on for my own eventual use. Even most of those tags stemmed from being asked to see what I could bring in from playtyping's traits. The rest is ALL a reaction to the requests of other modders on the team. Most of those projects I'd preferred not to do in the first place but I'm trying to be useful to not only myself. So being accused of not allowing input from the rest of you is just absurd since the majority of this is directly the result of input from the rest of you.
I did put a bit more thought into the Religious Disabling project than had been discussed however, but the only extensions beyond that which was stated in the forums were added in during further consideration during these last few weeks of debugging. The outright banning element came from realizing I had overlooked a detail and when I realized the implications of having overlooked that detail I also immediately realized that it could be a good thing to offer a counter tag to the bAllReligionsActive tags. In an effort to get the rest of the projects in place here I threw that last bit in and so far I'm not hearing anyone complain about that ONE portion of the project that went undiscussed on the site.
You know... now that I think about it... I've not only discussed the religious disabling mechanism with you 2 or 3 times on the site, but I've also quoted for you the previous discussions and compiled where those discussions had taken place so that it was all posted in one place for you to review as you were trying to make a quick fix solution that DH and I did not find sufficient to fulfill his vision. When I get done with this post I'll go find that and quote it over here for you again k?
No... the main complaint on religious hoarding and how it enables such an easily achieved steamroll for the player that does so is mostly about monasteries actually. In short, all religious buildings are considered in this. But if DH wants some of those buildings to have tags that remain active or are adjusted in their effectiveness, that stage of the project is still yet to be developed.
I had considered making this project as a game option. Wasn't sure if that's how y'all wanted it or not. I did not do so initially so as to gauge the reaction to it not being one. There's a growing resistance to more game options as well so I figured we the team would benefit from seeing how the players and ourselves react to the change before making it untestable in our current games without taking unusual and bug-prone actions to change the game options.
I suppose it should be an option. And perhaps it should be extracted into a branch then be restructured to be something more generic before being re-implemented. But it can just as easily be argued that even if its overreaching, its a strong patch to a huge pre-existing game imbalance. I'm not sure how I feel about that but a LOT of comments in the forums would suggest a number of players would feel that way.
Honestly? I don't even like that project. It's a reaction to tons of complaints that were going to lead to outright disabling of non-state religious buildings for the sake of game balance unless something was done to enable a solution in between. I had the vision to enable civics and traits to interact with that and brought it up with DH who asked for a means for establishing an in-between disabled and enabled setting rather than having the system be black and white disabled or not. This discussion was NOT in pms and was re-iterated over the course of two or three threads. Apparently it takes DOING something rather than just talking about it to make the project a reality enough for discussion to really open up on the subject.
Yes, I do say that things should be as close to flawless as humanly possible before being committed, and that things should be committed in small chunks. I do not see what the problem with that wish is for a reasonably organized software development effort like our own. For instance, if you added the new Trait tags 2 or 3 at a time and committed 2 or 3 times a week that would give us plenty of time to test and make sure that each new thing that is added is working properly and for Koshling to advise you on AI without you overwhelming us all. Now it is virtually impossible, given the volume of the code that was added, for us to test it all and find all of the bugs in any reasonable amount of time, which contributes to the instability of C2C which is our constant bane.
Ahem... I was talking about the conventions involved. I try and stick as well as I can to the core BtS coding and naming conventions for methods, variables, and XML schemas. You used the small issue that I forgot 'extra' in some of my method names as an excuse to go and completely change the whole structure of what I added. Now I can barely understand what is going on with something that I designed, and the promotions don't work anymore either. So I would strongly encourage you to revert those changes for now so I can make the one change that was actually needed and add new code for Improvements and units based on the conventions.
How on earth could that be? I have made no secret of the fact that I have a direction I want C2C to go and that I'll work my hardest to see it goes in that direction. But I'm not the one who absorbs everyone else's efforts with massive changes which are impossible to test and require us all to work around them. The sheer volume of stuff you are changing and making without input is what I'm saying is giving you de facto control of where C2C is going, and that direction is not one I like.
Thunderbrd
C2C War Dog
I've made every effort to ensure your tags will continue to work. That said, while playtesting the other night I noticed that there were some worker promos that were not working (or at least displaying) correctly before my changes but I didn't react much to that since I figured it would likely have been sorted out by the coding I did there. I had noticed and repaired a couple of bugs along the way and figured that could be the cause.
Are you saying that they aren't working at all? I'll need more information on that... perhaps its posted in the bugthread which I haven't gotten to yet today.
Let me ask you something. How were you going to differentiate between the unit base value and the promotion value when you had the promotion value named as you would want to have named the unit value?
And it's not an excuse to override your work. I'm trying to teach what I do know through example as its easier to evaluate an example than understand a clumsy explanation of the difference.
And I did take the time to make this all as flawless as humanly possible. There are simply some AI regions that need to be addressed that I'd be a bull in a china shop making an unguided attempt to do so and its easier for those who would guide me to have the codes that are in place on hand and in effect as they go about offering that guidance.
Somehow there's ALWAYS going to be small, minor bugs that only get picked up during a wide playtesting sample. But I did test fairly thoroughly... don't know what happened with the trait display though... seemed to be working before I committed but at least I have a good bead on what could be wrong there and should have a fix as soon as I'm done discussing things here.
You're accusing me of making changes without input. Very little of what is here was done without input. In fact, very little was done without the project being a pure reaction to the request from another modder. I'd call that input wouldn't you?
Looking for a new job while still on the old one for the last days. Certainly not reading some discussion in a modmod thread.
strategyonly
C2C Supreme Commander
or did I
Thunderbrd
C2C War Dog
Yeah, I suppose some of that discussion was taking place when you were in your downtime.
Look... here's the deal AIAndy. I say this in absolute respect. The answer to why I didn't do things the way you would've done things is simply because you're flat out more intelligent and experienced. I'm not at all offended if you say something should be done a different or better way. I DO, however, get frightened of being put in a position where I no longer understand how to work with those changes. In this, I understand what ls612 is saying about the adjustments I made to the promo tags.
You've implemented a lot that I still don't know very well how to use. And a more generic approach simply doesn't always occur to me. I concede that there's almost always a better way to have done anything I do. So if we need to make some changes to the religious disabling mechanism to generate a more generic system that can apply to other things then I am interested to see how you'd suggest we go about that. I have some ideas on how it could be done but its all just that... ideas.
TB, I don't expect you to come up with the generic solutions yourself. That is why I ask you to get our input on how to solve it before you start the implementation. This way the programming might get a bit more complex, but it progresses our code base and future possibilities and so is a far more valuable use of your time.
There are a lot of patterns in the Civ4 software architecture that are not good solutions for the large scale mod that C2C has become. So just saying that is how it has always been done is not good. We can't change it all but we can make sure all effort that we invest brings us closer to a better state.
Thunderbrd
C2C War Dog
Fair 'nuff. But are you saying that I should be pming you with every project plan before beginning? I thought that's what the forum posts were for. If you aren't keeping up on reviewing all the forum posts I can understand that and try to make sure you're made aware of all planning discussions that may be good for you to review.
To this end, I'd like to draw your attention to Leader Archtype project and ask directly for feedback on the planned implementation there. See if there's anything you'd suggest to go about that differently. That's one I wish I had started on before getting wrapped up in this group of projects since RtS is patiently awaiting some implementation there in code so he can get his xml done for that.
Back on this subject of a generic implementation of a semi-disabling on buildings. Would you suggest we back this part out and redesign it before going further or do we have enough cause to see other future purpose in a more generic solution here? I did not consider it much until later in the project because no other area of the game has yet really suggested a need for other causes for semi-disabling. This makes me wonder if it would be worth the effort to rethink the project implementation from scratch. What do you think there?
As we say down under, fair go. As in, give Thunderbrd a fair go. A lot of this stuff was just him trying to help others. He did what he could as best as he could and was humble enough to admit it might not but perfect. As he said;
How else can work to do with the AI side of things, and whatever else, get done. Maybe he should of asked for AIAndy's help or should of done this or that, but at the end of the day he's only trying to help and to improve the mod.
How else can work to do with the AI side of things, and whatever else, get done. Maybe he should of asked for AIAndy's help or should of done this or that, but at the end of the day he's only trying to help and to improve the mod.
Dancing Hoskuld
Deity
The request for disabling religious buildings has been going on for years. Eventually Tbrd and I got into discussion on how it might be done, but even that was slow and over many threads. It takes me time to think on the implications
. When I get my head around what has been provided here I will make a modmod or option for the religious building disabling.
Thunderbrd
C2C War Dog
Thanks for the support bro! Well put and true.
Optioning that would have to be done in the dll. If you'd like it to be segmented off into a game option so we have some further time for deeper development in a beta project mode, I can have that done and committed by the end of the day.The request for disabling religious buildings has been going on for years. Eventually Tbrd and I got into discussion on how it might be done, but even that was slow and over many threads. It takes me time to think on the implications
Probably best to do it that way anyhow.
There are a lot of things discussed in this forum that never reach the point where they would actually be implemented. What I would like is that once a non trivial project has reached the discussion state that it is ready to be implemented and has someone wanting to do the implementation that I am made aware of that and that we then discuss how it is best done (so it fits into the larger pattern and easy generic fruits are harvested on the way).
As far as I can see what you are doing there is adding a new XML file that is nearly entirely a copy of the old. I think it would be better if you add inheritance capability to info classes. That means you have your archetypes as normal leaderheads defined but with some new tag that makes them inactive or declares them abstract or something. Then you add a new tag (best on a similar level as the Replacement code stuff) that allows you to inherit information from one or more base classes. That is a quite generic piece of code and should also work on other info classes as it can use the copyNonDefault methods to copy in the information from the base classes.
One thing that would be needed is for every info class that should support that the copyNonDefault needs to be truely copying, not moving information as it sometimes does now.
A tag that makes info classes inactive is useful for the replacement stuff as well.
If you keep what is disabled hard coded, then it is quite the step to a generic solution. But if you make that settable by an XML file, then you are not that far away from allowing multiple causes of partial disabling.
Dancing Hoskuld
Deity
I am muddled headed at the moment, I think I have a cold, hay fever and a virus/whatever - bah humbug! However I consider it better if options can be done in XML since it opens it up for more people to tinker with it.
Thunderbrd
C2C War Dog
I'll pick up this discussion with you in that thread.
Well... at least we're on the same page then. That was what I was thinking here in retrospect. You once told me about how we can identify tags from the dll and bring them into reference in xml. To do this I'd have to do that. I'd also have to think more generically and give a couple of tags in that new class that enable the tag to operate in differing ways. Big project but yes it could be done and it would enable what could be some interesting future effects.
I'm inclined to suggest then that I option out what we currently have at for the religious disabling at the moment and leave it there for those who want a more balanced game at the expense of some player strategies and outside of establishing the tags in the civics/traits that aid the system pretty much leave it alone from there and begin working in a more generic system.
But I've been way overdue in addressing the archtype mechanism so aside from some small debugs here to work out that's my next focus.
Thunderbrd
C2C War Dog
Currently, the religiously disabling state is the default. The mechanism as a whole is what would need to be optioned out of usual play. When in play, xml tags in civics and traits can define whether a nation is under religious disabling, banning of non-state religions, or allowing them all. Further development of the mechanism is probably best to go on hold thereafter until a more generic system such as AIAndy is suggesting is implemented.
If your saying it should be a modder option (bug option) rather than a game option I can understand that point and I think I can work out in the code how to switch based on that but I'd need someone more familiar with the python/xml setup side of that to establish the option itself and since we have the ability to change gameoptions in game with the map editor now it shouldn't be so bad having it as a game option would it? (In short it'd be a lot easier for me to go about it this way as I have full familiarity with that method.)
Dancing Hoskuld
Deity
I keep meaning to write up where I think religions should be going in C2C but I never get the time. Some religions get on fine with each other eg Shinto and Buddhism in Japan others don't! If you are running polytheism then all religions should be active, if you are running monotheism then only one should be unless you have separated church from state in which case some buildings of other religions should function.
Thunderbrd
C2C War Dog
Some religious compatibilities or incompatibilities could be worked into the system... would be far more complex that way but could be done.
Dancing Hoskuld
Deity
Team Project 3: Capture Mechanics tags
These do seem to provide all the information that is needed for the capture mechanism. I will give them a go to see what happens. What is the default values if no value is provided?
What we eventually want to end up with is the whole capture mechanism outside Python and inside the XML using outcomes. Similar to the way we do the animals, but I don't want a bunch of outcomes on every unit. It would be better if it could be done at a higher level.
Spoiler :
These do seem to provide all the information that is needed for the capture mechanism. I will give them a go to see what happens. What is the default values if no value is provided?
What we eventually want to end up with is the whole capture mechanism outside Python and inside the XML using outcomes. Similar to the way we do the animals, but I don't want a bunch of outcomes on every unit. It would be better if it could be done at a higher level.
Similar threads
