Problem with CTP loadscreens and Project Q

[Legacy_SuperFly_2000]

                I have a module with Q and CTP in it (not all the CTP tilesets but some of them).

Six (of Project Q) told me to have the CTP resources ABOVE Q but I don't want to loose any of the Q additions to the original tilesets...so I placed CTP under Q instead.

I wonder...can I just move the CTP loadscreens higher up? ...but will then the other loadscreens be borked?

Screenshot of the cc resources list:


http://www.qnwn.net/...ttach=401;image


This was also posted on the Project Q forums.
               
               

               

                     Modifié par SuperFly_2000, 10 septembre 2011 - 12:49 .
                     
                  

            

[Legacy_AndarianTD]

               

SuperFly_2000 wrote...

I have a module with Q and CTP in it (not all the CTP tilesets but some of them).

Six (of Project Q) told me to have the CTP resources ABOVE Q but I don't want to loose any of the Q additions to the original tilesets...so I placed CTP under Q instead.

I wonder...can I just move the CTP loadscreens higher up? ...but will then the other loadscreens be borked?

This is straightforward to determine. Take the loadscreens.2da from each (q_tilesets and ctp_loadscreens), feed them into the Combinulator, and see if there are any conflicts or any lines missing in Q that aren't in CEP. Personally, I have a custom loadscreens.2da that includes module-specific loadscreens, so I just merged the three, put the result in my top hak, and left the haks in my default order (Sanctum, then Q, then CTP, then others).

I just checked it again, and what you'll find is that the two respected each others' 2da lines pretty much to the letter. All the non-matching lines in the Q haks say "CTP Reserved," and the Q entries are all after the end of the ranges used by CTP. With that kind situation, creating a merged 2da should take you about five or ten minutes using the combinulator. Because of it, though, it's definitely a case of "putting one first makes you lose the other." The only way to get both is with a top hak.
               
               

               

                     Modifié par AndarianTD, 10 septembre 2011 - 01:57 .
                     
                  

            

[Legacy_Bannor Bloodfist]

               You should just be able to move the ctp_loadscreens.hak above the q_tilesets.hak and it should work without any merging necessary.  The purpose of having "***" entries in the q loadscreens.2da is to allow you to do just that.  No need to worry about "losing" anything, it should work just fine.  

So, just move the one ctp_loadscreens.hak to be above the project q haks, and it should all work.  But realize that this is called "stacking" and can sometimes not work, depending on how many total files are being loaded etc...
               
               

               
            

[Legacy_AndarianTD]

               

Bannor Bloodfist wrote...

You should just be able to move the ctp_loadscreens.hak above the q_tilesets.hak and it should work without any merging necessary.  The purpose of having "***" entries in the q loadscreens.2da is to allow you to do just that.  No need to worry about "losing" anything, it should work just fine.  

So, just move the one ctp_loadscreens.hak to be above the project q haks, and it should all work.  But realize that this is called "stacking" and can sometimes not work, depending on how many total files are being loaded etc...

CTP's loadscreens.2da only goes up to entry 294 and has no lines after that, while Q's loadscreens.2da goes up to entry 1030. And those latter aren't all "****" entries -- 1019 thru 1030 have legitimate loadscreen entries in them.

So are you saying that if you put two 2DAs in the hak list, that the engine will dynamically "merge" or stack them, so that the unstarred entries in one will override the starred entries the other, regardless of which is first? And that it will treat lines actually missing from the first hak in the same way (i.e., as though they were present and starred)? If so, that is news to me, although not unwelcome.
               
               

               

                     Modifié par AndarianTD, 10 septembre 2011 - 05:19 .
                     
                  

            

[Legacy_Bannor Bloodfist]

               What I am saying is that since the Project q lines related to CTP are *** entries, they are just place holders, so the engine loads the ENTIRE entry from project Q.  Then if it finds a 2da loaded LATER, and the specific lines do not conflict ( a *** entry is NOT a conflict but a place holder) it will fill in the *** entries with the correct data.


