full PLE mod for BUG

ruff_hi · Jan 14, 2009

EmperorFool said:
Silly question: have you tried them both and can tell us the difference?

Of course not. How about I use one for odd units and the other for even units and post a screenie - a cookie to the first person who guesses which was used for odd and which for even.

ruff_hi · Jan 16, 2009

more ruff / EF chat ...

Spoiler chat :

ruff_hi · Feb 1, 2009

I've finished my update on the unit plot. The user can now select between original BtS unit plot style or the (ugly) PLE style

. They also have options on ...

promo frame
GG indicator
injured indicator
mission indicator
upgrade indicator.

The pic below has PLE style as the insert and vanilla BtS below that (all 5 options above ON).

I couldn't massage the option screen but this is what I think it should look like ...

(more than happy for someone else to put together something nicer)

ruff_hi · Jun 12, 2009

EmperorFool said:
Hehe, I'll just say it won't be trivial and will be complicated by the . . . intriguing . . . coding of PLE. The basic idea was to create a data structure to contain the visual style of each unit. The code already builds a data structure of some data to allow it to sort the units. This would be similar.

Then you compare the structures you are about to draw to those that you previously drew and update the graphical elements with only the differences. I highly recommend creating a simple class in a new PLE module (Contrib/PlotList.py? or add it to BUG/UnitUtil.py?) to hold the data instead of packing it into a list.

Code:

class PlotList: def __init__(self, pUnit): self.bSelected = ... self.eUnit = pUnit.getUnitType() self.iDamage = pUnit.getDamage() self.iMovesLeft = pUnit.movesLeft() self.iMoves = pUnit.getMoves() self.bPromo = ... self.bGG = ... self.bUpgrade = ... self.iMission = ...

You can pull all the code to assign values to those fields from PLE itself. The only tricky one is the mission tag. I don't remember if I have created the set of constants for them (orders and missions) yet or not. See BUG/OrderUtil.

Then the draw code will just compare the previous to current PlotList object field-by-field and only change the visual elements where the values are different. For example,

Code:

if prev.bSelected != new.bSelected: screen.setState(szUnitIcon, new.bSelected)

You will need to handle the cases where a cell in the grid didn't have a unit and does now and vice versa. You could make this easier by creating functions to draw each individual element.

Code:

if prev is None: if new is not None: # draw all visual elements using new screen.setImageButton(szUnitIcon, getUnitIcon(new.eUnitType)) ... else: # no unit in both views, nothing to do pass elif new is None: # hide all visual elements screen.hide(szUnitIcon) ... else: # test each field in prev to new, drawing the differences if prev.bSelected != new.bSelected: screen.setState(szUnitIcon, new.bSelected) ...

Don't forget to remove the code that hides everything before drawing as the point is to only hide/show when necessary.

Hmm, now that I think about it, perhaps an easier pattern is this:

Code:

if new is None: if prev is not None: # hide all elements else: # change all different elements if prev is None or prev.bSelected != new.bSelected: screen.setState(szUnitIcon, new.bSelected) ... if prev is None: # show elements screen.show(szUnitIcon)

Note that some elements are strictly handled by showing/hiding them (upgade and promo indicators), and some may be hidden sometimes (mission tag).

Oh, you also need to deal with the case of options changing. I recommend creating a reset() function that redraws the entire plot list ignoring the previous entries. You can call this function in an onChange handler for most of the PLE options.

Edit: Honestly, this is the type of comprehensive feature that would convince me to rewrite the whole plot list code to integrate PLE with the old style as far as drawing goes. I would keep both types of behavior and visual style, but merge the code that handles the redrawing so that both types are sped up by this change.

You would need a few major function breakdowns:

Sorting units. PLE: filters and sorting. Standard: just sorting

Placing units into cells. For PLE, apply view mode. Standard, only mode is multiline. This step creates the PlotList objects above.

Draw. This code can be mostly uniform since the Standard vs. PLE style differences are applied when placing the original controls (health bar below).

I would also move all this code to a new module. That would be totally freaking awesome.
[*]

