Krazyguy75

Yeah, I think either would work, mainly I just think that EXALT would have a hard time blending their normal people in if they all looked like they were clones of someone from the past.

Hm, I think I'd like the basic exalt to look more mundane, as if they were summoned all of a sudden, grabbed weapons from a hiding space, and deployed instantly, the quick reaction troops. Whereas Exalt Elites should be shadowy occult figures wearing advanced gear, as if EXALT deployed them specifically to eliminate XCOM.

...almost everything in XCOM is hard coded. That's why we need to hex edit for most mods. But I don't think it'd be that hard, probably just changing a case statement somewhere. However, it might be in native code. I'll try to look for it in my spare time.

What about things like the directional meld indicator and so?

I suspect it is trying to find the meld. I could try putting some sort of exception in the upk, 'cept I'm still not very good at writing my own pieces of functions...

The problem with early psi is that you can clear missions easily with early mind control. Very, very, very easily. You get a free scout every 5 turns, as well as essentially killing off an alien. Granted, it is temporary, but most aliens can be killed off before the third mind control turn. Mindfray + high cover = nigh impossible for early aliens to hit and very hard to flank. Granted, Psi Inspiration would be many times more useful to get rid of those rookie panics early on, but MC is OP vs the early, low will enemies... The only way I could see this being fair is if you had to research each level individually.

It appears not, the game freezes upon loading the maps (presumably, since I set them as new maps and a 90% weight.)

1. Maybe, I'd have to test. But if so they will lack Meld. 2. No, don't think so, as it'll most likely break a bunch of code.

Their version was almost certainly changed to include special types of objects that would then be broken down into the tiles we see now. I doubt they built the levels out of these puzzle pieces.

They do? I thought that only the balance mods do? What have you successfully changed?

Did you make the edit to the exe or use one of the many programs that does it?

Short answer: Not really. Long answer: Yes, AFAIK, I believe it is technically possible, but we'd have to individually move each and every part of an existing map (1 tile of floor, 1 tile of wall, or 1 block of cover at a time), and even then I'm not sure if we'd be able to add or remove parts and I'm sure we cannot add types of parts not already in said map. It's just way way way too time consuming.

Anyone checked the code for C-Hive? Winning that mission may involve leaving people behind (both living and dead) and as such, their equipment should be lost.

e_CP_Robotic is the character property that makes robots immune to psionics. As for the second question, I don't know.

Or maybe it is the reverse: a soldier equipped with these unavailable items would get the perk, to support modding (since they finally started acknowledging its existance). Testing is required.

Amineri already figured the solution out in another thread, think it might have been the discovery thread, and I believe she managed to keep the yellow symbol by just replacing the reference to the gene mod soldier getting a different model.

Did you modify the EXE to load the ini or use a program that does this?

Ah, OK. My programmer-speak is still not fluent. Then what I was referring to is the ability to change the variable type of an individual item in said struct to an array, which I gather isn't possible. What gave me the idea was that m_i and m_e were used both in the struct and as the base variables, so I was thinking that maybe m_arr could be used in both. But if we can't change that, oh well. Just makes my planned code a little more complicated.

Have you made the necessary changes to the exe to get it to load the ini? Cause otherwise that'd be your problem.

To be more precise, the variables in question that I was wondering about were not the base variables in the ini, but the variables in the arrays (characters, armor, weapons, etc). I'm pretty sure you cannot add more variables to these arrays (correct?), so I wanted to know if I could turn one of the existing variables into an array. But if my assumption that we can't add more variables to these arrays is wrong, then my idea was pointless.

So, I was just wondering, when editing an ini, if you repurpose the variable in the UPK files, does the variable type (int, string, array, etc) have to remain the same in the ini file? Because I know that all the variables come with prefixes indicating their types (m_arr, m_i, m_e, m_str), and I was wondering if these are checked by the code to make sure they're the same, or if I could change the code in the ini to an array, and then have the array import correctly, as if it were the base variable (wiping out the previous code related to said variable, of course). I'm to much of a n00b to test it out, but I thought that, if you could change the variable type (since the name doesn't include the type prefix internally; unless it is in the hex: I'm not familiar with the config import code) to an array, and then change the recieving side's code to read the first value of that array, and use all the spare values for additional config. Ofc, I have no idea how any of this really works so it'll probably have tons of issues, but I just figured I might as well share my crazy idea, in case, by some wild coincidence, it works.

Would the killaliens command work? Also, for the above method, I think you can bind "slomo [something huge]" to another key to speed up time.

It's not that simple, alas. The gene mod is the character model, not the armor, so you just get plating sticking wierdly out of their skin.

We can rewrite entire functions, so long as the function size (in bytes) is unchanged.

It is risky and can be taken down from copyright infringement, as they do belong to Firaxis. It will prolly not get you in trouble, tho.