423 réponses à ce sujet

[Estelindis]

MerricksDad wrote...

it seems just that simple.

Simple to outline doesn't necessarily mean easy to do.    The less work there is, the more likely it is to be completed!  But, by all means, if there are enough people willing to give their time to achieve multiple options, why not?

[MerricksDad]

One thing a new modular form would accomplish is that if the old CEP staff does come back, all you do is drop the modules that they can claim and continue on with those that they cannot. The package following original CEP architecture cannot benefit that way if a fight does start.

[meaglyn]

The Amethyst Dragon wrote...

I say, "Fear not!."  I would not take this on (nor instigate it) if it meant making a builder's work unusable.  I myself use CEP 2.4 heavily, and will not break backward compatibility by removing older content or moving around CEP 2da lines.

I'm pretty sure we can't make this compatible with Q unless lines are moved. We'll either have to do it in CEP or Q.

Neither of which will be popular I suspect.

[The Amethyst Dragon]

I would not let a new (standard) CEP version break compatibility with current CEP modules/servers.  A CEP/Q merger hak would do that, but it would be completely optional and up to an individual builder to decide to do that.

I tossed up the idea of CEP/Q merger just because I know a lot of people would love to have the option.

I'm thinking two options, one where conflicts between the two means CEP stuff stays in place and Q stuff gets renumbered/renamed to work around it, and one where Q stuff stays in place and conflicting CEP stuff gets moved around.

Both would be optional, of course, since doing the first (CEP over Q) would mean modules build with Project Q and later adding the CEP would break and have to be repaired with lots of toolset work, and doing the second one (Q over CEP), modules built with CEP and later adding Project Q would have the same situation.

The only way either of those would work for a builder without adding work would be with a brand new module where nothing has been built yet.

When we get an update to CEP out there, perhaps it could be tackled by someone with some time and experience in merging haks.  I'd hold off on even starting work on this option until a newer version of CEP is released.

I can tell you right now that a lot of Q/CEP merging would involve 2da merging and body part sorting (armor/clothing/PC parts).  Right now there are several parts between the two that overlap and conflict...some are the same, others really do conflict.

Very, very tentative CEP 3 (hak) plan.

Modifié par The Amethyst Dragon, 14 janvier 2014 - 03:36 .

[henesua]

Estelindis wrote...

MerricksDad wrote...
it seems just that simple.

Simple to outline doesn't necessarily mean easy to do.    The less work there is, the more likely it is to be completed!  But, by all means, if there are enough people willing to give their time to achieve multiple options, why not?

True.

I also think that we need to limit the number of options we are trying to achieve and focus on simple achievable goals. I propose that since that the immediate needs include improvements to CEP 2 as it currently stands, that those improvements be made.

The CEP 3 project should be structured so that it is made interoperable with other packages out of the box (including CEP 2 as much as that is possible), AND so that it is easy for the team to maintain and update the project. This will take more thought than actual work. A modular approach is a baby step towards making this happen.

Considering all the thought and planning that needs to go into CEP 3, it would be a mistake to rush into it. Much better is to improve upon CEP 2 immediately so as to start making progress and build up steam.

I have other thoughts on this on the WIKI. TAD did a great job of posting a plan there which should be discussed. But again I don't see the purpose in being bogged down by planning CEP 3 when CEP 2 needs attention NOW and any imporvements made to CEP 2 can be brought over to CEP 3. By all means we should work on a CEP 3 plan now, but what I eman to say is that we should not let it stop us from rolling up our sleeves and working.

Modifié par henesua, 14 janvier 2014 - 03:35 .

[MerricksDad]

With a triple purpose library (which I already have in the works), one that works with 2DA, TLK and GFF files all at once (and could be made to edit SET), a PW owner could download a tool to update their module(s) to a new CEP/Q merge. When the toolset is open, your module is uncompiled into a subfolder and allows access to all GFF file format parts within the module, including module-specific unit and item blueprints. Pass the tool a to-do list, and either Q or CEP resrefs could be modified to line up with new TLK offsets. Tile indices could be updated. Without editing anything else in the module, do a save and close and the module is repackaged with your changed files. Reopen and you should see magic take hold. Ive done this with my tileset master program a few years ago (actually that was like 8 years now....I feel old...). Anyway, the only user input the script would need is yes/no is your PW using Q? If not, you should not be running it on your mod. If so, push all TLK refs up 8388563, and update accordingly. All else, refer to to-do list, which would modify offsets for armor, appearance types, tiles, etc. This would be a list managed by new CEP staff, and would only need to be made once and never updated, unless CEP and Q continued making separate updates (which I suspect will happen).

This is of course all hypothetical since I have not yet finished the GFF/TLK/2DA overlord, and I don't see one currently available, especially one that would take external to-do lists.

But imagine the power...

