UFO:Alien Invasion
Technical support => Feature Requests => Topic started by: Another Guy on July 09, 2009, 12:07:15 am
-
I propose the way production happens change to suport large engineer groups in a base.
The way production happens today, if *produt required engineer hours < available engineerson that base*, then the exeding engineer hours is wasted. Max production per hour is one unit.
eg. Assuming one item require 1 engineer hour to produce and u have 100 engineers on the base (with apropriate workshop space), one would expect that over one hour 100 itens would be produced. The way it is handled today, only one item is produced every hour, so it would take 100 hours, wasting the work time of 99 engineers.
If production output gets calculated every 1/10000 hour intead of every hour (prodution would have to support fractions) this could be solved. I propose such large fraction to support any given situation and calculations not involving products of 10 engineer hours (eg. 273 engineer hours with 34 engineers). Maybe even larger (1/100k, 1/1kk...).
-
I propose the way production happens change to suport large engineer groups in a base.
The way production happens today, if *produt required engineer hours < available engineerson that base*, then the exeding engineer hours is wasted. Max production per hour is one unit.
eg. Assuming one item require 1 engineer hour to produce and u have 100 engineers on the base (with apropriate workshop space), one would expect that over one hour 100 itens would be produced. The way it is handled today, only one item is produced every hour, so it would take 100 hours, wasting the work time of 99 engineers.
If production output gets calculated every 1/10000 hour intead of every hour (prodution would have to support fractions) this could be solved. I propose such large fraction to support any given situation and calculations not involving products of 10 engineer hours (eg. 273 engineer hours with 34 engineers). Maybe even larger (1/100k, 1/1kk...).
Hmmm, tat sounds logical and interesting... have u got the proposed codes too?? Maybe u can submit an update on that??
-
I like this idea too, and it sounds like something I could do easily. Should I try to do this?
My proposal on this matter is to break it down to the minute, so it will be 60 times an hour. Now, while you can still waste some engineers, 60 items per hour may be more reasonable. I'm sure someone can think of some reasons why (like transferring them to storage or something). So, this will be the only change I will attempt..
Basically, I'll try to find the code that checks production completion, have it check every minute rather than every hour, and divide the work done by 60. I don't want to over tax the cpu by checking 10,000 times an hour or something...
-
My first quick examine of cl_produce.c has found the function:
static float PR_CalculateProductionPercentDone (const base_t *base, technology_t *tech, components_t *comp, qboolean disassembly)
Oddly, the function ends with the following:
/* Don't allow to return fraction greater than 1 (you still need at least 1 hour to produce an item). */
if (fraction > 1.0f)
return 1;
else
return fraction;
Since the comment indicates you need at least 1 hour to produce an item, this is starting to look more like someone meant it to be 1 item per hour maximum. Are we changing this now?
(10 minutes looking at code at this point)
I have located:
void PR_ProductionRun (void)
This changes my expected implementation a bit. It is this function that calls PR_CalculateProductionPercentDone, and if we desire, it looks easy to change PR_CalculateProductionPercentDone to return values greater than 1.0f, and we can handle the additional amounts in PR_ProductionRun, so that it can handle values greater than 1.0f. My idea is to subtract 1.0f for each item we create, and save the rest of the progress for the next time. If we are done creating all the items in the current queue, we simply 0 it, and that's it. While we may still waste most of the engineer's work for when they actually complete a queue, we can just say they are retooling, and stuff for the rest of the hour. In this way we don't increase the cpu used by much at all, and get an accurate rate of completion allowing any number of objects to be created in 1 hour, if you have the manpower for it...
Is this what you want done?
-
My initial tests don't show any problems with the completed code. I don't have a large enough production facility to produce more than 1 item per hour at this time though. The changes are relatively simple though, but there can always be odd things that happen. Testing is all I can see for it now... Attached is my completed UFO 2.2.1 file (since testing on a stable release is a good idea I feel). Please compile these small changes in and see if they do anything like what you want. We can figure out if we actually want them later... It may be a good idea to diff the changes since I'm not familiar with this code, at all.
-
The code changed much since 2.2.1 I don't think patching it would make a sense. Also patching PR_* functions not enough as PR_ProductionRun is called only once every hour (from CL_CampaignRun).
And another: If I set a production with ONE item I want it to produce only ONE not twenty nor a hundred. I think If we want to make it more detailed then in the rest of time workers should work on the next item in the queue but not producing more then asked.
-geever
-
Aye. This code is called once per hour as expected. This is fine, and expected, which is why I said you could waste engineer's time via retooling for the next queue item.
Second, if you ask to produce only 1 item, only one will be produced. This is handled by the if statement for if the amount you are producing reaches 0 or less. (Less is probably a safety for sanity reasons). When there are 0 items requested to be produced, the rest of the production never happens, and you are not charged for the rest of it.
Thus, both of your situations are correctly handled. Thank you for your concerns.
Edit: I'd like this tested before we make a patch of it, but even if we do, we can do a merge patch.. I'm not sure exactly what's it's called, but it basically transfers the differences between 2.2.1 and my code, and applies the differences to whatever version you want to. I know Tortoise CVS (for example) can do this fine. I mention this product since it has been mentioned a few times on this board as well.
-
Aye. This code is called once per hour as expected. This is fine, and expected, which is why I said you could waste engineer's time via retooling for the next queue item.
Second, if you ask to produce only 1 item, only one will be produced. This is handled by the if statement for if the amount you are producing reaches 0 or less. (Less is probably a safety for sanity reasons). When there are 0 items requested to be produced, the rest of the production never happens, and you are not charged for the rest of it.
Thus, both of your situations are correctly handled. Thank you for your concerns.
Edit: I'd like this tested before we make a patch of it, but even if we do, we can do a merge patch.. I'm not sure exactly what's it's called, but it basically transfers the differences between 2.2.1 and my code, and applies the differences to whatever version you want to. I know Tortoise CVS (for example) can do this fine. I mention this product since it has been mentioned a few times on this board as well.
Nice work. I haven't actually found cl_produce.c to be the file that handles it at the time I posted it. Ur solution seems very good. Way to go.
Maybe adding it up up geever one (in case there is still an excedding time on the end of hour after producing all the itens requested, that could carry on for the next item in queue) would make production system perfect. I'd still would have to figure it all how to do it (haven't actually looked into the file yet).
Cheers!
-
If you don't want any time lost in production due to retooling, this would also be easy to do, but I would need to make a couple new functions:
First function: Calculate how much extra work has been done via the opposite method to PR_CalculateProductionPercentDone. It will take in the float value of how many items have been produced, and return a value that can be fed into a 'second function'.
Second Function: Either a modified PR_CalculateProductionPercentDone, or a new one which does basically the same thing, except can handle partial production hours, taking in the value from the first function.
This wouldn't be too hard to do. Is this really what you want done though?
-
This wouldn't be too hard to do. Is this really what you want done though?
I'm not even sure we want to change it anyways. I'll ask BTAxis.
And please, work on the trunk. That file doesn't even exist in the current version and more than 10000 revisions old..
-geever
-
Ah, that didn't even occur to me. XD
Ok, I will try to get the trunk, but I am very limited in the amount of bandwidth I'm able to use in a month. 5 gigs per month is what I can use. This is why I hadn't done so previously.
-
I have just finished downloading and installing the latest 2.3 dev version.
It took only a few seconds of source browsing to locate cp_produce.c, which has the same functions:
PR_CalculateProductionPercentDone and PR_ProductionRun which behave in the same manner and in the same way as before. I've only looked at it for a few minutes, but I saw all the exact same places I had changed in cl_produce.c as being there. I feel I can easily remake the same changes to cp_produce.c if that is wanted. They are such simple changes though, if they were wanted, they could probably have been done in a few minutes anyway. I'm unsure of if you want to continue. Let me know please... I'm suspecting this wasn't meant to be done though.
-
BTAxis had no quarrel with it so we can go on.
I think the easiest would be calling PR_ProductionRun in every minute and patch PR_CalculateProductionPercentDone to calculate more fractions.
Criusmac, what do you think?
-geever
-
but please upload diffs - not full files
-
OOOoo,
I ma so liking this idea of having production queues checked every min instead of hr!
Go go go! Go criusmac! :D I am sure u will be able to do it!
Btw, if u ever need some big map / svn files, and u r capped by bandwidth, let me know.
I can dump the svn directory for u, and zipped (i am using good powerful RAR files with MAX compression) before uploading to somewhere like nakido for u. That way, u can all the files u wan yet super small. :D
The files in svn are unzipped, so esp files like maps and models are insanely large. :D
Toodles!
-
Great! This does look like a very easy thing to do. I'll only do the single player files though, since I'm not sure if there is production in Multiplayer.
I'm not sure if it is easier to call the production calculations every minute, or every hour, but I suspect it'll be less cpu intensive to calculate it every hour. That might make a difference if people compress time a lot.
The idea I was working with would calculate an hour's work, and then subtract all the work needed to produce all the requested items. At this point, we can then apply the remaining work to the next items in the queue, and so on. This is fairly easy to do, and would require fewer files to be changed since we wouldn't need to change how often PR_ProductionRun is called, and all changes would only need to be in cp_produce.c (I think). CL_CampaignRun in cp_campaign.c does not currently call events every minute, and I don't like the idea of making it do so since this seems easy enough to get around.
So, my proposal is more or less what I've said in previous posts:
Continue calling PR_ProductionRun every hour, as it currently is.
Calculate how many items are created in that hour, and subtracting all the items we wanted made from that value.
If production is not complete, we are done. Wait for the next hour to call PR_ProductionRun again.
If production is complete, report this to the user, and find out how much extra work was done on the items. Apply this extra work to the next item in the queue instead.
If next item production is not complete, we are done.
If next item production is complete, repeat the above process.
Disadvantage to this is production completion will only be reported/executed on the hour, even if it is done before the hour is up. I suspect we can come up with some excuse to say this, like the Engineers are too busy to report every minute or something, or maybe the delivery staff can't move it to storage until an hour is up, but I don't really know.
Advantage to this is (I believe) we will use less cpu power to calculate the production work being done, and fewer files will need to be changed.
Let me know if you are ok with this proposal.
Thank you Odie, I would like the files I need to compile the game for testing purposes, for these production changes. I have downloaded the R25071 version, which was missing the manifest file. I'll try to track it down and see if anything else is missing.
Mattn, is there a specific diff utility you would like me to use to save the file differences? Some of them work better than others, and may report differently.
-
I probably answered that too fast. What is most important is how it works, right?
In this case, I'll make a second proposal more in line with what people seem to want, and let you guys choose which one:
Second Proposal:
Production runs every minute, due to a minor modification to CL_CampaignRun.
Advantage: The code changes in PR_ProductionRun and PR_CalculateProductionPercentDone can be very minor - almost no changes at all except divide the work done each call by 60.
Other events are more easily run every minute since this code will not be in place.
Items are available the minute they are made, and reports for work done can come in any minute as well.
Disadvantage:
Engineers can not produce more than 1 item per minute.
Probably more cpu power used.
I threw this together fairly quickly, so there may be more advantages and disadvantages around.
This would require (on the whole) fewer changes, but it's really a question of which route we want to go.
A third proposal might be to allow this to be configured somehow, as to which method we want to use, but that's just getting silly now, isn't it?
-
Man I just typed the my objections on the first one. :)
The second one is fair enough (the same as I wrote? :D). One item per minute is a good compromise.
About CPU power we can check how much it slows down the geo when it's implemented, I don't think it will be too much. And we can think about optimizatzion if needed.
-geever
-
And about diff-ing, svn can do it svn diff in a console svn client, there must be such functions in GUI ones either.
If it doesn't work for you somehow GNU diff is fair enough in this case make sure you're creating a unified diff (diff -u oldifle newfile).
GNU Diffutils Homepage (http://www.gnu.org/software/diffutils/diffutils.html)
DiffUtils for Windows (SF) (http://gnuwin32.sourceforge.net/packages/diffutils.htm)
-geever
-
Great! The changes are done as per Proposal 2, but I need to compile the UFOAI to be able to start testing. My initial searches found a .deb file in the nightly deb builds that I downloaded, but I can't make heads or tails or it, and no decompressors knew what a .deb file was. I guess I'm off to try to find the manifest file in some other way.
-
Great! The changes are done as per Proposal 2, but I need to compile the UFOAI to be able to start testing. My initial searches found a .deb file in the nightly deb builds that I downloaded, but I can't make heads or tails or it, and no decompressors knew what a .deb file was. I guess I'm off to try to find the manifest file in some other way.
How about our SVN's Webaccess page (http://ufoai.svn.sourceforge.net/viewvc/ufoai/ufoai/trunk/build/projects/ufo.exe.manifest?view=log)?
(deb file is a debian package, quite common :))
-geever
-
Thank you, that was the only file needed.
Initial testing seems to show the work is getting done properly, and my computer is probably too powerful to notice any geoscape slowdowns. Time to completion is now being displayed in minutes, instead of hours, but still with an 'h' afterwards, so the completion times are now displayed incorrectly.
Also, the actual completion time (In both my modified code and the original untouched developer's version) appears to be somewhat random, which suggests an uninitialized variable somewhere in the code. I'll dig around for it, and see if I can find it.
I haven't figured out how to get CodeBlocks to run to cursor, or honour breakpoints yet. It appears to ignore all requests to do so. I'll need to work on better understanding this debugger, which will take a long time it appears.
-
I could not figure out how to get CodeBlocks to break at a given line, so my testing wasn't as thorough as I would have liked, but after running the game a dozen times, it seems to be working exactly as wanted.
I tested running at maximum speed, and noticed the time ends a bit randomly in both the unmodified ufoai file, and my modified one.
I tested at maximum speed, and slowed to 1 hour running speed when production was almost done. Production ended at the proper time.
I tested at normal speed all the way, and production ended at the proper time.
I tested with several different production running speeds to make certain the code I was changing was did what I expected with different values.
I did not test disassembling, although the code should work with that as well.
Let me know if this patch file is the format you wanted. g:\program files\UFOAI-2.3-dev is the unmodified installation from ufoai-2.3-dev-win32-25071.exe.
-
thanks - i'll let this to geever - but if you plan to contribute more patches, please read our coding guidelines. i'm very picky about whitespaces ;)
-
I tested running at maximum speed, and noticed the time ends a bit randomly in both the unmodified ufoai file, and my modified one.
I tested at maximum speed, and slowed to 1 hour running speed when production was almost done. Production ended at the proper time.
I tested at normal speed all the way, and production ended at the proper time.
I tested with several different production running speeds to make certain the code I was changing was did what I expected with different values.
I did not test disassembling, although the code should work with that as well.
Let me know if this patch file is the format you wanted. g:\program files\UFOAI-2.3-dev is the unmodified installation from ufoai-2.3-dev-win32-25071.exe.
I had to hack the patch at the headers due to the file paths but no problem.
Your patch was committed to the trunk with minor modifications.
(You missed the spaces around the operators in PR_CalculateProductionPercentDone also 60 constants should be SECONDS_PER_MINUTE.)
Please read our Coding guidelines (http://ufoai.ninex.info/wiki/index.php/Coding_guidelines).
You can send patches to our Patch Tracker (https://sourceforge.net/tracker/?group_id=157793&atid=805244) next time.
-geever
-
Oh thank you! I missed that, even though I made that define. XD
I remember reading about the spaces in the coding guidelines before, but didn't check it afterwords.
In the end, I hope it saved more time than it cost to fix all these problems.
Should be better next time I do this.
-
Oh, before I forget, the 60s I wrote in are actually MINUTES_PER_HOUR, not SECONDS_PER_MINUTE. It'll be wrong if they are not equal. (They are correct for now only since SECONDS_PER_MINUTE and MINUTES_PER_HOUR are equal.
I'll modify the patch to fix this, and recheck the white spaces better.
-
Ok, it is done. I discovered by default CodeBlocks doesn't use tab characters, and so it was converting all my tabs to spaces. I have changed this editor setting, so white spaces should now be better.
I have added the white spaces around the operators, added MINUTES_PER_HOUR to common.h, and used it in place of the 60s. The paths will still be wrong, but best I can do without more details. I am including the patch file here again rather than the patch logged since the previous patch was, sorta wrong, and shouldn't have been entered with those mistaken defines.
-
Oh, before I forget, the 60s I wrote in are actually MINUTES_PER_HOUR, not SECONDS_PER_MINUTE. It'll be wrong if they are not equal. (They are correct for now only since SECONDS_PER_MINUTE and MINUTES_PER_HOUR are equal.
True, my mistake. Fixed it.
I couldn't use your second patch as a patch as it was created from the old code. Merged the relevant part.
Btw. that's svn good for (for example): update to the latest rev, change/fix, create new patch on it.
-geever
-
Nice work guys! I'll test it as soon as possible.
-
BTAxis had no quarrel with it so we can go on.
I think the easiest would be calling PR_ProductionRun in every minute and patch PR_CalculateProductionPercentDone to calculate more fractions.
Criusmac, what do you think?
-geever
how much of a hit will that have on performance? especially at the higher time compressions?
-
how much of a hit will that have on performance? especially at the higher time compressions?
Check it yourself. The code is already in the trunk. (No relevant slowdown experienced.)
-geever
-
hmm, this system makes only sense in a limited way :D
There should still be a limit on producable items per minute/hour/whatever. Only because you have 100 workers doesn't mean you have the items/space for 100 items at a time... correct me if i'm wrong. You won't have 100 machines able to produce rockets, 100 for ammunition, 100 for weapons, 100 for armor etc., you'll probably have 1 per workshop. More workers around the same machine won't make it go faster. Also the theoretical 1 minute per item makes only sense for mass-producable or really really simple stuff, perhaps wooden stakes to drive into the alien's hearts (though i doubt it will go through their armor... and they aren't vampires... eh... whatever :D ), more advanced weapons will just take more time.(cooldown time of metal and other stuff that has physical limitations...).
just my 5 cents on this
i guess there's no way to... hmmm... flag an item as "mass-producable" = 1 per minute or not "mass-producable" = 1 per hour, is there? :D
-
You can't have that many workers on a base so it could be a real problem. For more than 40 you have to give up something (defence, interceptors, etc.). An other limitation is 5 production per workshop in the queue IIRC.
-geever
-
You can't have that many workers on a base so it could be a real problem. For more than 40 you have to give up something (defence, interceptors, etc.). An other limitation is 5 production per workshop in the queue IIRC.
-geever
was that an answer to my post?
1st.: with the planned bigger bases as i understand them you will be able to.
2nd.: even if you you substituted the 100's with 50's it wouldn't change some of the points i made at all. For playability reasons ignore the first half of my other post, but i still think a minimum time makes a lot of sense for many items, mainly the not mass-producable ones.
-
Hmm? What the hell you want?
-geever