This mod adds the full functionality of 12monkeys' original
Plot List Button Enhancement (PLE) mod to Version 2.22 of BUG (BTS Unaltered Gameplay).

To install the mod simply unzip and copy the contents to your
~\My Documents\My Games\Beyond the Sword directory. (Assuming you have the
standard CIV/BTS installation.)

This mod is intended to be installed on top of BUG 2.22.


BUG 2.22 MUST be installed first!


This mod DOES NOT WORK with the current version of BAT.

This mod is for use with BTS 3.13.

This mod does not change gameplay in any way.

WARNING: The mod changes the CIV4ArtDefines_Unit.xml file. If you have any
additional custom unit graphics it will be necessary to edit this file.

( For anyone unfamiliar with BUG and PLE, these mods are intended to
improve the CIV4 interface without changing the game itself.
The creators of BUG choose to include some (but not all) of the features of
PLE. This mod simply adds the rest of the features of PLE to BUG for the
benefit of those who have grown accustomed to PLE. )


Credits:
The PLEmod was originally created by 12monkeys

BUG has many contributers including -
Alerum68
Cammagno
EmperorFool
NikNaks93
ruff_hi

This version of the PLEmod for use with BUG was adapted by daengle from
a version of the PLEmod adapted for BTS by turlute.

Post of this mod in civfanatics archive -

http://forums.civfanatics.com/downloads.php?do=file&id=9342

Nice.;) EF and Ruff are going to be hard pressed talking me out of adding this into BUG completely.

@daengle - Sweet! Our mod is even having mods. :)

@Alerum - I was never against adding all of PLE into BUG. I was only against me doing the work. :p I would love it if you could merge it in to the latest BUG and add options for some of the features. Actually, I should check first to see if daengle did that already.

@daengle - Did you? If not, would you like to do that (we can help show you how) and have it included into BUG?

All I did was splice together the CivMainInterface.py files from turlute's PLE and BUG 2.22. It doesn't talk to the BUG options screen or .ini files.

Sorry, my skill with python is quite limited. I was amazed when it actually worked.

Speaking of working correctly (or not), I am having a problem with the automatic unit name generator feature.
It doesn't seem to work correctly with my version of CivMainInterface.py

I can't tell why but I think it may be due turlute's PLE handling the mouse overs differently than BUG, but I am not sure. I am looking into it.

Commited this to the SVN, with our latest changes. There are a few things we need to fix in it. More of conforming to BUG format then anything else.

Commited this to the SVN, with our latest changes. There are a few things we need to fix in it. More of conforming to BUG format then anything else.

I'm an appassionate fan of PLE, but I don't know if adding it like this is a good idea... it' seems somehow an external body in BUG code... :confused:

That's how all the Mods we've added have started out Cam.;) We just have to make a few small changes to the way the code handles 12Monkey's tools. The INIParser he uses is basically the same as our, just a generic version.

That's how all the Mods we've added have started out Cam.;) We just have to make a few small changes to the way the code handles 12Monkey's tools. The INIParser he uses is basically the same as our, just a generic version.

Ok, I'll be more than happy if we'll end up with full PLE inside BUG.
We also need some documentation about the use of those icons :)

There is a full readme contained in the Zip that daengle included. I'm going to roll that into the help, and drop the IUI help file. We'll also need to include Daengle in the credits.

I am having a problem with the automatic unit name generator feature.

Can you describe how it's not working? Interface issues? Broken functionality?

Also, I want to list you in the BUG credits. Do you want "Daengle" or "daengle" or some other name? You can PM me or answer here.

There is a full readme contained in the Zip that daengle included. I'm going to roll that into the help, and drop the IUI help file. We'll also need to include Daengle in the credits.

Just looked at it... I didn't remembered that PLE was full of so many good features... amazing. I really hope that it will be fully included in BUG with options and so (and that the filters can be made inclusive instead of exclusive... ever hated that).

When I added this to BUG v2.22, I get two python exceptions every time I mouse over any of the small PLE icons that this adds to the main screen. See the image below for the messages.

I don't think I did anything wrong but you never know. Can someone else confirm this bug?

http://img186.imageshack.us/img186/120/plebugerrorsfr0.th.jpg (http://img186.imageshack.us/my.php?image=plebugerrorsfr0.jpg)

Also, when you enter WorldBuilder, the new PLE icons remain on the screen. This has always been a problem with PLE however dating back to its earlier days.

Alerum has integrated it into the latest (SVN) version of BUG. He's now adding all the options to a PLE tab in the options screen and will be looking at any issues that pop up.

I started up a game with the current version, and it seems to work fine, hovers and all. I didn't test worldbuilder but assume it still has that problem.

Alerum has integrated it into the latest (SVN) version of BUG. He's now adding all the options to a PLE tab in the options screen and will be looking at any issues that pop up.

I started up a game with the current version, and it seems to work fine, hovers and all. I didn't test worldbuilder but assume it still has that problem.Thanks, must have been me. :crazyeye:

Options are commited, but haven't made the Tab yet.

Options are commited, but haven't made the Tab yet.

Everything works perfectly, :goodjob: to both of you, guys. When we'll have the option tab added, it will be a real part of BUG... I'm very happy about it :D
And together with the new MA, managing units will be a pleasure... :cool:

Yeah. I'm actually planning out the layout for the Tab as we speak. EF is going to do a bit to remove the last of the INIParser traces, (I hope), and then we should be 100% BUG ready.;)

BTW - Hold off on translating the Options help file for a bit.

Can you describe how it's not working? Interface issues? Broken functionality?

Also, I want to list you in the BUG credits. Do you want "Daengle" or "daengle" or some other name? You can PM me or answer here.

daengle is fine. Thank you.

My problem with the automatic unit numbering is simply that all my units have the standard names (Archer, Warrior, Catapult, etc.) Checking the box to turn on automatic unit numbering doesn't seem to do anything. I'm not sure why. It may have nothing to do with the PLE mod. But I'm not doing anything else so it must...

Amra's error is completely new to me, I have not see anything like it.

I'm looking into this now, but the game starts up and behaves very slowly now. I don't know if it's PLE itself or the changes we've made in the past day or so (switching to the BUG options core). Just be warned that if you update, it'll be sloooooow until I get this fixed.

Edit: Okay, it's not PLE. I did something last night when converting to BUG options core. I'll update soon again.

Crisis averted. Apparently Python has a severe aversion to dividing an integer by a boolean. ;)

Apparently Python has a severe aversion to dividing an integer by a boolean. ;)Are you kidding me? :crazyeye:

I'm not really sure. That was the one logic error I made when plugging in the options (wrong boolean option for an integer calculation). The other possibilities were accessing the options inside a tight loop. I doubt this could be it because it was looping over only a few units, and it was a huge slowdown.

The game hung for 20 seconds while loading, and clicking any stack (1-5 units) I could detect a 1-2 second pause. That seems too large for such a small loop, so I'm betting on the int / boolean. The odd thing is that the boolean was True, so it wasn't even a divide by zero exception. I'm just glad it's fixed, as I really didn't want to back out all that work!

Crisis averted. Apparently Python has a severe aversion to dividing an integer by a boolean. ;)

Silly language.

Obviously,

n/true -> true (for n <> 0)
0/true -> false, and
n/false -> false.

Nothing else makes any sense at all.

I just upgraded to the new BUG mod version and I LOVE it so thanks a lot for making it!

But I could not figure out how to disable/turn off the little unit filter buttons at the bottom of the interface. (part of the PLE mod?) I tried clicking on/off each of the available options in the BUG options menu but the buttons just won't go away! Is there a way to do this from the .ini file?

The way PLE is set up now, it's part of the MainInterface.py file. To make it 100% optional we'll need to do give it is own file that's imported into the interface file. That will take some time. We felt the new features we added were worth not having PLE 100% optional.

Is there any way to comment out some rows in CivMainInterface.py so I can make at least hide the buttons? I have a Python editor and have done some minor edits before.

EF, I have the latest from the SVN and the PLE isn't showing moves a unit can make still.

I did get that to work - a little bit trick, select a unit, hover over it and press and hold the ALT key (or some combination of that).

IIRC, you have to press and hold TAB before you hover. Hovering and then pressing TAB does nothing. Of course, IIRI, well, I'm just wrong. ;)

I had a little time today, so I completed some work on PLE I had started earlier.


Added default view and group modes, applied when starting Civ. Changing the option in-game takes effect next time you start Civ, and changing via the buttons on the main interface doesn't change the setting.
Added Filter Behavior (PLE vs. BUG) option. BUG behavior is more intuitive IMHO.*
Added missing checkbox for GG indicator to options screen.

* Here's how the BUG filter behavior works:


Start seeing all units, no filters selected.
Click the "wounded" filter -> only wounded units are displayed.
Click the "healthy" filter -> "wounded" filter is deselected, and only healthy units are displayed.
Click the "healthy" filter again -> back to normal, no filters selected.

If that sounds confusing, try it out -- it's clearer if you just play with it. Now you click a filter button to see only the units that match the filter, and only one filter in a related group can be selected at a time. It made no sense to be able to filter out both wounded and healthy units, leaving no units displayed.

Now the big question: What more options do we really need? Here are some from past discussions:


Disable PLE entirely
Disable filtering, hide filter buttons (view and group buttons remain)
Hide all buttons, but keep PLE active
Use normal BtS hover info pane instead of PLE's

Sweet.:) The only thing else I can think of are hover tips for the PLE buttons, so you know what each one does.

Is it okay if the hover text says, "Read the BUG help file"? ;)

Is fine for now. Just make it XML, and I'll fix it up when you're done.

I've added an option to show/hide all of the PLE buttons together in the PlotList options tab. This does not disable PLE; it just hides the tiny new buttons in the main interface.

Is it okay if the hover text says, "Read the BUG help file"? ;)

Are you referring to the publisher file in my bugmod folder? It is blank.

Are you referring to the publisher file in my bugmod folder? It is blank.

There is a Windows help file included with BUG. It is called "BUG Mod Help.chm" and can be opened using the "Help" button on the BUG Options screen (ALT + CTRL + O while playing a game). You may not see the ".chm" extension as extensions are hidden by default in WinXP.

If it is opening with MS Publisher, it seems that Publisher has stolen the CHM file type. That's odd since Microsoft makes both Windows (chm) and Publisher. You can change the type so it will open correctly pretty easily, but I don't know if this will interfere with Publisher. This operation can be undone (see below).


Go to Windows (File) Explorer
In the menu, select Tools : Folder Options...
Click the File Types tab
In the Registered file types list, scroll down to "CHM" (you can type "CHM")
Click the Change... button (circled in red in the screenshot)
The Open With window will appear
In the Programs list, select "Microsoft(R) HTML Help Executable"
Click the OK button to close the Open With window
Click the OK button to close the Folder Options window

http://i222.photobucket.com/albums/dd275/EmperorFool/Random/FileTypesScreenshot.pngIf you have trouble with Publisher, you can change it back following the same instructions, except select "Microsoft(R) Publisher" in step 7.

Random fun fact: Microsoft's Windows File Association (http://shell.windows.com/fileassoc/0409/xml/redir.asp?Ext=CHM) website has no idea what their own CHM file type (http://www.fileinfo.net/extension/chm) is. :goodjob:

Did that, clicked help in ctrl-alt-O....game crashed

Did that, clicked help in ctrl-alt-O....game crashed

Hmm, all that does is launch the CHM file a la double-clicking it in Windows Explorer. Here's something simpler than changing the file association to try first.

Right-click the CHM file in Windows Explorer and select Open With.... Is that a submenu? If so, is "Microsoft(R) HTML Help Executable" in the list? If not, select Choose Program.... You'll see the second window in the screenshot in my previous post.

The help file is a standard Windows file type. I'm surprised it's not working for you.

Tried that. It has the table of contents on the left side then in the main window it says unable to open. Suggests checking my internet connection. When I open the help file from the game, it crashes to the desktop.

I think I'll just ignore the features i don't understand and use those I do. It's just some of the PLE that i was wondering about. I figured out the left side that lines up units. It's the little tank/airplane/ship (probably for filtering land/air/naval units)

It's the little tank/airplane/ship (probably for filtering land/air/naval units)

Yes, that's exactly what those are.

Wounded and Healthy
Land, Air, Sea
Non-combat (worker, settler, missionary, exec, scout, explorer, spy) and combat -- house and tank IIRC
Foreign (red) and domestic (green)

In BUG 2.30, clicking a filter hides units that match it. Click again to show the units. The soon-to-be-released BUG 3.0 adds a more intuitive behavior (click wounded to see wounded units only).

BTW, feel free to ask about any features or interface elements you do not understand. Sorry the help file isn't working for you. Are you on Windows XP?

Yes, that's exactly what those are.

Wounded and Healthy
Land, Air, Sea
Non-combat (worker, settler, missionary, exec, scout, explorer, spy) and combat -- house and tank IIRC
Foreign (red) and domestic (green)

In BUG 2.30, clicking a filter hides units that match it. Click again to show the units. The soon-to-be-released BUG 3.0 adds a more intuitive behavior (click wounded to see wounded units only).

BTW, feel free to ask about any features or interface elements you do not understand. Sorry the help file isn't working for you. Are you on Windows XP?

Yup on XP (hangs head in shame at lack of savviness to run linux [or even pronounce it]). And I had it backwards on the little red/green crosses I thought they made those units show up.

Not sure what the star/arrow are or the stacked squares/triangle-square

You can also view the help file on-line, but PLE help isn't in either help file.;)

The backwards behavior you are experiencing is the default PLE mode. I think it's counter-intuitive, and I'd guess you agree. :) I added a BUG mode that works as you'd expect.

Also, with the PLE mode, you can hide both wounded and healthy units resulting in all units being hidden. I thought that was also counter-intuitive, so the BUG mode makes related filters mutually exclusive. If you have "show only wounded" selected and click "show only healthy", the "show only wounded" filter turns off.

This new mode is only available in our code repository right now. I won't subject you to SVN, though I think you've demonstrated enough skill to handle it up to this point. We should be releasing 3.0 in the next couple weeks, though. *crosses fingers*

Not sure what the star/arrow are or the stacked squares/triangle-square.

Oops, forgot to answer this part. The first two are actually specialized views for promoting and upgrading units. The second two alter the stacked column/row views.

Star: View units that can be promoted with buttons for each available promotion next to the unit.

Up-Arrow: View units that can be upgraded with buttons for each target upgrade next to the unit.

Stacked Squares: When using horizontal or vertical stacking view mode (3rd and 4th buttons from left), groups units by unit type.

Triangle and Square: When using horizontal or vertical stacking view mode (3rd and 4th buttons from left), groups units by selection group.

You can also view the help file on-line, but PLE help isn't in either help file.;)

----> That is an arrow. Could you point that arrow towards this mythical on-line help file?

----> Online BUG Help (http://civ4bug.sourceforge.net/BUGModHelp/index.htm)

The latest SVN version now has help text when you hover over each of the PLE buttons.

I still don't know why we need these new fangled PLE filters. Ctrl-H (select damaged units) works fine for me.

Because you're not the only one using BUG, and not everyone has the same taste in play style as you?:p

Because you're not the only one using BUG, and not everyone has the same taste in play style as you?:pAs long as I can turn those stupid buttons off - and remove some of the additional lines / boxes, etc around my units. :gripe:
all in good fun, not meaning to be a dick or anything :D

I don't use the filters, but I really like the horizontal stack view mode. Actually, in my wars I've started using the Healthy unit filter so I can easily move the unhurt units forward to the next city. And when a war partner drops their stack on top of mine, the Domestic filter comes in handy, too.

As long as I can turn those stupid buttons off

That was added a couple days ago. Set your default view and group mode and then turn off all the buttons. Problem solved. :)

