Jump to content

Campaign summary/Journal


tracktwo

Recommended Posts

Excellent plan of action -- indeed.

 

Putting the "Graphs-View" next on the burning plate is a lot more cohesive for development reasons as you so aptly described.

Besides, all of these "Mockup" tasks for the Summary feature (and others) are a work in progress. But fear not... the actual HUD-UI elements (and the coding required to sustain them) will not be that hard to do **IF** great care is taken to re-purpose most of the vanilla SWF-GFX methods & assets -- with some of our own tricky design choices in mind. Don't forget we've got a master UI guru just waiting to put a big X imprint on the entire stuff - eventually. :smile:

 

For example, the latest Mission-Report concept phase has again been turned upside-down towards a new "structure" (rationalized for optimal usage of screen areas -- sort of) that i believe would be MUCH more efficient and easy to code. I'll have a sample of that one... soonish.

 

Take all the time and decisions you figure are best, TT-Jo! We'll always be here to watch any of your fantastic results once ready. :wink:

Edited by Zyxpsilon
Link to comment
Share on other sites

  • Replies 176
  • Created
  • Last Reply

Top Posters In This Topic

Good news -- i might have figured out some optimal solution for the "Mission-Reports".

 

It involves a simple HUD switch (via clicks on the Title bar) between the Squad & Debrief components. Pretty much everything on these elements are re-using actual SWF default structures with re-sizing & string corrections to fit the necessary width or "panels" extent.

 

See below...

 

1) The SQUAD panel -- most common during gameplay is Eight Troopers... anything above can still scroll;

 

 

http://s21.postimg.org/3y1movhxz/Mission_Report_Mockup2_Squad.png

 

-- Ideally, that pseudo Barracks-List (scaled from the default size at exactly 65%) would allow the primary weapons & one small-item slot or MEC's secondary to be shown.

 

-- Didn't insert the Kills & Captures symbols... they'll be similar to what has been drawn on the first Mockup.

 

 

 

2) The DEBRIEF panel which requires three individual scrollable columns that contain 5 specific sections -- if needed;

 

 

http://s22.postimg.org/q8oc6frox/Mission_Report_Mockup2_Debrief.png

 

-- Each header sub-titles are valid strings found in the INT files.

 

-- I feel a single scroll to the right side is enough as the whole panel should somehow move itself around when extra bottom stuff is present.

 

-- Code-wise, i really dunno if these five individual areas can be dynamically assembled for visual balance or within some appropriately structured contexts. I just have to wish they'll be deploying in such a manner that the popup will be relatively easy to examine.

 

 

 

Of course -- if anyone thinks there might be a better way, please share your thoughts. But to me... this is the very nearly finalized concept.

Edited by Zyxpsilon
Link to comment
Share on other sites

Wow... some good questions there.

 

Much of the images that you currently see on any of these Mockup samples are simply "transfered" (when snapshots are taken) from my own in-game assets (mostly dispatched by the ReCLR projects TPF files). Texmod being completely customizable (or not), it will certainly adapt to/with/against anyone's UI needs and won't touch anything if people just want to keep all of the Vanilla defaults.

 

Flags -- these are also altered locally... i prefer them as pseudo-buttons that don't interfere with the Rank Icons. That's a personal issue (visual balance, btw) and (again) their custom versions won't be shown on people's HUD if ReCLR isn't activated.

 

Hear from us soon?

It really all depends on TrackTwo's (and maybe X) slated schedule(s) of corresponding tasks. I know he has written that he would prefer to tackle the various features in this manner... 1) Journal 2) Graphs 3) Summary.

It is also a matter of dedicated time & progressing with results -- rapidly or less so. I'm simply a source of "inspiration" (while just hoping to be obvious and direct enough about the concepts phase) for these *VERY* important coders. They have the skills & hopefully, the necessary persistent will -- to realize that entire stuff in due time.

 

XCom2 is lurking like a ghost that will possibly take-over our precious calendars... besides, whatever comes next will be candy for LW-Fans.

 

Sooooo don't worry -- i'm busy (Lately with the LW--Pedia feature) and i suspect everyone else involved in this huge project is too.

Link to comment
Share on other sites

Here's the current working status of the timeline:

 

 

 

http://i.imgur.com/pFRqZ7T.jpg

 

 

 

A few notes:

  • This is not a mock up, it's a real in-game screenshot
  • The "head" on the gutter doesn't move yet and can't yet be dragged, and the play button doesn't "play", stepping continuously through events. But the forward and backward buttons step through events.
  • Events are shown with almost no processing. I did split out the date/time, but otherwise it's "raw" data from the journal. This looks crappy for certain events, especially mission results. They need more pretty-printing.
  • Events that occur at the same day & time are grouped in the same box and treated as one "step". Not sure if this is a good approach or if each step should be a full day. Days can get very long, though, especially late game with a multi-mission day.
  • Text box doesn't scroll yet, so text is cut off at the bottom if the grouping of events is longer than it can show at once.
  • My icons are aligned badly, but haven't yet been able to figure out how to get flash to center a shape inside another shape. Not sure if it'd be better to just replace them with plain vanilla text buttons "Play"/"Pause", "Next Event", "Prev Event".
Edited by tracktwo
Link to comment
Share on other sites

Feels great to finally witness such cool results.

 

Adding some extra assets from here-on-end will be icing on a cake. It's functional at least and will effectively render the journal'izing process as it should.

 

-- Controls look awesome in this greenish (#5CD16C) design. Just as i imagined they would get -- the Icons are perfectly fine and they (three for now) integrate very smoothly in the current setup. Really like that "slider" principle for people to go straight at any points on their timeline. You-Tube has influence everywhere!

 

-- Pretty symbols? Don't worry i got you covered... below are just some preview of the costs assets from the LW-Pedia framework which might be used later on along with other gimmicky artsy stuff filling my folders daily overhere.

 

http://s21.postimg.org/bvu7ljf1v/Items_Cost_E_T_144x32.png ... http://s22.postimg.org/hpyq369hd/Items_Cost_EAFM_320x32.png! :wink:

 

Engineers, Time................Elerium.........Alloys..........Fragments....Meld. I simply fill in the values above these tilted shapes.

 

Costs & Requirements will remain verbose as i feel they supply the proper hint for that special location.

 

I'm fairly sure you still have some of the sample PNG items (MTc, Mx, Tags, etc) i eMailed earlier. It's very easy to insert img (preferably SVG for scaling potential) stuff anywhere within any of the strings flow via Flash encoding.

 

-- Daily quantity is one concern... but quality will take over this feature in no time. Auto-scroll to the rescue -- maybe.

 

-- Bof, the Icons represent candy to the UI freaks like me. Visual appeal is fun... functionality better.

 

Fantastic progress.

 

You are GO for the rest!! 1-2-3-4-5... The Thunderbirds are GO!!! :D

Edited by Zyxpsilon
Link to comment
Share on other sites

Here's the current working status of the timeline:

[snip]

Looks like it's coming along nicely, good job :thumbsup:

 

I think the layout could use some more work. Some notes:

 

The "head" on the gutter doesn't move yet and can't yet be dragged, and the play button doesn't "play", stepping continuously through events. But the forward and backward buttons step through events.

I'd suggest hooking up your timeline control to the existing XComSlider widget AS class, that should have all the interactivity features you're looking for out-of-the box. Or just place one of the default slider widgets, though that probably clashes with your intended green color scheme, so you'll want a re-skinned widget :smile:

 

Events are shown with almost no processing. I did split out the date/time, but otherwise it's "raw" data from the journal. This looks crappy for certain events, especially mission results. They need more pretty-printing.

What I think would be pretty nifty would be if the journal entries would be folded into the event list component you see in various base menus (main view, mission control, engineering, etc.). So in a sense playing back the timeline would also re-display the list of events that you were seeing at the corresponding points in time.

 

Event list items allow you to categorize items (denoted via event icon) and are accompanied by a 'time left' display and a short text description. I imagine it would be nice if the event list could be filtered to only show items of specific categories, e.g. for tracking research progress or missions undertaken, etc.

 

Text box doesn't scroll yet, so text is cut off at the bottom if the grouping of events is longer than it can show at once.

Again, extending a stock XCOM widget class could help you out here. Depending on what you have in mind when talking about 'scrolling' there's a few options. For instance, you could employ an auto-scrolling text component as it is used for research reports (XComVerticalScrollingTextField, I think, not sure about the name off the top of my head).

 

If you're thinking about manually scrolling, an XComList would probably be best, i.e. wrapping your journal entries in list items and populating a vertical list with it. This is basically what the aforementioned event list does, so personally I would favor that solution over a plain text dump :smile:

 

My icons are aligned badly, but haven't yet been able to figure out how to get flash to center a shape inside another shape.

What do you mean by 'get flash to...'? Are you talking about Adobe Flash as in the authoring software? In that case there should be the usual alignment options if you have one or more elements selected in the stage [further reading]. I think centering is based on the pivot of your movie clip objects, so you should make sure to neatly align your sub-clips to make things easier.

 

If you're talking about aligning stuff with ActionScript, there's no convenient shortcut for it, but playing around with the _x, _y, _width and _height MovieClip properties is pretty straightforward. It's usually a matter of something along the lines of

this._x = (this._parent._width - this._width) / 2.0

if the object you want to align is a child of the object you want to align to. If 'aligner' and 'alignee' share a common parent it would be

this._x = that._x + (that._width - this._width) / 2.0

Again, taking good care of your movie clips' pivots is good practice as the _x property refers to the pivot location, not the left edge of the clip itself.

 

 

Not sure if it'd be better to just replace them with plain vanilla text buttons "Play"/"Pause", "Next Event", "Prev Event".

Using text-based buttons would be a viable alternative, however you'd have to take localization into consideration. The icons you're using are pretty universally understood, which is a rather elegant solution in my book :smile:

 

 

Finally, a few random notes about the visuals (just my personal opinion, so to be taken with a grain of salt):

  • I don't think the slanted look suits the track and knob very well
  • the control buttons could use a slightly thicker border and maybe a few of the trademark double-thickness corner segments (might make them look too 'heavyweight' for their small-ish size though)
  • the bottom text view could stand to be much smaller horizontally, there's lots of wasted space currently that could be used for other components (e.g. event list view, filter buttons *nudge nudge* :wink:)
  • the timeline slider component on the other hand could be made much wider and more detailed, e.g. it could feature begin-of-month tick marks (maybe with month labels) or show little marker icons pointing to the track denoting certain events-of-interest, have a crappy mockup:

  • the bottom section could be moved down a bit to overlap a little less with with map portion

 

I'm quite interested to see how this develops, looking pretty promising so far :)

 

Link to comment
Share on other sites

Nice principle of "Ticks" to indicate time-gaps, X.

 

Taking this idea a step further with additional MTc components, if you won't mind...

 

 

 

http://s3.postimg.org/5tbujhkxv/Timeline_Slider_Ticks_sample_X2.png

 

 

 

1) Simply inserted -- Abduction, UFO-Crash, Exalt, Terror, UFO-Land, Council, Foundry project, Alien-Base-Assault.

 