sigh - what have I gotten myself in to.

I've already combined the actual showing component ...

Code:

		if bEnable:
			self.displayUnitPlotList_Dot( screen, pLoopUnit, szString, iCount, x, y )
			self.displayUnitPlotList_Promo( screen, pLoopUnit, szString )
			self.displayUnitPlotList_Upgrade( screen, pLoopUnit, szString, iCount, x, y )
			self.displayUnitPlotList_HealthBar( screen, pLoopUnit, szString )
			self.displayUnitPlotList_MoveBar( screen, pLoopUnit, szString )
			self.displayUnitPlotList_Mission( screen, pLoopUnit, szString, iCount, x, y, 16 )

... so that the actual show is independent of PLE of non-PLE. I was thinking of just keeping a running list of what is shown for each plot keyed by one of the inputs (szString?) and then just showing or not if required. A class is obviously cleaner.

EmperorFool · Jun 12, 2009

I was thinking a little more about this while shopping, but all my ideas are around abstracting the process to make the code cleaner and easier to write, but definitely more complicated to understand if you're not used to the patterns.

Essentially, I'd create an object for each type of graphic. These objects (classes) would have the code that hides, shows, and draws their element given a PlotList object as above while taking into account the option settings. For example, PlotListDot, PlotListMissionTag, PlotListUpgradeIndicator, etc.

This is basically what you're doing, only you're using functions instead of classes. What's the difference? By abstracting the functions into classes, you can treat them as a single set. Your code above would become

Code:

for each cell:
  prev = ...
  next  = ...
  for each component:
    component.update(prev, next, iCount, x, y)

Adding a new component would not require this code to change. You'd only have to add it to the initialization part. Not that we're adding new components any time soon. :mischief:

ruff_hi · Jun 17, 2009

leaving aside the component part ... I understand your plotlist class (quoted by me in post 104 - but I am calling it UnitPlot class from now on in). Now, this is only a data construct of what is in the plot. It doesn't control the location of the plot, spacing, how many per row, etc. PLE and non-PLE (and BtS raw / vanilla) all approach this in slightly different ways.

IIRC, BtS vanilla slaps down a panel (invisible) fro each row and stacks these panels up for the number of rows it deems is 'good' The 'y' is the panel and the 'x' is the count across the panel. PLE just has one giant panel and works out the (x,y) as required.

Is there any problem with including an (x,y) with the UnitPlot class so that it holds the location too.

Code:

class UnitPlot:
	def __init__(self, x, y):

Then I can do the following ...

PlotList.Push(pUnit)
PlotList.Update()

The 'Push' will push a unit into that plot and push the existing unit there to an internal class variable (previous) while the Update will update the visual elements as per your outline above.

I will need a way to initialize / update the display options (PLE v non-PLE) but that should be ok.

So, is this valid or am I mixing a data class with a display class?

EmperorFool · Jun 18, 2009

