Community Launcher / Auto-Downloader / Updater Project...

[Legacy_leo_x]

               Weeell... I'll toss in a little dissent, maybe concern would be a better word.  This is no insult to NWNCX, it looks like a wonderful project.  I think for a project this large to succeed it will need some... ruthless, for lack of a better word, commitment to clarity and maybe I'm missing what is meant.

1)  I mentioned this above NWNCX is not currently cross-platform.  Will it ever be? and with the level of features that it can/does/will have on Windows?  With the Steam Linux client going into open beta and Valve announcing their "Steam console" (also built on Linux).  I can imagine a world in which Linux is a much much more popular consumer platform (for games).  A handful of people on my relatively small server use it already.

2) "The Launcher makes the modifications to the engine to enable enhanced services."  Could you elaborate on what the enhanced services are?  Is this what NWNCX already provides, VFX unlocking, etc?  What it does today is pretty much totally orthogonal to a what I've taken 'launcher' to mean. 

3) "It also needs to determine resources needed and construct the environment the engine (server and/or client) runs in".  Is the engine still consuming HAK files at this point?  If by 'environment' you mean some client ResMan, sign me up to use it.  But if it's HAKs slurped together with nwn-lib, I see no reason to either a) do all that in C++ or embed Ruby or c) call back out to a Ruby script/exe.  It would be way simpler to pass command line arguments to NWNCX (maybe add a --dialog TLK switch for overriding the dialog.tlk) which it already passes on to nwmain after everything was downloaded/updated/constructed.  

Edit: I might be looking at this from a different perspective.  I just realized maybe you want to be able to use the client to navigate to a module / saved game / server in a gamespy list (if anyone replaces it) and then have all the 'magic' happen when it's loaded/connected to in game?

That's all I have time to write ATM.
               
               

               

                     Modifié par pope_leo, 20 décembre 2012 - 02:32 .
                     
                  

            

[Legacy_Rolo Kipp]

               <grunting...>

pope_leo wrote...
Weeell... I'll toss in a little dissent, maybe concern would be a better word.  This is no insult to NWNCX, it looks like a wonderful project.  I think for a project this large to succeed it will need some... ruthless, for lack of a better word, commitment to clarity and maybe I'm missing what is meant.

Clarity good! Communication good!

1)  I mentioned this above NWNCX is not currently cross-platform.  Will it ever be? and with the level of features that it can/does/will have on Windows?  With the Steam Linux client going into open beta and Valve announcing their "Steam console" (also built on Linux).  I can imagine a world in which Linux is a much much more popular consumer platform (for games).  A handful of people on my relatively small server use it already.

Just to be clear, NwNCx is the client extender that Vm's been using to hook into the engine and provide client-side enhancements, the repository of which he is copying to github (along with NwNx stuff) for consideration. I.e. it is already something that works in the direction we are going.

I'm much more aware of the windows limitations in NwNx. I didn't realize NwNCx suffered similarly. But even so, it is a base to work from and the primary developer is familiar with ruby/nwn-lib. A big plus to me.

Anyway, that's the justification for my above statement. I think it's a viable candidate for Ascension (reading Steven Erickson :-P )

Ack! Rides here... more later

<...like a caveman in a hurry>
               
               

               
            

[Legacy_Rolo Kipp]

               <erasing...>

pope_leo wrote...
2) "The Launcher makes the modifications to the engine to enable enhanced services."  Could you elaborate on what the enhanced services are?  Is this what NWNCX already provides, VFX unlocking, etc?  What it does today is pretty much totally orthogonal to a what I've taken 'launcher' to mean.

The Launcher, as I envision it, is a wrapper around the legacy engine that:
1) Enables enhanced services (VFX unlocking, skip master server, etc)
2) Loads module (metadata file?) and determines resources needed/missing. Collates resources into runtime environment for module.
3) Launches module on server (or server-client if people insist :-P) and connects client to server (if local, played in SP mode)

What are you picturing for the Launcher and what it needs to do?

3) "It also needs to determine resources needed and construct the environment the engine (server and/or client) runs in".  Is the engine still consuming HAK files at this point?  If by 'environment' you mean some client ResMan, sign me up to use it.  But if it's HAKs slurped together with nwn-lib, I see no reason to either a) do all that in C++ or embed Ruby or c) call back out to a Ruby script/exe.  It would be way simpler to pass command line arguments to NWNCX (maybe add a --dialog TLK switch for overriding the dialog.tlk) which it already passes on to nwmain after everything was downloaded/updated/constructed.  

