View Single Post
Old 02-19-16, 07:30 AM   #4009
vdr1981
Navy Seal
 
Join Date: May 2010
Location: Србија
Posts: 6,078
Downloads: 581
Uploads: 13


Default

Quote:
Originally Posted by gap View Post
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.
Thank you once again gap for your resourceful answers. 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) and my understanding of those files is limited. I'm going to open a new thread. There's too much traffic here...

Quote:
Originally Posted by gap View Post
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.
I hope I wont be able to confirm your claim. For now it seems that nothing is "blocked" due to hardcode...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...
vdr1981 is offline   Reply With Quote