[Note: A method is a function defined on a class. It doesn't differ in any other way.]

It's perfectly valid to mix behavior and data--that is the whole point of Object-Oriented Programming. Your Shape class has a draw() method and holds the data that tells the method how to draw. Then you create subclasses of Shape like Rectangle and Circle with new draw() methods and data. Shape probably has an origin (x, y) data point while Rectangle as width and height and Circle has radius.

Here, of course, we won't need subclasses and only one draw() method so it will be easier. I agree that the UnitPlot class should have its x and y coordinate (in the plot matrix--not screen coordinate) and index (called iCount in PLE I think) if necessary.

However, I would not assign previous and current CyUnit objects to it. Instead, each UnitPlot should contain all the summary info needed to draw a single unit, and you'd create a previous and current UnitPlot instead. Otherwise you'll have to copy every field from current -> previous instead of a single field. I laid out the UnitPlot class above pretty much exactly as I would do it.

As for whether or not UnitPlot should do the drawing, I don't think it will matter much. The key is that you need two UnitPlots to do the drawing: the previous one and the current one for comparison. So either you have

CvMainInterface.draw(prevUnitPlot, currUnitPlot)

or

UnitPlot.draw(prevUnitPlot)

where you call the draw() method on the current UnitPlot and pass the previous one for comparison. I personally would go the first route and put the draw() method into a new class called PlotList which has two subclasses: BugPlotList and PlePlotList. These classes would do all the drawing and lay out coordinates for the different objects. You could have a getOrigin(UnitPlot) method that the draw() method could use. Each subclass would define getOrigin() as-needed but not need to have their own specific draw() methods.

PlotList would track the currently displayed UnitPlot objects in an array, one per cell in the plot list matrix (the spots for visible unit icons). Where there was no unit displayed, it would store the value None. So the array would always have N values in it where N is the width times the height of the matrix. Then PlotList would loop over the matrix, calling draw() for each pair of previous/current UnitPlots.

Feel free to send/post code along the way if you want more explanation. This design is pretty tricky, and I don't feel I'm being very clear. Often writing code is the best way to be clear, but I get the sense you want to tackle this yourself.

ruff_hi · Jun 21, 2009

I think I prefer the UnitPlot.Draw() method - mainly so that we can start to strip down the size of the maininterface file. I'll try and ghost some code together just to see if I am heading in the right direction.

However, I would not assign previous and current CyUnit objects to it. Instead, each UnitPlot should contain all the summary info needed to draw a single unit, and you'd create a previous and current UnitPlot instead. Otherwise you'll have to copy every field from current -> previous instead of a single field. I laid out the UnitPlot class above pretty much exactly as I would do it.

I must admit that I am still tempted to have the curr / prev units associated with a plot both contained within the UnitPlot class - at the end of the day, we will need that information. I understand the 'single move / multiple move' think, but let me hack something up so that I can describe what I am talking about - I think we are just saying the same thing in a slightly different way.

Balderstrom · Jun 21, 2009

Aren't you both in essence just talking about a linked list? Wherein Ruff wants each UnitPlot class to link prev/next ?

And isn't what EF is talking about - is that if you store the prev/next in the UnitPlot - it is only relevant if you don't change any of the filter options - as soon as you do will have to update all the prev/next pointers.

Or... I'm completely misreading

ruff_hi · Jun 21, 2009

Unit Plot List

Background

BUG has enhanced the unit plot list (the section of screen real estate that contains the little unit icons) with additional information. This makes it easier to find units that can be upgraded, that have movement points left, that are injured or have an attached Great General (and others that I will not mention here). As such, the BUG Unit Plot List is pretty cluttered with new icons and other indicators.

The downside of this is that the current system updates all of the unit plots every time it gets 'dirty'. Thus, there is a large number of that get hidden and then reshown each time you change the selected unit in the plot list. With a small number of units, you will not notice this slow down. However, with a large number of units, the drag is noticeable.

Enhancement

BUG is being enhanced so that only the 'new' icons will be refreshed. Other icons that don't change from one refresh to the next will not be re-drawn. It is expected that this will overcome the lag when dealing with large number of units.

The approach being discussed is to compare the previous unit's feature (ie blue promo frame) to the unit currently occupying that unit plot list. If the status is the same (ie both on or off), then no screen changes will be required. If the status is different, then the promo frame will either need to be hidden (previous was on, current is off) or shown (previous was off, current is on).

The following discussion concentrates on the vanilla unit plot list. It is expected that the PLE changes will only involve the actual placement of some of the icons and not the required mechanics.

Classes

A UnitPlots class will be created to contain some generic information such as:

number of rows
number of columns
conversion formula to go from row / column to index
conversion formula to go from index to row / column
.Update() - updates the unit plots
.Reset() - deletes the previous units stored
etc

A UnitPlot class will be created that will contain information such as:

the currently displayed unit
contain functions that display / hide the various components of the unit plot
Previous unit displayed on this unit plot (held as a UnitDisplay variable)
.Update(vUnit) method that accepts the unit to display. It also moves that unit to an internal variable at the end of the display code (previous unit)
.Reset() - deletes previous unit

A UnitDisplay class will be created that controls the various components that are displayed on the unit plot. It will contain:

Promo Frame boolean
Mission Tag
GG Indicator
Movement points
etc

Unit Plot List Panel

A single panel will be created to hold all of the unit plot lists. The dimensions of this panel will be controlled by game generated constants that change with screen resolution. The panel will be 'x' columns wide and 'y' rows high. The location of the panel will be unchanged from vanilla BtS. Each unit plot list can be referenced by its (x,y) co-ordinates as well as an index.

Code

You want to update, refresh or clean the unit plot list ...

- UnitPlots.Update()

This update function loops over the units on the current plot, calling UnitPlot.Update(pUnit) for each of them. The UnitPlot.Update() function will do the following:

Code:

UnitPlot.Update(vUnit)

CurrUnit as UnitDisplay(vUnit)

if CurrUnit.Promo != PrevUnit.Promo: refresh Promo
if CurrUnit.Mission != PrevUnit.Mission: refresh Mission
etc

We should also put some code in here to control the display order (promo at the back, selected frame at the front, etc).

PrevUnit = CurrUnit

Return 0

EmperorFool · Jun 21, 2009

I gotta go cook dinner, but a couple points real quick.

I would rename UnitPlots to PlotList to make it easier to distinguish from UnitPlot. So a PlotList will contain multiple UnitPlot objects.

Function names should begin with a lowercase letter. Classes should begin with an upper case letter (as you have done). Variables should also use lowercase letters. So PlotList.update(), etc.

I'll take a more in-depth look tonight, but I like the thinking so far. :goodjob:

ruff_hi · Jun 21, 2009

when you start sketching stuff like this out - do you start at the top and work down, or start at the bottom and work up ... or a bit of both?

EmperorFool · Jun 21, 2009

I usually sketch out the overall flow in comments at the top, getting a feel for what pieces I will need. Once I get that clear--or at least have a direction I think may not be totally wrong--I will start building small pieces from the bottom up that I can test individually.

It's harder when you're replacing an entire set of working functionality. There's no way to just do one piece in isolation. I would definitely do the unit icon by itself first, get that working, then add a second. Once you have two things that work similarly you can generalize to some base class behavior to extend it to the other items.

Don't forget that you can use the Python console in BTS by hitting shift - backtick (~). Once there you can write what you'd normally put into a module. Import the module you need stuff from and then create your objects.

Code:

import PlotList as pl
u = gc.getPlayer(0).getUnit(0)
up = pl.UnitPlot(u)
print up.unitType
print up.movesLeft

The above is based on how I had envisioned the UP class working, so adjust for your needs.

EmperorFool · Jun 22, 2009

This is looking good. A few more quick things:

No need to return 0 if you don't actually need a result from a function. Just let it drop off the end or use "return" by itself if you need to return early.
I'm lazy, so I'd probably name the UnitDisplay class Unit because it just holds data about a single unit.
I would still recommend creating a function that builds a list of UnitDisplay objects from the plot. This list would be fed into the top-level PlotList class's update() function. This would allow PLE vs. Standard modes to create their list using their own algorithm. The drawing code would not need to be aware of this aspect.

Gorey · Jun 24, 2009

not sure if this is the right place for this (nor have i really read through this thread).. but i always noticed that as my stacks grew.. there was alot of lag when selecting units in a stack.

so i decided to turn off all the PLE features during my last game to see if it would get rid of the lag. but after i disabled it, there were alot of units that were "stuck" on the interface, even when i didn't have a city or stack selected.

only way to describe them is that they were sorta like ghost icons of units that did nothing. i tried restarting the game and reloading my save and they were still present. they stayed with me until the end of the game.

i'm guesing that these "ghosts" were in a stack i had selected when i initially turned off PLE, and now they're forever stuck on screen.

sucks because i really like the PLE features, but by mid-game it gets really frustrating trying to select one riflemen out of a stack and having to wait a half second. my PC is pretty beefy (custom built), so i dont think thats the problem.

EmperorFool · Jun 24, 2009

Gorey said:
not sure if this is the right place for this (nor have i really read through this thread).. but i always noticed that as my stacks grew.. there was alot of lag when selecting units in a stack.

Yes, that is precisely what Ruff and I are discussing now: how to address the lag. We have a solution, but it's a lot of work. I did testing and the slowdown is the way all those graphics are drawn: they are hidden and redrawn each time.

Gorey said:
so i decided to turn off all the PLE features during my last game to see if it would get rid of the lag. but after i disabled it, there were alot of units that were "stuck" on the interface, even when i didn't have a city or stack selected.

What exactly was stuck? The unit icons? The mission tags? The upgrade indicators (orange up arrow)? Everything? I would think our idea would end up fixing this too . . .

Gorey said:
i tried restarting the game and reloading my save and they were still present. they stayed with me until the end of the game.

. . . except that this makes it sound like it's a different problem. Were you using any filters? These are the buttons below all the units that allow you to hide units that don't apply, e.g. "show only injured units", etc.

Gorey said:
My PC is pretty beefy (custom built), so i dont think thats the problem.

Mine too, and my game lags when the stacks get large as well. Hopefully we'll be able to get this done soon and make PLE a lot less painful to use in the late game.

Gorey · Jun 24, 2009

the "stuck" icons were pretty much just like normal unit icons.. but they weren't tied to a unit, and are always on screen. when you select a stack they get mixed into that stack, and when no stack is selected they are still on screen. selecting them puts a yellow border around them, but they dont do anything beyond that.

dont think i had any filters on at the time.

try it. turn off PLE mid-game and you'll start seeing some units always on the interface.

EmperorFool · Jun 25, 2009

The only way I can see this happening is if you had units filtered. I'll do some testing, but if you could post one of those saves in the meantime, that would be very helpful.

I suspect you could fix the issue by doing the following:

Turn on the PLE style (first checkbox on Plot List tab).
Close the options screen
Click the Clear Filters button (red circle with a line through it)
Turn off the PLE style

Please let me know if that works. If it does, I can devise a fix that will do this automatically so that others don't get bitten by it.

Gorey · Jun 25, 2009

nope, doesn't work.

i decided to test this out for you.

started a new map:

1. moved my first warrior and settled my 1st city.

2. turned off PLE in the options screen.

3. started noticing that even when i had my city selected, my roaming warrior icon was still present on the screen. selecting that "ghost" icon and trying to move my roaming warrior with it via the mouse did nothing. although the unit icon looks as though its selected when i click on it... no movement cues are displayed when i drag around with the right mouse button. the icon is officially tied to nothing.

4. trained another warrior and fortified him in the city. now when i selet my city i get 2 warrior icons instead of 1. 1 is the warrior in my city, and the other is the "ghost" icon that does nothing. selecting my roaming warrior shows just 1 icon. when neither my city bar or the roaming warrior have the focus (such as the end of the turn etc.) it still shows that ghost icon.

5. go back into the options and turn PLE back on.. and nothing has changed. i still get the ghost icon.

6. hit clear filters, nothing changed.

7. turn PLE back off.. and nothing changed.

this gets worse the more units you have when you turn PLE off. though the logic behind which ones get stuck im not sure yet. i initially thought it was whichever units were selected when you turn it off, but in my last test i didn't have anything selected.

one game i had 4 workers, an axemen, an archer and a great prophet stuck on the screen. it was difficult to tell which units were actually real.

Gorey · Jun 25, 2009

my conclusion is that when you turn off PLE some icons get stuck.. and they are only funcitonal when the actual unit it belongs to has focus. when that unit doesn't have focus it does nothing, but still gets displayed.

full PLE mod for BUG

Live 4ever! Or die trying

Live 4ever! Or die trying

Live 4ever! Or die trying

Live 4ever! Or die trying

Deity

Live 4ever! Or die trying

Deity

Live 4ever! Or die trying

Emperor

Live 4ever! Or die trying

Deity

Live 4ever! Or die trying

Deity

Deity

Prince

Deity

Prince

Deity

Prince

Prince

Similar threads