project-navigation
Personal tools

Author Topic: Production time  (Read 14789 times)

Offline criusmac

  • Squad Leader
  • ****
  • Posts: 168
    • View Profile
Re: Production time
« Reply #15 on: July 11, 2009, 11:46:28 pm »
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.

Offline criusmac

  • Squad Leader
  • ****
  • Posts: 168
    • View Profile
Re: Production time
« Reply #16 on: July 12, 2009, 12:14:28 am »
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?

Offline geever

  • Project Coder
  • PHALANX Commander
  • ***
  • Posts: 2561
    • View Profile
Re: Production time
« Reply #17 on: July 12, 2009, 12:27:13 am »
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

Offline geever

  • Project Coder
  • PHALANX Commander
  • ***
  • Posts: 2561
    • View Profile
Re: Production time
« Reply #18 on: July 12, 2009, 12:34:19 am »
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
DiffUtils for Windows (SF)

-geever

Offline criusmac

  • Squad Leader
  • ****
  • Posts: 168
    • View Profile
Re: Production time
« Reply #19 on: July 12, 2009, 12:59:01 am »
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.

Offline geever

  • Project Coder
  • PHALANX Commander
  • ***
  • Posts: 2561
    • View Profile
Re: Production time
« Reply #20 on: July 12, 2009, 01:21:25 am »
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?

(deb file is a debian package, quite common :))

-geever

Offline criusmac

  • Squad Leader
  • ****
  • Posts: 168
    • View Profile
Re: Production time
« Reply #21 on: July 12, 2009, 02:34:52 am »
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.

Offline criusmac

  • Squad Leader
  • ****
  • Posts: 168
    • View Profile
Re: Production time
« Reply #22 on: July 12, 2009, 07:08:41 pm »
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.

Offline Mattn

  • Administrator
  • PHALANX Commander
  • *****
  • Posts: 4831
  • https://github.com/mgerhardy/vengi
    • View Profile
    • Vengi Voxel Tools
Re: Production time
« Reply #23 on: July 12, 2009, 08:27:07 pm »
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 ;)

Offline geever

  • Project Coder
  • PHALANX Commander
  • ***
  • Posts: 2561
    • View Profile
Re: Production time
« Reply #24 on: July 12, 2009, 08:31:46 pm »
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.
You can send patches to our Patch Tracker next time.

-geever

Offline criusmac

  • Squad Leader
  • ****
  • Posts: 168
    • View Profile
Re: Production time
« Reply #25 on: July 12, 2009, 08:58:51 pm »
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.

Offline criusmac

  • Squad Leader
  • ****
  • Posts: 168
    • View Profile
Re: Production time
« Reply #26 on: July 12, 2009, 09:09:34 pm »
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.
« Last Edit: July 12, 2009, 09:11:45 pm by criusmac »

Offline criusmac

  • Squad Leader
  • ****
  • Posts: 168
    • View Profile
Re: Production time
« Reply #27 on: July 12, 2009, 09:32:41 pm »
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.

Offline geever

  • Project Coder
  • PHALANX Commander
  • ***
  • Posts: 2561
    • View Profile
Re: Production time
« Reply #28 on: July 12, 2009, 10:28:09 pm »
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

Offline Another Guy

  • Squad Leader
  • ****
  • Posts: 239
    • View Profile
Re: Production time
« Reply #29 on: July 13, 2009, 06:20:18 am »
Nice work guys! I'll test it as soon as possible.