Integer truncation with Research time?

[MikeTheRed]

In message #7 in another thread, I raised an issue about integer truncation that was mentioned on UFOpaedia some years ago. Specifically, if you assigned 10 people to a project for which 51 hours was rolled, you would finish in 5 days, not 6. Can anyone here confirm (or deny) that integer truncation does indeed work like this for X-COM research?

 

It strikes me as an odd way for the game to work, as stated in that message. But if it is true, it is true.

 

I am about to re-write that section and don't have time to test that concept. If someone can re-affirm it, I'll proceed.

 

Thanks,

 

MTR

[Zombie]

I cannot confirm or deny it MTR. I can however speak from experience dealing with the inner workings of the game that integer truncation is used almost everywhere. It would not surprise me one little bit if it was used for research completion calculations (in fact, I would find it more odd if the game didn't use truncation here).

 

And just to clarify, this isn't a case of the game mathematically truncating a decimal intentionally. It's because the game isn't programmed to use real numbers - everything is integer based. So the decimal is cut as it's saved into the integer declared variable.

 

- Zombie

[zaimoni]

In message #7 in another thread, I raised an issue about integer truncation that was mentioned on UFOpaedia some years ago. Specifically, if you assigned 10 people to a project for which 51 hours was rolled, you would finish in 5 days, not 6.

I have tested this extensively (I normally watch the scientist-days when playing in a hex editor). In general, this is completely wrong: if 51 scientist-days is rolled, the countdown is: 51, 41, 31, 21, 11, 1, -9 : six days. To cheat i.e. optimize research hours, one would set the scientists to 1 when 11 was the number of scientist days, then reset to 10, to avoid wasting 9 scientist-days.

 

There is a documented bug, where projects started immediately at midnight, that are later than the completed project that triggered the reassignment, get the research immediately. If the project with 51 scientist days gets its 10 scientists during the post-research midnight allocation, it will complete in five days because the 51 to 41 transition happens immediately.

 

Engineering-hours works the same way in general; I have not tested whether the hyper-efficient bug is present there.

[MikeTheRed]

Thanks folks, I thought it sounded fishy ... I didn't understand why it didn't effectively round up, given that it checked for completion each night.

 

Zaimoni, is there a reason why you said "set the scientists to 1 when 11 was the number of scientist days, then reset to 10, to avoid wasting 9 scientist-days" instead of just saying "set it to 1 scientist on the last day". Is there something more complicated going on?

 

I appreciate the input!

 

Mike

[zaimoni]

Zaimoni, is there a reason why you said "set the scientists to 1 when 11 was the number of scientist days, then reset to 10, to avoid wasting 9 scientist-days" instead of just saying "set it to 1 scientist on the last day". Is there something more complicated going on?

The research-days are applied in strictly increasing order of the project listing; the efficiency exploit is that the reallocation screen happens *before* any research-days in projects listed after the just-completed project are applied.

 

Setting the scientists to 1 on the last day, then applying the 9 scientists to a project later than the one being completed, wastes the 9 scientist-days just like having all 10 scientists applied on the last day to 1-scientist day of research. To avoid wasting them, they have to be diverted the midnight check before the midnight-check that completes, then restored for the last midnight check. Both of these are trivial calculations.

[MikeTheRed]

The research-days are applied in strictly increasing order of the project listing; the efficiency exploit is that the reallocation screen happens *before* any research-days in projects listed after the just-completed project are applied.

Ok... as you said, this is the Research Rollover bug/exploit, eh? The description of that bug always left too much unanswered to me:

• If you just finished a project, it's gone from the list... so how can you know what was before or after it? (This caused the bug description to not make sense to me)
  
• It talks about assigning scientists to a "new" project, but doesn't specify if it means an existing one or a brand new one.
  

I never worried about it because research is so easy anyway, shrug. But I think you're saying that 1) you have to keep track of where your project was, and 2) you have to put the scientists into a brand new project. Am I on target?

 

I'm really glad you know Research well! So I can finish revising that wiki text

 

MTR

[zaimoni]

1. Take notes. The listing order of the projects is consistent across all game files, so the easy way to implement in C is an enum. All technology pre-requisites are strictly before the projects they enable, while all alien research topics are after the projects they enable.
    
   
2. Pre-existing works (the research-days hours needed are initialized when the research is started, even with 0 scientists). I have seen cases where the starting research is less than minimum with a new project (e.g., Laser pistol after laser weapons), so I assume the research-days hours are initialized before the buggy research-days are applied.
   

[MikeTheRed]

Thanks, this is great... now I think I understand. Correct me if wrong:

 

1) The order is always the same as in e.g. RESEARCH.DAT. So, we could take notes... or we could just consult something like that

 

