Some more questions about the mod.

Oh... yeah that's probably what they were looking at. hmm... There are other ways to address this of course. Like requiring that the current build category (unit/building/wonder) not change without forcing a break, which is what I thought we were operating with in the first place. That would far more directly apply to eliminating loopholes that are probably still allowed otherwise. You could do this to finish a building quickly as well right now, even if said building was not a wonder. That would also manage the food issue to at least keep buildings of any kind from being the recipient of food production directly.
Can you have SEVERAL same-type checks one after another in the code?
Like:
CHECK 1
Find out the FIRST item's category and modifiers. Calculate overflow to the next item.
If non-zero, go next.
If zero, BREAK
CHECK 2
Find out the NEXT item's category and modifiers. RE-calculate leftover overflow according to the new data.
If non-zero, LOOP between C1 and C2 until you use up all of the turn's production.
If zero, BREAK.
I tried putting this into CODE, but it's too new for me to do it on the spot.
But I hope this explanation was simple enough to convert it into the CODE - which is rather simple itself, I was just confused by the LOOPING mechanism.
EDIT:
Oh, you simply need to introduce "Basic_Production" alongside "Factual_Production" for this to work.
Then use "%_of_BP being used up by FP for this item" in the end recalculation of a check.
Quite simple, really.
 
It's fine as long as the code was commented out rather than deleted, so we don't forget about the exploit in multiple production that is now introduced.
Its commented out.
 
I added issue to github, so information about exploits doesn't fall out.
 
I added issue to github, so information about exploits doesn't fall out.
So...
When does it pop up at SVN then?
Do you keep it synchronized between the two, or not really?

Sorry if it sounds rude - I'm just super eager to try it out on my game.
It would make a HUGE difference, given how I always play a Mega Capital strategy,which ALSO meant a Mega Busy Forever Building Endless Wonders Capital strategy before this switch.
But NOW... well, let's just say it'll remove the BUSY part almost instantly.
And the INCREASE... mmm... beware, world, Somebody613 is out there to VASSALISE you!!!
MWAHAHAHAHAHA!!!
 
Can you have SEVERAL same-type checks one after another in the code?
Like:
CHECK 1
Find out the FIRST item's category and modifiers. Calculate overflow to the next item.
If non-zero, go next.
If zero, BREAK
CHECK 2
Find out the NEXT item's category and modifiers. RE-calculate leftover overflow according to the new data.
If non-zero, LOOP between C1 and C2 until you use up all of the turn's production.
If zero, BREAK.
I tried putting this into CODE, but it's too new for me to do it on the spot.
But I hope this explanation was simple enough to convert it into the CODE - which is rather simple itself, I was just confused by the LOOPING mechanism.
EDIT:
Oh, you simply need to introduce "Basic_Production" alongside "Factual_Production" for this to work.
Then use "%_of_BP being used up by FP for this item" in the end recalculation of a check.
Quite simple, really.
If you want me to explain what I need to do here... I need to figure out when to store the type of the current build and then refer to it as the last type and check that the current type is the same as the last type. If it isn't the same, break the cycle for the round, much as the commented out code was doing. I may have to create some universal variables but I'm not sure yet. If it's looping through everything within the same function then those variables that store the type can be local ones only but if the function is called for each item that was queued then it will need to be a variable declared in the .h file. I don't think it will have to be but it will take a bit more code evaluation of what's taking place there than I have attempted on that function yet.
 
So...
When does it pop up at SVN then?
Do you keep it synchronized between the two, or not really?
You might wait few days, as this things need to be refined.
Also there is more stuff going on too on Github.
 
If you want me to explain what I need to do here... I need to figure out when to store the type of the current build and then refer to it as the last type and check that the current type is the same as the last type. If it isn't the same, break the cycle for the round, much as the commented out code was doing. I may have to create some universal variables but I'm not sure yet. If it's looping through everything within the same function then those variables that store the type can be local ones only but if the function is called for each item that was queued then it will need to be a variable declared in the .h file. I don't think it will have to be but it will take a bit more code evaluation of what's taking place there than I have attempted on that function yet.
How about Current_Item_Type, lol?
In CHECK1, If CIT1 = CIT2, then do the normal routine, else RE-EVALUATE and go to CHECK2 (and then back), just like in the loop I suggested.
Also, needs Production_Basic and Production_Actual, and calculating % of PB being used up as PA during each item's completion.
Not pretty, but not really that much of a hard math either.
If I was more familiar with the code style, I'd do it myself easily - I'm just confused by the unfamiliar looks of it, that's all.
 