and remove some of the additional lines / boxes, etc around my units.

If you give me specifics, I'll see what I can do.

----> Online BUG Help (http://civ4bug.sourceforge.net/BUGModHelp/index.htm)

neener neener neener, found it last night alllll by myself. But thanks. It has oodles of goodies. Soon I will figure out the unit namingh stuff and then the world will be at my feet

I don't use the filters, but I really like the horizontal stack view mode. Actually, in my wars I've started using the Healthy unit filter so I can easily move the unhurt units forward to the next city. And when a war partner drops their stack on top of mine, the Domestic filter comes in handy, too.

I use all of them (some frequently, some less), and with the new BUG mode for filters, they are even better! :goodjob:

Firstly - let me say that I haven't tried out the latest version of PLE in BUG and what I am about to say could already be in BUG.

Here is the standard unit plot ...

http://img529.imageshack.us/img529/8954/normaldc6.jpg

Here is my version of BUG ...

http://img529.imageshack.us/img529/9409/bugpleml0.jpg

You will notice some differences ... little arrow for upgrade two bars at the top for movement(?) and health(?) - any idea which is which? removal of bar at the bottom (health) movement dot has moved up slightlyObviously, I chose a poor example as this one doesn't show promotion available, current function (ie fort) or GG added (little star).

What I would like is the ability to add / strip off all of the PLE additions one by one so that I can get back to vanilla BtS unit plots. Now that doesn't sound too hard does it? :D

Go to the BUG Options screen and switch to the "Unit Icons" tab.


Under "Indicators, uncheck these options:

Upgrade Available
Great General
Mission Tag

Uncheck "Movement Bar"

Done!

BTW, the health bar is on top (green/red by default); the movement (blue/yellow) is on bottom. You can freely change these colors as well.

Now, I'm sorry but the health bar cannot be moved to below the unit, nor can the dot be lowered currently. Do these settings satisfy your needs, though?

Those new buttons and the hover text in the latest SVN version are great ! Great work, as usual :goodjob: !!!

Thanks! The new icons are courtesy of NikNaks, the designer of our logo. Look forward to some new buttons for CDA as well. :)

A question for you all that have used the filtering buttons (healthy and wounded; land, sea and air; civilian and military; and foreign and domestic): I want to add some more filters, but space will become a problem. I have thought of a way to combine related buttons into a single button. Please comment on how you think this would appeal or not to you.

All filters start off -- you see all your units.


You click the "healthy" filter (the green plus). It gets highlighted with a yellow circle and only healthy units are shown.
You click it again and it turns into a red plus. Only wounded units are shown.
You click it a third time, the highlight is removed and it turns back into a green plus. All units are shown; the filter is off.

Does this seem confusing? It might be hard to tell without actually playing with the button, but I'd love some feedback before I change it.

Also, if anyone has requests for other filters, post those please. The first one that comes to mind to me is a "can move" filter to hide units that can't move anymore this turn. It will make attacking a city from a stack much easier, hiding units that have already attacked.

is there a 'turn off all silly filters, groupings, etc' button?

is there a 'turn off all silly filters, groupings, etc' button?

Yes, the first checkbox on the "Unit Icons" tab of the BUG Options screen, but I highly recommend you try out the filters and stacked view modes. </evangelism>

I think Ruff is just one of those guys who once he made his POV known, he wont' change that POV, even if it means he stands still while the tornado sucks up his house.:p

Yes, the first checkbox on the "Unit Icons" tab of the BUG Options screen, but I highly recommend you try out the filters and stacked view modes. </evangelism>

I think Ruff is just one of those guys who once he made his POV known, he wont' change that POV, even if it means he stands still while the tornado sucks up his house.:pTruth be told, I actually do sometimes use these little suckers :p :run:

It would be nice if the promotion available sign was more obvious than the light blue surround. When you have units selected you can no longer see this! A better way might be to have the upward arrow as the promotion available sign, since the majority of players will generally be aware of upgrade potential. Plus, this wouldn't conflict with when units are selected.

I've noticed that too, DrJambo. What about a white star to match the PLE button and Combat I promotion?

The thing I like about a highlight is that for those of us with poor vision, the upgrade arrow and GG star just aren't visible.

is there a 'turn off all silly filters, groupings, etc' button?

Yes, the first checkbox on the "Unit Icons" tab of the BUG Options screen, but I highly recommend you try out the filters and stacked view modes. </evangelism>No - I meant is there a button that undoes all of the filters. Just been playing in an SG and turned on various filters only to loss all of my units - no unit icons at all. I would like a button that I can click to reset to my Ctrl-Alt-O default.

BTW - nice buttons, huge improvement.

umm... EF was talking about having a button for that... he didn't code it in?

Yes, I have a button graphic for the now, but I need to make room. It will reset all filters, and maybe I will make it reset to your default modes as well.

So I coded up my idea of tri-state buttons (click to see healthy, again to see wounded, again to clear filter), and I want to get some feedback. Also, right-clicking the filter goes in the opposite direction.

Please replace CvMainInterface.py with the following file (backup your file first and change this file's extension) and tell me what you think. Only the healthy/wounded filter is changed.

* Note: This isn't a ZIP, it's a PY file.

Yes, I have a button graphic for the now, but I need to make room. It will reset all filters, and maybe I will make it reset to your default modes as well.

So I coded up my idea of tri-state buttons (click to see healthy, again to see wounded, again to clear filter), and I want to get some feedback. Also, right-clicking the filter goes in the opposite direction.

I fear it is not so intuitive, or at least, IMHO going in that direction we loose some of the increase in immediateness that we have get with your "BUG mode" and hover text. Furthermore, IMO if we want to do this, the hover text should be fixed (in your example is mismatched) and more important we need a different icon for the "all" state (for example, I think that the unselected green cross is non enought to differentiate from the selected green cross).

I have a different suggestion: leave the filter buttons as they are, and create a unique 4-status grouping button. You will free room equivalent to 3 buttons, and you'll avoid the problems which I mentioned above, because doing so you will not add a "status" (so, no more image needed), and furthermore you always are in one and only one of the four status, so IMO it is intuitive to have a unique button cycling through them.

we lose some of the increase in immediateness that we have with your "BUG mode".

That is precisely what I fear. If we go this way, though, the hover text would be rewritten and each group of filters would have its own "off" button. For the health-related ones, that's a gray cross.

Create a unique 4-status grouping button.

That is a possibility, but it suffers the same drawback (lack of immediateness). I only use those four buttons, however, when I'm looking at a city screen with a ton of units. This is why I was thinking of a "city screen view mode" so I wouldn't even need to click the buttons. Alerum says he uses them also when he's got a large stack and cannot click where he wants to move units.

However, given that I suspect people will filter more than change view modes, I think that might be the better solution and provide just enough room for the "clear all filters" button and a new "movement" filter button group.

Now for the four right-most buttons. From people's comments, I think it is unclear that they are mutually exclusive. They aren't entirely related, though. The left two switch how units are grouped in the four view modes. I will combine these into a two-state button.

The right two switch the whole plot list into completely different operational modes, showing all units that can be promoted or upgraded depending on which button you push along with icons showing how they can be promoted or upgraded. Clicking the icons should do that thing, but it didn't work for me. Also, unless I'm mistaken, all the normal filters lose their effect temporarily.

One option is to remove these two modes entirely and turn them into regular filters. They would each be a single button only, as I don't see the point of "show me all units that cannot be promoted". Same for upgrade.

The other option is to at least push the group-mode button (squares, triangle) next to the promo button so it's clear that the three are mutually exclusive.

I looked at it and here is are some comments ...

why do we have a single row option - that was early civ4 vanilla and they (Feraxis or how every you spell their name) stole the idea from someone here at CFC ... we shouldn't have the option to do something that is horrible cycle filters for one filter but not for the others is not consistent I see now about 3rd / 4th from right filter options to get my unit icons back ... not clear even with hovers did I mention I like the new buttons? <whinge>I still cannot get back to vanilla BtS PLE icons </whinge>

... my suggestion watch rush hour 4 ... its not that bad remove single row icon, keep other three ways of stacking icons next icon should be toggle icon (highlight not there / there) that says 'turn filtering off / on have a small break and then display all of the filter options ... laid out, not toggle version BUT only show them if the filtering option is ON. remember the last filter setup (not between civ4 sessions)

BTW: GG star is now in a horrible place ... will mock up different icon and suggest new spot ... maybe right below dot.

That is precisely what I fear. If we go this way, though, the hover text would be rewritten and each group of filters would have its own "off" button. For the health-related ones, that's a gray cross.

Ok :)

That is a possibility, but it suffers the same drawback (lack of immediateness). I only use those four buttons, however, when I'm looking at a city screen with a ton of units. This is why I was thinking of a "city screen view mode" so I wouldn't even need to click the buttons. Alerum says he uses them also when he's got a large stack and cannot click where he wants to move units.

Yes, but IMHO the immediateness is more than in the other option, and, as you said, the use of those button is much less common.

Now for the four right-most buttons. From people's comments, I think it is unclear that they are mutually exclusive. They aren't entirely related, though. The left two switch how units are grouped in the four view modes. I will combine these into a two-state button.

Good idea! And maybe move it near the unique 4-views button?

The right two switch the whole plot list into completely different operational modes, showing all units that can be promoted or upgraded depending on which button you push along with icons showing how they can be promoted or upgraded. Clicking the icons should do that thing, but it didn't work for me. Also, unless I'm mistaken, all the normal filters lose their effect temporarily.
One option is to remove these two modes entirely and turn them into regular filters. They would each be a single button only, as I don't see the point of "show me all units that cannot be promoted". Same for upgrade.


If the promotion or upgrade doesn't work (and it's not possible to make it work) turning them in regolar filters can be ok. If it is possible to make them work, of course they'll be useful.

In my quest to make PLE look good, I'm looking for feedback on this:

http://i279.photobucket.com/albums/kk123/NikNaks93/PLEimageoverlay.png or http://i279.photobucket.com/albums/kk123/NikNaks93/PLEimageoverlayround.png or http://i279.photobucket.com/albums/kk123/NikNaks93/PLEimageoverlayroundoutline.png or http://i279.photobucket.com/albums/kk123/NikNaks93/PLEimageoverlayroundoutlinesolidbg.png vs http://i279.photobucket.com/albums/kk123/NikNaks93/PLEtextoverlay.png

I'm aiming to swap out the text for icons in the corner of the unit button. EF made a good point that it might be hard to see so I'm wondering anyone else thinks. Say which you like the most (saying its number, going from left to right).

EDIT: Added version with outline per EF's suggestion.

The fourth image with a full circle that overhangs the unit's icon is much clearer to me. Perhaps add a thin black border to the circle? Not sure if that would help or hurt.

Okay, I've added that to the options in two forms, one with a semi-transparent background, one without.

Personally, I like the fourth version the most. It seems brighter and clearer to me.

the question I have is are we replacing all of the text actions with little icons?

the question I have is are we replacing all of the text actions with little icons?

The answer I have is "Yes." ;) As long as NikNaks can design icons that are clearly distinct and easily recognizable, I will swap them out for the text tags. If you press, I could make this configurable.

My main reason for this is to avoid having non-translatable text in graphics. Sure, we could make different graphics for the same icon usage, but that take more time and can't be done by the translators themselves, slowing the process.

Besides, the German and Italian text tag icons would need to be 250 pixels wide, only allowing five units on the screen at a time. :P

The answer I have is "Yes." ;) As long as NikNaks can design icons that are clearly distinct and easily recognizable, I will swap them out for the text tags. If you press, I could make this configurable.

My main reason for this is to avoid having non-translatable text in graphics. Sure, we could make different graphics for the same icon usage, but that take more time and can't be done by the translators themselves, slowing the process.

I support this idea, the icon are much prettier and furthermore it's a pity to have translated everything, even the more hidden word, and then having not-localized words in full view in the main area.

Besides, the German and Italian text tag icons would need to be 250 pixels wide, only allowing five units on the screen at a time. :P

:lol::lol::lol:

Ah, I'm also for the 4th picture, very good ^_^

Clearly number #4. If only I could play better to match the BUG Mod in it's ever increasing perfection... ;) :D It's sad to get steamrolled by Boobica of the Celts :D with a 50 Cavalry stack...

New Green GG indicator looks crap. We need a graphic guy (hint hint) to redo the dot move injured etc indicators as stars and then replace the dot with those stars if the unit is a GG.

Halfway there, Ruff. :)

New Green GG indicator looks crap. We need a graphic guy (hint hint) to redo the dot move injured etc indicators as stars and then replace the dot with those stars if the unit is a GG.I've done it for the custom colours added by PLE, I just need to do it for the default ones.Clearly number #4. If only I could play better to match the BUG Mod in it's ever increasing perfection... ;) :D It's sad to get steamrolled by Boobica of the Celts :D with a 50 Cavalry stack...Who the hell is Boobica? :lol:

The first set of PLE changes have been finalized and are in SVN. Check out the New Features and Fixes thread (http://forums.civfanatics.com/showthread.php?t=249117) for the details.

Post comments about them to this thread only please.

Awesome. Completely awesome.

With the new look PLE is even better, great work indeed! :goodjob::goodjob:

Only a couple of things:
1) in Standard Mode, the group type should appear in the hover text (something like "Standard Mode (grouped by Unit Type)" and "Standard Mode (grouped by Selection group)" , while now the 2 hover texts for the two option are the same). The same happens with the first button on the left. I've seen (and translated) the text for the single states, so I think that they should appear somewhere, but or I don't find them, or they don't show.
2) some other unit-related text appear in the left pannel on the back of our hover text if the user keep the left button pressed over a button (all of them) for more than a second: can it be removed?
3) while all the hover text pannels resize properly, the white foot one doesn't: it gets a vertical scrolling bar (you ca't realize this with the short English text)

Anyway, this mod is great :)

1) in Standard Mode, the group type should appear in the hover text (something like "Standard Mode (grouped by Unit Type)" and "Standard Mode (grouped by Selection group)" , while now the 2 hover texts for the two option are the same).

That's a good suggestion. I'd like to clean up some of that text as well, as the same text is included in many tags whereas it should be built from unique pieces. As we get closer to the release date, I'm finding more things to fix than crossing off my list.

2) some other unit-related text appear in the left pannel on the back of our hover text if the user keep the left button pressed over a button (all of them) for more than a second: can it be removed?

Unfortunately, that's Civ showing the hover text for the plot which your mouse is over. It doesn't seem to send an event for when the mouse button is pressed (for me to hide the hover) -- only after it is released.

3) while all the hover text panels resize properly, the white foot one doesn't: it gets a vertical scrolling bar (you ca't realize this with the short English text)

Darn. I saw this on one of the English ones and shortened it. This doesn't happen with the unit info hover, so maybe I just need to set the font smaller.

Thanks for the feedback. :goodjob:

Unfortunately, that's Civ showing the hover text for the plot which your mouse is over. It doesn't seem to send an event for when the mouse button is pressed (for me to hide the hover) -- only after it is released.

Get it. I never realized that those info were shown even when the cursor was on the blue bottom bar.
What about making the hover pannel a bit less transparent, so that it can hide a bit better the back text when it appears? Not so important, anyway.

I figure that once you start to actually click the button, you're past the point of reading the hover text. You either know what you're doing, or you don't care. ;)

In all seriousness, I could do that, but it would then look different from the game. I'd prefer to find a way to make our hover disappear when the mouse gets pressed but not released. I'll keep looking . . .

I've committed a fix for the scrollbar. I simply shrunk the text size to that used for the unit info hover and the built-in help text for other icons.

