Campaign summary/Journal

[tracktwo]

Oh right, that's something that I forgot. All pngs used in the flash need have dimensions that are powers of 2. So the 32x32 ones are good to go, bit the world map needs to 1024x512. You can keep the actual map the same size and just center it on a slightly larger transparent background, that's what I'll do with the version above. But, just for future reference...

[Zyxpsilon]

Finally... i started the 16 countries batch -- with an incomplete India version.

 

EDIT... *** The image that was here has been deprecated since the finalized version is further below! :D

 

The shadowy layer (for everything outside the country) has to be inserted onto that image & maybe i'll add a subtle glowing effect around the borders -- of INDIA.

Good night (...week), folks! :ninja:

 

PS; Shoooottsss 1024x512 ... really?

Edited July 13, 2015 by Zyxpsilon

[tracktwo]

Yep, always powers of two for the textures in the UDK, and the import process will create textures out of all the .png files in the .swf. I'll start an initial mock-up of the flash file tonight with the full world map and try to get a few of the pieces assembled.

 

I also realized this morning that I'm going to need to change how the location info is stored. I want to minimize the amount of string processing I need to do, and also I want to maximize the localization of the information. There is a XGMission.GetLocationString() function that will return the location of the mission in a localized, human-readable form. E.g. for a location that has a city (most missions), it'll say e.g. "Beijing, China". If it doesn't have a city (ufo missions) it'll just say "China". It will also just say the continent in some cases, e.g. for a base defense. I don't have a save available for a base assault or an air base mission, but for a base defense it records both the location string (in my case, "North America") and the location coordinates (0.22,0.27 - the position of the HQ on the map). So I think that those two pieces of info will be enough to both display a human-readable string on the mission box and pinpoint the location on the map. I'd still like to test some of the other mission types though. If anyone reading this happens to have saves available - either at the geoscape with the mission available or right in the mission itself - I'd appreciate if you'd send me a copy. I need a base assault and an air base mission for now.

 

I also discovered that the default mission recording correctly uses the customized rank strings ("Tech Sergeant" if you are using LW) but uses the supra-class names ("Weapons") instead of the specific class name. I need to dig out where those are. But, I think this mod can be mostly independent of LW - it won't be too much effort I don't think to make sure it works with vanilla too. At least at this point, it depends on whether or not we'll need to take a dependency on something LW has already changed as we get further along.

[Amineri]

Class indicators are a bit tricky in LW.

 

Originally I just used the XGStrategySoldier.m_iEnergy field to store subclass info. However, when we added the subclass-specific icons, I had to figure out a way to pass such information to the tactical game so the correct subclass icon could be displayed there.

 

There's a little bit of duplication in the vanilla game that I took advantage of. Class information is stored within XGStrategySoldier in both :

m_kChar.eClass
m_kSoldier.kClass.eType

The function XGStrategySoldier.GetClass() returns the m_kChar.eClass value. This is the supraclass, so all MECs have class 6 , for example.

 

When soldiers are transferred to the tactical game in XGStrategySoldier.BuildTransferSoldier, the other value is set to the subclass using :

kTransfer.kSoldier.kClass.eType = byte(m_iEnergy);

Subclass indices are non-dense, using multiple of 10 to indicate specific variants.

+10 => subclass variant one

+20 => subclass variant two

+30 => MEC variant of subclass variant one

+40 => MEC variant of subclass variant two

 

An alternative way to look at MECs is that MEC version is +20 compared to soldier version.

 

Typically in the strategy game, it's more robust to use the GetEnergy accessor, as in XGDebriefUI.BuildSoldierOption :

    kItem.m_eSoldierClass = byte(kSoldier.GetEnergy());

The m_kSoldier.kClass.eType value is not guaranteed to be valid until the soldier goes on a tactical mission. However, in your case in XGStrategy.RecordMissionResults, info is being drawn directly from TTransferSoldier instead of from an updated XGStrategySoldier, so GetEnergy isn't available. Also, the soldiers necessarily must have been sent on a tactical mission, so m_kSoldier.kClass.eType should be valid.

 

I think you'll need to change the value :

((Soldier.kChar.eClass != 0) ? GetSoldierClassName(Soldier.kChar.eClass) : ""))

to:

((Soldier.kSoldier.kClass.eType != 0) ? GetSoldierClassName(Soldier.kSoldier.kClass.eType) : ""))

This should retrieve the subclass name instead of the supraclass name.

Edited July 12, 2015 by Amineri

[Zyxpsilon]

Alright my friends... meet the final version of...

 

#1) NE_Australia(1024x512_WG) ... Scale == 1/1 -- Clip Range... T=1074 L=3072 B=1592 R=4096

 

(( NE=NaturalEarth & WG=White Glowing effect ))

 

 

 

http://s4.postimg.org/96p8qaii5/NE_Australia_1024x512_WG.png

 

 

 

This exact location is calibrated to respond with & to strict coding references. Since the basic grid will be 24x12 -- if you consider the source file is 4096x2048, a 15° "box" is built around a pure 170x170 pixels scale. As a result, no formula fiddling would be necessary for a few countries that won't need zooming factors such as African, European or Japan, etc.

So far, Brazil + Canada + China (and maybe India) should all fit into this category too -- as i found a way to keep them reasonably tight in the very same perspective instead of a 90° spin (Argentina will need that tricky variation, i guess)

 

One down -- fifteen more to go!

 

Any rational suggestions for the gimmicky Russian width... it's a major puzzle to solve, AFAIC.

 

Not sure yet if i will need to use a shadow-gradient layer (in the neighboring areas) for any of the others. I'll probably trust some visual artistic instinct in many cases. :wink:

Edited July 16, 2015 by Zyxpsilon

[tracktwo]

I started playing with the actual map today. Couple of questions for you, though, Zyx.

 

It looks like the world map is not actually embedded in the flash for the situation room UI. If you scroll around in the base, you can see it already displayed on the wall before even entering the situation room. Once you enter the situation room, it gets a darker overlay, but is otherwise the same. This looks to be due to a "screen" that gets dropped on top of the map from flash (if you open up UICollection_Strategy_40, it's shape 208. There are also additional shapes for the countries to drop the red overlays on top of the countries that have left the council. The "mapArea" shape that is the little screen is actually 481x303 pixels in size, but it gets scaled by the current resolution. Where did you get the dimensions you had before for the world map?

 

At any rate, it'd be simple enough (I hope!) to scale these images to the right sizes based on the current resolution so they fit correctly into the existing background. I had hoped to re-use as much as possible from the existing logic to do that, though.

 

In other news, I'm about ready to throw both SWF Quicker and Vectorian Giotto out the window. It looks like I can install previous versions of flash - including CS6 - with a subscription to Flash, so I think I'm going to try that out for a month or so and see if it actually works. They're both sort of OK for laying out shapes and sprites on the screen, but are terrible for ActionScript support, which is something I very much need to have working well in order to do pretty much anything complex with the UI. They also both crash quite a bit and haven't been updated in years.

 

Also, for Russia, maybe just squash it in the X dimension? It'd distort it, and we'd need to apply the same squashing to the location of blips put on the Russia map, but that shouldn't be too bad.

[Zyxpsilon]

Next formal step(s) in the concept phase.

 

Let's talk about Lists and spreadsheets.

 

To me, the most likely candidates for relatively simple screen areas fall in two straight forward repurposing attempts.

 

1) Covert way...

 

 

 

http://s7.postimg.org/et0eeozjv/Covert_Style_Box.png

 

 

 

It is slightly narrower than #2 below. Can accomodate at least 4 (plus 1 or 2 more) solid lines. Its wide box (..on site) could offer ample space to put "legend & column description stuff". We possibly wouldn't need the "Egypt + Exalt cell present" instances. Tightly fits the bottom section and is symetrical. Must have a scroll bar.

 

2) Satellite way...

 

 

 

http://s17.postimg.org/5evkjgngv/Satellite_Style_Box.png

 

 

 

Wider range. The "HAS SATELLITE" area could be replaced by an exact copy of the yellow "..on site" above. While discarding "UNITED STATES" section.

Guess-timate -- probably 6-9 lines judging from its strings proportions and as shown by their current text sizes, we'd get more bang per lines. Plenty of width to work with.

 

And -- one more feature thingy...

 

3) The secondary "Mission Info box".

 

 

 

http://s9.postimg.org/t3ow7ql8f/Missions_Pop_Up.png

 

 

 

Why not simply re-use the pre-briefing popup that we get during the SkyRanger flight. Much more details about & from the post-mission results could be squeezed into the structure itself. Even the "LOADING..." banner corner area would be perfect for "Mission Completed!". List of artifacts recovered. Aliens killed or Captured. No more Tips. Location coordinates. Symbols. Icons. Squad ID's, etc.

 