[MerricksDad]

But again I don't see the purpose in being bogged down by planning CEP 3 when CEP 2 needs attention NOW and any imporvements made to CEP 2 can be brought over to CEP 3. By all means we should work on a CEP 3 plan now, but what I eman to say is that we should not let it stop us from rolling up our sleeves and working.

Agreed. Get a CEP update together and use it as a test to see if this is worth the effort. See if a team can actually form, work together, and also put out.

[Pstemarie]

KlatchainCoffee wrote...

Pstemarie wrote...


1. Keep the CEP 2.4 architecture in place so builders don't have to go back and completely redo things. Having to rebuild takes a live PW offline for days or weeks. Downtime means lost players and decreases the chance that any PW will warm up to a new CEP.

What do you mean by 'architecture' in this context? Sounds like something that would preclude the re-configuration into modular many here seem to be favouring.

Basically, yeah. Just because the FEW people here favor it, doesn't mean that such a drastic change would be welcome by other builders that haven't chimed in. If you want to maximize use of CEP3 then you need to keep it backwards compatible. Unfortunately, that caveat chains you to the architecture already in place. Anything new should go in haks that sit on top of the 2.4 structure.

EDIT: I see AD already addressed this so I'm just beating a dead horse here 

Modifié par Pstemarie, 14 janvier 2014 - 04:25 .

[Proleric]

Obviously, there are many complex issues here, which makes it hard to say "yes" or "no" to a schema off-the-cuff. Perhaps we should have a separate session on each proposal, with a view to drawing up a consolidated list of pros, cons and workarounds, which everyone can see, before deciding?

The devil is in the detail, so it might also help to have separate side-conversations on the most tricky topics, such as armour, phenos / animations, tilesets, licensing etc

Modifié par Proleric1, 14 janvier 2014 - 04:34 .

[henesua]

Disagree, Pstemarie, interoperability is the key. CEP 3 can thus be compatible with CEP 2, without requiring it to be fully backwards compatible. This means that it need not be an all or nothing approach but instead users can pick and choose what they use of it.

Each module of CEP 3 in this case would be designed to be self contained and sit on top of CEP 2.

Merick, we need to talk. I was just discussing such a translator with team members.

[MerricksDad]

Do we have a dead horse model yet?

[T0r0]

3 pages + in less than 24 hrs definitely demonstrates that everyone has your back TAD. All fancy words aside/approaches aside, a simple (not so simple) manner to improve current cep would be a good start.
So instead of mutiny, what do you call it when a dragon comes along and takes your hoard ! =)

[MerricksDad]

henesua wrote...
Merick, we need to talk. I was just discussing such a translator with team members.

again, agreed. Thankfully the time when such a program would be needed is likely months away. I plan to continue working on the libraries, or actually the merging of them. I already have a custom GFF editor for when I rebuilt infinity engine from scratch with improvements, so likely I already have that code and just need to bring it up to date. If not, the file specifications are easily available on the vault still.

The TLK structure has already been built in VB2008 and functions like an excel doc with col and row calls. The 2DA library was actually the easiest, especially since file specifications were readily available.

Combine that with all the tileset modding I did in 2006 and adding a SET library would be super simple. I was going to do interface, but what need would we have of an interface when we're just handing it a to-do list.

So basically, its just steps away from being finished. Make CEP3 reality and this could make things super simple.

Once I get a little further along, I'll put this out there as open source for the community and people can convert it to C or something easier to code in and reuse with other languages. Actually I had even started making some JSON libraries to run 2da data, trying to see it it was faster that way, via greasemonkey or something client side.

[MerricksDad]

T0r0 wrote...
So instead of mutiny, what do you call it when a dragon comes along and takes your hoard ! =)

I think we can simply call it "Progress", at least for the allies and underlings of said dragon.

[Pstemarie]

henesua wrote...

Disagree, Pstemarie, interoperability is the key. CEP 3 can thus be compatible with CEP 2, without requiring it to be fully backwards compatible. This means that it need not be an all or nothing approach but instead users can pick and choose what they use of it.

Each module of CEP 3 in this case would be designed to be self contained and sit on top of CEP 2.

Actually, we do agree. I just have the flu and can't articulate right now. YES, make CEP3 self contained and have it sit on top of CEP2. That's basically what I was getting at - DO NOT muck with the CEP2 haks (don't remove stuff from them, don't change their names, etc.). Any changes you make should be contained in the CEP3 arcitechture.

Modifié par Pstemarie, 14 janvier 2014 - 05:12 .

[The Amethyst Dragon]

MerricksDad wrote...

Do we have a dead horse model yet?

I think both CEP and Project Q already have one...and you can ride it.

[Pstemarie]

The Amethyst Dragon wrote...

MerricksDad wrote...

Do we have a dead horse model yet?

