I noticed that depth charge launcher seem to fire at commanders in transports, I included a demo of this happening. Dealing a lot of damage to friendly units.
Sometimes it is difficult to build a depth charge launcher because accidentally dragging it over water will transform it into a torpedo launcher and then when you drag it back over land it transforms into an llt. The positioning of the build-menu relative to the map can make this difficult to avoid.
Apart from that, I'm really enjoying BA with the new engine.
Two small problems
Moderator: Content Developer
Two small problems
- Attachments
-
- depth_charges_fire_at_transport.sdf
- (335.8 KiB) Downloaded 9 times
Re: Two small problems
That widget is so annoying. I'd be happy if the BA team would disable it by default.Ares wrote:Sometimes it is difficult to build a depth charge launcher because accidentally dragging it over water will transform it into a torpedo launcher and then when you drag it back over land it transforms into an llt. The positioning of the build-menu relative to the map can make this difficult to avoid.
- Silentwings
- Posts: 3720
- Joined: 25 Oct 2008, 00:23
Re: Two small problems
That's an engine bug which is already fixed for upcoming 94.0 release.I noticed that depth charge launcher seem to fire at commanders in transports, I included a demo of this happening. Dealing a lot of damage to friendly units.
What is stopping you moving the map? The widget is called 'context build' if you want to disable it :)Sometimes it is difficult to build a depth charge launcher because accidentally dragging it over water will transform it into a torpedo launcher and then when you drag it back over land it transforms into an llt. The positioning of the build-menu relative to the map can make this difficult to avoid.
Re: Two small problems
IMO the problem with 'context build' is, that it does not switch back to the unit I had originally chosen for building. If I can move the mouse between land and water, and the unit switches between the one I chose in the menu and the_other_one, it would be fine.
- Silentwings
- Posts: 3720
- Joined: 25 Oct 2008, 00:23
- Silentwings
- Posts: 3720
- Joined: 25 Oct 2008, 00:23
Re: Two small problems
Dansan, which sequence of units is causing you problems?
I made version of the widget so as it remember its previous unit and goes back to it - but after reading the unit list at the top of the widget I think that BA should only ever be switching between pairs of units and so should never 'start off in the wrong place within a cycle'. Although for other mods it will be an issue. http://imolarpg.dyndns.org/trac/balates ... _build.lua
I made version of the widget so as it remember its previous unit and goes back to it - but after reading the unit list at the top of the widget I think that BA should only ever be switching between pairs of units and so should never 'start off in the wrong place within a cycle'. Although for other mods it will be an issue. http://imolarpg.dyndns.org/trac/balates ... _build.lua
Re: Two small problems
Bad cycle:
deepth charger -> torp -> llt
dragon eye -> sonar -> radar
Optional addidtion:
dt -> nothing (could be shark teeth)
Inconsistent
bot-lab -> ship-lab -> bot lab
veh-lab -> nothing
air-lab -> nothing
---
solar -> tidal -> solar
wind -> nothing
deepth charger -> torp -> llt
dragon eye -> sonar -> radar
Optional addidtion:
dt -> nothing (could be shark teeth)
Inconsistent
bot-lab -> ship-lab -> bot lab
veh-lab -> nothing
air-lab -> nothing
---
solar -> tidal -> solar
wind -> nothing
- Silentwings
- Posts: 3720
- Joined: 25 Oct 2008, 00:23
Re: Two small problems
The first of those bad cycles are not present in the BA-svn version of the widget that I linked too (although it is 7.72). Vbs spotted the issue and removed it, it looks like.
Since I've now written a local version that remembers where it was in the cycle I'll turn the inconsistencies and the 'bad cycles' (which I guess you would call inconsistencies if you used the BA-svn version) into proper cycles.
The reason dt and sharks teeth don't interchange is because they can both be built in shallow water.
Ty for pointing this out :p
Since I've now written a local version that remembers where it was in the cycle I'll turn the inconsistencies and the 'bad cycles' (which I guess you would call inconsistencies if you used the BA-svn version) into proper cycles.
The reason dt and sharks teeth don't interchange is because they can both be built in shallow water.
Ty for pointing this out :p
Re: Two small problems
Nice - thanx for fixing it.
- very_bad_soldier
- Posts: 1397
- Joined: 20 Feb 2007, 01:10
Re: Two small problems
IIRC the problem was just that the widget contained ambigious relations between buildings. I think I fixed (or at least tried) to remove them like 3 months ago, no?
Not sure if its wise to implement a "state" into the widget. It might lead to confusion and not reproducable behvavior (from the view of the player) if the widget changes buildings depending on a previously selected building. It should only switch 1:1 clearly between water and land units IMO.
Not sure if its wise to implement a "state" into the widget. It might lead to confusion and not reproducable behvavior (from the view of the player) if the widget changes buildings depending on a previously selected building. It should only switch 1:1 clearly between water and land units IMO.
- Silentwings
- Posts: 3720
- Joined: 25 Oct 2008, 00:23
Re: Two small problems
I think the 'ambiguous loops' were meant to be cycles (like the mexes or the XTA energy). From reading the code it looks as though the widget was designed to deal with cycles as well as pairs.
My plan was to store whichever unit, on mouse move between water/land, was pre-move selected for building and then, if at some point in the future we move back onto water/land without changing the builder or the selected unit in the meantime, revert back to the stored unit. Can you find any non-reproducible behaviour coming out of that?
My plan was to store whichever unit, on mouse move between water/land, was pre-move selected for building and then, if at some point in the future we move back onto water/land without changing the builder or the selected unit in the meantime, revert back to the stored unit. Can you find any non-reproducible behaviour coming out of that?