10 réponses à ce sujet

[SuperFly_2000]

Specifically Babylon, Black Desert and Dwarven Halls. I guess theese tilesets have complete minimaps right? Have you tried any of theese tilesets...what do you think about them?

The hak order is:

ctp_common
ctp_loadscreens
ctp_tileset(x)

At least that is what is written on the vault....

[SuperFly_2000]

Oh yes...and also hak order if I would want to put CEP (and project Q) into that...

[Karvon]

If you wanted to merge CTP, CEP and Project Q, you would have to open up any overlapping 2das and merge them into a new one for a top hak for your project, at the bare minimum. You'd then have to see if any individual elements overlapped in the tool kit when you added all the respective haks in. You'd have to examine those and decide which one(s) you preferred and then restack the haks, or copy the preferred elements into the top hak as well.



Karvon

[SuperFly_2000]

Damn....

So...maybe better to make a choice then.

Still the question remains....what hak order to use if I say just use some CTP tilesets and then CEP. Does CTP come first or CEP?

Modifié par SuperFly_2000, 17 février 2011 - 02:46 .

[AndarianTD]

Karvon wrote...

If you wanted to merge CTP, CEP and Project Q, you would have to open up any overlapping 2das and merge them
into a new one for a top hak for your project, at the bare minimum. You'd then have to see if any individual elements overlapped in the tool kit when you added all the respective haks in. You'd have to examine those and decide which one(s) you preferred and then restack the haks, or copy the preferred elements into the top hak as well.

This is precisely what I did in setting up Sanctum 3, except that I also had module-specific CC that had to be integrated into the mix as well. With a few exceptions it's not all that hard, but CEP and Project Q conflict in a number of places and you simply have to deal with that. There's no one way to resolve those conflicts and no way to get around the need to decide what you want to take precedence, or moving things when you want to keep both -- and that's going to vary for each user's specific module development needs.

I found that the worst part of the merge was the phenotypes, since the numbers are hard-coded in the models and the Q phenos badly collide with the CEP and Sanctum phenos. Fortunately I didn't need most of the CEP phenos and could ignore them, and I handled the exceptions by moving them to new ranges. I was already using tailored versions of those to allow visible cloaks when flying, riding and crawling, so it was mainly a very tedious process of editing large numbers of model files (fortunately aided by software) to change the phenotype numbers. CTP presented little integration difficulty that I can remember.

SuperFly_2000 wrote...

Damn....

So...maybe better to make a choice then.

Still the question remains....what hak order to use if I say just use some CTP tilesets and then CEP. Does CTP come first or CEP?

The general approach I took was to try to keep to the Q layout as much as possible and to make CEP and CTP secondary. My hak order was Sanctum, then PQ, then CTP, then CEP. I overrode CEP in preference to other things, and moved CEP content that I wanted or needed to keep to other open ranges. I posted to the Q forums about some of my experiences here if you're interested.

Modifié par AndarianTD, 17 février 2011 - 03:35 .

[SuperFly_2000]

Wait...are you saying that CEP and CTP do not work together without merging also?

[AndarianTD]

SuperFly_2000 wrote...

Wait...are you saying that CEP and CTP do not work together without merging also?

I don't think I remember conflicts between CTP and CEP or CTP and Q, no. As I wrote, "CTP presented little integration difficulty that I can remember." But CTP's doors did need a 2DA merge with some of my Sanctum specific content, and with Goudea's Futuristic City Interior Tileset, which I also use. That's why I said that any attempt to integrate these is going to be driven to a significant extent by your own personal design criteria.

Modifié par AndarianTD, 17 février 2011 - 03:58 .

[Karvon]

SuperFly_2000 wrote...

Wait...are you saying that CEP and CTP do not work together without merging also?

Usually, tile haks have very few, if any conflicts with each other.  The primary one is, as noted above, door 2da merging. Occasionally you may have an odd texture conflict reported, but often that is simply the same texture used in two different haks.

Other possible 2da merges you may have to sometimes consider to get the full benefit of tile haks are loadscreens, sky and placeable 2das.

In the case of CTP, I seem to recall their team did make an effort to pad their 2da's to be CEP compatible, so you may not have any problems at all, if that's true of the tilesets you want to use in combo with CEP.

Karvon

[Bannor Bloodfist]

There was not supposed to be any conflicts between the two teams, and at one point in time that was true. However, when CEP went into 2.1 phase, they changed their opinion and decided to pretty much do what THEY wanted instead of recognizing other groups.

However, as far as I know, there are only about 4 files that need to be checked for in the CEP content.