I think both CEP and Project Q already have one...and you can ride it.

Yes, the undead horse in CEP is a pre-release version of the undead horse Six and I made for Q and does not contain the final fixes made before it was officially released as part of Q. I have no idea how it got into CEP, but it needs to be replaced with the models from the Q haks.

[3RavensMore]

Is it done yet? 

[meaglyn]

MerricksDad wrote...

Once I get a little further along, I'll put this out there as open source for the community and people can convert it to C or something easier to code in and reuse with other languages. Actually I had even started making some JSON libraries to run 2da data, trying to see it it was faster that way, via greasemonkey or something client side.

Cool. it sounds useful. I was hoping it wasn't Windows only. But it still sounds good.

Elven's ruby tools for gff conversion are very useful for changing things like pc part numbers,
apparances etc, using the filter mechanism. I've used it a lot when merging CEP and Q.

prwo has a neat tool called hakasm  which merges haks from a sort of build file. It's very good a
renumbering PC part modles and such.

Fwiw,  I think the whole CEP thing could be tracked in something like git. Maybe the textures themselves etc
might be in their own archive.  Anything text or easily converted to and from text. Then have some sort of build system so that making the haks in different forms is just essentailly pushing a button (and waiting a while...).

[henesua]

I like how you think, Meaglyn. I second your proposals.

But I do want to point out that you don't need fancy tools for moving models around: simply using command line tools like find and sed and find and rename are all you need (once the MDLs are decompiled).

I love regular expressions.

Pstemarie, glad we are on the same page. When I talk about a modular approach, self-contained and interoperable is what I mean. I particularly dislike the all or nothing approach of CEP 2.

T0r0 wrote...
So instead of mutiny, what do you call it when a dragon comes along and takes your hoard ! =)

Priceless...

Modifié par henesua, 14 janvier 2014 - 05:35 .

[Killmonger]

Wow.
Way to respond guise & grrls!
The journey of a thousand steps has begun.
I am in awe of the technical potential that resides here for Nwn improvements.
Automation of the relevant merger elements would make this project possible sooner than later...
Thanks MerricksDad
Clearly this mutiny has some momentum !

I agree with much of the above. Without changing the (working) CEP24 files some overrides should be examined. Most important is a calculated and transparent approach before any changes (read improvements). It would be good to see the detailed problems of this campaign examined in side threads (aka clothes, phenos, scripts, wishlist etc).

Let us not needlessly duplicate our efforts internally. Those with the skills should be warming up their Gimp/Photoshop/3dMax and workflow process. Those inclined may also wish to consider the new knowledge about multiple plt, tga, and txi files. Beware of the "burn out" factor ! Educate first.
It is our community and it's obvious that a lot of heartfelt joy (and real work) goes with it
Thanks to AD for setting up the first tentative wiki to address this.

A New Hope <sigh>

[meaglyn]

henesua wrote...

I like how you think, Meaglyn. I second your proposals.

But I do want to point out that you don't need fancy tools for moving models around: simply using command line tools like find and sed and find and rename are all you need (once the MDLs are decompiled).

I love regular expressions.

True. I do all my work on linux with mostly command line tools, plus wine for the toolset itself.

That was mostly just an example and (non) pointer to something useful. It does a bit more at once, but comes at a price - only runs on windows. I used it once to remap all the ACAG parts to holes in the CEP 2das to keep from breaking all the existing armor and clothing. Worked well for that.

Btw where is this "team" you mentioned ealrier?  I'm not seeing a lot of discussion yet on the wiki page...

[henesua]

The team I was talking about earlier is the Vives team. Someone joined us from another project and is interested in reusing their work. A translation tool would be useful in converting areas built with one set of content, to work with a different set of content. If by "wiki" you were referring to the Vives WIKI, we have a private wiki behind the scenes. Our public blog is a very limited thing that any one can view.

If you meant the CEP team. I think we're just getting started. I didn't mean to name myself as a team member here though. I don't know how much I can commit. But I will do what I can. I would like to tackle moving all non-essential content (optional overrides etc...) into a CEP team managed facelift for NWN. We should get Zwerk on board with that too.

[meaglyn]

henesua wrote...

If you meant the CEP team. I think we're just getting started. I didn't mean to name myself as a team member here though. I don't know how much I can commit. But I will do what I can. I would like to tackle moving all non-essential content (optional overrides etc...) into a CEP team managed facelift for NWN. We should get Zwerk on board with that too.

Ahh, that makes more sense.. I thought it was early to be talking about a team having being formed here already. Thought maybe I missed something

[henesua]

sorry. i'll try not to speak so casually from here on out. might help with eliminating the confusion above that probably wouldn't have happened if i had clarified the difference between a interoperable setup which is compatible if the user desires it versus a setup that is fully backwards compatible.