tracktwo

Great idea on the selection ring, that's what I ended up going with. The indicator style is now configurable, and I've defaulted it to a ring so that the same .u can be used for both LW and EW. There are also three colours to choose from for your viewing pleasure, green (default), orange, and gold. I got excited that there would be more options because there are additional variables listed for indicator materials, but some of them (e.g. purple) aren't actually implemented - the material doesn't exist. But if Drakous79 can make some progress in adding new materials, there's more options here for brand-new indicator styles. 1.0 is now up on github and also here on nexus.

That would be fairly tough to make a custom icon here, as custom ui work is a real pain in EW. I wanted it to be attached to the unit flag, and there isn't much available that I can reuse here without interfering with other functionality. Other things could be changed, as long as you stay within the confines of the existing ui. So changing the health colour is possible. My original prototype used the EKG animation for panicked units, but that was not great because there was no way to indicate both visibility & panic. I also wanted to bring this mod to EW, but the code for showing the overwatch icons isn't enabled on aliens there. I could try to reimplement what LW did, but I was considering putting a little ring around the units instead. E.g. maybe the hunker down visibility range ring, shrunk down to just surrounding the enemy itself. I'd add a config var so you can choose the one you prefer in LW. Would you prefer differently coloured HP over the ring? I could probably do both and again allow configuration in the ini. BTW thanks for all the debugging and suggestions, its a big help. I also have fixes for the first two issues you reported and will post an update probably after working out the ui. If you don't find any major bugs before that I'll probably make that 1.0 and upload to nexus to let more people take a crack at it.

Did you happen to get a save file with the bug? This one might be tough to track down without a save that shows the exact conditions.

Awesome, thanks and keep em coming! Interesting that they show up on the motion tracker... ah, I know why. It's because I specifically excluded hidden *seekers* but not other alien types, cause they ordinarily can't stealth. Yes on disappearing on the alien turn, agreed. I also want to turn them off while the active unit is performing actions, e.g. during targeting. They're really only needed while pathing. And #3 is by design, yes. It won't show you aliens that are hidden but would become visible should you move there. It seems cheat-y to show you all the alien locations, you could use it to more accurately place grenades and rockets on aliens nobody can see.

It should be in the .zip file under the release tab. The actual repo only contains the sources, not the cooked packages, and all the patch scripts are in separate files in the repo but are combined into one big patch in the release.

Ok I think I've fixed the movement bug. The problem occurred because there were a few situations where I was dropping the helper units on top of an existing one or when moving an existing unit they'd land on the helper. The particular settings of the helper didn't seem to matter, it looks to be entirely a problem with two units occupying the same tile - it'd be interesting to see if the same sort of bugs occur when you happen to be standing on a tile where a drop-in occurs. I've fixed this by always shuffling the helpers out of the way before beginning a move action and this looks like it works, but more testing would be great. Anyway, that's the last of my major known bugs, so I've pushed the sources up to github and added a pre-release to the releases tab. You can install it with the installation instructions in the README.md file included in the release .zip file and also on the github page. Feedback and any new bug reports are very welcome so I can get a reasonable 1.0 release out here on Nexus. This is an incredibly beta release, please don't try it on an ironman campaign you really don't want to lose. Also please try modifying the SIGHTLINE_TICK_DELAY config value as documented in the readme. I can't tell for sure if it's really slowing my computer down having very low tick values or if it's just my imagination. Task manager shows no difference in CPU usage, but it *feels* slower. For the record my CPU is rather old. Github repo: https://github.com/tracktwo/sightlines Oh, and I suppose I should say how it's intended to work. Enemies that will be visible from the tile you're hovering over will have the little overwatch eye icon displayed, but in XCOM blue instead of Alien red. Aliens that are on overwatch will toggle back and forth between the blue and red states to remind you they're on overwatch (and the toggle period is configurable, see the readme). There is a delay between moving the cursor and the UI refresh (also configurable) so give it a moment to update as you're mousing around. I'm very interested especially in any bugs in the actual LoS computation. Moving somewhere and finding the results don't match what the indicator said are very bad and I would really appreciate a save file showing the problem. Other bugs are good to know too, like if you can ever actually spot or observe any side-effect of the invisible helper units.

I'll add that to my list of things to try. Not sure if dead aliens can see anything :)

Hey SpazmoJones, long time no see :) are you back for some xcom2 modding? I actually used a drone instead of the chryssalid initially, but even when invisible it made the annoying drone hover sound. So I replaced it with a seeker, which then caused the cursor to go crazy when leaving it in the same spot (presumably due to the wavy tentacles) so I changed that to the chryssalid. It remains to be seen if the chryssalid will occasionally make idle chryssalid scream noises, but so far I haven't heard anything :) But to answer your original question, no it doesn't help because they need to be landed to get correct LoS calculations, and I need it to be a cover using unit in order to get correct step-out behavior. If I move it up, it may change the distance to the target, and there may be locations in the map where moving it up would move it across some LoS blocking geometry like a ceiling.

Thanks, and just playing with it to try to find any more bugs would be appreciated. I'll upload the sources and a build to github later tonight but I don't want to add it to nexus quite yet cause it's not quite ready for general use with this bug. I think tonight I'll try removing all the funny stuff from the helper units and just make them neutral. There will be visible units following the mouse around the map but it'll be useful to see if it's something to do with all the various visibility and physics changes or just bug with teleporting units around.

Over the past few days I've been working on a little mod to bring the LoS indicators from XCOM2 to LW. These are the indicators that tell you which enemies will be visible while you're hovering over a tile for a potential move. I started this a few weeks ago, but quickly gave up cause it was super buggy. I decided to take another look and made some real breakthroughs, but I'm still having a fairly serious bug. I'm posting this here to try to see if anyone else has some ideas on how to address this. The bug isn't really related to LoS itself - that aspect of it seems to work perfectly from what I've tested. The problem is the side effects of how I did it interfere with the game in some major ways. To get this to work for EW, it's a real hack. There is no direct way that I could find to query the LoS engine to ask "If this unit was standing in this position, which enemies would be visible?". The existing game logic, including the AI, use an approximation. And this approximation is buggy, which is extremely unhelpful for a mod that tries to help combat LoS bugs. The query you can make is: can unit X see this location? That's often good enough, by making the assumption that if they can see me then I can see them, but this isn't always true and is complicated by factors like whether or not the unit is cover-using, as this affects stepping out behavior. So the way I did it is this: I spawn a sectoid and a chrysallid, make them invisible, add them to the neutral team, and disable all physics on them. As you move the cursor around, the units follow it and the engine updates what they can see, and I use that to determine whether I should show the LoS indicator or not. I need both units so I can test LoS using the Sectoid for normal units and using the Chryssalid for SHIVs/MECs/etc that don't use cover and don't step out. This all works like a charm, and is completely invisible to the player (so far, at least). The last major problem I have right now is moving these units around appears to disturb tile blocking. I already needed to clear the tile blocking (via XComWorldData.ClearTileBlockedByUnitFlag) when moving the helper units around so they don't accidentally block the tile they're standing on so the selected unit can't move to it. More problematic was if you were standing behind high cover and move the mouse to the tile you peek out from, the helper would block the peeking tile and currently visible aliens would disappear, exactly as if something was blocking that peeking tile (cause there is!). But even temporarily disabling this unblocking to ensure it isn't the cause, there are problems where these units leave the tiles they were on in an "unoccupied" state. So moving to that tile (currently occupied by the invisible helper), and then selecting another unit, you can move that new unit right on top of the one you just moved. Gross. Anyone have any ideas on how to debug and fix this? If you want to try experimenting with the current state of the mod, I can provide a build & post the source on GitHub. I'm going to keep poking at it and see if I can fix it, but hopefully someone else will have a bright idea.

Ah, as someone who spent an unreasonable amount of my teenage years in SoftICE pulling apart game assembly, I can say we have a nice senior's area here on the hype train :)

Does that mean you're back for xcom2 wghost? If so, wooo!

Ah, parens are ignored. That explains things. My personal preference would be for parens around directives to be meaningful, and this would also allow you to get rid of EndFP as it is then unambiguous where each subexpression ends. E.g. if I could write foo().bar(a + 2, b) as something like context(virtualcall(foo), virtualcall(bar, plus_intint(local(a), intconst(2)), local(b))). EndFP can be automatically inserted into the right places for the calls and the add. Not sure if you can handle variable argument lengths or not, which are needed for the calls. Aside: I work in compilers so I am happy to help if you run into parsing problems :)

Very cool! Mnemonics for complex expressions, especially complex ones like &&, || etc will be a huge time saver. I almost always forget the skip offset or put the parens in the wrong place or miss a 0x16 somewhere and spend 15 minutes scratching my head staring at the code to figure out what's wrong. But it looks like you've got embedded disk/memory offsets back in there, is that right? It's late but I can't figure out what they're for, cause you still seem to have label support. Are they just tokens inserted into the decompiled code as annotations like the comments inserted by hex2pseudocode, or are they actually used for something? Going back to manually computing jump offsets isn't something I'd look forward to... That aside, this is great, great stuff, thanks for sharing!

Agreed. Even if players typically install the mods directly through steam workshop, the forums and wiki here are extremely valuable for discussions between modders and sharing info. And sooner or later we're probably to want to push the limits of the game further than what can be done easily with the official mod support tools and we'll be back to R&D threads digging out new stuff from the game. Plus the recent bug tracking features are great and I don't think steam has them (but correct me if I'm wrong). Much better than trying to dig bug reports out of huge comment threads and trying to figure out if something's been reported before and what's fixed in what version.

There are pretty big rewards for defeating the exalt base. And each exalt mission does give a flat cash bonus, big enough that many people intentionally leave the exalt base alive after they've identified it so they can continue farming the exalt missions for cash. IIRC there are also techincal reasons why the items are gone: those item slots were repurposed to implement the new LW specific items.

I'm still not planning on doing any more work on the EW version of the campaign summary, there isn't much time left before xcom2. I still dunno if I plan on doing something similar for xcom2 or not, it depends on what if anything is already there in the base game and how much has changed with the modding tools for UI work. It was a huge pain to do for EW.

Good question, and one I'd like to know the answer to too. It might take the community a while to settle on a place. Since they'll presumably be distributed mostly through steamworks, who knows if they'll also regularly be posted here... There's an xcom2mods subreddit, but its lightly used right now and Reddit isn't really the best for long term discussions or the current knowledge on the wiki.

Yes, this is how abductions work in LW. Now panic increases more through terror missions and some specific strategy-level ufo missions instead of through missions you cannot take.

No, scatter is not controlled by the ini. The patrol value is something else (the chances that a pod will sit in the same spot vs move around the map before being activated, IIRC). Changing this behavior would need hex mods.

It looks like the first command is succeeding, but the second one is failing since you put the "echo" after the corresponding cp_ and it is printing the first one but not the second. When you say the XEW folder exists do you mean the one "<path to Xcom .app>/Contents/Resources/MacOverrides/XEW" or the one "<path to xcom folder>/Data/XEW"? Note there is a difference there between the two and not just on the end: the second is looking inside the .app and the first is not. IIRC (it's been a long time since I've used a mac) you need to take some special actions in the finder to be able to look "inside" an app to see its contents instead of executing it, and this is where the path in the error line is pointing.

It sounds like your install folder structure doesn't look at all like the one the script is expecting. I don't have a mac, but from what I understand there are a few different ways to get the game on mac and they all have slightly different setups. Evidently you don't have the same version as the person who created the mac script. The problem probably isn't in locating the xcomgame.int file within the LW package, my guess is that it can't find the *destination* folder it's trying to copy it to within the game package. It's hard to tell wtih all the variables in there, but one thing you can try to see exactly what it's trying to copy where is to make a copy of those two lines starting with cp_ and in the copy, put "echo" in front of cp_. That'll print out the line to the screen so it'll show you what command it's trying to execute. E.g. it should look like this: echo cp_ "${MOD_DATA_DIR}/$file" "${installdir}/${FERAL_OVERRIDE_DIR}/`basename $file`" echo cp_ "${MOD_DATA_DIR}/$file" "${userfiles}/MacInit/`basename $file`" In addition to the original two lines without echo. Then run it again and take a look at the output on the screen. See if you can find the corresponding destination folders in your game package at all, or if not, if you can at least find an existing xcomgame.int file in there.