The mechanics are TBD. I see, at least at the start, sticking with haks. Coarse granularity. 
But I *want* to move toward something like resman. And the reason for choosing the framework early is simply that it makes it easier when we really start getting tricky.

Edit: I might be looking at this from a different perspective.  I just realized maybe you want to be able to use the client to navigate to a module / saved game / server in a gamespy list (if anyone replaces it) and then have all the 'magic' happen when it's loaded/connected to in game?

Specifically, I want it to work as transparently as possible for the player/admin. Double-click on icon. NwN launches with menu. Pick module/server to play on. Launcher enables the environment NwN expects and then launches it.

Different services for clients and servers, btw. But the *Launcher* is *module* oriented and is all about getting the module loaded properly with service enhancements and optimized content (minimal resources).

<...the blackboard in a white cloud>
               
               

               
            

[Legacy_leo_x]

               Well, maybe we are on the same page, at least up to the enhanced services being in the launcher -- and my main issue with that is it isn't cross-platform.  

I was using Launcher in the sense of what I proposed and prototyped in the OP. People could download and use it today probably. It's in Python tho. Here is the process assuming the player had the 'neverrun' launcher prototype installed:

1) Player finds server they want to try.
2) Server has Neverwinter Resource Locator (NRL) -- which is just a JSON file
3) Player dowloads said file.  Double-clicking that file is essentially the sum total of user interface.
4) An example of what the system would generate for my server: here You'd need to look at the links in the OP to get a better idea of what it all meant.
5) They would double click on it. It would recognize that it's never been installed before.  It would fetch whatever resources were needed to login.*  Since most people already have picked a server would download the NRL mainly as a direct connector / updater, they'd probably not have to actually download anything.
6) Everything would be downloaded and installed.
7) Next time the player double-clicks the NRL it phones home (the source field in the JSON file described in the OP) and checks if it has changed.  If not it direct connects you to the server.  If so, it downloads and installs whatever is different and then direct connects you to the server.

The prototype does allow for a few modifications to nwmain.exe in order to facilitate a) server specific dialog.tlk overrides and preloading haks on a hak by hak basis** via nwnpatch.ini.  This is the one place where NWNCX would be nice, but I feel that interfacing with it on the command line level would be nicer than being a plugin.  I.e. in the launcher's configuration there could be a value saying "use_nwncx=1".  Then instead of modifying and running  'nwmain.exe <DIRECT CONNECT STUFF>' it could run 'nwncx.exe <DIRECT CONNECT STUFF> --dialog mydialog.tlk --preload a.hak b.hak ...'

I don't really care if that prototype goes to the dustbin, this is all to explain my perspective after implementing something that covers most of today's use cases (I think).

* On the first use of the launcher it generates sha1's (better than md5 from what I've read) for all modules, haks, tlks you have in your NWN directory.  

** I'm not sure if nwnx_connect/NWNCX is like this, but at first I tried preloading everything and the shutdown time for NWN was atrocious: it jumped to 5-6 seconds which I couldn't handle.
               
               

               

                     Modifié par pope_leo, 20 décembre 2012 - 06:53 .
                     
                  

            

[Legacy_Rolo Kipp]

               <taking notes...>

So moving the enhanced services management to the Package Manager, rather than the Launcher, if I get it right. Basically, splitting NwNCx in two (Enhanced services and runtime environment - i.e. you're still wanting *some* of the NwNCx functionality to get loaded and running, but want to put engine modification (plug-ins, enhancements, etc) in a different section). I don't have a problem with that. Suits me fine, in fact. =)

Other viewpoints? Vm? Baaleos?

sha1? Link? Interested :-)

<...and running from bards>
               
               

               
            

[Legacy_leo_x]

               In that scenario enhanced services like NWNCX and custom clients would just be different resources packages that people could install if they wanted to or if a server needed them to.  Nothing in NWNCX is necessary to cover today's most basic use cases as far as loading server resources and launching servers, so far as I can tell.

sha1 link.  It's what git, etc, use to ensure data in their versioning schemes.
               
               

               

                     Modifié par pope_leo, 20 décembre 2012 - 07:14 .