Messages

136

Feature Requests / Re: Production time

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

137

Feature Requests / Re: Production time

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

138

Windows / Re: ufo.exe.manifest missing

« on: July 12, 2009, 06:09:39 pm »

Thank you, only the ufo.exe.manifest was missing. After downloading it via someone's link, the game compiles great.

139

Feature Requests / Re: Production time

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

140

Bugs prior to release 2.3 / Starting money bug

« on: July 12, 2009, 02:13:12 am »

When you first start the game, you can choose whether or not to include buildings and/or employees in your first base.
If you choose to include both buildings and employees, you start with a positive amount of money. (Assuming proper)
If you choose to include only buildings, but no employees, you start with a negative amount of money.
Not sure if this is right or not, but that is how it is.

Version

    * Where did you download the version of the game and what version(-number) is it. Please be as verbose as possible here.
http://ufoai.ninex.info/forum/index.php?topic=3462.75
    * SVN users please state the branch of the svn tree you use (e.g. "trunk" or one of the version-branches) and the revision number. You can get both by using the "svn info" command.
UFOAI 2.3 R25071 Developer's Built

System

    * What operating system do you run UFO:AI on?
Windows XP Home Service Pack 3 Build 2600
    * What computer and graphics card do you have? (graphic driver version if you know)
Processor   x86 Family 15 Model 55 Stepping 2 AuthenticAMD ~2204 Mhz
Name   Sapphire RADEON X1600 PRO
Driver Version   6.14.10.6806


    * What architecture does your system use (e.g. like i386, x86_64)
Processor   x86 Family 15 Model 55 Stepping 2 AuthenticAMD ~2204 Mhz?

This is especially useful for everything from graphics bugs, setup problems, performance issues, os dependent errors, etc...
What happened before the bug occurred? Is the bug reproducible?
Game began, bug reproducible each time.

The bug itself is often just a symptom of things that happened right before (or often even a long time ago).

Some things to check:

    * The first thing we ask you is to check if you can reproduce the bug. The simpler the reproduction-steps are, the better.
Bug is reproducible.
    * Does the bug also happen when starting a new game or only after loading a saved game (most likely a bug in the load/save system)
Bug happens when starting a new game.

141

Feature Requests / Re: Production time

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

142

Feature Requests / Re: Production time

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

143

Feature Requests / Re: Production time

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

144

Windows / ufo.exe.manifest missing

« on: July 11, 2009, 07:40:19 am »

I downloaded Odie's latest build UFOAI 2.3 R25071 Developer's Built, but compiling it fails due to missing ufo.exe.manifest.
Uh, are some files missing from this download that I need to get from somewhere else? Or did I just build it wrong somehow?

Right now I'm suspecting a manifest file is not something I actually need to compile, since it appears to be a "Windows Visual Stylesheet XML File", which doesn't make much sense to me. So, what did I do wrong?

145

Feature Requests / Re: Production time

« on: July 11, 2009, 07:18:30 am »

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.

146

Feature Requests / Re: Production time

« on: July 10, 2009, 06:28:44 pm »

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.

147

Feature Requests / Re: Production time

« on: July 10, 2009, 04:36:46 pm »

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?

148

Feature Requests / Re: Production time

« on: July 10, 2009, 09:56:48 am »

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.

149

Feature Requests / Re: Production time

« on: July 10, 2009, 07:12:56 am »

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.

150

Feature Requests / Re: Production time

« on: July 10, 2009, 06:20:05 am »

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?