It CAN work, but it can also run into issues, it truly depends on how the various lines are entered.  In this case, since the CTP 2da does not go as far down the list as the Project Q entries do, when the Project Q entries are loaded, the 2da is filled all the way to the last entry.  All the CTP entries, being *** are just place holders, when the CTP 2da is loaded, it only touches lines with data in them (it also has *** entries too) and replaces the *** entries for the respective line from Project Q with the real data.

It will NOT help if there are different actual data lines in a given 2da.  IE if line 210 has one complete entry, and the other 2da has a DIFFERENT data line for that same entry, only the last one loaded will work.

Anyway, Project Q and CTP deliberately worked together this way, so that we would not step on each other's respective toes.  This was actually tested a ways back, although no new testing with later Q content has been made, as long as they have not touched the CTP reserved lines, there should be no issue.  When CTP releases it's NEXT loadscreen update, we will be filling in different lines and we will make sure to not step on any Project Q entries or any lines reserved by Project Q.

Anyway, it works, you may still need to be careful, but it does work.  

EDIT:  As to being "dynamic", no, the engine loads each 2da as it finds them.  you CAN overwrite lines with different real data, the engine doesn't care, it only handles reserved lines to allow the "dynamic" bit of loading.  It loads each file, any differences between data and reserved lines, are handled in such a way that if it has REAL data, not a reservation, it will keep that data, the reserved lines are just kept as placeholders.  So, 3 files, each with different data on a given line will not merge, but be overwritten by the last file loaded, BUT if two of those files have that line as reserved, and only one of the files has real data, it will use the real data from the various files.
               
               

               

                     Modifié par Bannor Bloodfist, 10 septembre 2011 - 07:51 .
                     
                  

            

[Legacy_AndarianTD]

               @Bannor: Thanks, I did not know that. It'll make some of my hak merging a bit easier.
               
               

               

                     Modifié par AndarianTD, 10 septembre 2011 - 08:28 .
                     
                  

            

[Legacy_Bannor Bloodfist]

               I have been warned on this in the past, and it bears repeating... this is NOT the best way to handle things.  Sometimes the engine can screw it up.  If you are already using a top hak etc, it is ALWAYS better to have the merged 2da as a single file in that top hak.  Less chance of something not working as expected.

The positive thing about it though, is that it requires less work, IF the 2 different 2da's have respected each other's reserved lines.  The engine will reserve memory space for the largest of however many you load, and take REAL data from any place it finds it.  This includes the Bioware reserved lines found in various Bif's etc.  It CAN get confused though, and trusting such an old merging system can cause issues, although I have never experienced any issues, I was warned about that possibility of an issue by some of the folks in DLA way back when, including former Bioware employees.  But those same folks explained to me how it was designed to work, which is what I explained above.

File one has 253 lines of data, some of the lines have reserved *** entries...is loaded last.
File two has 118 lines of data, filling in some of those reserved *** entries and not touching the 135 lines past it.  The engine STILL reserves the full 253 lines and merges the two.
File 3 has 1024 lines of data, many of which are reserved *** entries, and none of which overwrite the original 253 lines OR the 118 lines from file 2.  Now the engine merges all 3, into a 1024 line table, and fills in every line with valid data from any of the 3 files.  All non-used reserved lines are left as reserved.  (basically wasted space unless those lines are filled in by Bioware resources loaded from bif entries etc...)

Does that help to make it clearer?
               
               

               
            

[Legacy_SuperFly_2000]

               I will try to do as you suggested Bannor...and see where that leads me.

Thanks a lot for the help so far.

Wow...that description there was very elaborate hehe :-P


At the moment I do not have the intention to use my own tophak or doing 2da merging...so I guess I can just test it this way....and hopefully it works fully or at least partly...
               
               

               

                     Modifié par SuperFly_2000, 10 septembre 2011 - 10:23 .