Wondering.. would it be possible to make the TAI drag-able?

A possible idea about my floating TAI problem.

I have my periscope depth graphic turned off in the upper left. Maybe the TAI isn't sliding over to the left properly because it's taking into account that invisible/removed periscope depth graphic still?

This is a laymen's idea.. probably wrong. :)

Just A heads up on the TAI Map as That is the same way Your trying to anchor it as mine.
You need to select the bottom left corner of the Page Default hud as the anchor point.
Then Offset Y (OFFY) value 50.
That will lock it to that point. :up:

It looks like your TAi is only anchored to the bottom left corner. (You can see that in the 2nd pic)
When you maximise it its getting thrown out of wack due to it getting pushed out by the BottomBar.

Awesome Reaper.. on behalf of TDW.. thank you. :)

that's what is being done already. I can't duplicate his problem though so it's hard to figure out why it's doing what it's doing. I don't 'move' it anytime except for when the depth bar and map tools visibility changes.

EDIT:

what screen res are you using McHub532?

Looking at it again It possibly the Maptools being hidden thats causing the issue.
In the first pic the TAI map is to the right of the original Maptools position.
Because the Maptools are hidden and no longer on screen when you click maximize the maptools is no longer in position to stop the TAI from expanding backwards.

I got around that problem by anchoring the Maptool in the bottom left of the TAI Map (The TAI is then anchored to the position the Maptools were in or the Bottom left of the page) These can be scripted to hide when the TAI in mimimzed.
THis method also frees up some real estate (Just hide the Background of the Maptools for a better look. :up:

gimme a trigger and i can :D

Problem with last beta:

after surfacing, propullsion switch automaticaly to recharge batterys, thats ok... but if i switching manualy to standard propullsion (which is sometimes needed to gain max speed), it switch automaticaly back to recharging ...this occurs also in calm waters :timeout:

There is another problem...

after diving the script is switching to std propullsion, and triggers a not fitting sound after diving, i use a special sound for that via commands.cfg... would be fine, if this could be disabled.

...but let me se if i swap the audio files, so after surfacing, if recharge triggers recharging batterys, i make a sound with commands and noise of starting the diesel engines followed by a recharging batterys command.

...regarding the sample for switching to standard propullsion, i connect a sound for disconnecting the diesel engines from the electric engines, which may also fit after diving.

But this wont help with against the problem above (at current no manual control over recharging or std propullsion while surfaced, even in calm seas).

is there a certain time (in seconds or something) that this switching back to recharge occurs when you manually select std propulsion? I can't say I've had this happen to me yet.

the time delay for water level has to timeout (default is 3 seconds) to avoid unnecessary switching then the time delay for switching to standard propulsion has to time out (default is 15 seconds) before switching to standard propulsion. What are you looking for to be disabled?

I found the problem, i used the "R" key, connected via commands.cfg for "toggle recharging", but using your UI interface is working without the problem. Using a key command was working fine with the version before, delay in current version using a key command is exact 15 seconds. But it isnt a big problem using your UI for switching :)

...let me swap the audio files, so after surfacing, if recharge triggers recharging batterys, i make a sound with commands and noise of starting the diesel engines followed by a recharging batterys command.

...regarding the sample for switching to standard propullsion, i connect a sound for disconnecting the diesel engines from the electric engines, which may also fit after diving.

problem fixed and tested by McHub532.

this is a very good bug report. I was not monitoring the key command for toggle recharing or toggle standard mode. I'll have to update the code to fix this. User should be able to use keyboard (hotkeys) or the UI icons :yep:

One comment about the new delay in switching from recharging to standard but it's entirely detached from TC since it's a "player" delay as opposed to a "game" delay, which can cause excessive delays in game.

So for me, I'll generally cruise around at 128-256x TC, slow down, submerge, cruise for an hour or so listening, then surface and speed up. I'd set the delay time down to 5 seconds.

What happened is I surfaced at 02:07 but my batteries didn't start charging till 02:38, a full half an hour after surfacing. That's a lot of lost recharge time. heh I'm guessing the solution would be to tie the delay into the in-game clock, based on minutes I guess? If that's possible. I know in game radio messages can appear at X time in game, but sometimes are delayed too.

We'll wanna see what kind of effect the new realistic torpedo doors have under TC as well.

Still having the same problem with the ship's journal.

revised 3.0.0.

test.dat

The file seems to save fine. But fails to load in game and the editor says that it's unable to read.