Production time

[Another Guy]

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...).

[odie]

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??

[criusmac]

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...

[criusmac]

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?

[criusmac]

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.

[geever]

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

[criusmac]

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.

[Another Guy]

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!

[criusmac]

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?

[geever]

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

[criusmac]

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.

[criusmac]

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.

[geever]

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

[Mattn]

but please upload diffs - not full files

[odie]

OOOoo,

I ma so liking this idea of having production queues checked every min instead of hr!

Go go go! Go criusmac! 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.

The files in svn are unzipped, so esp files like maps and models are insanely large.

Toodles!