2) You said "pre-existing works"... brand-new projects work too, right?

 

 

So, ok. With your comments on the above, I will probably touch up the Research Rollover description on these points.

 

 

But do you mind if I run this by you one more time:

 

We looked at an example of a project with 51 days, and how you would switch it up so you could assign 10 scientists on the last day... but if I'm understanding right, your approach actually only got you one extra (exploit) hour versus my approach of just re-assigning the 9 on the last day?

 

Look at it this way: When that final (sixth) midnight is done, I have had a total of 60 days applied to projects... you have had 61. (See what I mean?) So, as long as a person knows exactly how many days a project needs and they arrange things accordingly, the exploit essentially only lets them re-use the days that were used on the last day, not the days that were wasted.

 

But in the more normal situation of a person not peeking at PROJECTS, then the exploit DOES get them the wasted hours (and the used hours), because they would not e.g. have switched 9 scientists on the last day. They would have just kept them all assigned, still. So, this exploit works best when you work least (i.e., don't check PROJECTS)

 

3) Does this make sense? (Am I fully understanding, finally?)

 

4) Wouldn't there be a corollary to the Research Rollover exploit that goes like this: IF you are deliberately using this exploit, then you should try your best to put newly-arrived scientists into lower-numbered projects (so they can be rolled up into higher ones later). Also, always try to roll them into the next-higher one (because you can't roll them into lower ones). In a nutshell, unless high priorities over-ride efficiency, you should always be cascading your scientists up through the order of (available) research projects. And if you ever reach the "end", then go back to the very beginning (top research project) and start all over again.

 

Thanks again for all your advice!

[MikeTheRed]

Thanks for your info, Zaimoni! I rewrote the Research Rollover bug - please take a look and revise if needed.

[zaimoni]

Thanks, this is great... now I think I understand. Correct me if wrong:

 

1) The order is always the same as in e.g. RESEARCH.DAT. So, we could take notes... or we could just consult something like that

 

2) You said "pre-existing works"... brand-new projects work too, right?

Yes to both.

 

 

We looked at an example of a project with 51 days, and how you would switch it up so you could assign 10 scientists on the last day... but if I'm understanding right, your approach actually only got you one extra (exploit) hour versus my approach of just re-assigning the 9 on the last day?

My approach gets me the full ten exploit scientist-days. Your proposed only gets you one exploit scientist-day.

 

Look at it this way: When that final (sixth) midnight is done, I have had a total of 60 days applied to projects... you have had 61. (See what I mean?)

That is point-blank wrong. You get 61 net-scientist days, my recommended approach guarantees 70 net scientist-days.

So, as long as a person knows exactly how many days a project needs and they arrange things accordingly, the exploit essentially only lets them re-use the days that were used on the last day, not the days that were wasted.

True; this is how I know the prior statement is point-blank wrong as a trivial calculation. The trick is to never waste days on the day a project completes..

4) Wouldn't there be a corollary to the Research Rollover exploit that goes like this: IF you are deliberately using this exploit, then you should try your best to put newly-arrived scientists into lower-numbered projects (so they can be rolled up into higher ones later). Also, always try to roll them into the next-higher one (because you can't roll them into lower ones). In a nutshell, unless high priorities over-ride efficiency, you should always be cascading your scientists up through the order of (available) research projects. And if you ever reach the "end", then go back to the very beginning (top research project) and start all over again.

Yes, this is what I do when using the exploit.

 

Thanks for your info, Zaimoni! I rewrote the Research Rollover bug - please take a look and revise if needed.

No revisions needed; interpretation is accurate enough when not using a hex editor.

[MikeTheRed]

Mentally I had ignored your scientists on the project, on the last day. But you're right, you get 70 workdays out of them (in 60 days), simple as that. Thanks for clarifying. And thanks for being on top of how research works.