I figure that once you start to actually click the button, you're past the point of reading the hover text. You either know what you're doing, or you don't care. ;)

In all seriousness, I could do that, but it would then look different from the game. I'd prefer to find a way to make our hover disappear when the mouse gets pressed but not released. I'll keep looking . . .

I've committed a fix for the scrollbar. I simply shrunk the text size to that used for the unit info hover and the built-in help text for other icons.

Thanks :)

Feature request: the upgrade arrow in the buttom left corner can be made green if you have enough money to upgrade and red if you have not? :blush:

The right two switch the whole plot list into completely different operational modes, showing all units that can be promoted or upgraded depending on which button you push along with icons showing how they can be promoted or upgraded. Clicking the icons should do that thing, but it didn't work for me. Also, unless I'm mistaken, all the normal filters lose their effect temporarily.

One option is to remove these two modes entirely and turn them into regular filters. They would each be a single button only, as I don't see the point of "show me all units that cannot be promoted". Same for upgrade.

They works now (and no, the normal filters works even with them). I don't know if you did something, or if simply they didn't work for you because you had not enough money.
Maybe, if it is possible, if you have not enough money we can add a red square around them, or if it is not possible we can add a light blu square around the possible promotion and a yellow square around the possible upgrade, leaving them without square if you have not enough money.

Now that I've re-read your post, I understand the buttons' order, so i deleted my previous post asking for some changes in it.
BTW, the "domain" buttons should be reordered according the Civ4 order (so it acts as a reminder of the order in which the units or groups of units are displayed): sea, air, land

Yes, the promotion and upgrade buttons are working for me, too. It must have been pilot error. :)

BTW, the "domain" buttons should be reordered according the Civ4 order (so it acts as a reminder of the order in which the units or groups of units are displayed): sea, air, land

Hmm, I put them into the order they are in in the build list, and I think people will more likely want to see just land units, thus it's on the left. Anyone else want them ordered as they are in the plot list? I'm open to it.

One thing I just noticed is that PLE doesn't show air or land units that are loaded on ships. I'm thinking of changing this so that both the ship and its matching units will be shown if it has any units that match the filters. The ship would be shown just so you know why the units are shown and that they are indeed on a ship. How does that sound?

Yes, the promotion and upgrade buttons are working for me, too. It must have been pilot error. :)

BTW, the button layout you have made is much more intuitive, and together with the hover text (remember to think about adding the status of the togle buttons) and that huge help file (just translated it) I think that we can greatly reduce the questions about PLE.

Hmm, I put them into the order they are in in the build list, and I think people will more likely want to see just land units, thus it's on the left. Anyone else want them ordered as they are in the plot list? I'm open to it.

Good argomentation, so let them as they are :)

One thing I just noticed is that PLE doesn't show air or land units that are loaded on ships. I'm thinking of changing this so that both the ship and its matching units will be shown if it has any units that match the filters. The ship would be shown just so you know why the units are shown and that they are indeed on a ship. How does that sound?

Are you sure that they are not shown? The readme says they are shown in the same pack.

you haven't got another little snazzy icon that says this unit is on a transport? btw - nice avatar.

I suggested that already...

Are you sure that they are not shown? The readme says they are shown in the same pack.

I had just noticed it when I posted. I had a fleet with some transports carrying tanks and a carrier full of planes. Clicking air and land cleared the plot list entirely. You may be thinking of the other way around. If a transport passes the filters, all the units it is carrying are displayed.

you haven't got another little snazzy icon that says this unit is on a transport?

I could do that for land units since they'll just be "waiting" on a transport. But planes can be in intercept mode. I could add an icon in a different place, perhaps where the upgrade arrow is now. That's a bit more work but doable for sure. Is it worth it?

btw - nice avatar.

Thanks! That's custom artwork by our resident artist, NikNaks. I've wanted to draw that since I started using the name EmperorFool, but my drawing skills are limited to, well, I'd need to have some drawing skills in the first place for them to be limited to something.

@Cammagno - I forgot to address your idea of coloring the upgrade arrow. Would you mind putting that into the Feature Request tracker? I like that idea, and it shouldn't be too hard.

[chanting in the background, a computer print out on the table, incense hanging in the air and a general feeling of apprehension ...]

:bowdown: Oh great forum manager in the sky, we, the unworthy, ask that you grant us the ability to resurrect this thread that was let die before its time. We know that the PLE additions still need work and we promise to not let this thread die until we have provided the all demanding user the ability to completely remove the ugly PLE unit plot style and return to the beautiful, elegant unit plot style that once was.


thread resurrection successful!! :band:

I've posted some code in the main interface to revert to the vanilla unit plot instead of PLE. Unfortunately, you completely lose some of the way cool things that BUG added (promo frame, GG indicator, mission indicator) as well as breaking some other silly stuff (hover info).

I will work on this so that the cool stuff is available on the vanilla unit plots and look into why the hover info is broken.

What is the functional difference between these two lines ...


screen.addSpecificUnitGraphicGFC( "InterfaceUnitModel", CyInterface().getHeadSelectedUnit(), 175, yResolution - 138, 123, 132, WidgetTypes.WIDGET_UNIT_MODEL, CyInterface().getHeadSelectedUnit().getUnitType(), -1, -20, 30, 1, False )


screen.addUnitGraphicGFC( "InterfaceUnitModel", CyInterface().getHeadSelectedUnit().getUnitType(), 175, yResolution - 138, 123, 132, WidgetTypes.WIDGET_UNIT_MODEL, CyInterface().getHeadSelectedUnit().getUnitType(), -1, -20, 30, 1, False )


Do we have a preference for one over the other?

Interesting. The first takes the CyUnit while the other one takes just the Unit Type. My first guess was that the Specific one showed the icon for the actual unit, taking UU into consideration and that the second one showed the generic unit type icon (Maceman for a Samurai), but I have no idea why one takes a different parameter. Both should be able to function in my assumed way using either parameter.

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

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.

more ruff / EF chat ...


ruff_hi: have question for you re PLE
emperor.fool: yes, that was what I was suggesting in my post: disable title click for 7-1
emperor.fool: que es?
ruff_hi: did you see I broke BUG when I included ';enabled'
emperor.fool: that you broke the plot list, yes
ruff_hi: if you save the option unchecked, quit game and then restart BUG craps ouyt
ruff_hi: divide by zero error
emperor.fool: that's what I kept msging you about. tho I didn't understand your recent post
emperor.fool: oh, hehe
emperor.fool: I didn't see that
ruff_hi: changed the 'disabled' to 'PLE_Style'
ruff_hi: so - check PLE Style and you get PLE in all its glory (gory)
emperor.fool: oh, I wonder if that's the thing I was seeing
ruff_hi: uncheck and you get plain old vanilla BtS
emperor.fool: hehe
emperor.fool: and it works now? sweet
emperor.fool: committed?
ruff_hi: but - I want (yes) plain old vanilla BtS plots with GG, promo, upgrade and mission added
emperor.fool: I'm currently checking out install program creators as it looks like that's gonna be my job now
ruff_hi: however, those 4 check boxes look like they only work for PLE (on the option screen)
emperor.fool: hmm, we'll have to redo the options screen, then, as those checkboxes should control both views
ruff_hi: I want to get the message to the user that PLE style turns on / off all of the PLE options but does nothing to GG, promo, upgrade and mission
ruff_hi: how do I do that?
emperor.fool: by moving those checkboxes "before" the plot style selector
ruff_hi: was thinking we need to re-work option screen to get all of PLE items together and isolate the 4 I want to share
emperor.fool: we'll have to play with the ordering to see how it looks
emperor.fool: yes
emperor.fool: and as long as you put those 4 above and/or to the left of the PLE stuff, that should be clear
ruff_hi: now - did you know that we create all of the promo art and then hide it - only show it if required
emperor.fool: yup
ruff_hi: BUT for the GG, we distroy and create as required
emperor.fool: that's standard Civ4 UI behavior
ruff_hi: why are these two done differently
emperor.fool: ya I noticed that and just left it alone
emperor.fool: I didn't look into it
ruff_hi: the thing is - the promo frame will be located differently for PLE and non-PLE style plot list
emperor.fool: the PLE code is honestly so hokey that I cringe whenever I have to deal with it
ruff_hi: so we would need 2 complete (hidden) promo frames if we go that way
emperor.fool: yes, so the temptation is to create dual copies of everything a la widescreen bars
emperor.fool: I *hate* that, but not enough to roll up my sleeves and fix it yet
emperor.fool: I just assumed that civ's UI must get confused if you add/remove a bunch of stuff, but clear that isn't the case. we should write it correctly from the start
ruff_hi: well - we do have 2 complete copies of the unit graphics
emperor.fool: no we do? or we did before?
emperor.fool: now we do? or we did before?
ruff_hi: we do now - after I added back the vanilla plot list
emperor.fool: ok ya
ruff_hi: and the promo frame has to go behind the unit graphic
ruff_hi: seems like I will need two complete lists of promo frames
emperor.fool: given that we can call functions when options are changed, it wouldn't be *too* hard to write a function to delete/readd the items (or just move them) when the user switches views
ruff_hi: another of those 4 are also pre-created (hide and show) but I cannot remember which
emperor.fool: dot is I think. what about mission tag?
ruff_hi: they are created during screen init - best to prob just leave it
ruff_hi: 1 sec
emperor.fool: probably the dot since every unit has one
emperor.fool: ya, it's not like they are going to have thousands of units on a single plot
ruff_hi: there is one def that creates all of the unit plot stuff - very ugly
emperor.fool: the trick is that you'll need to hide *both* sets of things at the start of drawing a plot in case they switch the option while a unit is selected
ruff_hi: broke it up by putting in the following
ruff_hi: 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 )

emperor.fool: omg thank you!
ruff_hi: the ones with x, y create
ruff_hi: the others show and hide
emperor.fool: ah ok
ruff_hi: promo has to stay with show and hide
ruff_hi: not sure about health bar - probably it is best if so - progress bars are difficult if I remember
emperor.fool: well, we could do moveToBack for it
ruff_hi: so that leaves us with (move to back / front has never worked for me) with 2 sets of ...
emperor.fool: after adding promo frame, move it to the back
ruff_hi: unit plot, promo frame and move bar
emperor.fool: I use move to front for the tick marks
ruff_hi: scratch that ... health bar
emperor.fool: right
emperor.fool: and GG, upgrade, and mission tag are add/remove, right?
ruff_hi: well - I can try that and see if it works
ruff_hi: yes
emperor.fool: and move bar
emperor.fool: er, move bar is constant, but only 1 of them
ruff_hi: I think I have committed the maininterface with the above changes
emperor.fool: awesome
emperor.fool: I won't make any MI changes for a while in case we need to revert
ruff_hi: so, double unit plot, promo, health
ruff_hi: 1 move
ruff_hi: create / distroy GG, upgrade and mission - sounds like a plan
emperor.fool: oh GG indicator is the dot now, I forgot
ruff_hi: yeah - that was a totally awesome insight - was that you?
emperor.fool: so 2 sets of dots which includes GG indicator
emperor.fool: yup
ruff_hi: dots / GGs are create and distroy - only need 1
emperor.fool: NN asked if I had any graphics needs one day and it just hit me out of the blue
emperor.fool: ok
ruff_hi: just need to get the x, y offset correct
emperor.fool: ya
emperor.fool: still want to have two upgrade indicators: green and orange
ruff_hi: can just seem me mixing those 2 up and having the dot floating 5 pixels away from the unit
emperor.fool: hehe
ruff_hi: green (afford), orange (not enough cash)?
emperor.fool: it took a few tries to get it to line up nicely
emperor.fool: yes
ruff_hi: what about if you have 800 and it costs 200 to upgrade
emperor.fool: screw the color blind!
ruff_hi: and you have 5 units to upgrade?
emperor.fool: it would only consider each in turn
ruff_hi: green, green, green, green, oranage?
emperor.fool: ya that's another way to do it, the problem is what happens when units are on boats? or if you group by selection list? it would work
ruff_hi: 1 sec
emperor.fool: better still, what if you have rifling and an axe and a sword but only enough cash to do the axe OR sword. it would show green axe, red sword ... makes me think I couldn't do the sword by itself
emperor.fool: but we could do either way. that would actually be nice, and since you tend to upgrade starting with the best units down (I do anyway, mostly), that would work
ruff_hi: yeah - ok

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 :D. 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).

http://img186.imageshack.us/img186/4784/ple0004zu1.jpg

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

http://img514.imageshack.us/img514/8207/pleoptionscreen0001qu7.jpg

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

Hehe, I'll just say it won't be trivial and will be complicated by the . . . intriguing . . . coding of PLE. :mischief: 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.


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,


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.


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:


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. :D


sigh - what have I gotten myself in to.

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


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.

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


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:

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.


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?

[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.

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.

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 :-)

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:


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

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:

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?

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.


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.

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.

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.

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.

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 . . .

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.

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.

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.

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.

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.

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.

Yes, I found the same thing. And restarting Civ doesn't get rid of the ghost icons for you? It did for me. I'll see if I can fix this before we do the whole PLE rewrite thing.

not for me. whenever i reload that save, the same icons are still stuck.

I've started the coding for the UnitPlotList enhancements. I've committed the UnitPlotListUtil.py file (revision 1866).

Now, don't get carried away because nothing actually uses it yet.

I've started the coding for the UnitPlotList enhancements. I've committed the UnitPlotListUtil.py file (revision 1866).Revision 1867 - updated UnitPlotListUtil.py with more stuff. While it only contains the promoframe at the moment, I think it is time to start folding this into the maininterface.

I mentioned/asked this over in the BUG Questions thread, a few days back. It would have some bearing on the PlotList primarily - as that seems to be what causes most folks slow-downs when using BUG.

I don't recall where I read it, one of the guides or some of the documentation that has been created in regards to CIV modding.

Would CIV still read/recognize the python files if they were compiled into .pyc files?
The only place I see them are in the directories that have files for the CvGameCoreDLL.dll. If it is possible then it stands to reason things like MainInterface screen and the like should get a speed boost.

Revision 1867 - updated UnitPlotListUtil.py with more stuff. While it only contains the promoframe at the moment, I think it is time to start folding this into the maininterface.

As per our other discussion, definitely do not fold this into BUG at this time--way too risky and also incomplete. Feel free to create a branch in SVN for this work, however, and go to town. :)

Would CIV still read/recognize the python files if they were compiled into .pyc files?

Sorry, I forgot to reply to this the other day. Precompiling Python files would only help speed up loading of Python. All Python files are compiled eventually, and this is not the cause of the slowness issues. I have no idea if Civ4 would recognize .pyc files, but I do believe that they would make no difference if so.

The slowness with PLE isn't even the Python. The Python code is trivial. The slowness is that it draws/hides so many overlapping graphical elements, and I would be that the Civ4 engine redraws the screen with each call that changes the graphics. This time is spent in the EXE layer which we cannot control. We'll attack the problem by limiting the amount of drawing we do by detecting when we don't need to redraw an element that hasn't changed.

Ah yeah, in my CivilizationIV.ini I posted though, there is a setting:
; Copy entire image each frame, not just dirty pixels
BinkCopyAll = 0

I believe that setting helps a lot more than most of the other tweaks in the .ini

Anyways, sorry for OT!! :)

As per our other discussion, definitely do not fold this into BUG at this time--way too risky and also incomplete. Feel free to create a branch in SVN for this work, however, and go to town. :)I was just going to ruin my local copy. But I would value your 2c if you have time to take a quick look at what I have committed.

Sure, here are a few notes along the way.


localText = CyTranslator()


