Author Topic: Question about HAKs  (Read 401 times)

Legacy_henesua

  • Hero Member
  • *****
  • Posts: 6519
  • Karma: +0/-0
Question about HAKs
« on: January 27, 2011, 05:27:36 pm »


               I was wondering if the module when loading its haks, just looks for presence or absence of a HAK by name, or if it actually looks more closely at the hak.

I'd like to have server side only haks, a builder set of haks, and a player set of haks, and not  bother with switching them on and off everytime you start working on the module. Does this work?

Could I for example have a placeables hak, that includes more palette options for a builder than for a dm? The hak name stays the same but the contents differ for different players. I'll experiement with this myself when I get to the weekend, but before I pursue was hoping to hear about other's experience.
               
               

               
            

Legacy_Shadooow

  • Hero Member
  • *****
  • Posts: 7698
  • Karma: +0/-0
Question about HAKs
« Reply #1 on: January 27, 2011, 05:41:47 pm »


               yes it does work
               
               

               
            

Legacy_henesua

  • Hero Member
  • *****
  • Posts: 6519
  • Karma: +0/-0
Question about HAKs
« Reply #2 on: January 27, 2011, 05:54:57 pm »


               Great news. That opens up a number of possibilities.
               
               

               
            

Legacy_Lightfoot8

  • Hero Member
  • *****
  • Posts: 4797
  • Karma: +0/-0
Question about HAKs
« Reply #3 on: January 27, 2011, 06:30:58 pm »


               It does not work in the way you are thinking.  



You are correct in the fack that the module will load with no problem when the content different between the server and player haks.  



However if your haks are in place when you save the game with the toolset. The .itp file for the DM palette are  going to get saved in the game file.  the easiest way to then replace the .itp file will be to replace the hak, in your hak folder with the lighter versions, Reopen the game in the toolset, refresh you palettes and resave.    



The DM's palette  does not really care about what is in the hak's  it is already built and in the game as an .itp file for each catagory.   Since it sounds like all you are really trying to do is override the DM palette, It may be eaiser for you to just build the DM Palettes you want then either place them in the override folder for the server,



Then when you want to build all you will have to do is pull the overrides out of the folder.  Just place them back into the folder before you start the server and the DM's will use them instead of the ones used to build the game.
               
               

               
            

Legacy_henesua

  • Hero Member
  • *****
  • Posts: 6519
  • Karma: +0/-0
Question about HAKs
« Reply #4 on: January 27, 2011, 07:06:32 pm »


               Lightfoot - I actually wanted to separate the palette into DM appropriate and Builder appropriate while also limiting the object count in the module. Most static nature placeables for example, are completely unnecessary at runtime, but essential when you are building an area.



The goal is to make it easier for DMs to find what they want during the game, limit blueprints in the mod to what the DM needs or the module dynamically spawns, and to provide a more robust set up for builders.



I'll have to think about what you wrote here, and adjust my strategy accordingly. Maybe do some experimenting.
               
               

               
            

Legacy_Lightfoot8

  • Hero Member
  • *****
  • Posts: 4797
  • Karma: +0/-0
Question about HAKs
« Reply #5 on: January 27, 2011, 08:07:02 pm »


               

henesua wrote...

The goal is to make it easier for DMs to find what they want during the game, limit blueprints in the mod to what the DM needs or the module dynamically spawns, and to provide a more robust set up for builders.

 .


You only need to leave what the DM's need to use on the paette.  When a script creates an object it does not use the palette. The script onl;y need to know the ResRef of the object. As long as that file is in the Resources for the module the game will find it and create it,  It does not have to be on the palette for that to happen.
               
               

               
            

Legacy_henesua

  • Hero Member
  • *****
  • Posts: 6519
  • Karma: +0/-0
Question about HAKs
« Reply #6 on: January 27, 2011, 08:35:20 pm »


               Lightfoot... I'm also talking about pulling the resources themselves from the mod. Its not just a pallet adjustment. I am looking at a system that can handle resources for different situations. In my understanding, once a placeable is placed in an area for example, you no longer need the UTP because its information becomes part of the area file.