2) Might get much crowded, sooooo... suggesting a way to expand (+) or contract (-) the events time-flow in some Minutes(chunks) / Hours / Days / Weeks / Months... gapping spans.

 

3) Of course, parsing by categories (Hint; just Research & even, with actual Months (what happened in June) or Countries) only would be a must. Thus, you'd probably want to permanently activate my previous side-panels stuff (( Refer to this post http://forums.nexusmods.com/index.php?/topic/3012609-campaign-summaryjournal/?p=27182869 )) ... in such a manner that their indirect selection features would be connected with the timeline component(s).

Edited by Zyxpsilon
Link to comment
Share on other sites

Thanks for the feedback and input, guys! After I posted this last night I did some more testing with a few things, and I think this will impact how to proceed with the UI.

Firstly, some comments on the existing UI. As for the recommendations for using the standard Firaxis widgets to control various things, if I can reference these classes externally without needing to embed them in my .swf then I will see if I can use them. I don't want to have to embed any assets owned by Firaxis in the mod. That may mean I need to write my own (basic) slider and scrolling text field, but that shouldn't be too difficult. As for the current layout, I'm currently borrowing the existing layout from the situation room country info UI. I can see about resizing things, e.g. to narrow the text box to avoid too much wasted horizontal space, but I'm not sure if that will work. To make the slider longer, I'd need to remove the current country info box (the box the slider, buttons, and current date all live in). It's possible to just not reuse any of these assets and design the whole UI from scratch, but this was convenient as a starting point, especially since I'm a flash noob and poor designer, so implementing the actual UI takes me way longer than writing any of the code.