Our previous tiny Mission-Box (on the maps) should offer a quick access button to that one. Which btw -- has a weird coincidental size... nearly the same as "Maps"!! :wink:

Edited July 13, 2015 by Zyxpsilon

[Zyxpsilon]

I really wouldn't know the exact SWF structure of the Situation-Room. There are many options that lead to various type of screens.

 

As long as our 1024x512 "standard" for the 17 instances can fit the usual area (either through layering or as a direct GFX component) -- i'm okay with any easy coding solutions you might offer. My theory dimension was simply picked from a snapshot of the 1920x1080 screen on my monitor... thus, the 952x508 framework, initially.

 

Russia? You mean like changing its ratio to 1/1.5 (or else) or something? Yep, that would do the trick i think. In fact, i had reasoned earlier this evening that a simple 1/2 sized rendering would somehow work. It would make that country a lot thinner than others though. Here's what i'll do -- i'll create some temporary variations test images and you'll pick what you prefer -- later on. I'll keep that beast of a graphic edition task for last!! :wink:

 

EDIT; Okay... i opened up the gfxSituationRoom.SWF file to find if a proper reference shape or sprite would indicate how the various assets are being displayed on the basic HUD structure. And lo-behold -- sprite #145 is indeed a layer element that has weird composite scaling. 514x351.

 

http://s29.postimg.org/ldqxfwtuv/145.png)

 

This image has two strange factors... one pixel to the left and bottom & a large band (about 20 pixels to the left of my inserted parenthesis) which are transparent! The black area at the bottom is normally used by a ticker as you know already. Note that this resource certainly gets a proportional re-scaling applied by a code function somewhere, somehow.

 

*** (( Worthy NOTE, btw; there's a possibility here. Maybe we just could exploit this layer feature to keep the default background file and its animated process **BUT** fixing the layer as to adjust appearances to my "darker grey-scale with a touch of cyan hues" coloring schema. Needs ingame testing once you have a working custom flash component.))

 

Thus -- i really have to wonder **HOW** exactly does the texturing occur. The world map also has a tricky method of various animation tricks. The best example for this sort of effect can be demonstrated by the T_Earth_Holo_Index_Scrambled file;

 

 

 

http://s12.postimg.org/du0a149i5/T_Earth_Holo_Index_Scrambled.png

 

 

 

Which *IS* 1024x512... so you were right about that proportion. But, as i understand that process -- the runtime engine must be "re-adjusting" anything for display. Looking at my 952x508 snapshot you'll also notice as slight variation in height proportions (from the valid Holo-Index style).

 

As a result, the essential concern here is that the basic source (for our 17 maps) is that 1024x512 should perform correctly. With your code magic!

And -- that the extra layers might have to be adapted to these rendering contexts in order to provide; Dots & Circles, Dataset Numbers for the 8 colored boxes, Mission box text & images, etc.

Edited July 13, 2015 by Zyxpsilon

[tracktwo]

It likely doesn't matter too too much what the original source image size is unless it needs to be scaled up, and I think 1024x512 is big enough that this should be the case. I am still trying to decipher how the scaling occurs but haven't had too much success yet. That's something I'm going to keep looking into.

 

Worst case, I can't figure out how the game does the scaling or can't correctly hook into how it does it, and I'll need to reimplement the scaling myself in the custom flash movie. Not the worst thing in the world, but I'd rather reuse what I can.

[Zyxpsilon]

Strangely, i suspect this area (for the central map only and its generic assets like the animation) is a simple dropholder pre-defined by & for a pure 3D model!

It has to be built according to UV mapping details declared within the common format of "SkeletalMeshes" or via some direct *.PSK file compression along with DIF & NRM texturing resources.

I found this stuff by extracting a few things like Static_xx or the MedKit & ArcThrower (which i wanted to re-texture exactly as they are pictured for their Inventory images -- red casing and all).

IIRC, the SituationRoom has a dedicated "board" mesh (and many more objects like consoles) that must receive our map -- as a pseudo-texture that can also obtain run-time effects.

This is where you will find the generic facts, i believe.

 

Let's see -- opening UModelGui -- loading the uncompressed Static_SituationRoom.UPK file -- finding the right object(s)...

 

 

 

http://s22.postimg.org/rylqabfxd/World_Map_Panel.png

 

 

 

Yep, it *IS* a full blown Model... aka -- "Plane"!! :wink:

Edited July 13, 2015 by Zyxpsilon