Use BugUtil.getPlainText() and BugUtil.getText() instead to pull translated strings out. The ones in BugUtil have options for having a default and translating our custom s if needed. Of course, I doubt you'll be using them much.


iLeaderPromo = gc.getInfoTypeForString('PROMOTION_LEADER')
sFileNamePromo = ArtFileMgr.getInterfaceArtInfo("OVERLAY_PROMOTION_FRAME").getPath()


There are some cases where this gc-acquired stuff isn't available when the Python module loads. This is why I have init() functions in many BUG modules. You can either test to make sure these work or you can use an init() function for maximum safety. The latter ties the module to BUG, but that shouldn't be a problem here.


screen = CyGInterfaceScreen( "MainInterface", CvScreenEnums.MAIN_INTERFACE )


All of the Civ4 code I've seen does this each time the screen is needed, usually in a function called getScreen(). I have no idea if it's necessary. For CyGlobalContext, you can clearly create a single one in a global variable as you've done. We know that works. For CyEngine, I found I couldn't do that with the Strategy Layer for some odd reason; I had to create a new one each time I needed to update the screen. Be prepared for this to fail or start with a getScreen() function from the get-go.


# constants
sUpdateShow = "SHOW"
sUpdateShowIf = "SHOWIF"
sUpdateHide = "HIDE"
sUpdateNothing = "NOTHING"


I tend to favor int constants for things like these. They are called "enumerations" when you have a bunch of related values, for example the cardinal directions. For this I would use a little trick using range() so you don't have to assign a value to each manually:


(
sUpdateShow,
sUpdateShowIf,
sUpdateHide,
sUpdateNothing,
) = range(4)


This assigns 0, 1, 2, 3 to those variables. When you need to add a new value, just add a new line and change 4 to 5. It's nice because you can reorder the values if you want to merely by reordering the lines. Ints are generally preferable to strings because they are smaller (space) and cheaper to compare. Here that won't make a noticeable difference, but it's a good thing to practice I believe.


def updatePLEOptions():
# Capture these for looping over the plot's units
self.bShowWoundedIndicator = PleOpt.isShowWoundedIndicator()
...


This function doesn't believe to a class, so you must remove the "self." prefixes and declare them as globals:


bShowWoundedIndicator = False
...

def updatePLEOptions():
global bShowWoundedIndicator, ...
bShowWoundedIndicator = PleOpt.isShowWoundedIndicator()
...


Keep in mind that you'll need to redraw the plot list (easy way) when any of these options change or hide/show just the changed option (hard way). If you want to start coding this module to be more extensible (add new elements later), you might want to generalize this.

Use the range() trick above to define an enumeration of Plot List Elements. Then map each option to an element. Finally, track which are visible in a list of booleans:


NUM_PLE_OPTIONS = 7
(
WOUNDED_DOT,
HEALTH_BAR,
MOVE_BAR,
GG_INDICATOR,
PROMO_INDICATOR,
UPGRADE_INDICATOR,
MISSION_TAG,
) = range(NUM_PLE_OPTIONS)

PLE_OPTION_MAP = {
WOUNDED_DOT: PleOpt.isShowWoundedIndicator, # note no () after function
HEALTH_BAR: PleOpt.isShowHealthBar,
...
}

pleOptions = [False] * NUM_PLE_OPTIONS

def updatePLEOptions():
for element, option in PLE_OPTION_MAP.iteritems():
pleOptions[element] = option()


Now when you add a new element, you only have to add a new constant in the range() block and a line to map it to the option accessor in the MAP. Note that I used PLE in the names, but clearly these apply to the plot list as a whole, so maybe drop PLE entirely from most things here except PLE-specifics.


## - the vanilla BtS unit plot list has a panel for each row of icons and the units are arranged from the bottom left
## - the PLE unit plot list has no panel (drawn straight onto the screen) and counts from the top left (when in standard format)
## - the BUG unit plot list has one big panel and counts from the bottom left
## - this means that the max'th row fills up first, then the max'th-1, etc.


I would consider normalizing the use of y to be the same for all, with 0 at the bottom and increasing toward the top of the screen (or vice versa) to make the code much easier. You'll be writing all the code essentially from scratch by pulling pieces from CvMI and modifying it, so you may as well make that easier and reuse as much as possible.

As I explained before, I think we can get away with having a single draw function with a few plugin functions that calculate [I]where the elements get drawn. For example, both Vanillla and PLE have a health bar. The only difference is where it gets drawn in relation to the unit's icon. You don't need two draw functions for it, merely call a getX() and getY() function within the single draw function. Each PlotList subclass would be able to override the getX/Y() functions and inherit the master drawing code.


class UnitList:
def __init__(self, vScreen, vCols, vRows, yRes):
screen = vScreen
iCols = vCols
iRows = vRows
...


All these variables you are setting in __init__() are instance (class) variables and thus require "self." before them:


self.screen= vScreen
self.iCols = vCols
...


BTW, since these have "self." in front, you don't have to give them names different from the parameter names above. Change vCols to iCols, etc.


self.iCols = iCols


Here these are two separate variables with no danger of clashing. Once you get used to this it becomes easier, though it may seem error prone at the start. The only time you have the danger of making a typo is in the __init__ function itself.


iCols = iCols


Clearly this does nothing, but you'd catch it as soon as some other function tried to access "self.iCols" with "AttributeError: object has no attribute iCols".


_x = 315 - 3
_y = yRes - 169 - 3 + (1 - vRows) * 34
_w = vCols * 34 + 3
_h = vRows * 34 + 3


I get nervous when I see numbers in calculations like this. First, I see 34 in three places, which screams make me a constant!, probably ICON_SIZE or CELL_SIZE or perhaps it's not constant but a function getCellSize/Width/Height() that is based on option settings? The others like 315 and 169 look like they are based on resolution, and 3 is probably a spacing. Create constants for these so that the intent is clear.


class UnitPlot:
def __init__(self, vBupPanel, iIndex, x, y):
sBupString = sBupStringBase + str(iIndex)
xPixel = _getxPixel(x)
yPixel = _getyPixel(x)


Oopsies! :D Also, "self."s are needed here too.


# add promo frame
screen.addDDSGFCAt(sBupString + "PromoFrame", vBupPanel, sFileNamePromo, xPixel + 2, yPixel + 2, 32, 32, WidgetTypes.WIDGET_PLOT_LIST, iIndex, -1, False )
screen.hide(sBupString + "PromoFrame")


This should be extracted to a create() function. I think here is where you have a great opportunity for abstraction and generalization that will save you a lot of coding. Create a separate object for each element. I'll write more about this tomorrow as it will get pretty complex.


def _getxPixel(self, x):
return x * 34 + 3


Again, use constants. These are probably the same 34 and 3 as above. By using a constant/function, if we ever change it we can do so in one place.


_updatePromo(sBupString + "PromoFrame", pCurrUnit, pPrevUnit, sUpdateHide)
_updatePromo(sBupString + "PromoFrame", pCurrUnit, pPrevUnit, sUpdateNothing)
_updatePromo(sBupString + "PromoFrame", pCurrUnit, pPrevUnit, sUpdateShowIf)
_updatePromo(sBupString + "PromoFrame", pCurrUnit, pPrevUnit, sUpdateShow)


I'll get more into this tomorrow, but here I would more likely use different functions rather than a parameter for what to do. Also, I would have the function create the element ID (what if an element has two graphics?) and access pCurrUnit and pPrevUnit via the self object, so you don't need to pass them in:


if not pCurrUnit:
if not pPrevUnit:
# both have no unit, nothing to do
else:
# empty -> full
_drawPromo()
else:
if not pPrevUnit:
# full -> empty
_hidePromo()
else:
# both full
_updatePromo() # this function doesn't do anything, but e.g. mission tag updates the image


Using separate functions makes the following code easier to write and read, and as you'll see tomorrow, this can have a huge payoff when you generalize the element functions into classes.


def _getPromoString():
return self.sBupString + "PromoFrame"

def _drawPromo():
if self.pCurrUnit.bPromo:
self._showPromo()

def _updatePromo():
if self.pCurrUnit.bPromo and not self.pPrevUnit.bPromo:
self._showPromo()
elif not self.pCurrUnit.bPromo and self.pCurrUnit.bPromo:
self._hidePromo()

def _hidePromo():
if self.pPrevUnit.bPromo:
self.screen.hide(_getPromoString())

def _showPromo():
self.screen.show(_getPromoString())


The UnitDisplay class looks great. The only slight impovement (not sure even if it is) I can make would be for the dot indicator. Instead of calculating and storing all the effects, store only the data that determine those effects later: GG (already done later), has moved, and injured (both booleans):


self.bMoved = pUnit...
self.bInjured = pUnit...


This way you push off doing the calculations and image-choosing to the last possible moment (when it must be drawn). When the data doesn't change (the part we're trying to optimize), you won't need to do those calculations. They would be done in the _drawDot() function instead of here and they'd use the bGG, bMoved, and bInjured values as you already, just in a different function.

As for _getMission(), let's finally hook in UnitUtil.getOrder() which returns an enumeration constant. We can then turn that constant into an image using a simple constant list.

This is a great start, and I'd say you're on a very good track.I'll go into more details tomorrow about what I mean when I say to abstract the elements into classes. Essentially you'll have a class for each element type (promo frame, upgrade indicator, mission tag, etc) that knows how to draw itself given a UnitDisplay (or two in the case of updating).

PlotList would have a constant list of these objects, and it would loop over them calling the appropriate function (hide, draw, or update) on each one.


if pPrevUnit:
if pCurrUnit:
# both full
for element in elements:
element.update(pPrevUnit, pCurrUnit)
else:
# full -> empty
for element in elements:
element.hide(pPrevUnit)
else:
if pCurrUnit:
# empty -> full
for element in elements:
element.draw(pPrevUnit)
else:
# both empty
# do nothing


As you can see if we add a new element one of this code has to change. You only have to write the new element draw functions (same) and add it to the list of elements (1 line). Much easier. This is OOP at its best.

Firstly - thanks for all of the comments. I will review and update my file based on what you have suggested.

A couple of return comments ...



## - the vanilla BtS unit plot list has a panel for each row of icons and the units are arranged from the bottom left
## - the PLE unit plot list has no panel (drawn straight onto the screen) and counts from the top left (when in standard format)
## - the BUG unit plot list has one big panel and counts from the bottom left
## - this means that the max'th row fills up first, then the max'th-1, etc.


I would consider normalizing the use of y to be the same for all, with 0 at the bottom and increasing toward the top of the screen (or vice versa) to make the code much easier. You'll be writing all the code essentially from scratch by pulling pieces from CvMI and modifying it, so you may as well make that easier and reuse as much as possible.

Part of me agrees, but the PLE action is to actually show the 'top' unit at the top left, while the vanilla BtS action is to show the 'top' unit at the bottom right. Also, the x,y for each index will change with the different PLE options. I am hoping to bury this complicated stuff in these getx functions. I'll start with vanilla BtS and then worry about PLE.



# add promo frame
screen.addDDSGFCAt(sBupString + "PromoFrame", vBupPanel, sFileNamePromo, xPixel + 2, yPixel + 2, 32, 32, WidgetTypes.WIDGET_PLOT_LIST, iIndex, -1, False )
screen.hide(sBupString + "PromoFrame")


This should be extracted to a create() function. I think here is where you have a great opportunity for abstraction and generalization that will save you a lot of coding. Create a separate object for each element. I'll write more about this tomorrow as it will get pretty complex.
I totally agree with your comments and have noted them down. However, I am 100% sure that I have no idea how to even approach this. My thinking was to get promo frame up and running and then to see if I can extract that do a create() function. I guess I am putting off what I have no idea how to do while I work on something that I have a 25% idea about.

Constants are good. One of the most difficult things I found about working with Firaxian CIV files and DungeonSiege were the designers reliance on hardcoded numbers for GUI elements. DungeonSiege even more so as it made the frontend GUI scale extremely poorly with higher than 1024x|1280x resolutions.

Of course at least in DS their .gas (script) files were basically runTime C code, as opposed to having to learn a new language (Python) for CIV.

Part of me agrees, but the PLE action is to actually show the 'top' unit at the top left, while the vanilla BtS action is to show the 'top' unit at the bottom right.

I think I would handle that behavior with the sorting stage that creates the list of UnitDisplay objects that are to be drawn on-screen. However, you are spot on to hide this behind the getX/Y() functions.

My thinking was to get promo frame up and running and then to see if I can extract that do a create() function.

That is exactly what I would do first. The first one (promo frame) lets you figure out the basic flow. The second one (e.g. unit icon) should be similar but add a new twist, or perhaps do another one just like promo frame before this one. From these you can then find the commonalities and extract some base functions that don't vary or only vary slightly and build yourself a class to contain the common functions and placeholders for the ones that differ.

I find it far easier to devise an abstraction with a few cases worked out than to do it up front.

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.This looks like the bug that we saw the other day. I've got a solution for this that I will fold into the SVN version of BUG.

Edit: Fixed in revision 1882.

def _drawPromo():
if self.pCurrUnit.bPromo:
self._showPromo()

def _updatePromo():
if self.pCurrUnit.bPromo and not self.pPrevUnit.bPromo:
self._showPromo()
elif not self.pCurrUnit.bPromo and self.pCurrUnit.bPromo:
self._hidePromo()

def _hidePromo():
if self.pPrevUnit.bPromo:
self.screen.hide(_getPromoString())

def _showPromo():
self.screen.show(_getPromoString())


I was working on this a little over the week end. I think some of the above is redundant so I put it in as follows:


def _updatePromo():
if not self.pPrevUnit.bPromo:
self._showPromo()
elif not self.pCurrUnit.bPromo:
self._hidePromo()

def _hidePromo():
if self.pPrevUnit.bPromo:
self.screen.hide(_getPromoString())

def _showPromo():
if self.pCurrUnit.bPromo:
self.screen.show(_getPromoString())

The reason for the seemingly duplicate functions is that they each serve a very different need. Below "graphic" means whatever is appropriate for the feature.

Draw - Show the graphic if necessary.

This is called to draw a unit when nothing is visible currently. It is called the first time a stack is selected from none being selected and when a unit appears in a cell that was previously empty (these are really the same case). It must check the unit being displayed to determine whether or not to call show().

Erase - Hide the graphic if necessary.

This is the reverse of draw(). It hides the graphic if it's currently visible. It should check the previous unit to decide whether or not to call hide().

Show - Show the graphic.

The graphic has been determined to be visible now where it wasn't previously.

Hide - Hide the graphic.

Reverse of show(), it hides the graphic that is known to be currently visible. In my function above I tested pPrevUnit, but this should be moved to the new function erase(). It should look like show() which doesn't examine any units.

This function is also called when switching between PLE and non-PLE mode to ensure that all graphics are hidden properly. It would be followed by clearing the "previous units" and calling draw() for each cell.

Update - Show or hide the graphic as needed.

This compares the state of the previous and current units--including testing for None--and calls either hide() or show(). This is the real crux of the speed improvement.

This function also needs to check beyond hide/show for the mission indicator, health and move bars, and dot (GG/moved/injured).

ok, fair enough. However ... Q: Should 'update' show or hide or should it draw or erase?

ok, fair enough. However ... Q: Should 'update' show or hide or should it draw or erase?

Both. ;) Looking at my psuedocode above, you can see it calls draw(), hide(), and show() under different circumstances. Ideally it will call hide()/show() if it knows for sure that they should be called. In the case of draw(), it calls that because it only knows that there is a unit where none was there before. It leaves it up to draw() to decide whether or not to call show().


if not pCurrUnit:
if not pPrevUnit:
# both have no unit, nothing to do
else:
# empty -> full
draw(pCurrUnit)
else:
if not pPrevUnit:
# full -> empty
hide(pPrevUnit)
else:
# both full
update(pPrevUnit, pCurrUnit)


Now that I'm thinking more about this, I like more the idea of creating a class for each graphic. The graphic class would decide which fields are required from the CyUnit (some take multiple) and produce a key that determines how the graphic is drawn. When no unit is in the cell, it would have a default "none" key that is used.

Its update() function would use the previous and current keys to do the drawing, and it would have the same hide()/show() functions as above and possibly draw()/erase() as well (gotta figure that out). I'll throw some actual code together to see if I can solidify this idea into reality.

let me upload what I have - about 45 mins from now.

Edit: or now - committed.

As I so often find, everything changes considerably once you start writing actual code. ;) I'm pursuing the idea of having a class for each "artifact" which is typically a single graphical element. This means that the GG and Wounded Indicator options are combined into a single artifact.

Here are the concrete artifacts:


Unit Icon
Star/Dot
Health Bar
Move Bar
Promotion Frame
Upgrade Indicator
Mission Tag

I am writing base classes to handle some of the artifacts more generally. For example the Promotion Frame and Upgrade Indicator are both simple toggled graphics. I have also found that we can change the image used on a DDSGFC. I wonder if recreating the DDS each time is part of the slowdown (upgrade, mission tag, star/dot). Probably not--more likely it's just the redraw that causes the delay.

What I'm finding is that all artifacts will need create(), draw(unit), erase(unit), and update(prevUnit, currUnit). The separate hide() and show() functions are specific to the ToggledArtifact class used by the upgrade/promotion indicators.

What I've done is have each artifact have a function to create a key for a unit that encapsulates all of the data needed to draw itself. These keys are then passed to the above functions instead of the unit object. This allows the framework to compare keys and call the appropriate function. For example, if the prev and curr keys are equal, update() is not called for that artifact.

This makes the concrete artifact code much easier to write and should result in the most significant speed improvement.

If you can post your code we can start working toward a common interface between the two.

One thing I noticed is that the upgrade indicator might be responsible for a big time cost. I haven't measured it alone yet, but every unit is checked for possible upgrades every time it is drawn. I'm guessing that this performs a loop over all unit types checking to see if the current unit can upgrade to it, and if so, calculating the cost and comparing it to the player's gold. We could speed this up by keeping a list of all unit types that have upgrade possibilities and updating it each turn (it shouldn't change during a player's turn). This makes the check for upgradability a quick check in a set (near instant runtime). At the same time it would be good to change the indicator to red for possible but cannot afford and green to can afford.

bump - EF ... are you around tomorrow (Sat 19th) to discuss this? I am going to look at the maininterface file and add a variable (UsePLEClass) to create a logical branch in the code. 'On' and it uses our new code, 'Off' and it uses the existing code.

Yes, I should be around most of tomorrow. That's a good first step. It will make plugging in whatever you or I create much easier later.

as well as speed testing to see if it actually does anything. Maybe we should run some speed tests at it stands so that we can determine where our biggest wins might be.

Hmm - I am going to the 11:30am screening of Avatar tomorrow so we might have to talk before then (you'll be asleep, won't you?) of around 4pm my time.

When I did the timing tests before, I found the largest source of time cost to be the calls to draw the graphics. The time to inspect the units is insignificant. Telling it to draw the same graphic that is already there takes just as long as telling it to draw a new graphic. The underlying UI engine isn't smart enough to detect that nothing has changed--you pay the penalty no matter what.

Thus I need to avoid the calls to draw() when I can. My design is centered around detecting when the graphics must change and only calling draw for that case. It is slightly complicated by the fact that not all graphics are on/off. For example the mission tag is off or one of many icons. It got complicated as I started to work in off vs. not present (no unit in that cell), and I think I over-complicated it.

Here is my thinking. Each plot currently has a list of associated units ...

CyInterface().cacheInterfacePlotUnits(pPlot)
for i in range(CyInterface().getNumCachedInterfacePlotUnits ()):
pLoopUnit = CyInterface().getCachedInterfacePlotUnit(i)

This is totally separate from the unit display. The unit display array (the part of the screen that actually shows you the unit icons) is ...