How about Current_Item_Type, lol?
In CHECK1, If CIT1 = CIT2, then do the normal routine, else RE-EVALUATE and go to CHECK2 (and then back), just like in the loop I suggested.
Also, needs Production_True and Production_Actual, and calculating % of PT being used up as PA during each item's completion.
Not pretty, but not really that much of a hard math either.
If I was more familiar with the code style, I'd do it myself easily - I'm just confused by the unfamiliar looks of it, that's all.
I don't think it's moving through the process in the way you are suggesting and I shouldn't need to change the order of events at all here.
 
I don't think it's moving through the process in the way you are suggesting and I shouldn't need to change the order of events at all here.
Like I said - I'm totally unfamiliar with this code's mechanism, so I'm thinking in (lol) GM-style code, more or less.
Where you can LOOP between evaluations without any problem, yeah.
But if it's always one-directional, then it IS a problem - though not a super huge one, you'd just need to squeeze everything into ONE check, ugh.
 
@Somebody613 now that thing is in SVN - you can now build all food requiring units (workers/settlers) and wonders smoothly (multiple per turn).
Those exploits will be fixed later.

I disliked inability to build multiple wonders per turn too lol.
 
You have become quite the contributor of late haven't you. ;):scan::goodjob:
More like the nagging annoyance that dares to not stop nagging until he gets what he wants at least in some way, loool.
The funny thing is that most of the changes are either stuff that everyone had wanted long ago but nobody cared to push through with, or genuine errors that should have been spotted and fixed just as long ago.
Which kinda baffles me, to be honest.
 
More like the nagging annoyance that dares to not stop nagging until he gets what he wants at least in some way, loool.
The funny thing is that most of the changes are either stuff that everyone had wanted long ago but nobody cared to push through with, or genuine errors that should have been spotted and fixed just as long ago.
Which kinda baffles me, to be honest.
You have no idea how much has been done and how much has had to be placed on a back burner in the process and how many other competing goals for development there are. You cannot just spend time addressing problems or it becomes nothing but a slog. Much is left to be done later at some point in favor of what you want to address now. Nearly all work is towards addressing some issue or another WHILE achieving larger design goals, so if a problem isn't along the development path, it just gets pushed aside for a long time as lower priority. Yes, sometimes a person comes along and whines about something enough to make it high enough priority to look at, but that's all that's happening, is that its pushing one item among thousands up to the front of the work queue.
 
You have no idea how much has been done and how much has had to be placed on a back burner in the process and how many other competing goals for development there are. You cannot just spend time addressing problems or it becomes nothing but a slog. Much is left to be done later at some point in favor of what you want to address now. Nearly all work is towards addressing some issue or another WHILE achieving larger design goals, so if a problem isn't along the development path, it just gets pushed aside for a long time as lower priority. Yes, sometimes a person comes along and whines about something enough to make it high enough priority to look at, but that's all that's happening, is that its pushing one item among thousands up to the front of the work queue.
How's that different from what I said, lol?
 
Which kinda baffles me, to be honest.
Was answering to this insinuation that if it's been an issue so long, why wasn't it fixed already? Is that not what you meant here?
 
Was answering to this insinuation that if it's been an issue so long, why wasn't it fixed already? Is that not what you meant here?
There are passive issues and active issues.
Stuff like empty cultures is passive, since it rarely triggers a reaction in anyone, and many players don't even bump into them altogether.
On the other hand, forcibly limited multi-building is extremely active, because it annoys almost everyone and in every game.
So it's no wonder nobody cared to fix the cultures - but it does surprise me how none of you cared enough to fix the multi-building limitations that actually make no sense.
My confusion stems from the apparent "fact" that you needed MY complaint for that issue to even move from its years-long stasis - now THAT was weird to me.
But let's not delve into this topic too much - it's quite unnecessary, don't you agree?
 
Back
Top Bottom