Spring RTS Engine

If you have random bugs with BA then here is something that may help you:

1) After any game, open up infolog.txt, it's in same folder as spring.exe.
2) Look for a section where it has lines like

Failed to load: gui_advplayerslist.lua (duplicate name)
Failed to load: gui_attack_aoe.lua (duplicate name)

3) All of the widgets that are listed like this, look in your \spring\luaui\widgets folder and delete them. These widgets come as inside BA and your local versions are "duplicates" that may be causing bugs.

[The problem: Your local version is loading in place of the BA default - so if your local version is out of date (e.g. designed for an older engine) then it can cause you bugs. If you don't have any lines in infolog.txt like are quoted above then you don't have this problem! If you want the full list of widgets that come as part of BA, which you should not have in your widget folder, look here: http://imolarpg.dyndns.org/trac/balates ... ui/widgets]

Of course, this won't solve every bug and if you still have bugs please make other threads here, with your infologs and so on

This should be stickied somewhere or added to a big "Common bugs" topic which is stickied or something

[f=0000000] Failed to load: gui_defenserange.lua (duplicate name)
[f=0000000] Failed to load: unit_customformations2.lua (duplicate name)
[f=0000000] Failed to load: unit_ghostradar.lua (duplicate name)
[f=0000000] Failed to load: unit_initial_queue.lua (duplicate name)
[f=0000000] Failed to load: unit_smart_area_reclaim.lua (duplicate name)

Also get problems when trying to line bomb with bombers, i issue the order and one by one it chooses to cancel each order individually, have tried re installing etc etc and nothing so far :D if you have managed to work this bug out you would have reinstated my passion for BA.

I imagine there are a lot of people playing with ancient copies of widgets who: won't see this post, won't be able to follow the technical steps, or just think the widget-related bugs they are experiencing are just nuances of the mod/engine.

So a better solution to this would be to change the widget handler so that when there are both user and mod copies of a widget it loads the one with the higher version, rather than always using the users copy.

This would ensure the out-of-date/incompatible user widgets get overridden by up-to-date working copies from the mod, without requiring any interaction/understanding from the user. As well as other benefits.

That would be a good solution. But where do you think should that version come frome? Widgets do not carry a version information in their headers. You can find some that encoded a version string inside their description in an arbitrary format but that will be very unreliable to parse Im afraid.

That might be a good idea.

I actually made this post so as I could just link people to it in future, wasn't expecting anyone to read it.

You could add this to troubleshooting faq http://springrts.com/wiki/FAQ
since in other games you can have the same problem.

imo since some time BA comes with a good enough selection of widgets, for the average player there is not much need to download more.

Widgets do not carry a version information in their headers. You can find some that encoded a version string inside their description in an arbitrary format but that will be very unreliable to parse Im afraid.

Coming up with some standard way for version should not be impossible..
Ofc someone would have to check that it is followed and remove offending widgets from http://widgets.springrts.de/
Though widgetDB is problematic in itself, it makes it easy to download widgets that the mod already has.

knorke wrote: Ofc someone would have to check that it is followed and remove offending widgets from http://widgets.springrts.de/

so this is no good?
https://github.com/gajop/Toolbox/blob/m ... tor.lua#L8

very_bad_soldier wrote:That would be a good solution. But where do you think should that version come frome? Widgets do not carry a version information in their headers. You can find some that encoded a version string inside their description in an arbitrary format but that will be very unreliable to parse Im afraid.

knorke wrote:Ofc someone would have to check that it is followed and remove offending widgets from http://widgets.springrts.de/

It isn't essential that every widget have a parsable version. If there are multiple copies of a widget and the highest-version one can't be determined then you can just fall back to the current system - take the one that was loaded first. (You could also do something more complicated, but it's likely not worth it). If there aren't multiple copies then the version doesn't even need to be looked at.

I see the version-based system being a change from the current "discard any duplicate found" to "allow found duplicates to override the existing if they have a higher* version, otherwise discard".

* widget X would be defined as having a higher version than widget Y iff widget X has a parsable version and either Y doesn't or Y's parsed version is lower.

Last step would be making sure all the widgets that ship with the mod are up to date, and assigning parsable version numbers to any that are missing them**.

** This ensures that mod widgets (which have been updated to the most recent versions) beat any user widget unless the users widget has a parsable version that is higher (i.e. they have a copy of the widget which was updated after the mod was released).

the current system - take the one that was loaded first.

with BAs (default?) widgethandler is it basically "random" which one gets loaded first?

Apart from same different version of widget there is also the problem of conflicting widgets. (simplest example being something like having two overlapping playerlists turned on)

But nowadays it seems most widgets are maintained in the SVNs of their game. Brings the advantage of commit history but every game modifies their stuff in different ways and that can be confusing.
(for example healthbars widget is slightly different in basically all mods that use it. Or chiliUI where it supposedly the zK version is very different from the one on github.)

Either way it quickly gets so complex that players should not have to bother with it.

knorke wrote:Or chiliUI where it supposedly the zK version is very different from the one on github.)

Btw I've done a chili merge from Toolbox's version (probably similar to ZK's) into chili's official version. It's still not 100% as good as it was in Toolbox (some layouts seem off), but it seems better than the official chili (some bugs were fixed, editbox added etc.).

I suggest people either fork my chili version or take jk's one, and send some pull requests there (I'll accept any pull requests to chili and will pass them to jk), so we can work and further improve it (fix bugs, add features, etc.).

F.e I also implemented an edit box (months ago) but it's not that easy to share it when everyone's using their own version. I've also implemented a file open/save dialog, combobox, and so on (just using chili, but not as part of the chili library yet), which could all be a part chili if anyone wanted.

Also from screenshots/games I've seen that people have implemented tab control but I don't see that as part of chili yet.

Imo the only thing you should have in your project's chili version is a different implementation of the skins (that should also be moved outside of chili's dir, but let's leave that part for later...).

Afaik the BA widget handler will always choose user widget over mod widget if there is a conflict.

And yes, once widgets become part of BA they are mostly maintained by mod devs. I completely agree that players should only have to care about widgets if they want to make their own.

Reaper wrote:Also get problems when trying to line bomb with bombers, i issue the order and one by one it chooses to cancel each order individually, have tried re installing etc etc and nothing so far :D if you have managed to work this bug out you would have reinstated my passion for BA.

Known engine bugs fixed for next version. I think a fix for this version would require you to re implement attack commands in lua. http://springrts.com/mantis/view.php?id=3334 http://springrts.com/mantis/view.php?id=3264

At the moment, a bug in spring 91 means that line bombing in BA only partially works (to be precise, it works if you don't try to queue multiple line bombs at once and this is thanks to Google_Frogs hotfix).

In spring 92, which is not released yet, the bug is fixed and line bombing (along with the other stuff affected by this bug) works as it should.

"[unitsync] Error: GetInfoValue: deprecated unitsync function called: GetInfoValue
[unitsync] Error: GetInfoValue: deprecated unitsync function called: GetInfoValue
[unitsync] Error: GetInfoValue: deprecated unitsync function called: GetInfoValue
[unitsync] Error: GetInfoValue: deprecated unitsync function called: GetInfoValue
[unitsync] Error: GetInfoValue: deprecated unitsync function called: GetInfoValue
[unitsync] Error: GetInfoValue: deprecated unitsync function called: GetInfoValue
[unitsync] Error: GetInfoValue: deprecated unitsync function called: GetInfoValue
[unitsync] Error: GetInfoValue: deprecated unitsync function called: GetInfoValue
[unitsync] Error: GetInfoValue: deprecated unitsync function called: GetInfoValue
[unitsync] Error: GetInfoValue: deprecated unitsync function called: GetInfoValue
[unitsync] Error: GetInfoValue: deprecated unitsync function called: GetInfoValue
[unitsync] Error: GetInfoValue: deprecated unitsync function called: GetInfoValue"

anything important???

I did (again) wipe some old widgets from my directory but sadly for me it fixed nothing. Still Dgun-Multifire and bombers behave as before.

Would be cool to have someone who knows for sure which bugs he fixed with this method.

I wiped some doubles after reading the opening post and after that I realised that I was using some widgets that I adjusted a bit myself.. Now i'm stuck with the standard again. Didn't fix any bugs as far as I can see.

Still Dgun-Multifire

Check if your commander is set to Repeat On, if it is then turn it off and that fixes it.

Ares wrote:

Still Dgun-Multifire

Check if your commander is set to Repeat On, if it is then turn it off and that fixes it.

I lol'd

Continuing dgun fire is a known bug though, right? Initially caused by the independent (target while moving) targeting feature.