if ((iCount == 0) and (CyInterface().getPlotListColumn() > 0)):
bLeftArrow = True
elif ((iCount == (gc.getMAX_PLOT_LIST_ROWS() * self.numPlotListButtons() - 1)) and ...

... CyInterface().getPlotListColumn() columns wide and gc.getMAX_PLOT_LIST_ROWS() rows high.

Current Method

loop over all unit display elements

hide graphical elements

loop over all units in the plot

calculate where in the unit display array the pLoopUnit should be displayed (the x and y) - this will vary on lots of things ... column / row format selected, PLE style (#1 unit is shown on top left most unit display element) / vanilla BtS style (#1 unit is shown on bottom left most unit display element), etc, etc
determine the characteristics of the unit (type, selected, promo available, moves left, GG, etc, etc)
display said characteristics


Final Method

loop over all units in the plot

calculate where in the unit display array the pLoopUnit should be displayed (the x and y) - this will vary on lots of things ... column / row format selected, PLE style (#1 unit is shown on top left most unit display element) / vanilla BtS style (#1 unit is shown on bottom left most unit display element), etc, etc
determine the characteristics of the unit (type, selected, promo available, moves left, GG, etc, etc)
compare said characteristics to current unit display element settings
adjust if required (show, hide, change)

loop over all unit display elements

hide graphical elements if not associated with unit



Now, changing from current to future in 1 fell swoop might be asking for trouble. As such, I would like to bite it off in chunks and head towards this position to start with ...

Interim Method

loop over all units in the plot

calculate where in the unit display array the pLoopUnit should be displayed (the x and y) - this will vary on lots of things ... column / row format selected, PLE style (#1 unit is shown on top left most unit display element) / vanilla BtS style (#1 unit is shown on bottom left most unit display element), etc, etc
determine the characteristics of the unit (type, selected, promo available, moves left, GG, etc, etc)
compare said characteristics to current unit display element settings
adjust if required (show, hide, change)
display said characteristics

loop over all unit display elements

hide graphical elements if not associated with unit

Question for our uses - do you use the PLE filters? If so, what do you do with them?

I've started to pull the 1000s of line of code for PLE out of MainInterface into its own file. I haven't got it completely working yet but it is mostly there. Some of the functions in the PLE file are used for the other unit plot methods so they will need to be extracted to some other more generic file at a later stage.

EF and I discussed the plot lists and neither of us could figure out what what these two suckers did ...

CyInterface().getPlotListColumn()
CyInterface().getPlotListOffset()

Well, after some testing and playing with units, I can say that CyInterface().getPlotListOffset() is the number of plot list 'slots' from the top left to the active unit. Vanilla PlotLists number the slots from the top left to the bottom right. When they display the units, the head unit is displayed on the top left (up the screen enough to get them all on one page, multiple rows if required). So CyInterface().getPlotListOffset() tells the draw routine how many empty holes to leave before drawing the first unit.

CyInterface().getPlotListColumn() only comes into play when you have too many units (need to scroll them back and forth). I haven't fully tested this (don't have time to WB in 281 units) but I would assume that it shows the unit number in the top right less 1. So, if I have 280 units, the head unit is displayed in the top left slot. If I add a unit, then the little right / left arrows are enabled. I can then scroll the units left and right. If I move the head unit off the 'page', then I am guessing that CyInterface().getPlotListColumn() will become '1' (ie the head unit is 1 column offset).

I've been thinking about this overnight and have the following to share ...

The vanilla BtS unit plot list ties the unit to the on screen location. Each unit plot has a widget number associated with it (k) and the DLL converts clicking / hover action over the widget location to the unit number in the group on that plot. With the PLE unit display methods (grouping, filtering, different layouts) that linkage between on screen location and location in the plot group is totally broken. Thus the author of PLE had to write tons of their own code to redo what the system did for him.

That is not what we want to do with the BUG version. Instead, we are going to decouple the on screen location and the location in the plot group. To do this, we need the individual screen unit place holders to be able to have different widget numbers (k).

The vanilla method sets up the on screen unit place holders ...

for iIndex in range(self.MaxCells):
szBupCell = self._getCellWidget(iIndex)
iX = self._getX(self._getCol(iIndex))
iY = self._getY(self._getRow(iIndex))

screen.addCheckBoxGFCAt(self.sBupPanel, szBupCell, sTexture, sHiLiteTexture, iX, iY, 32, 32, WidgetTypes.WIDGET_PLOT_LIST, iIndex, -1, ButtonStyles.BUTTON_STYLE_LABEL, True)

(my value k discussed above is iIndex in the above code)

... and then just changes the display picture based on what unit it should represent ...


iIndex = CyInterface().getPlotListOffset()
for pBupUnit in self.BupUnits:
szBupCell = self._getCellWidget(iIndex)
self.screen.changeImageButton(szBupCell, gc.getUnitInfo(pBupUnit.pUnit.getUnitType()).getBu tton())
self.screen.show(szBupCell)
iIndex += 1


Instead of doing this, we'll need to make note of the unit's place in the plot group and recreate the CheckBoxGFC every time we update the unit plot list so that we can reset the 'k' value to that value. Then we can just use the DLLs method of tying the on screen representation of the unit to the unit in the plot group.

Removing and adding the checkbox would put it in front of all the adornments (status dot, health and movement bars, upgrade arrow, and mission tag). And you can't move an item behind another item--only to the front of back completely. But the promotion frame must be behind the checkbox, so you'd have to push that back as well.

For each unit, you must do this:


Delete checkbox
Create checkbox
Move checkbox to back
Move promotion frame to back

Note that when we get the smart redraw code working, removing/replacing the checkboxes will defeat some of the performance gains.

That may only be necessary when you filter/scroll--not when selecting units, right? Maybe that would be okay, but it seems not worth it. Is having that extra code that horrible? I doubt that it is part of the performance problems with PLE.

The above only applies when you filter or have a non horizontal layout. We should use code that works for vanilla layout and the above for when you are being PLE tricky. The new code isn't just select, it is also info pain, upgrade, etc.

The other option is that we add the 'k' value as a decoration (btw - that is what the author of PLE called all the eye candy that you can add to the unit icon) and if it changes, then we do a complete re-draw - probably of the whole plot list, not just that unit plot.

I see the following as my development order ...
add eye candy to BugPanel
fold in code to minimize re-draw
add PLE functionality to BugPanel

all of this work is to speed up displaying plots that have lots of units. Do we have any time tests on the current system? How would I go about setting something like that up?\

I was thinking of using the BUG timer code and then just hitting '>' 10 times.

That's exactly what I did originally, except I clicked. > works better probably since you don't have to move the mouse (lazy bum). BugUtil.Timer is the way to go.

care to refresh my memory about all of the .Timer commands?

timer = BugUtil.Timer("draw plot list")
...
timer.log()

got it ... results with about 130ish (edit: actually 165!) units ...

18:10:30 DEBUG: Timer - draw plot list took 624 ms
18:10:34 DEBUG: Timer - draw plot list took 698 ms
18:10:35 DEBUG: Timer - draw plot list took 708 ms
18:10:37 DEBUG: Timer - draw plot list took 691 ms
18:10:38 DEBUG: Timer - draw plot list took 700 ms
18:10:40 DEBUG: Timer - draw plot list took 704 ms
18:10:41 DEBUG: Timer - draw plot list took 711 ms
18:10:43 DEBUG: Timer - draw plot list took 708 ms

So - about 700 ms - totally noticeable.

just for fun, I commented out the code that actually does the drawing ... got these results:

21:24:09 DEBUG: Timer - draw plot list took 12 ms
21:24:11 DEBUG: Timer - draw plot list took 13 ms
21:24:12 DEBUG: Timer - draw plot list took 13 ms
21:24:12 DEBUG: Timer - draw plot list took 12 ms

So if people are willing to play with NO unit plot icons, we can get this game to sing!

I now have some functional code that does all that Vanilla BtS does. Here is the timing with the 165 units that I have been using for testing ...

22:11:34 DEBUG: Timer - draw plot list took 743 ms <--- this is the first time that I selected the plot
22:11:58 DEBUG: Timer - draw plot list took 4 ms <--- all I did from here was hit '>' as per the test above
22:11:58 DEBUG: Timer - draw plot list took 4 ms
22:11:59 DEBUG: Timer - draw plot list took 4 ms
22:11:59 DEBUG: Timer - draw plot list took 4 ms
22:12:00 DEBUG: Timer - draw plot list took 4 ms
22:12:00 DEBUG: Timer - draw plot list took 4 ms
22:12:01 DEBUG: Timer - draw plot list took 4 ms

Hmm - even better than I got when I wasn't displaying anything - how cool is that!

Gotta say, that's pretty sweet! :goodjob: Have you done some thorough testing with things like promoting units, upgrading, attacking, issuing orders, grouping, ungrouping, selecting units, etc?

Gotta say, that's pretty sweet! :goodjob: Have you done some thorough testing with things like promoting units, upgrading, attacking, issuing orders, grouping, ungrouping, selecting units, etc?No, no, no, a little, yes and yes. I think I got that right. Its not ready for prime time yet ... still need to allow for the situation where there are too many units on the plot (those little arrow things), for when the city screen is up (only 1 row) and also need to include non-player units.

If only we had some people who were interested in helping to test this.

If it doesn't require compiling, I'd be interested in helping test.

its all python and can be driven from the custom asset folder.

No, no, no, a little, yes and yes. I think I got that right. Its not ready for prime time yet ... still need to allow for the situation where there are too many units on the plot (those little arrow things), for when the city screen is up (only 1 row) and also need to include non-player units.

If only we had some people who were interested in helping to test this.

I can lend a hand. I helped 12monkeys with testing the original PLE. I was also planning to start a new game anyway to finish testing my unofficial patch update to BULL (http://forums.civfanatics.com/showthread.php?t=349380).

I'm missing some of the history surrounding this undertaking. I usually play with the PLE itself off, but use the blue outline for promotion-eligible units, wounded dots and GG stars. Even this gets slow late game, however. Are your speed enhancements aimed at helping the plot list in general or only when having the PLE option on? I guess at some point you separated the blue outlines etc. from the PLE itself.

I'm willing to give it a try either way though.

I originally stopped using the PLE option because of the slow down and some quirks that I noticed along the way. The most severe of which was the inability to select all non-air units in the plot when there were air units present. The stock game doesn't allow an easy way to do this either, but clicking on a single non-air unit and then ALT+SHIFT clicking on another non-air unit got the job done. This trick didn't work in the BUG PLE. This could be rather outdated, however.

Point me to the files and any options I need to set to activate it. I thought I read in previous posts (that I very quickly skimmed) the code is in there, but currently being bypassed. As I said before, a little background would help focus my testing. Am I looking for stability, speed enhancements etc.

I haven't got much time now - I will be able to provide full details Thursday night. I've attached the 5 files that you need to copy over v4.2 of BUG (custom asset install or as a mod - doesn't matter). Suggest you create a new folder for this so that we don't trash your existing v4.2 install.

On the PLE tab of the options you will see a drop down called 'draw method'. BUG is the brand new method - not fully functional yet. PLE is the PLE method but I have pulled (or attempted to pull) all of the PLE code out of the maininterface file - I tested it but not fully so don't be surprised if PLE falls over. Vanilla is the normal BtS method but it uses some PLE functions to actually draw the Dot, Upgrade, Promoframe, etc. I don't expect any errors with vanilla.

Are we looking for errors/crashes, or checking speed? Or should I just wait for Thursday's info? :) And will it be useful to separately check on XP/Vista/7?

There shouldn't be any operating system issues in play here; this is pure basic Civ4 drawing code. We're looking for any bugs you find: drawing problems, error messages in Logs/PythonErr.log, etc. Also, is it faster or slower for you now?

I haven't merged ruff_hi's files into my own yet since I'm still using BUG build 2085. I quickly popped into the game to familiarize with some of the options, and I have a question. What does the top-left-most checkbox do? I think it's called "use PLE style" or something similar. The hover text suggests it needs to be checked for the rest of the tab to function, but this is not the case. It doesn't seem to have an effect at all.

Hopefully I'll be able to give this a whirl within the next few days.

"use PLE style"I admit it - I hate the look of PLE. It just grates on me. As I have access to the python code, I jumped in and restored the traditional vanilla look (health bars at the top, etc). Unchecking PLE style uses the vanilla approach and all of that fancy horizontal grouping doesn't work. The dot, mission, promo stuff does work.

History

As you know, BUG started as a collection of other people's mini-mods. Typically, we reviewed and improved the code as we folded it into BUG (120% of the improvement was due to EF, -20% of the improvement was due to Ruff). Neither of us had the burning desire to fold in the 1000 or so lines of code contained in PLE. However, I liked the promo frame and some of the other do-dads (star for GG), so I lifted that code and put it into the unit plot list.

Honesty alert: I hate PLE. It is ugly, doesn't provide any benefit, the code is horrible, you have to recode tons of stuff just to get it to work and I hate it. Don't expect me to like it. If I had my way, we would nuke it from orbit (http://nukeitfromorbit.com/). Now that I have declared my preferences, I feel totally fine in letting my bias come through :D. Feel free to tell me that I am nuts and that PLE adds X, Y or Z functionality and is really, really cool. Just expect me to totally disagree with you.

There were a few requests for PLE and we kept them at bay with the 'no time' line. That was, until a user posted a fully working, latest BUG, maininterface python file with PLE included. We (foolishly in my opinion) just grabbed it, wrapped some options around it and folded it in and thus 'broke' the vanilla unit plot list method. This was about 12 hours before a major release ... don't ask me why we did that.

Anyway, subsequent to that, we improved the graphics, re-enabled the vanilla code (PLE style check box) and left it.

Both methods suffer when you have plots with lots of units (> 100). EF postulated that this is because we are redrawing the whole screen every time. EF and I discussed how to fix and it stalled for lack of will / desire / skill / time (take your pick). Both EF and I took separate stabs at wrapping the unit plot stuff in classes, but neither of us fully finished anything (me because I don't fully understand classes and EF because he had other stuff on his plate).

Current Code Changes

So that we don't totally break the current situation, I added a 3rd method of drawing the unit plot list - the BUG method (see 'Notes on BUG method' section below). There are now 3 methods ... Vanilla, PLE and BUG. As a side aim of this, I decided to try and pull the 1000 lines of PLE code out of the maininterface file. It is my hope that the BUG method will totally replace the Vanilla method and that the ugly PLE method will remain as an alternative.

General Testing

You should test the normal stuff that you do with the unit plot list (selecting units, grouping, ungrouping, issuing orders, promoting, upgrading, etc, etc. Feel free to test this with any of the 3 methods (Vanilla, BUG and PLE). Keep in mind that we aim to replace Vanilla with BUG at some stage. If there is any differences, then the Vanilla method should win as it should reflect raw BtS the best. We want BUG and PLE to enhance the Vanilla methods so we shouldn't lose functionality when we move away from Vanilla.

You shouldn't see any speed improvements when using Vanilla or PLE. All of our current speed improvement code is in the BUG method. I would suggest that you play a normal game but with error logging enabled (including on screen pop-ups). At the end of a session, check the error log file (file name) to see if you ran into any errors. Keep in mind that we are modding a core part of the screen refresh code that is fired lots and lots of time - if you run into an error, you will probably have to Ctrl-Alt-Delete back to the task manager to kill off Civ4.

Vanilla Method Testing

Nothing really to add here as I didn't really play with the code. I did push some display methods into the PLE file but I don't think they should have caused any problems.

PLE Method Testing

As mentioned above, I pulled the PLE code out of the main interface file into its own file. I got it working but I know that I didn't test every little PLE thing - there could easily be bugs in there.

BUG Method Testing

This code is totally new and not fully functional as yet. I'll put together a list of things that this code will need and indicate if (I think) it is in there yet. I expect quiet a bit of feedback from this section of the testing (ie lots of bugs).

Notes on BUG method

The main aim of the BUG method is to utilize the core unit selection process built into the game (so that we don't need to re-write the unit selection, upgrade, etc code as per PLE) and to provide a significant speed improvement. The speed improvement comes by comparing the unit in a particular unit plot cell to the prior unit in that cell and only drawing stuff if it changes. At the moment, changing plots causes a complete redraw, so you will not see any speed improvement if you flip between 2 plots that both have 100 warriors in them. You should see speed improvement if you flip between different warriors in the same cell.

BUG Unit Plot Items Required


unit button (done)
selected unit yellow highlight (done)
other player units in non enabled mode (done)
Promo Frame (done)
Dot information (done)
Upgrade arrow (done)
Mission (done)
Health Bar (done)
Hide Health bar if in battle (done)
White arrows if more than x units (x changes with resolution) (outstanding)
Number of units per row changes with resolution (done)
City screen up (outstanding)
Normal unit actions (issue orders, upgrade, promote, group, degroup, etc) (done)
movement bar (really? Doesn't the dot give you that information?)

Are there others that I need to add to this list?So, maybe Thursday comes early this week :D

Great summary!

Are there others that I need to add to this list?

Movement bar would be nice too.

BUG Unit Plot Items Required

Updated file. City screen up now works. Did you always get the hovers containing unit information when the city screen was up (hover over a unit in your city)?


unit button (done)
selected unit yellow highlight (done)
other player units in non enabled mode (done)
Promo Frame (done)
Dot information (done)
Upgrade arrow (done)
Mission (done)
Health Bar (done)
Hide Health bar if in battle (not sure)
White arrows if more than x units (x changes with resolution) (outstanding)
Number of units per row changes with resolution (done)
City screen up (done)
Normal unit actions (issue orders, upgrade, promote, group, degroup, etc) (done)
movement bar (really? Doesn't the dot give you that information?)

BUG Unit Plot Items Required

Updated file. City screen up now works. Did you always get the hovers containing unit information when the city screen was up (hover over a unit in your city)?

Downloaded and merged your attachment. I'm going to implement local subversion so I can better answer questions like this regarding mouseovers of units in the city screen. My answer right now is: I don't remember either. My personal preference is: I never use mouseover info (or the plot list for that matter) when in the city screen, but I'm sure others do.



Health Bar (done)


I can't get health bars to show up at all with the BUG layout activated. I tried numerous combinations of options in the plot list tab of the BUG options screen to no avail.

Somewhat off-topic: Eventually, you may want to rethink the plot list options tab of the BUG options screen. This goes back to my question earlier about the PLE style option. It's not clear at all what options are affected by activating the PLE style. Is it only the placement of the health/movement bars?

I'm working off your Jan 13, 2010, 10:18 PM drop. Unless you branch in subversion, I guess we're stuck referring to releases by attachment post on these forums.

responses ... I checked vanilla BtS and it does have a hover in city screen up mode.
Health Bar - hmmn - I have one bar there - at the bottom of the unit icon ... isn't that the health bar?
the option tab will be completely redone (later) to make it clear what is in both, what is in PLE and what is in BUG

See attached screenshot. No bars of any kind. I'd include an options screenie as well, but as I said, I tried many combinations. Our configurations must be different somehow. Can you branch off a dev SVN for this so I can copy down your entire customAssets? If that's too much trouble, how about a ZIP of your folder?

I tried a clean BUG build 2092 with your Jan 13, 2010, 10:18 PM changes and had the same result.

I've branched on our web based SVN (https://civ4bull.svn.sourceforge.net/svnroot/civ4bug/branches/PLE). Do you have read access to that? I don't know if it creates a daily download. Have to ask EF about that.

I just discovered the branch an hour ago by looking at some other posts. Somehow I missed it previously, one too many mouse clicks I guess.

In any event, I synced with the PLE branch revision 2087 (which BTW has a different version of BugUnitPlot.py than the ZIP you posted earlier), and am still missing all bars on the plots.

I feel like we're still in revision hell. Perhaps there's more file(s) I need that aren't under revision control on your system.

I haven't pushed my latest file to the SVN - I'll do that. However, be away that I am playing with the white arrows and they don't work at the moment.

I just cracked open a game to grab a screen shot ... only to find that I don't have any bars either. I do have dots, missions, promoframe and stuff. Guess I will need to look at my code.

BUG Unit Plot Items Required

See the SVN for the latest version (https://civ4bull.svn.sourceforge.net...g/branches/PLE). Note that the unit scroll white arrows are NOT WORKING.

Update as of Revision 2094

unit button (done)
selected unit yellow highlight (done)
other player units in non enabled mode (not tested yet)
Promo Frame (done)
Dot information (done)
Upgrade arrow (done)
Mission (done)
Health Bar (outstanding)
Hide Health bar if in battle (not sure)
White arrows if more than x units (x changes with resolution) (under development)
Number of units per row changes with resolution (done)
City screen up (done) - but the white arrows are broken
Normal unit actions (issue orders, upgrade, promote, group, degroup, etc) (done)
movement bar (outstanding)

BUG Unit Plot Items Required

See the SVN for the latest version (https://civ4bull.svn.sourceforge.net...g/branches/PLE). Note that the unit scroll white arrows are NOT WORKING.

Update as of Revision 2095

unit button (done)
selected unit yellow highlight (done)
other player units in non enabled mode (not tested yet)
Promo Frame (done)
Dot information (done)
Upgrade arrow (done)
Mission (done)
Health Bar (done)
Hide Health bar if in battle (done)
White arrows if more than x units (x changes with resolution) (under development)
Number of units per row changes with resolution (done)
City screen up (done) - but the white arrows are broken
Normal unit actions (issue orders, upgrade, promote, group, degroup, etc) (done)
movement bar (outstanding)


I added the health bar. Note that the health bar color will only be Green if the unit is at full health. If it is between 67% and full health, the color should be Light Green (no more hunting for that 1 unit that isn't full health). I haven't tested this as I don't have any injured units - hopefully you can tell the difference between Green and Light Green.

The speed improvement is definitely noticeable. I no longer cringe when clicking on large stacks. :goodjob:

I guess I'll keep a running list of issues:

1. Promotions appear behind the unit graphics. The attached Calvary example is no big deal, but other units cut off half the promotions. Switching back to vanilla mode corrected the problem as expected.
2. Plot list leaks through on the spaceship completion screen. (I'll try to check if that always happened. It's not a big deal since the popups in the upper right corner do the same thing).
3. CTRL and ALT clicks deselect the current unit if it was already selected. If I have an infantry selected (with yellow outline) and CTRL click on it, I'd expect to see all the infantry in the stack selected. That happens, except the Infantry I CTRL clicked on is now deselected. Similar erroneous behavior with ALT clicks. After more tinkering I think the unit is selected (as far as the game is concerned) but the yellow outline disappears.
4. Possible enhancement: ALT click on ground units select all ground units, not air units. This behavior has been around since vanilla civ4.
5. Possible enhancement: It would be nice if the right-click movement indicator actually displayed how far a stack can move over railroads. See the last two screenshots below.
6. Hiding the interface (via ALT+I) doesn't hide the plot list. May be related to the issue of the plot list not disappearing on its own if you switch back to Vanilla or PLE mode. A screen refresh via ALT+TAB is necessary otherwise the BUG plot list turns into a ghost.

This is all per revision 2094. I see that you posted revision 2095, so I'll give that a whirl next (I really was missing my health bar :sad:).

1. I didn't touch (I think) that but I will have a look
2. Oops - good catch
3. Hmm - I'll take a look but not to sure what I can do there
4. Noted
5. Isn't that built in? I will try and look at it if I can. I am planning on folding in the route highlight code
6. I'll take a look.

1. I didn't touch (I think) that but I will have a look
Well when you switch back to vanilla it works fine, so something's different with the BUG PLE regarding this. Becomes a bit of a problem in the later game.
3. Hmm - I'll take a look but not to sure what I can do there
As my add-on note says, it's just a matter of the yellow highlight behavior. The yellow highlight shouldn't disappear if I was holding ALT or CTRL and clicked on the unit.
5. Isn't that built in? I will try and look at it if I can. I am planning on folding in the route highlight code
If you look at my two last screenshots in the previous post you'll see that the right-click-hold movement indicator (that is built in to the game) is incorrect. It shows that stack of units as having run out of movement points much sooner than what actually happens. If you crunch the algorithm to make the route highlight code work, it should be the same basic principle to apply to this.


New additions:
7. Great general star dot non-functional.
8. Plot list should hide when fully zoomed out (in world view).

I'm not ready to call it an issue yet, but I noticed enemies' health bars do not display when I have a unit in the same plot. They show up as greyed out, but with no health bars. The health bars do display with the vanilla version, but I'm torn how useful it was.

Just to give a quick update. I've played quite extensively and haven't found anything more past the 8 issues that are pending, two of which are just enhancement requests. The most annoying to play with (IMHO) are the yellow highlight behavior and missing great general star dot.

I've been trying to nail down the yellow highlight behavior to better describe it. There are two cases that I see.

a. The first is when a group of units is selected and you click on a single unit within that group (already highlighted). That single unit is now the only one active as confirmed by the lower left window. The yellow highlight is gone, however, and the plot list looks like nothing is selected. If you give an order that one unit responds as expected.

b. The second I already brought up. CTRL or ALT clicking on an already active unit removes the yellow highlight. The unit really is still selected, however.

Conclusion: The unit selection behavior is fine. The correct units are always selected, but the yellow highlight becomes out of sync with what units really are active.

I haven't been able to look at this this week. I'll review your 8 issues and post some suggestions / comments / additional code.

Are you ok with grabbing stuff from the SVN branch for this?

No rush. :) I think you're almost there since I can't find much else wrong. :goodjob: Your work is definitely worth it though. The speed differences and associated smooth game-play are rather noticeable.

PLE branch access is fine. I've been working off rev 2095.

BUG Unit Plot Items Required

See the SVN for the latest version (https://civ4bull.svn.sourceforge.net...g/branches/PLE). Note that the unit scroll white arrows are NOT WORKING.

Update as of Revision 2095

unit button (done)
selected unit yellow highlight (done)
other player units in non enabled mode (not tested yet)
Promo Frame (done)
Dot information (done)
Upgrade arrow (done)
Mission (done)
Health Bar (done)
Hide Health bar if in battle (done)
White arrows if more than x units (x changes with resolution) (under development)
Number of units per row changes with resolution (done)
City screen up (done) - but the white arrows are broken
Normal unit actions (issue orders, upgrade, promote, group, degroup, etc) (done)
movement bar (outstanding)


Reported Issues

Promotions appear behind the unit graphics. The attached Calvary example is no big deal, but other units cut off half the promotions. Switching back to vanilla mode corrected the problem as expected
Plot list leaks through on the spaceship completion screen. (I'll try to check if that always happened. It's not a big deal since the popups in the upper right corner do the same thing)
CTRL and ALT clicks deselect the current unit if it was already selected. If I have an infantry selected (with yellow outline) and CTRL click on it, I'd expect to see all the infantry in the stack selected. That happens, except the Infantry I CTRL clicked on is now deselected. Similar erroneous behavior with ALT clicks. After more tinkering I think the unit is selected (as far as the game is concerned) but the yellow outline disappears
Possible enhancement: ALT click on ground units select all ground units, not air units. This behavior has been around since vanilla civ4
Possible enhancement: It would be nice if the right-click movement indicator actually displayed how far a stack can move over railroads. See the last two screenshots below
Hiding the interface (via ALT+I) doesn't hide the plot list. May be related to the issue of the plot list not disappearing on its own if you switch back to Vanilla or PLE mode. A screen refresh via ALT+TAB is necessary otherwise the BUG plot list turns into a ghost.
Great general star dot non-functional
Plot list should hide when fully zoomed out (in world view).


I've changed your reported issues to A, B, C, etc so that they don't clash with my list of required items.

BUG Unit Plot Items Required

See the SVN for the latest version (https://civ4bull.svn.sourceforge.net...g/branches/PLE). Note that the unit scroll white arrows are NOT WORKING.

Update as of Revision 2103

unit button (done)
selected unit yellow highlight (done)
other player units in non enabled mode (not tested yet)
Promo Frame (done)
Dot information (done)
Upgrade arrow (done)
Mission (done)
Health Bar (done)
Hide Health bar if in battle (done)
White arrows if more than x units (x changes with resolution) (under development)
Number of units per row changes with resolution (done)
City screen up (done) - but the white arrows are broken
Normal unit actions (issue orders, upgrade, promote, group, degroup, etc) (done)
movement bar (outstanding)


Reported Issues

Promotions appear behind the unit graphics. The attached Calvary example is no big deal, but other units cut off half the promotions. Switching back to vanilla mode corrected the problem as expected
(fixed in 2103) Plot list leaks through on the spaceship completion screen. (I'll try to check if that always happened. It's not a big deal since the popups in the upper right corner do the same thing)
CTRL and ALT clicks deselect the current unit if it was already selected. If I have an infantry selected (with yellow outline) and CTRL click on it, I'd expect to see all the infantry in the stack selected. That happens, except the Infantry I CTRL clicked on is now deselected. Similar erroneous behavior with ALT clicks. After more tinkering I think the unit is selected (as far as the game is concerned) but the yellow outline disappears
Possible enhancement: ALT click on ground units select all ground units, not air units. This behavior has been around since vanilla civ4
Possible enhancement: It would be nice if the right-click movement indicator actually displayed how far a stack can move over railroads. See the last two screenshots below
(fixed in 2103) Hiding the interface (via ALT+I) doesn't hide the plot list. May be related to the issue of the plot list not disappearing on its own if you switch back to Vanilla or PLE mode. A screen refresh via ALT+TAB is necessary otherwise the BUG plot list turns into a ghost
(fixed in 2103) Great general star dot non-functional
(fixed in 2103) Plot list should hide when fully zoomed out (in world view)


Revision 2103 fixes B, F, G and H. I can reproduce A and C but I currently have no idea what is causing that behaviour. Note that A is fixed if you promote the unit. Must be something to do with the order of the panel draw.

Fixes for B, F & H look good.

Issue G remains in rev 2103. There still is no great general dot.

This is annoying. I have G working and then not working and then working and not working again. Stupid star!

Edit: It works if you change the underlying python file and the alt-tab back into the game. Civ reloads the python. Guess I need to change where the game saves the GG promotion.

BUG Unit Plot Items Required

See the SVN for the latest version (https://civ4bull.svn.sourceforge.net...g/branches/PLE). Note that the unit scroll white arrows are NOT WORKING.

Update as of Revision 2106

unit button (done)
selected unit yellow highlight (done)
other player units in non enabled mode (not tested yet)
Promo Frame (done)
Dot information (done)
Upgrade arrow (done)
Mission (done)
Health Bar (done)
Hide Health bar if in battle (done)
White arrows if more than x units (x changes with resolution) (under development)
Number of units per row changes with resolution (done)
City screen up (done) - but the white arrows are broken
Normal unit actions (issue orders, upgrade, promote, group, degroup, etc) (done)
movement bar (outstanding)
ALT click to only select units of similar zone (all air, all ground, etc) (outstanding)
12Monkey's movement plot display (outstanding)


Reported Issues

(fixed in 2106) Promotions appear behind the unit graphics. The attached Calvary example is no big deal, but other units cut off half the promotions. Switching back to vanilla mode corrected the problem as expected
(fixed in 2103) Plot list leaks through on the spaceship completion screen. (I'll try to check if that always happened. It's not a big deal since the popups in the upper right corner do the same thing)
CTRL and ALT clicks deselect the current unit if it was already selected. If I have an infantry selected (with yellow outline) and CTRL click on it, I'd expect to see all the infantry in the stack selected. That happens, except the Infantry I CTRL clicked on is now deselected. Similar erroneous behavior with ALT clicks. After more tinkering I think the unit is selected (as far as the game is concerned) but the yellow outline disappears
Possible enhancement: ALT click on ground units select all ground units, not air units. This behavior has been around since vanilla civ4
Possible enhancement: It would be nice if the right-click movement indicator actually displayed how far a stack can move over railroads. See the last two screenshots below
(fixed in 2103) Hiding the interface (via ALT+I) doesn't hide the plot list. May be related to the issue of the plot list not disappearing on its own if you switch back to Vanilla or PLE mode. A screen refresh via ALT+TAB is necessary otherwise the BUG plot list turns into a ghost
(fixed for real in 2106) Great general star dot non-functional
(fixed in 2103) Plot list should hide when fully zoomed out (in world view)


Revision 2106 fixes A and G (this time when the game first loads :D)

Nevermind.

Some items loaded by XML files are not available when the Python modules are initially loaded. This causes getInfoTypeForString() to return -1 for PROMOTION_LEADER. This is exactly why I created the <init> element in the configuration XML files.


GG_PROMO = None

...

def init():
global GG_PROMO
GG_PROMO = gc.getInfoTypeForString("PROMOTION_LEADER")

BUG Unit Plot Items Required

See the SVN for the latest version (https://civ4bull.svn.sourceforge.net...g/branches/PLE). Note that the unit scroll white arrows are NOT WORKING.

Update as of Revision 2108

unit button (done)
selected unit yellow highlight (done)
other player units in non enabled mode (not tested yet)
Promo Frame (done)
Dot information (done)
Upgrade arrow (done)
Mission (done)
Health Bar (done)
Hide Health bar if in battle (done)
White arrows if more than x units (x changes with resolution) (under development)
Number of units per row changes with resolution (done)
City screen up (done) - but the white arrows are broken
Normal unit actions (issue orders, upgrade, promote, group, degroup, etc) (done)
movement bar (outstanding)
ALT click to only select units of similar zone (all air, all ground, etc) (outstanding)
12Monkey's movement plot display (outstanding)


Reported Issues

(fixed in 2108) Promotions appear behind the unit graphics. The attached Calvary example is no big deal, but other units cut off half the promotions. Switching back to vanilla mode corrected the problem as expected
(fixed in 2103) Plot list leaks through on the spaceship completion screen. (I'll try to check if that always happened. It's not a big deal since the popups in the upper right corner do the same thing)
(fixed in 2103) CTRL and ALT clicks deselect the current unit if it was already selected. If I have an infantry selected (with yellow outline) and CTRL click on it, I'd expect to see all the infantry in the stack selected. That happens, except the Infantry I CTRL clicked on is now deselected. Similar erroneous behavior with ALT clicks. After more tinkering I think the unit is selected (as far as the game is concerned) but the yellow outline disappears
Possible enhancement: ALT click on ground units select all ground units, not air units. This behavior has been around since vanilla civ4
Possible enhancement: It would be nice if the right-click movement indicator actually displayed how far a stack can move over railroads. See the last two screenshots below
(fixed in 2103) Hiding the interface (via ALT+I) doesn't hide the plot list. May be related to the issue of the plot list not disappearing on its own if you switch back to Vanilla or PLE mode. A screen refresh via ALT+TAB is necessary otherwise the BUG plot list turns into a ghost
(fixed for real in 2106) Great general star dot non-functional
(fixed in 2103) Plot list should hide when fully zoomed out (in world view)
(fixed in 2108) Non current players units are missing their health bars


Revision 2108 fixes C and I. C was funny ... I wasn't updating the unit plot because nothing had changed (unit, owner, is selected). However, the unit icon is actually a check box and so the mouse click was deselecting it. I've changed to force update the yellow box for all icons - this will slow it down a little, but not much we can do about it.

I wasn't updating the unit plot because nothing had changed (unit, owner, is selected). However, the unit icon is actually a check box and so the mouse click was deselecting it. I've changed to force update the yellow box for all icons - this will slow it down a little, but not much we can do about it.

Try force updating it only if it is the head selected unit (CyInterface().getHeadSelectedUnit() or something like that). This should be the unit that was actually clicked.

Rev 2108, issue C:

Still some odd behavior to report on the yellow outline. The first screenshot below shows the first plot I clicked on when loading a save - one unit selected, no yellow outline. Second screenshot shows the same on another stack.

There's additional quirks: Have any unit somewhere selected. Hold ALT and click a different plot / stack. All of the units will be selected in the left-bottom window, but the yellow outlines don't match.

Both problems are intermittent, and only really reproducible when loading a save. It seems to straighten out while playing, but as soon as you open/close BTS, the yellow outlines become out of sync again.

ALT clicking directly on the little unit icons when the plot is already active seems to be straightened out as do the keyboard shortcuts for ALT and CTRL selecting.

Rev 2108, issue I:

Third screenshot shows two problems - yellow outline around a foreign unit, and missing health bars on foreign units.

Rev 2108, issue C:
Rev 2108, issue I:Hereby designated ...
Issue J - Quirky highlight behaviour, especially when loading game
Issue K - yellow highlight for foreign units
Issue L - Missing health bars for foreign units

Have you been trying to make the PLE faster ruff_hi?

Have you been trying to make the PLE faster ruff_hi?Did you read any of the last few pages? Read posts 169, 156 and 158.

The short answer is YES. The longer answer is that I hate PLE and would quiet happily see it die. We are writing a BUG version of the unit plot code that is quick, provides vanilla features (bare minimum) and PLE features (if we can).

Did you read any of the last few pages? Read posts 169, 156 and 158.

The short answer is YES. The longer answer is that I hate PLE and would quiet happily see it die. We are writing a BUG version of the unit plot code that is quick, provides vanilla features (bare minimum) and PLE features (if we can).Very good!:goodjob: I hate PLE to.;)

Some more clarification on issue J (still rev 2108):

I'm going to say the problem is not so intermittent and not really tied to loading saves. "Refreshing" the stacks (by selecting all units thus synchronizing the yellow highlights with what's actually selected) seems to only fix the problem for a couple turns. Clicking on more stacks during normal gameplay still results in the yellow highlights being all over the place.

Not sure if you want to break this one off issue J, but city screen yellow highlights are off as well. They'll be phantom yellow highlights present on the city screen, and then selecting something to build will result in them disappearing. All the while, nothing is really selected.

Another example along similar lines is when I had an archer tied to unit group 1. Pressing 1 on the keyboard selects the archer (with yellow highlight correctly drawn) but another unit gets a yellow highlight as well (which is a phantom). Ordering the archer to skip a turn results in the yellow highlight disappearing from both, which is incorrect since the archer is still active.

All in all, I'm going to say that rev 2106 was in better shape. While rev 2108 specifically addresses issue C, I think it created more problems.

Sorry I haven't progressed this much lately - RL study / work / relationships / dog walks (not in priority order :lol:) have to take precedence over civ.

I've been thinking about the PLE filters (show only air units, show only healthy units, etc) and I think that we can still do this to some degree while maintaining the generic civ4 selection process. I was thinking that we could do one of the following:

grey out any unit that doesn't pass the filter (similar to a an AIs unit)
completely leave the slot for a unit that doesn't pass the filter blank
pulse (similar to suggested worker actions) units that do pass the filter
remove the unit icon but put a light green box there (the same as the promo frame) for units that don't pass the filter

Alt and Ctrl-click wouldn't be filtered so you could still pick up units that you are trying to filter ... but you could use hunt and click.

grey out any unit that doesn't pass the filter (similar to a an AIs unit)

I really like this option. It will be easy to spot when you have a filtered unit selected so you can remove it if you want. In fact, we could add a new button that removes filtered units from the selection list. Hmm, if that works, we could even have an option that does this every time after you select units (I think).

Sorry I haven't progressed this much lately - RL study / work / relationships / dog walks (not in priority order :lol:) have to precedence over civ.

I'bve been thinking about the PLE filters (show only air units, show only healthy units, etc) and I think that we can still do this to some degree while maintaining the generic civ4 selection process. I was thinking that we could do one of the following:

grey out any unit that doesn't pass the filter (similar to a an AIs unit)
completely leave the slot for a unit that doesn't pass the filter blank
pulse (similar to suggested worker actions) units that do pass the filter
remove the unit icon but put a light green box there (the same as the promo frame) for units that don't pass the filter

Alt and Ctrl-click wouldn't be filtered so you could still pick up units that you are trying to filter ... but you could use hunt and click.

I guess this comes down to personal preference. I never use the PLE filters (except in the beginning with 12monkeys on original Civ4), and I think we have a similar dislike for it. That said, I'm trying to look at this objectively:

There's nothing really wrong with this idea, but I think your time could be better spent. Personally, I don't think it's necessary, but I'll continue to help you test it if you go in this direction. I think it's already painfully obvious which units are air/naval/land by the grouping already present in your current design, as it was in the unaltered plot list of BTS.

The colored dots further illustrate who's wounded and you even have health bars to show how badly. Plus you have CTRL+H that came with BTS to instantly highlight wounded units. A quick regrouping, and it's very simple to invert the selection and move out the units who aren't wounded to continue the advance.

Foreign units are already grayed out. I'm not sure why I would ever want to show foreign units by themselves on the plot. Even if I did, they're already grouped and greyed separately.

The colored dots already show :move: status as they did in BTS.

Promotions are easy to spot, even in large stacks, with the blue outline. Same for the upgrade arrow.

If I ever were to use the filters it would be to quickly select all the units that survived the filters. EX: I want to move all military, full health, ground units to plot X. Your last statement says this functionality would be lacking. If we're going to have to hunt and click anyway, I don't see why the current visual aids aren't just as helpful.

My conclusion: devote your precious time to finishing off the list of issues & required items and call it a day. You achieved what you wanted: a fast plot list with the best qualities of the PLE.

Hey - ab - don't get me wrong. Replicating filters is way, way down the list. Getting a working BUG unit plot is the first goal. I'd be quite happy to say 'on your bike, sunshine' to the filters and the various stacking options found in PLE. If people really want them, use PLE.

BUG Unit Plot Items Required

See the SVN for the latest version (https://civ4bull.svn.sourceforge.net...g/branches/PLE). Note that the unit scroll white arrows are NOT WORKING.

Update as of Revision 2166

unit button (done)
selected unit yellow highlight (done)
other player units in non enabled mode (done)
Promo Frame (done)
Dot information (done)
Upgrade arrow (done)
Mission (done)
Health Bar (done)
Hide Health bar if in battle (done)
White arrows if more than x units (x changes with resolution) (under development)
Number of units per row changes with resolution (done)
City screen up (done) - but the white arrows are broken
Normal unit actions (issue orders, upgrade, promote, group, degroup, etc) (done)
movement bar (outstanding)
ALT click to only select units of similar zone (all air, all ground, etc) (outstanding)
12Monkey's movement plot display (outstanding)


Reported Issues

(fixed in 2108) Promotions appear behind the unit graphics. The attached Calvary example is no big deal, but other units cut off half the promotions. Switching back to vanilla mode corrected the problem as expected
(fixed in 2103) Plot list leaks through on the spaceship completion screen. (I'll try to check if that always happened. It's not a big deal since the popups in the upper right corner do the same thing)
(fixed in 2103) CTRL and ALT clicks deselect the current unit if it was already selected. If I have an infantry selected (with yellow outline) and CTRL click on it, I'd expect to see all the infantry in the stack selected. That happens, except the Infantry I CTRL clicked on is now deselected. Similar erroneous behavior with ALT clicks. After more tinkering I think the unit is selected (as far as the game is concerned) but the yellow outline disappears
Possible enhancement: ALT click on ground units select all ground units, not air units. This behavior has been around since vanilla civ4
Possible enhancement: It would be nice if the right-click movement indicator actually displayed how far a stack can move over railroads. See the last two screenshots below
(fixed in 2103) Hiding the interface (via ALT+I) doesn't hide the plot list. May be related to the issue of the plot list not disappearing on its own if you switch back to Vanilla or PLE mode. A screen refresh via ALT+TAB is necessary otherwise the BUG plot list turns into a ghost
(fixed for real in 2106) Great general star dot non-functional
(fixed in 2103) Plot list should hide when fully zoomed out (in world view)
(fixed in 2108) Non current players units are missing their health bars
(fixed in 2166) Quirky highlight behaviour, especially when loading game
(fixed in 2166) Yellow highlight for foreign units
(fixed in 2166) Missing health bars for foreign units

J. (fixed in 2166) Quirky highlight behaviour, especially when loading game
K. (fixed in 2166) Yellow highlight for foreign units
L. (fixed in 2166) Missing health bars for foreign units


Need to beat it up some more, but initial testing looks good. :goodjob:

good - just need to nut out that silly white arrows when you get tons of units, fix the city screen and we might be good to go for a public release.

BUG Unit Plot Items Required

I spent some time nutting out what Civ does with these white arrows (only happens when you have too many units on the plot to display. Finally figured it out only to work out that my basic approach was a little broken. Luckily, I found a quick shortcut and not (I think) the little white arrows are working on the maininterface. I haven't tried them on the city screen yet. See the SVN for the latest version (https://civ4bull.svn.sourceforge.net...g/branches/PLE).

Update as of Revision 2172

unit button (done)
selected unit yellow highlight (done)
other player units in non enabled mode (done)
Promo Frame (done)
Dot information (done)
Upgrade arrow (done)
Mission (done)
Health Bar (done)
Hide Health bar if in battle (done)
White arrows if more than x units (x changes with resolution) (done)
Number of units per row changes with resolution (done)
City screen up (done) - haven't checked the white arrows but they might work
Normal unit actions (issue orders, upgrade, promote, group, degroup, etc) (done)
movement bar (outstanding)
ALT click to only select units of similar zone (all air, all ground, etc) (outstanding)
12Monkey's movement plot display (outstanding)


Reported Issues

(fixed in 2108) Promotions appear behind the unit graphics. The attached Calvary example is no big deal, but other units cut off half the promotions. Switching back to vanilla mode corrected the problem as expected
(fixed in 2103) Plot list leaks through on the spaceship completion screen. (I'll try to check if that always happened. It's not a big deal since the popups in the upper right corner do the same thing)
(fixed in 2103) CTRL and ALT clicks deselect the current unit if it was already selected. If I have an infantry selected (with yellow outline) and CTRL click on it, I'd expect to see all the infantry in the stack selected. That happens, except the Infantry I CTRL clicked on is now deselected. Similar erroneous behavior with ALT clicks. After more tinkering I think the unit is selected (as far as the game is concerned) but the yellow outline disappears
Possible enhancement: ALT click on ground units select all ground units, not air units. This behavior has been around since vanilla civ4
Possible enhancement: It would be nice if the right-click movement indicator actually displayed how far a stack can move over railroads. See the last two screenshots below
(fixed in 2103) Hiding the interface (via ALT+I) doesn't hide the plot list. May be related to the issue of the plot list not disappearing on its own if you switch back to Vanilla or PLE mode. A screen refresh via ALT+TAB is necessary otherwise the BUG plot list turns into a ghost
(fixed for real in 2106) Great general star dot non-functional
(fixed in 2103) Plot list should hide when fully zoomed out (in world view)
(fixed in 2108) Non current players units are missing their health bars
(fixed in 2166) Quirky highlight behaviour, especially when loading game
(fixed in 2166) Yellow highlight for foreign units
(fixed in 2166) Missing health bars for foreign units

PLE / BUG Unit Plot enhancements folded back into branch - r2173

I haven't tried them on the city screen yet.

BUG r2174 (which includes PLE branch r2172): I have no plot list on the city screen. :mischief:

so - guess it is working perfectly then. Oh well - something for me to look at. Does it work for Vanilla and PLE draw methods?

PLE and Vanilla draw methods are okay.
BUG draw method doesn't show on the city screen.

Clicking the city bar is fine from the main view, but opening the city view is a problem.

those links you posted to sourceforge are chopped and don't work.

those links you posted to sourceforge are chopped and don't work.They are also now out of date. We deleted the BUG Unit Plot branch. It got folded back into the trunk.

Clicking the city bar is fine from the main view, but opening the city view is a problem.Are you saying opening the city screen when using BUG draw method results in a crash?

No, the plot list is simply missing, that's all.

Does it show up for you?

Ok - guess I have something still to look at. I also got a report that Ctrl and Alt unit selection isn't working on PLE either.

I also got a report that Ctrl and Alt unit selection isn't working on PLE either.

Looks accurate. CTRL or ALT clicking causes the plot list to disappear when using the PLE draw method. You need to click on a stack once again to make it reappear.

Odd, for me the plot list flashes but the unit selection doesn't change. In any case, it's borked.

Odd, for me the plot list flashes but the unit selection doesn't change. In any case, it's borked.fixed in r2182

BUG draw method doesn't show on the city screen.fixed in r2183

BUG draw method doesn't show on the city screen.

fixed in r2183

I only took a quick look, but r2183 seems to have addressed this.

I don't usually use the white arrows in the city screen, but thought I'd take a couple minutes and play. I have an example in a city screen where if I CTRL click on the right arrow, the units advance by nine just fine. If I then CTRL click the left arrow, the arrows disappear and become unusable.

I'm hoping this is reproducible on your end. I have the save game, but it's tied to a DLL that uses BetterAI and Bull. It will take some time to get together the necessary files I would need to send you in order for you to be able to open the save. If you can't get CTRL clicks with the arrows to foul up on your own, I'll try to work something out with this save.

I have a save with 29 units (my screen holds 28 :)) so I should be able to add a few and see what happens.

Bit of an issue here when unloading transports. I had all the transports active and right clicked on that land square immediately to the right. All the units successfully unloaded, but you can see the plot list got a little mucked up. Clicking something else and then coming back fixed the problem.

I've also noticed some problems with drafting under Nationhood. I take a considerable performance hit, and when entering the city screen where the draft came from, I'll get two copies of the plot list, one right after the other. Again, cycling to something else and coming back seems to fix the problem. This is intermittent, and may have something to do with the currently-active unit being in the plot list that the draft is entering. I haven't been successful in coming up with the cause, I'll keep at it and try to get you more information. Just something you may want to mess around with.

Something else I need to check on. CTRL clicks don't seem to be working with units that are in transports. I always found it annoying to unload your units on land when all your transports are out of movement points (right clicking on land like I did above doesn't work when the transport is out of movement points). Bhruic told me long ago that this wasn't really possible to change, and was a flaw inherent in BTS. So the alternative, if you really want to make landfall that turn, is to manually highlight all the land units and move them onto the adjacent land plot. I would swear I used to just SHIFT-CTRL-click my way through a couple transports' units (which would highlight the bulk) and then just SHIFT-click the unique units. Now you have to start clicking every unit with just SHIFT clicks in order to unload them.

well - at least we are down to situations that are themselves confusing. Do you have a save with transport units involved?

A temporary solution to the transports may be to highlight the transports and click Unload so the units become active. Then ALT + Click the plot to select all units with movement points left and move them to the beachhead.

civ is particularly flakey when it comes to trying to select units with no movement points left ... anyone tried to select a stack of workers that are auto-resting in one of your cities?

I thought that the fix to allow you to issue orders to units with no movement points left was added to the UP, but alas that must not be the case. It would remember the order and issue it the next turn instead of having the unit(s) forget it. I think it's in Pep's New Sentry Actions mod, but I haven't updated to the latest because I rewrote the original and updating is a PITA after a rewrite. I would also like to get the feature that issues orders for new units sent to waypoints.

If only modders would write their stuff for BUG/BULL from the start! :mischief:

well - at least we are down to situations that are themselves confusing. Do you have a save with transport units involved?

I'll go back through the autosaves and check.

A temporary solution to the transports may be to highlight the transports and click Unload so the units become active. Then ALT + Click the plot to select all units with movement points left and move them to the beachhead.

I'll give this a try. I've always wondered why the unload button is available even when the transports are not near land. I understand if the transport is in a city, but otherwise what is the unload button supposed to be accomplishing? Always seemed pretty useless.

I've always wondered why the unload button is available even when the transports are not near land. I understand if the transport is in a city, but otherwise what is the unload button supposed to be accomplishing?

Ferrying. I think they may have changed this along the way, and I never cared to MM this hard, but you used to be able to ferry units across great distances using multiple transports in one turn. Or I'm thinking of a different game. :crazyeye:

Ferrying. I think they may have changed this along the way, and I never cared to MM this hard, but you used to be able to ferry units across great distances using multiple transports in one turn. Or I'm thinking of a different game. :crazyeye:

Ferrying works in this game. Transferring units from one transport to the other while at sea can be accomplished by simply loading the units onto the new transport, you don't have to unload first. The only use of the unload button (when the transport is the active unit) is when the transport is in a city (perhaps a fort as well).

In any event, there were a couple cases where those SHIFT and ALT clicks weren't working for me. Your idea about using the unload button seems to snap all the transported units out of the problem. Thanks.

I've also noticed some problems with drafting under Nationhood. I take a considerable performance hit, and when entering the city screen where the draft came from, I'll get two copies of the plot list, one right after the other. Again, cycling to something else and coming back seems to fix the problem. This is intermittent, and may have something to do with the currently-active unit being in the plot list that the draft is entering. I haven't been successful in coming up with the cause, I'll keep at it and try to get you more information. Just something you may want to mess around with.

More information on this. I think I was on to something when I was talking about the currently-active unit being in the plot list when a new unit is added. I found this problem extends beyond drafting, since I just started a new game and I'm observing the same behavior when simply building units.

Consider the two screenshots below. In the first, the "#1 archer" was active from the previous turn. A settler was built since the last turn, but you'll notice the settler does not appear in the plot list (but there's three dots by the plot flag). I take a noticeable performance hit during this time as well: graphics/menu are choppy and slow to respond. You'll also notice that the scoreboard hasn't updated for this turn yet (read the worst enemy alerts).

Clicking on a different plot sometimes displays this new plot correctly, and other times shows some garbage (usually copies of the original plot list). Either way, clicking a second time back to the original plot yields the second screenshot. Notice the scoreboard has now updated. The only thing I did between screenshots is click the missionary and then click back to Beijing.

I first observed this behavior in the game when I met De Gaulle. I said we'll have peace but he never showed in the scoreboard. I knew something was wrong since his leaderhead was sluggish as well when we met. Clicking on some different plots snapped the game out of it, and he showed in the scoreboard.

So, I'm going to say that there's an issue when drafted / built units are added to the plot that was active the turn before.

The interface getting choppy means that there is an exception (error) happening repeatedly inside a loop. Please post your PythonErr.log file (or a section of it) so Ruff can take a look.

Clicking on a different plot sometimes displays this new plot correctly, and other times shows some garbage (usually copies of the original plot list).

Attached is the screenshot that chronologically goes in between the two above. This is when I click on the missionary. When I click back to Beijing (which is the second screenshot above) everything is fine.

The interface getting choppy means that there is an exception (error) happening repeatedly inside a loop. Please post your PythonErr.log file (or a section of it) so Ruff can take a look.

It certainly feels like that, it's what I figured.

I only have these files in the <\My Documents\My Games\Beyond the Sword\Logs> folder:

init.log
PythonErr2.log
resmgr.log
xml.log

Did you mean PythonErr2.log?

No, that won't have it. Please look at the Troubleshooting page in my sig. It has instructions for enabling the Python error logging system. You should have the file PythonErr.log (no 2) after that.

I hadn't used the logging in quite some time, thanks for the reminder.

As expected this repeats over and over:

Traceback (most recent call last):

File "CvScreensInterface", line 954, in forceScreenRedraw

File "CvMainInterface", line 1227, in redraw

File "CvMainInterface", line 1687, in updatePlotListButtons

File "CvMainInterface", line 1980, in updatePlotListButtons_BUG

File "BugUnitPlot", line 207, in Draw

IndexError: list index out of range
ERR: Python function forceScreenRedraw failed, module CvScreensInterface

Yeah, looks like the list isn't long enough after the new unit gets added to the plot. A simple solution may be to reset the list and redraw the plot entirely at the start of the player's turn as if the player were selecting the stack for the first time. You'll pay a one-time performance penalty each turn, but the alternative is to update the plot list for all of the unit-based events.

I'll take a look at this. Seems like an error I should be able to reproduce.

Nothing earth-shattering, but I noticed that it doesn't have to be my units adding to the plot. Another civ moved an explorer into a city where the current unit was the active unit. Same thing. Guessing this comes up whenever the unit count on a plot increases between turns.

Guessing this comes up whenever the unit count on a plot increases between turns.

Exactly, and hopefully resetting and redrawing the selected plot in BeginActivePlayerTurn will solve it.

or actually fixing the code that draws the units would work too.

What do you mean "fix code?" I don't understand... isn't all of your code perfect to start with?

OMG! My faith is shattered!

Nuts! I just realized something! Does that mean I have to fix things, too? :p

What do you mean "fix code?" I don't understand... isn't all of your code perfect to start with?You are new here :D so I will waive your lack of understanding and let you in on the secret ... all of my code is broken ... by definition.

# prior unit doesn't exist - just need to draw the new unit
# this is handled below in the '_update*' functions
if (len(self.BupUnits_Prior) != 0
and (iUnit_Prior >= 0
or iUnit_Prior < len(self.BupUnits_Prior))):
BupUnit_Prior = self.BupUnits_Prior[iUnit_Prior]
else:
BupUnit_Prior = None

The red line is the one throwing an error. I thought the if statement above captured out of bound errors. Or is my understanding of python broken too?

Edit: Gees, am I an idiot? Should that 'or' be an 'and'?

Well, my understanding is a little fuzzy at this point, but I think it should be an "and". You want to define a condition between 0 and some number less than len(BupUnits_prior), to make the following line valid. Seems logical that it should be an "and" to evaluate both expressions.

But why listen to me? None of my installers, readme files, or zip files seem to actually work. :lol:

ha - welcome to the blind leading the blind :D

My seeing eye dog reads python. :p

...and Cosmo. :D

fix committed for above r2200

fix committed for above r2200

Fix looks good. :goodjob:

I was playing a SP game over the week end with BUG unit plots on and it went very smoothly. I did manage to recreate the 'mass unload from boats' issue twice - I remembered to save the game just before I unloaded the second time. There is some code in there that 'knows' if a unit plot was used last time and clears it if it isn't used this time - my guess is that this code isn't being reached due to the massive reduction in units in the plot.

some of those PLE options don't apply if you use the Vanilla or BUG draw methods. We probably should update that so that they get greyed out or have that info in the hover.
This would be very helpful. The plot list options screen could use an update to avoid the confusion.
we need to review the UnitPlot option tab. I'm not the best at working with these tabs but I will take a look at it and suggestion a revised grouping.