Regarding the tick marks and icons on the slider: I'm not sure if that will work out well in practice. There are literally hundreds if not thousands of discrete journal events in a late-game campaign in LW, there simply isn't enough space on the slider to show all of them. I also want to clearly separate the "summary" view that's been discussed before from the "timeline" view. I don't want to get into event filters and such in this view: it's purpose in my mind is to very simply be a version of the Civ game replay. The filtering/icons/etc. stuff IMHO belongs more in the graphs and summary views rather than the timeline. Adding some additional UI elements to capture the current "state" of the campaign at current point - e.g. putting back the country boxes w/ current panic levels, show countries with sats over them, etc might be useful, though, and would help flesh out the timeline to not be so sterile, I think. It also fits well with the model of the civ replay, where the primary UI element is the map showing where cities and borders are. The current state of the world is the reasonable analog to that in XCOM, I think.

However, this poses a bit of a problem. Not one that's unique to the timeline, it'll need to be solved for the summary and graph views too. The problem is in data analysis. Frankly, the journal is huge, and the unrealscript string processing functions are extremely limited. At the time when I posted the previous screenshot the entries shown in the textbox were generated on demand - as "time" moves forward by clicking the next button the mod goes off and scans the next chunk of journal events that all occur on the same day and groups them all up, then displays the date and the collected strings on screen. That's very fast and sufficient to show a basic timeline playback and can even support seeking fairly easily, but that isn't enough to show any collected info on the screen. For example, if I drag the slider over to a point that would represent "Jan 1 2017", how do I populate the country panic blocks? These are recorded as individual events in the journal like "Panic in china increased from 25 to 27". Panic isn't actually too bad - I'd just need to search backward through the journal until I see the last panic entry for each country, and that's enough. But determining something like total resource amounts requires scanning the *entire* journal and adding up all the values, as no journal event says "alloys increased from 157 to 160", just "alloys increased by 3".

 

As an experiment I changed the code to process the entire journal up-front into individual day chunks. Clicking on the campaign summary button then caused a 5-6 second delay while it read and processed the entire journal for a campaign that was only 9 months in. My computer is certainly no ultimate gaming rig, but it's not that old, and many people play on significantly less powerful computers. Having a 30 second delay when you click on the button while it aggregates all the journal data isn't ideal. Currently the game just appears to hang, I can probably work out a way to at least pop up a loading screen with a progress bar, but that still sucks.

In the real game, this kind of heavy processing would be done by native code, which is orders of magnitude faster. Unreal does have a dllbind mechanism that would work here, but it's only enabled by default for the non-licensed version of the UDK. Full licensees get a different native code mechanism, and that's what EW uses. The dllbind mechanism can be enabled even in fully licensed versions, but it looks like Firaxis didn't (why would they? Epic recommends against its use for full licensees). I built a custom test DLL and a UScript class using dllbind but it doesn't work in-game, unfortunately. If anyone out there from Firaxis lurks these forums, a native interface in XCOM2 would be hugely useful for anyone trying to write complex mods. UScript is just too slow and limited to do a lot of heavy processing without introducing pretty significant delays.

So where to go from here? Not sure yet. I can definitely get a moderately useful timeline going but anything requiring complex data analysis is going to be very slow to generate. One thing that could be done would be to add new journal entries that summarize the state of the game at regular intervals. This would put a much tighter bound on the amount of data I need to scan to generate useful data for any of the views, but wouldn't work with existing campaigns because the data aren't there. Firaxis included something like this already: every month it dumps a roster summary. I'd need to do something similar that dumps resource amounts, sat coverage, panic levels, etc on a monthly basis. The graphs and summary views are going to be hardest hit by this perf issue, especially the graphs, as it requires aggregation across the entire campaign to be useful.

Edited by tracktwo
Link to comment
Share on other sites

Firstly, some comments on the existing UI. As for the recommendations for using the standard Firaxis widgets to control various things, if I can reference these classes externally without needing to embed them in my .swf then I will see if I can use them. I don't want to have to embed any assets owned by Firaxis in the mod.