Reducing the number of UTP/UTI/UTC is another benefit for large modules. Vives PW for example hit the object limit four years ago, and has limited what can be added to the mod. For everything new, something must be removed.



I've been looking at pulling out unneeded resources into haks. Issuing blank haks to the players, issuing different haks for the server, builders, and dms.
               
               

               
            

Legacy_Lightfoot8

  • Hero Member
  • *****
  • Posts: 4797
  • Karma: +0/-0
Question about HAKs
« Reply #7 on: January 27, 2011, 11:03:40 pm »


               I understand all of that.   You are correct the blueprints are not needed to be in the palette unless you are going to spawn them dynamicly or by a DM.  In fact even if they where in the clients haks, the client would never use them.  The server would still create the item from the resources that it has.  



I also am not arguing about what you are trying to do, Just trying to state a few facts.  So let me start over.



The way I look at this is that there are three different kind of resources for this type of case.  Ones that are loaded by the server, ones that are loaded by the client, then the ones that are loaded by both.  The Tool set will need to have acess to all of them.  The client will only need to have the resources that it loads and the server will only need to have the resources it loads.  Now if there are resources in the haks that only the server uses, It does not matter if they are in the haks for the client or not.  Same with resources that only the client uses, they can or can not be in the haks that the server uses. If they are there the server will simply never use them. The tool set will still need to have all of them for building.



An instance of a BluePrint contains all the information that the blueprint contains pluse additinal infornation such as location and orientation . So once the instance is created the blueprint is no longer needed.



Examples of server only resources would be anything you can save in the .mod file itself. Scripts, BluePrints, .Palettes, Conversations, Areas  are all server only resources.



Examples of client resources would be Models, textures ect.



The only server and client resource i can think of aff the top of my head is the talk table and some of the 2da's



The only point I was trying to make in my first post is the fact the the DM palette is a server side resource.  It is saved into the module by the toolset.  This being the case if you save your module with the full haks intact, The palette will be built and placed in the module in that state.  Swapping you haks out for the lighter haks at this point will not decreese the size of the palette untill you reopen the toolset and rebuild/refresh the palette and resave.



With that being the case you may find it easier to just build the palette into that state you want for you DM one time, Then pull them out of the module/temp0 folder and use them as overrides. It could just save you some time.



The only point of my second post was that the Server only uses the palette to display the DM options.  A BluePrint does not have to be on the Palette inorder for the server to find and use it.
               
               

               
            

Legacy_henesua

  • Hero Member
  • *****
  • Posts: 6519
  • Karma: +0/-0
Question about HAKs
« Reply #8 on: January 27, 2011, 11:30:06 pm »


               

Lightfoot8 wrote...

I understand all of that.   You are correct the blueprints are not needed to be in the palette unless you are going to spawn them dynamicly or by a DM.  In fact even if they where in the clients haks, the client would never use them.  The server would still create the item from the resources that it has.  


The only point of my second post was that the Server only uses the palette to display the DM options.  A BluePrint does not have to be on the Palette inorder for the server to find and use it.


Thanks for explaining at such depth. It sounds like we are on the same page, but I misunderstood your last post.

I'll look into creating overrides for the DMs to issue to them. Cleaning up the palettes for DMs would be a great advantage for them.

Again, thanks for all the explanation, I greatly appreciate it. I'm learning about this stuff for the first time while retrofitting an ancient PW.
               
               

               


                     Modifié par henesua, 27 janvier 2011 - 11:31 .
                     
                  


            

Legacy_Lightfoot8

  • Hero Member
  • *****
  • Posts: 4797
  • Karma: +0/-0
Question about HAKs
« Reply #9 on: January 27, 2011, 11:54:26 pm »


               

henesua wrote...

I'll look into creating overrides for the DMs to issue to them.


No need to distribute it.  The palette is a server side resource.  You can place them in either the override folder for the server or into a hak on the server side only.   Even if you gave the palettes to the DM's to add to there system the DM client would ingnore them and load them from the server.
               
               

               
            

Legacy_henesua

  • Hero Member
  • *****
  • Posts: 6519
  • Karma: +0/-0
Question about HAKs
« Reply #10 on: January 28, 2011, 12:57:14 am »


               Interesting. I did not realize that the override did anything on the server side.