Per the instructions on the wiki (http://wiki.tesnexus.com/index.php/Basic_Guide_to_installing_mods#Enemy_Within), if you've uncompressed any of the .upk files you need to remove the corresponding .uncompressed_size file in the same folder. E.g. if you've uncompressed XEW\XComGame\CookedPCConsole\XcomGame.upk you need to delete XComGame.uncompressed_size in the same place. I just tried with a fresh vanilla installation, decompressed xcomgame.upk and the game would crash. After deleting the .uncompressed_size (and also making the .ini file hex edit in the same section) it loaded successfully for me.

You don't need any base mods for xcom. If you have found a mod that looks like it does what you need just install it and see if it does what you need. Most xcom mods are installed through a program called patchergui, so you'll need to get that if you don't have it already. Xcom was not designed for modding so there is no real official support for the mods and the installation process is a little awkward, but patchergui works fairly well. You may also need to use the patchergui options to disable "phoning home", depending on the mod. It's in the menu, and check the wiki for more info on modding vanilla EW. It is true that some mods were for EU and haven't been updated for EW, and if the mod you want is like that you may be out of luck, unfortunately.

I'm not entirely sure what you're trying to accomplish with that loop. It's going to loop over every perk in the game, and if you already have that perk and that perk is the one in the perk tree, it'll return an invalid perk. If the soldier doesn't have any perks it'll just run off the end of the loop (the check for HasUpgrade will never match) and I'm not sure what will happen cause I only see the snippet there and not the full function. But if I'm understanding your initial message correctly, you want to avoid special soldier dupes in TR. Like avoiding steadfast appearing in the TR perk tree on PVD. Like I said in a previous message, trying to change the perks returned by GetPerkInClassTree on-the-fly is going to be super buggy because that function is used all over the place, like as soon as you enter the abilities screen. It needs to use that function to populate the perk tree in the UI: this is how it knows which perks to put in the tree, including marking the perks you've already selected on promotion in the tree. Having the perk in the tree is also how the game decides whether or not a soldier is eligible for promotion: if you have enough XP for a rank but no perk from that level in the tree you can promote. So if you change GetPerkInClassTree to always return a different perk if you already have some perk in the tree things are going to get really weird really fast, like infinite promotion to all perks in the game weird. For the game to work properly GetPerkInClassTree() needs to return exactly the same perk every time if you call it with the same arguments. Consider it this way: as far as the game is concerned there is no difference between a regular soldier at LCPL rank with TR on where I rolled steadfast at the LCPL rank and manually chose it from PVD at LCPL rank where the game auto-assigned steadfast before I got a chance to choose something myself. In both cases the game sees the soldier has the steadfast perk and the steadfast perk appears at the LCPL level in the tree, but there is no way for it to tell whether the perk was assigned manually by the player or automatically by the game at that point. The only place where I can make that distinction are 1) when the perks are rolled or 2) when the auto-assigned perks are assigned. Since 1) happens before 2) this needs to be done at 2). Custom reward soldiers are awarded by XGFundingCouncil.GiveCustomSoldier, so that's where 2) happens. You can see the block for PVD near the bottom in the check for the nickname "The General" (Zhang and Annette are detected by their custom heads rather than their nicknames near the top of the function). Probably the thing to do is to add code here that walks the m_arrRandomPerks array for that soldier to see if the perk they are going to be auto-awarded is in there. if it is, replace it with some other random perk not already in their tree. Sadly there aren't really any free variables to use to iterate over the perks in the perk tree. But note that the very last statement in that function is Soldier.m_kChar.aStats[2] = 0, so that is as good a place as any. You can just re-roll that single perk, but then need to take care of ensuring it's a valid TR perk and that you don't already have it. Probably simpler is to just reroll the whole tree until you get one that doesn't have the auto perk. Pseudo-Code (untested): TopOfLoop: for (Soldier.m_kChar.aStats[2] = 0; Soldier.m_kChar.aStats[2] < Soldier.m_arrRandomPerks.Length; ++Soldier.m_kChar.aStats[2]) { if (Soldier.HasUpgrade(Soldier.m_arrRandomPerks[Soldier.m_kChar.aStats[2]]) { Soldier.AssignRandomPerks(); goto TopOfLoop; } }