Spring RTS Engine

you mean like this ?
http://manoa.flnet.org:79/spring/183.png
be careful with it as I just took the Chili window example file and copied everything quickly, there may be some fancy new bugs

1.83 Alpha 2: fixed cpu hogging during window movement due to creating additional windows without fully deleting the old ones

Wow, that looks awesome! Thanks!

latest version when my last remaining ally died. Also, should be moveable via tweakmode

fixed, but the tweakmode thing I am not familiar with, not sure where to start, it could be a good idea to use it

In the chili window add: tweakdraggable=true

that's.....not going to work, the chili window I create is based on other variables, if the chili window is moved the bars will still be drawn in the location before the window was moved.

unless there is a way to get the new location of the window after it was moved and pass that data to the bars

I'm thinking of adding mod compatibility so that the bars would adjust to the economy, I should find a way to detect the name of the active mod

Manoa wrote:that's.....not going to work, the chili window I create is based on other variables, if the chili window is moved the bars will still be drawn in the location before the window was moved.

unless there is a way to get the new location of the window after it was moved and pass that data to the bars

There is a way. You can use windowname.x and windowname.y. However we are coming to a fork in the road here...

You'd be adding a bunch of annoying redundant code where instead you can add chili's controls directly into the chili window, like progressbars and labels, instead of drawing them all yourself. This would make the widget only work in mods with chili, so we'd have two separate widgets going.

In fact there's already chili crudeplayerlist in zk which would be a great place to place these bars. For games like forb's evolution and zk that is the direction to take. For non chili, you might as well forget the silliness of moving your bar drawings around with a chili window.

thanks, I will try those variables

actually I am not into making the widget only work in mods with chili, I only wanted to add some chili support

first beta version of the 1.83 version, this brings some necessary fixes which I didn't attend for a long time:

• tool tip mess is now fixed, now you can also choose where the tool tips be drawn

• player names can also be placed of your choosing, left or right

• CPU and Ping can now also be displayed

in Beta 2 and newer these updates are also supported in Chili
in Beta 3: fixed bug with first player reporting incorrect CPU %

known bug: may crash the game when using zerver's multithreaded spring with an ATI video card

first release of the 1.84 version:

• display players ping and CPU on the right of the bars

• convert many pairs/ipairs loops into simpler for loops for performance

caveats:
these changes are not yet supported in Chili mode, but hopefully will be in the future
for the moment Ping and CPU cannot be controlled on which side to be displayed, and it does not support the combinement of player names on right and ping and cpu display

second release of 1.84, Alpha 2:

• fixed bug which crashed the plugin in player mode

• fixed bug where there is a space between enemy player teams [player mode]

• fixed missing code for drawing separators between enemy teams

but the caveats are still there xD

This widget seems really resource hungry.

At endgame I had 9 fps with it, and 16 fps without.

Floris wrote:This widget seems really resource hungry.

At endgame I had 9 fps with it, and 16 fps without.

FTL chili or not?

No chili, it was a BA game.
(but I guess this functionality has to be chilified at some point.)
Just for the record: the plain version included in BA has no performance issues.

The code in this widget is terrible, so it's hard to maintain. Maybe it would just be easier to redo the whole thing from scratch?

if it is terrible code, yeah. It might be bloated etc. Just look for the functional bits to replace and then begin rewriting, if your code still is slow maybe you are using the wrong call?

I see it's been improved a lot in the latest version, with someone replacing constant teamlist calls with table values. I had some old version.

But it still uses global mouse coordinate variables instead of using IsAbove() callin. And it adjusts the height back and forth instead of putting the values in a table. Things like that are not good code in my opinion.

But those things are not likely to make is hungry.

How did you profile this widget?

I tested with two pfofiler widgets and they yield different results: There is one profiler that shows all callins, and there is one that shows just the most expensive one (same as gadget profiler).

name = "Profiler",
desc = "Shows the duration of widget callins",
author = "MelTraX",
date = "2007-10-09"

name = "WidgetProfiler",
desc = "",
author = "jK",
version = "2.0",
date = "2007,2008,2009"

For me the profiler that is named just 'Profiler' shows this widget as much more hungry than the other one.

Im sorry, but afther testing the plugin (1.84 A2) I couldn't find the performance leak you describe, even with everything turned on in the options the plugin uses only 175 micro in meltrax profiler (less than 20 micro with everything turned off), and it has no effect at all on the FPS, if this performance leak still exist in this version please say the conditions in which this hapens.

and don't forget that the original purpose of this plugin was to optimize the original BA version, my version should perform significantly faster than the original BA version

I couldn't find where to download the other profiler which shows my plugin as using more resource, I will keep looking

Here is a link to jk:s profiler, in BA:s repo: http://imolarpg.dyndns.org/trac/balates ... ofiler.lua

It uses a lot of fps in the GameFrame callin when nothing special happens, as you can see from this screenshot: