Originally Posted by Koranis (Post 2382542)

If I remember correctly, there used to be a checkbox in the recognition manual that, once checked, identified manually the target you were seing through the periscope.

Originally Posted by Koranis (Post 2382556)

I'm talking about manual recognition process, not automatic one. In the manual process you had to find the ship you were looking at in the recognition manual, and once you found it you checked the box in the same recognition manual, just under the image of the ship. That turned "unknown ship" into "Victory class freighter" for example.

Originally Posted by Koranis (Post 2382559)

@gap

No, but close! :)

Yes, the filters are there but I'm not talking about those. The checkbox I'm talking about was indeed placed next to the filters, and now it's missing. It was responsible for giving a name to the "unknown ship".

I'm sure I haven't dreamed it! :)

Anyway, now that we can all agree that the checkbox I'm talking about is not there... how do you identify an unknown freighter? How do you make turn into "liberty cargo" for example?

Originally Posted by palmic (Post 2382558)

My style is to measure ship course, distance and speed from 20-40km by hydrophone bearing analysis go find 4 bearings method video at YT if you dont know how.
With this info you dont even need to measure it optically for long distance, just confirm it at ~5km.

Originally Posted by gap (Post 2382499)

Sorry man, I felt I had not got your idea correctly...



No, as long as you use the same granny file with unchanged bone names, there is no need to remap controller IDs. There are still some unsolved problems though:

1 - Most of the times, the name of the main model (within an unit's gr2 file), the name of the gr2 file, and the name of the folder containing the gr2 file, are matched. This is not always true for AI-controlled units, but it is for playable U-boats. If we change model name, we need to remap controller Id's. If we don't, there will be a mismatch between model name and gr2 and/or folder name. Honestly I don't know if such a mismatch can cause any problem, but this is something we should factor in.

2 - Even supposing that the above wasn't an issue, we would have two U-boats sharing the same bone IDs. It would be impossible for the two of them to appear in the same time and location, as they both would be playable U-boats, and the player can only command one U-boat at any given time. Nonetheless, we should consider that controllers are loaded in memory based on their parent IDs. Name and folder location of the binary files where the controllers are stored might play a role as well, but I am not too sure about this last statement. If the above was true, duplicating two units which share the same ID's shouldn't cause any issue until they both spawn in player's area (which, as stated above, is impossible for two playable units), but if on the contrary file name and location are unrelevant, the game would crash as soon as one of the two units is loaded in memory (because of the two sets of controllers clashing with each other). Testing this scenario on AI controlled units is easy: pick an unit, move one of its essential binary files in any folder and rename it to a random name. Set a test mission with the picked unit and run it. If the game crashes it means it couldnt locate the essential controllers, i.e. file name and location are relevant. If not, only IDs matter, and your idea is not viable. Another possible test: duplicate an unit copying its files to a new folder, and change the cfg file of the duplicated unit so that the game will recognize them as two different units. To be sure to put yourself into the worst possible circumstance, change a bit controller settings of the duplicated unit; set a test mission with either of the two units and load it. If the game crashes, then the two sets of controllers are loaded because the have the same parent Ids, no matter their name or folder.

Originally Posted by gap (Post 2382499)

3 - More importantly: how do you "tell" the game that there is a new playable unit that the player can get assigned to? As far as I know, at least in SH5, playable units are hardcoded. :hmmm:

Originally Posted by excel4004 (Post 2382506)

I got the same problem, someone got maybe a solution?

Originally Posted by vdr1981 (Post 2382564)

Thank you once again gap for your resourceful answers.

Originally Posted by vdr1981 (Post 2382564)

Right now I'm optimistic that it is actually possible to create one more playable units from submarine parts which are already implemented into the game, but I am not so sure that I alone will be able to do that. There is just too many files involved (especially upcge and upc files:doh:) and my understanding of those files is limited.

Originally Posted by vdr1981 (Post 2382564)

I hope I wont be able to confirm your claim. For now it seems that nothing is "blocked" due to hardcode...

Originally Posted by vdr1981 (Post 2382564)

My main issue is to set up correctly upc and upcge files. What I'm trying to do is to copy one already existing sub, edit one of them and to convince the game that those are actually two different units trough upcge, upc and cfg files. We'll see...:hmm2:

Originally Posted by GV_Vyga (Post 2382691)

maps

Originally Posted by Koranis (Post 2382561)

Wow, that's interesting. I've never been able to use hydrophone to obtain so much targetting info, I will have to check it.

Also it's interesting that I don't necessarily need to know the type of the ship. I always wondered how they were hitting those ships in conditions of near pitch black....

thanks, mate!

Originally Posted by vdr1981 (Post 2382473)

After a bit more testing I still haven't find bigger reason why U-FlaK shouldn't be added to SH5 as new submarine type, the very first one in SH5? It would be much easier to add new conning tower upgrade to C or C/41, but it would be much better to have it as stand alone unit because from what I know, U-FlaK were quite handicapped in number of torpedoes, range, maneuverability ect ...:hmm2: What do you say gap?:hmm2: