Jump to content

zaimoni

Members
  • Posts

    118
  • Joined

  • Last visited

Posts posted by zaimoni

  1. Acknowledged. I was testing some savefile-based AI augmentations within UFO Extender when the site started going very sluggish about a week back; when it didn't come back quickly my untrained gut reaction was "hardware failure or critical misconfiguration of CloudFlare". (I just supervised a server migration last month. The unmanaged dedicated server I lease for the domains I host, was starting to have hard drive issues that sabotaged saving cookie-indexed data to the hard drive.)

     

    The old server did wink out exactly as fast as this (midnight GMT July 16th).

  2. The UFOs have come for Ufopaedia ;) The DNS is live and pointing at Cloudflare, but the backend server is not where Cloudflare thinks it should be.

     

    Do any wiki admins (in particular Gazchap or NKF) have insider knowledge they're willing to share?

  3. My experience with Silent Storm Gold, is that "delete profile" is incomplete. The directory itself goes away, but the missions you have fully completed go inaccessible.

     

    With the Allies campaign, if I start a new Allies campaign in the same profile. after completing U.K. Commandant's office, then

    * it's impossible to get the hint on the first mission. Fortunately I can leave the base anyway.

    * English Manor/Wilkins is the first mission in South Britain, rather than the usual first mission.

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

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

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

  7. I've checked organizations one more time - everything is at 0% except Megapol - 32% and Nanotech 5%. Either this is updated once per week or I don't know how it is calculated.
    I haven't tested that carefully; I think it's updated every 30 minutes.
  8. The editor runs in a small square in the corner! It's fullscreen (no window) but it's only about an inch square in the top left corner. The rest of the screen is black. Any idea what's going on?
    Go into the control panel for the display, and set the screen resolution to as low as it will go. Reset it to where it was, when done.
  9. If I remember, FF value triggers a subroutinw with alien's analysis of situation and attributing of a new value to x4A. I am bit surprised that it occured at the end of the turn, but it's probably well possible, x4A is being reset in various routines / moments of the alien move.
    It did not happen at the end of the turn. The Floater took two hits in one autofire burst before dying, so the FF actually reached the savefile. (I assume being hit triggered the AI recalculate, but since the Floater died that was skipped)
  10. Huh? The x4A UNITREF flag = individual decision, as you call it.

     

    x4A

    - 0 means PATROL mode

    - 1 means SNIPER mode

    - 2 means COMBAT mode

    - 3 means ESCAPE mode

    So 255 i.e. -1 would be an intermediate mode. [saving a file with a Floater that had been wounded before it was killed, had 255 in this field.]
  11. Actually have no idea, because I was never aware of this nor read about. Are XCom units capable of shooting down through grav lift, or it's just a AI bug?
    It's an AI bug. Furthermore, the AI can reaction-shot down grav lifts fine; it's just intentionally shooting down grav lifts that's impaired.
  12. The randomness of stat-increases would be enough to justify it, yes. Not sure if there's any dice throws performed for tie-breakers. Wouldn't surprise me if we DO have it documented, but I can't be bothered to look it up at the moment... :P

    Seb76 has tracked down the "most promotable" formula (it's on UFOPaedia, and I swiped it for my Python 2.x-based editor suite). It's basically a sum of current stats.

  13. Odd behaviour for the day: Here we see a Shigeru getting promoted. However, I forgot to take a screencap of the end-mission report, so I re-invoked the game from the point where the mission ended so I could take one. However, after doing so, Mariko got promoted instead! I didn't save this new result, so she remains a squaddie, but I did try relaunching the game another ten times or so. Nearly every time, she got the promotion - didn't know there was a random element...
    I haven't formally checked, but I think it's the after-mission stats that figure into the relative promotion score the game uses. That is, the stat increases are applied first.
  14. More notably, the month-long retaliation "campaign" by the UFOs does not seem to be divided into "find base" or "attack discovered base" types. ....

     

    However, simply modifying the record for a base attack does not seem to work, there must be a retaliation "campaign" already in progress for the battleship to know where the base is. It seems that when the battleship arrives, XBASES.DAT tells it where to go (or not), and the scouts change XBASES.DAT when they discover the base.

    That sounds reasonable.

     

    The correct adjustment of XBASES.DAT will replace the next retaliation mission with a base-attack Battleship. I'm a bit fuzzy on whether this replacement also transmogrifies Research and Terror missions.

  15. In the second i researched lasers first and stuff,but i couldnt find any UFOs./maybe 1 or 2/So i checked the graph and lots of UFO activites were at Australia and those parts/with the spikes too/.

    On the third I did the same like the second but then there were ufo sightings almost everywhere EXCEPT Europe...Jeeez....

    Sorry for the long post but what tactics you guys use to prevent these things happen?/I was playing all of my games on Beginner/

    Well, research order is a learning curve thing (I made that mistake a couple of times myself), although there are several good options.

     

    Try sending Interceptors to the regions that are spiking (they can spot close-by UFOs as they're portable radar). If the activity rating is increasing then an interceptor has a chance of finding something. If the region's out of range of an Interceptor, a manned Skyranger still might have a chance if the UFO's one that actually lands.

    P.S.: I have an other question.When I was playing with this game in the first start.On terror missions the sectoids didnt use any psi stuffs.But in the second and third they are using that regularly on my soldiers.Is my game bugged or what?
    No; whether they want to use psi on terror missions is dependent on several factors.
  16. So what are some known bugs that could cause crashes at this spot?
    It is a Very Bad Thing to save a game with an interceptor window open. The resulting savegames eventually crash on open in Geoscape. This does include "had interceptor window open when starting Battlescape".

     

    "Eventually", because sometimes the crash-on-open doesn't start immediately.

  17. Are you sure? I tought that the research time got a multiplier in the needed research days as you increased the difficulty...
    I haven't seen this on Superhuman (looking at the relevant file in a hex editor).

     

    XComUtil has an option for drastically multiplying the needed research days as part of an optional mod, but that isn't difficulty-level sensitive either.

  18. Question: The 3 buttons on the left that show Snap shot, auto shot and aimed shot.. those are just to reserve TUs right? They in no way shape or form dictate what type of shot your soldier will take in a reaction, is that correct?
    Yes. I usually reserve TUs by calculating them before attempting the move.

     

    My understanding is that reaction shots are ALWAYS Snap Shots.. am I right on that?
    X-COM reaction fire is always snap shots. I haven't recently allowed a situation where I could personally verify whether alien reaction fire goes bursty at game-distance 3 or lower.
  19. How do people play without smoke, it seems that at least smoke can maybe help you survive the ramp, but without it, there isn't much of a chance.
    You give up on zero casualties.

     

    It becomes a matter of influencing who dies first. It doesn't help that there are no good in-game means for either screening Psi Strength (the most important stat), or sorting the soldier order.

     

    Also, Morale isn't that important -- ignoring mind control, once you have a Captain on the mission even Morale 10 will need like 5 X-COM (Rookie/Squaddie) deaths in a row to have any risk of panicking, after which you need two alien kills per X-COM (Rookie/Squaddie) death to prevent panicking.

    -----

    The minimal comprehensive solution for controlling soldier placement in Windows CE XCOM right now seems to be NKF's Neolem for fast ordering, followed by Seb76's UFOExtender for providing precision swapping. Isolated DOS versions will need another source of precision swapping.

     

    ClarkWehyr works fine once you have it installed, but the official *.EXE installer dies on W2K and higher. (Have not checked DOSBox 0.72/0.74.). ClarkWehyr also should not be used for base editing.

     

    Soldier.py (from my own suite of Python scripts) also provides precision swapping. The actual editors I have deployed currently are: Neolem, Extender, Jenny's, and mine (which also rips a few features from XCOMUtil that I actually use, such as battlescape overview).

  20. Update: still a problem.

     

    I was able to see the original crappy base layout and regular farmhouses by playing a new game from my "XCOMorig" folder. Then I ran XComUtil, choosing (among other options) to use the improved farm and desert terrains and to randomize ship layouts (once during XComUtil, not every time). Now I get the same ships as ever, but borked farmhouses.

     

    So, it seems that running this version of XComUtil (9.6) in this version of Boxer (0.87, which uses DOSBox 0.73) on a v1.4 UFO:EU executable under OS X 10.5.8 will repeatedly produce this issue.

    DOSBox 0.73 is known-bad.

     

    (It has a substantial reduction in the maximum command-line parameter length. No version of XComUtil has been released that can handle these truncated command lines. Per https://www.bladefirelight.com/downloads , there may be other issues.)

  21. Hello.

    As I understand, mission Floating Attack base is activated/beginning since shotdown UFO SUB. Only here this mission is activated only in 50% cases approximately. Activating of mission Floating Attack of base it is possible to look in the file of Missions.dat or with help transmission resolver in game. If a mission was activated after shotdown UFO SUB, the survey ship will arrive exactly in 50 hours after shotdown/

    Only not every succesful shotdown activates this mission. what can it depend?

    ~50% at what difficulty level?

     

    XCOM1 has been completely analyzed at the assembly level; it's strictly difficulty level there. I suspect at least the constants were changed around.

×
  • Create New...