XMarksTheSpot

Ideally you should be working with vector images in programs like InkScape for the basic cropping and scaling operations before doing a final rasterization and cloth overlay pass, so 'pixel considerations' like that should not be necessary.

The UV space and the texture dimensions are strictly 2:1, though the aspect ratio of the actual flag mesh is more like 8:5 (measured by looking at the male kevlar armor, might look different on other armors), i.e. the flag texture is squashed to about 80% of its width on the actual model. So to counteract that you'd need to stretch the flag images to about 125% in order to make them look proper in-game, I suppose. In terms of pixels, design the flag as a ~205x128 px image before stretching it to 256x128 in a final step.

There is no overwatch indicator in the vanilla game, unless you're talking about the 'world message' popup that is displayed when a unit is using the ability. It would be possible to remove the timeout of that popup to make it stay visible, but the hard part would be tracking and clearing these quasi-persistent popup instances once reaction fire is triggered or a new turn begins.

The overwatch indicator in LW is an all-new effect and as such is not 'fairly simple', at least not in the context of XCOM, which is pretty mod-unfriendly w.r.t. things like this. Furthermore the changes introduced in LW to show that indicator are also tied to some other adjustments to the tactical unit info display (more specifically health display). It's not impossible to divorce the overwatch indicator from the other LW changes, but this is no trivial task by any means. To elaborate on that, the game uses the Scaleform middleware which essentially incorporates Flash files for use as user interface components. The overwatch indicator is a custom sprite inserted into the 'unit flag' component via advanced hex editing techniques. Additionally some additional logic had to be inserted into related ActionScript and UnrealScript (the scripting languages of Flash and the Unreal engine respectively) classes to make the indicator respond to game events.

Maybe appending AdvanceVoice(0) to the AdvanceLanguage() function could do the trick to refresh the voice selection.

I doubt that fiddling around with the Flash UI would help here. The ActionScript setup for the soldier customization menu is super generic, its 'widget helpers' are for display and interaction purposes only, the actual logic resides in the UnrealScript classes UISoldierCustomize for setting up the helpers and handling input callbacks (i.e. the front-end part) as well as XGCustomizeUI which deals with manipulating the underlying data model (i.e. the back-end). In particular the function XGCustomizeUI.AdvanceLanguage() should be of interest here as it handles the language selection and automatically assigns the first member of what the content manager deems 'possible voices': XComContentManager(class'Engine'.static.GetEngine().GetContentManager()) .GetPossibleVoices(byte(m_kSoldier.m_kSoldier.kAppearance.iGender), NewLanguage, m_kSoldier.IsAugmented(), m_kPawn.PossibleVoices); m_kPawn.SetVoiceSilently(m_kPawn.PossibleVoices[0]); (sorry for the indentation, that's a pretty long line there) As it was already mentioned that determining the possible voices for female soldiers is bugged, it seems this applies to the indexing of voices as well, i.e. voice #2 is internally referred as the first possible voice and the UI doesn't properly reflect that.

This is looking great so far, keep up the awesome work :thumbsup: Yeah, some maps are pretty compact, I think the rooftops construction one is one such offender. As for an additional spawn location parameter, how about making it configurable via an (x, y) offset vector instead of using pre-defined constants? Depending on whether the offset would be relative to the extraction volume or the default spawn locations, at (0, 0) you'd either place them inside the EV or at their default positions. In either case it might help to consider the offset in local space relative to the LZ's specified orientation instead of world space (i.e. making it easier to think in terms of 'in front of the EV and a bit to the right'). By having some more control over the placement of the set of soldier spawns you could deliberately place them in interesting configurations, like next to the EV instead of in front of it, or at the other end of the map, if you wanted. Just my two cents :)