Areag.ini,  -- This one should be merged with any other version you find in another tileset.hak with the resulting file moved to a toplevel hak.
Loadscreens.2da,  -- This one should be merged with any other version you find in another
tileset.hak with the resulting file moved to a toplevel hak.
Doortypes.2da,  -- This one should be merged with any other version you find in another
tileset.hak with the resulting file moved to a toplevel hak.

Those three files will be found in CTP_Common.hak

Possibly genericdoors.2da and that one only if you choose to utilize the CTP generic doors. That file is only found in the ctp_genericdoors.hak and would have to be merged if necessary.

There should be NO TEXTURE conflicts at all, as CTP renames everything so that they will NOT interfere with anything else you may have in your mods/haks, IE, all CTP textures should have a ctp name, That is one of the reasons that the tilesets have their own texture files included, even when using a renamed Bioware texture, so that no overriding hak will affect CTP tilesets, UNLESS you specifically rename a texture somewhere else to make that change. IE, you CAN override it, but you have to take the specific action.

CTP_Common,
CTP_loadscreens,
CTP_tilesetx

There is ONE exception to that on the vault, and that is the CTPR_DustyDungeon.rar which WILL reskin any Default Bioware Dungeon, and MAY affect other dungeons created by other folks if they kept the original Bioware textures.

CTP offers NO PLACEABLES at all, so there will be no issue with those types of files, nor did we touch/affect any creatures, or npcs or anything other than Tiles, and Doors.

Modifié par Bannor Bloodfist, 17 février 2011 - 09:30 .

[SuperFly_2000]

Thanks for that elaborate answer. What this practically means for me is that if I choose to start building using HAK's or HAK-paks I should concentrate on one of them....

[AndarianTD]

SuperFly_2000 wrote...

Thanks for that elaborate answer. What this practically means for me is that if I choose to start building using HAK's or HAK-paks I should concentrate on one of them....

It really depends on what you want to accomplish and how much time you have to devote to doing the integration. What are you trying to build, and what do you actually need to accomplish it? Maybe I'm different from other builders, but I tend not to approach choosing and integrating CC as a pre-design decision. I tend to choose CC to meet my design goals, rather than tailoring my design goals around what CC I've decided to use.

In my case, Sanctum 3 is a continuation of Sanctum 1 & 2, which used both CEP and CTP, as well as some module specific content. Having a diverse variety of content available is important given the nature of the story. On the other hand, preferentially using high quality content when available was important given my quality goals. That led naturally to trying to retain my existing Sanctum/CEP/CTP design for variety and backward compatibility, but layering Project Q on top of it to improve the series' look and quality when applicable.

That meant putting the Q content ahead of CTP and CEP in the hak list, but it also meant going through every one of the 2DAs used by the existing (Sanctum/CEP/CTP) design and merging them with Q's 2DAs into a new "SanctumQ" top hak. And it meant looking at every 2DA range and, when I found a conflict, deciding which I wanted to retain and which I wanted to discard -- or if I wanted to retain both, which I wanted to move and where I wanted to move it to. That may sound like a daunting task, but it becomes a lot more tractable if you use Excimer's 2DA Combinabulator, which is one of the most useful building tools I'm aware of.

The reason why I keep harping on the "it depends on what you want to accomplish" theme is that I really don't think, if you want both the variety of CEP and the quality of Q, that you can get away from doing that custom integration. And how you do it is going to depend on your design goals, which may make some of it irrelevant and thereby make your life easier. For example, my modules don't need most of CEP's phenotypes; so when these conflicted with the Q phenos, I simply used the latter and didn't move the former. On the other hand, Goudea's crawling pheno and CEP's flying pheno, which are crucial to my modules' design, both collide with the ACP phenos in PQ. So since I'd decided that I wanted to have the option to use the ACP in Sanctum 3+ and I was already using modified versions of the former for visible cloaks, I just moved them. Another builder with different priorities (perhaps those more appropriate to the needs of a PW rather than a delimited SP mod like mine) might have resolved these conflicts differently.

I think that's the moral of the story here. The CEP and Q teams each made independent (and not always compatible) design decisions regarding the content they were going to make available in their systems and how it would work. You can't integrate such divergent systems without similarly taking on the responsibility of making those same kinds of design decisions when they conflict. That many builders just want to use a package in which those decisions have already been made for them, and tailor their building goals to the corresponding design, is understandable, since it saves a lot of effort. But it won't work in this case.

That said: since this is a thread about CTP, it's worth pointing out that from my experience CTP is easily integrated with either Q or CEP. So you don't have to settle on one of them; you can choose CEP/CTP or Q/CTP without much trouble.

Modifié par AndarianTD, 18 février 2011 - 10:12 .