From my experience it's possible to reference external ActionScript classes, you don't even need to explicitly import them like you do for sprite assets. Most of the game's Flash movies contain copies of commonly used classes, but those are just dummies; the actual classes reside in the gfxInterfaceMgr SWF movie. As menus are nested inside one another I suppose ActionScript classes are handed down along the hierarchy, too, i.e. sub-movies prefer to use classes from their ancestor movies instead of their local copies.

 

I have sucessfully registered sprites as instances of AS classes that weren't embedded in the Flash movie I edited, so it's definitely possible. Adobe Flash won't allow exporting such a setup though, so at the very least you'll need stubs of the game's AS classes you're trying to reference.

 

 

As for your data mining woes, I don't really know what the journal entries you're parsing look like, are they really plaintext items you're trying to parse? If that's the case, wouldn't it maybe make sense to hack into the code that prints those entries and alter them to be more compact and easier to parse? You could even go as far as encoding them in a binary format and printing them as Base64 strings. Or at the very least you could add missing information like the '[resource] increased from [old value] to [new value]' example you gave.

 

If the journal is as large as you say, loading all of it into memory is probably a bad idea to begin with. In such a situation you'd typically want some form of parallelized streaming solution combined with an indexing system, but I kind of have my doubts that you can perform low-level tasks like this via UnrealScript, script languages typically aren't designed around that kind of functionality.

 

Basically, a plaintext log is a very inefficient form of data storage, which puts considerable strain on re-parsing that into a data model. So my suggestion would be to condense the journal into something more usable - maybe some small additions could already help lessening the burden of data processing. For example, maybe it would be possible to insert a summary line of sorts at regular intervals (monthly, weekly, etc.) that would contain aggregated values. So to determine the value of a resource at any given point in time you wouldn't need to parse all those '[resource] has been incremented by [amount]' entries from the beginning, just from the last summary entry.

Link to comment
Share on other sites

Yep, that's exactly what I was thinking about the summary entries. As I said in my last post they're definitely possible to add, but the only drawback is they won't start being recorded until you install the mod, so any older campaigns won't have them. The journal is just plain text and is already loaded by the game at all times, so there is no additional memory overhead to having this mod. It's got a lot of entries and the string processing is slow, but in terms of raw data it's not taking up huge amounts of memory - you can fit a lot of strings in a megabyte.

 

Now, one possibility that I just thought of is to just do the "full parse" once. I can alter the journal to put a marker entry as the first entry. This would be added by default in any new campaign, and if it's present the mod will know the periodic summaries will be available. If it's not there, we can go off and take the 30s hit to index the journal and then build the summaries and inject the new entries into the journal, and then it never needs to occur again. The special first entry could even be a table of contents that contains the indices to find each of the summaries, to make processing and seeking even faster. It'll need a loading screen, though, as the way it is right now it actually hangs the game and even the music stops while processing, and that sucks.

 

Even better: don't use the journal at all for data visualization. It'd be used only to build the data structures used by the mod, which can be optimized to give the info we need for all the various views (especially graphs) and saved directly in the save file so they don't need to be regenerated every time. The mod can record the last journal entry it saw in the checkpoint data, and process any new entries that have been recorded since the last time the view was entered. This will be much faster than doing it all each time. It also lets me record the information in a way more natural and easy to use way than a huge array of free-format strings. I can have a big array of "day" data entries, where each one records the events that occurred and the current state of the world. That'd be a lot of duplicated info (panic levels don't change for all countries every day), but RAM is cheap :) A 2 year campaign would only have 730 entries anyway.

 

Glad to hear about the ActionScript class referencing... I can definitely just add stubs to the flash file to keep Flash happy, that's standard operating procedure for the custom uscript classes too.

 

I've also successfully narrowed the textbox to take up only half the screen width. It looks a little goofy because the right side is currently completely empty, and the country info box containing the buttons, slider, and date is still centered on the map (note: it's not actually centered, I noticed this when I correctly centered the slider and it ended up being in the center of the screen but not the center of the country box). I can also slide that box over, maybe. Or just get rid of it and put the buttons, date, and slider somewhere else.

Link to comment
Share on other sites

  • Recently Browsing   0 members

    • No registered users viewing this page.

×
×
  • Create New...