Okay, this can be done with a simple hex edit. Well, not so simple actually, but let me explain: Basically a color transform in a Flash file defines up to 8 values, i.e. two sets of RGBA values, one for multiplying color values and one for adding to color values. In the case of the rank outline the red, green and blue values are multiplied by 0 and then to that (255, 209, 56) is added. Now you might think looking for the hex representation of the additive color terms (i.e. FF D1 38) would be a good idea, but that won't help here. This is due to the way SWF files (and in extension GFX files, which are a Scaleform-specific extension of the SWF format) are set up, meaning that they make heavy use of bit packing to encode data. Now to dive into the relevant hex data. The section corresponding to the rank highlight component (inside UICollection_Strategy_SF.upk) is as follows: BF 06 27 00 00 00 2E 12 00 57 00 C5 8F 84 C7 C2 2D 32 19 40 E8 00 00 00 04 00 FF 34 43 80 00 72 61 6E 6B 48 69 67 68 6C 69 67 68 74 00In SWF terms this is a PlaceObject2 tag which in this case defines position and scaling information, a color transformation and a name for the sprite so it can be referenced by ActionScript. The color transform subsection resides in the following bytes: E8 00 00 00 04 00 FF 34 43 80 00Using the SWF File Format Specification document we can decode that sequence (a so-called CXFORMWITHALPHA record) as follows: hex E8 00 00 00 04 00 FF 34 43 80 00 binary 1110100000000000000000000000000000000100000000001111111100110100010000111000000000000000 ^^<10>< r* >< g* >< b* >< a* >< r+ >< g+ >< b+ >< a+ > To explain in detail, the first bit denotes that the record features additive terms and the second bit that there's also multiplicative terms. The next 4 bits encode the number of bits each term occupies (in this case 0b1010 = 10 bits). The following 80 bits are the multiplicative and additive terms as signed bit values. Here we see that the multiplicative terms for red, green and blue all end up as zero and the alpha mult as 0b0100000000 = 256 which means that the alpha value is essentially multiplied by 1.0, i.e. it is effectively left alone. Now for the interesting values, the additive terms, and how to change them. Here in the sequence we find our yellow color values, r = 0b0011111111 = 255, g = 0011010001 = 209, b = 0b0000111000 = 56. Now let's say we want to replace that with a light blue hue, for example (90, 152, 220). First we translate the decimal values to 10-digit binary, e.g. using windows calculator in programmer mode: (0b0001011010, 0b0010011000, 0b0011011100). Then we insert those values in the binary sequence above and convert the result back to hex: 00 5A 26 0D C0 00 ... 000000000101101000100110000011011100000000000000 a* >< r+ >< g+ >< b+ >< a+ > Et voilà, this is also part of our final hex replacement block: BF 06 27 00 00 00 2E 12 00 57 00 C5 8F 84 C7 C2 2D 32 19 40 E8 00 00 00 04 00 5A 26 0D C0 00 72 61 6E 6B 48 69 67 68 6C 69 67 68 74 00 Sorry about the lengthy exposition, but this is basically what you have to deal with when mucking around with SWF/GFX files :) I hope this makes sense to you, let me know if you run into any problems.

You have a really convoluted manner of speaking, I have a hard time understanding what exactly it is you are asking (plus you're often using technical terms not quite correctly). The game, or rather the engine, uses Scaleform middleware for user interfaces, which are basically Flash files, nothing baffling about that. It's simply easier and more efficient to stack the same image on top of another with a color transformation instead of having to paint a separate set of outline textures for such a minor UI element (the promotion outline effect appears nowhere else, after all). To elaborate on the term 'rank sprite', a sprite in Flash terms is a container which can hold other objects like text fields, vector shapes or other sprites. The rank sprite in XCOM is a shared resource (i.e. it is defined in a common file and can be imported into other GFX files at runtime) and is set up to contain a series of rectangle shapes each with one of the rank images as a bitmap fill. You can think of this as a bunch of simple polygons with rank textures on them. The rank sprite furthermore is set up to contain a bunch of labeled animation frames which are used to control which image sub-shape to display at a time. Back to the faux stroke effect, the rank sprite is imported into the Debrief file and two instances of it are placed inside the so-called SoldierSlot sprite which is the prototype of, you guessed it, the soldier slots in the debriefing screen list. One of the rank sprite instances gets a color transform which makes its contents all yellow as described in my previous post. Most of the time this instance is left invisible, it's only made visible when told so via ActionScript (the Flash-internal scripting language which the Unreal Engine's scripting language, UnrealScript can interface with thanks to Scaleform). The other instance is placed on top of the yellowed one and servers as the general rank icon you see most of the time. So, what I was trying to say earlier is that it is feasible to hex-edit the SoldierSlot sprite to replace the yellowed rank icons sprite with a simple static image shape. To actually get a new image into the GFX (i.e. Flash) file additional steps would need to be taken, to most straightforward one being to embed a texture directly in the file - like you would do when building a Flash video, but XCOM does that by pulling assets from the UPK file the GFX file is embedded in, again, Scaleform doing its magic here. In any case, this form of user interface modding (or 'Flash hacking' as I like to call it) is not for the faint of heart. For instance, adding data to a GFX file would obviously increase its size and getting that to work is a bit more involved and requires software like UPKModder or UPKUtils (i.e. a simple search-and-replace hex-edit won't do). To summarize, possible: yeah, easy: no.

This effect is achieved by overlaying the rank icon on top of another rank icon which has been scaled to 120% and which has a color transform that turns it completely yellow. Basically like this: http://i.imgur.com/VfshN9G.png As you can see this faux stroke effect works reasonably well for circular shapes, but less so for more complex concave shapes. In any case, since the outline is based on the actual rank image it would work automagically if you were to swap out the rank textures. Replacing the effect with a static promotion image onto which the rank sprite is layered is technically possible, that is, I believe you could embed a raster image directly into the Debrief GFX file and use that as a bitmap fill for a new shape that would be used in place of the tinted rank sprite. However, this procedure is not really straightforward and making it easily installable as a user mod is similarly tricky, I assume.

Here's the collection of vectorized symbols used in Long War so far (soldier stats and overwatch), as per request here. Feel free to shoot me any questions about GFX hexing you might have.

I think some gradation w.r.t. difficulty by factoring in elevation, cover and proximity to overwatching XCOM troops would be cool. So, for instance, an 'easy' drop would happen smack in the middle of a bunch of overwatching units whereas a 'hard' drop would maybe place a thin man on some roof in cover and outside the immediate visual range of your units so they invariably will run into its overwatch fire. Maybe coding in some special cases for 'cheap tricks' could be fun, too, like dropping a thin man right next to an injured soldier so that overwatch fire killing the thin man would be poisoning that already injured soldier, a 'suicide drop' if you will. Might be a little frustrating though, most people probably won't appreciate aliens playing dirty like that :happy: It would be cool if the drop-in animations for sectoids, chryssalids and mutons from the Slingshot DLC could be used to have more variation in alien unit types dropping in, but as far as I understand those are tied to the map packages in some fashion, bummer.

Alright, your wish has been granted, it's in the repository :)

Hm, yeah, I have run into this when developing on Ubuntu at work. Not sure what's causing it though. I'll try and see if I can resolve that. What I think is happening to super-size the window on your end is that the status text field and/or the UPK path text field in the bottom bar are initialized with some overly long string on application startup which messes up the preferred size of the component and in extension the layout of the whole frame. After the frame is packed to conform to its preferred size (derived from the preferred sizes of its child components) its minimum size is fixed to that value which prevents you from manually down-sizing the frame. I'll look into adjusting the layout to be generally smaller by default to better conform to lower screen resolutions. Edit: on a closer look it seems everything is working as intended, it's just that the default preferred sizes are chosen as a bit too generous resulting in a default frame width of about 1400 pixels. Lowering those values and possibly removing the minimum size restriction is an easy fix. Edit 2: the disappearing log button was due to some layout slip-up, should be fixed now

You're right, I forgot that on Linux systems popups need to trigger on mouse press events, whereas they trigger on mouse release on Windows. Thankfully that's a simple fix. Also, yeah, replicating some functionality in toolbars and menu bars generally is good practice. Currently there are no facilities to modify project settings in-application nor are there any directly editable global settings other than in some kind of workspace configuration binary file for remembering previously opened projects. I'll keep thinking about this, there's quite a bit of user interface stuff to take into consideration to tie all of that together. We're hardly experts at java coding either, neither do you need to be one to make small adjustments here and there (for instance, adding toLowerCase() calls in places dealing with UPK file names) :wink: And since you're already proficient in at least one other programming language it shouldn't be too hard for you to find your way around Java, all it takes is some reading up on documentation, which is usally excellent for the core classes :smile: As I've said earlier, the project's repository is publicly accessible, anyone's free to tinker around with the code at their own leisure/pace and we'd very much like to encourage other people to check out the source (pun intended :wink:).

Yeah, that's a reasonable suggestion and a pretty straightforward change. Since there's currently no way to change the source directory path in-application and the sourcefiles get dumped in a subdirectory of where the project XML is located it makes sense to just use a relative path, or maybe even do away with it completely. I think I had this argument with Amineri, but she was in favor of keeping UPK file associations project-specific, back then when the most immediately useful and needed feature was the reference updater. I agree that the way it's set up currently is not really suited to sharing mod files as you have to re-pick the target UPK files manually after importing. There should be a right-click context menu entry in the project tree view for that purpose. PS: since UPKModder is an open-source project you're free to check out the source, implement some changes yourself and deploy a custom version; I suppose Amineri could also grant you permission to commit code while we're at it :)

Maybe try looking into Cheat Engine, there seems to be an updated table for the most recent EW version in this forum thread. Not sure of its capabilities, but from a quick glance it looks like mucking about with soldiers stats is possible in some form at least.

I've tried to do this myself, but there's no real tutorials for modding XCOM. The wiki article about hex editing UPK files assumes you already know how to find the function to change. If you want to modify the actual loadout screen menu you'll need to edit the corresponding embedded Scaleform UI Flash files inside UICollection_Strategy_SF.upk which is a pretty involved process. However, as the game logic for the soldier inventory has changed in EW you won't actually make use of additional items as detailed in this post. You can make a third small item slot show up by editing the general number of small item slots in the DefaultGameCore.ini file, but again, you'll probably need to modify the game logic to make that extra slot have an effect. I'd focus on fixing that first before bothering with adding even more slots. If you're determined to do this I suppose the XGLoadoutMgr class inside XComGame.upk would be a starting point. X.

Pretty intriguing stuff. I've dabbled in 3D modeling myself, but unfortunately there doesn't seem to be a lot of documentation about the Unreal Engine's native internal model format around. Gildor's UE Viewer (formerly umodel) apparently can parse that format for display/export purposes, but contrary to several statements he made throughout the years he hasn't released the source code to it so far (bummer). Furthermore, from what I can tell the ActorX format seems to be a legacy format used in earlier renditions of the engine but has largely been superseded by the FBX format as the preferred 3D interchange format. In any case, if UE Viewer's export function in conjunction with an ActorX import plugin for some 3D modelling software creates a scene that when re-imported into the UDK is functionally equivalent to the original model we should be good to go. To test this out I'd propose to start off with low-complexity model like hair styles/headgear before moving on to creating/modifying more complex models like heads, bodies (i.e. armours), weapons or whole aliens. Besides, judging from the popularity of hair mods in other games like The Sims or the Elder Scrolls games I believe people would be all over this :laugh: X.

That's an issue that's currently being worked on. In the interim you can use the following hex change to make the soldier slots fill in the proper order (and to allow more than 6 slots to be filled): Also available in upk_mod format if you're using UPKModder: Probably doesn't work correctly in conjunction with OTS naggers, so use at your own risk :smile: X.

An interesting point, indeed. Especially so if it extends to importing new art assets, that I would like to see :) X.

Neat stuff, as always :smile: I wonder, if modifying the object list is a possibility, what's stopping you from introducing new local variables? Or to put it differently, what modifications are needed to create new variables (or structs, functions, classes, etc. for that matter)? By re-using an existing namelist entry (for the sake of simplicity) wouldn't you only need to append a new objectlist entry to the header? You'd likely need to adjust the file offsets of all objects to account for the extra entry size, but similar to the function resize operation that can be automated easily. Or as another alternative, how about re-locating local variables by changing their owner? Assume you re-write a function to not use a certain local variable anymore (maybe some debug function) could it be moved to another function instead? Maybe some 'borrowed' locals don't work properly because of some internal memory management shenanigans by the engine which could be circumvented by re-locating the variable. Just throwing around random ideas here :smile: X.

You will have to modify the Skyranger capacity to actually be able to select more soldiers. You can either use the changes detailed by yerude or modify the DefaultGameCore.ini for that. The change to XComGame.upk deals with fixing spawn locations so soldiers don't start out in odd places, it's recommended you apply that, too. That's good to know, apparently the flash menu was left untouched by the patch.

For the UICollection_Strategy_SF.upk change I only listed the beginning of the sequence to replace: 5F 5F 50 61 63 6B 61 67 65 73 2E 53 71 75 61 64 4C 69 73 74 00 FF 0E D5 0C 00 00 64 00 88 ... // and 5954 bytes more The complete sequence is 5984 (or 0x1760 in hexadecimal) bytes long, as outlined in the post. So you need to select 5984 bytes starting at (and including) the above sequence and replace it with the after bytes.

The uncompressed (and modified) UPK files can be used in place of the compressed ones. In addition, for the XComStrategyGame.upk you'll have to delete the XComStrategyGame.upk.uncompressed_size file to make the game accept the replacement. If the game still crashes you probably made a mistake when modifying the files - note that the changes are supposed to be replacements, you need to overwrite the exact number of bytes using the modified data, i.e. the total file size needs to stay the same. If you're using HxD it will notify you when you're about to change the file size, at which point you're about to make a mistake :) Glad you got it working :) I am aware of the 'bugs', but they are missing features really as this is just a work-in-progress version. In the final version you won't be able to scroll past your leftmost/rightmost usable slots and therefore you won't get to see any of those unusable empty boxes.