Client compile status
Re: Client compile status
'Focus,' 'continuum' and 'function signatures' are good words. I like that. I agree keeping the barriers low is paramount.
Perfect speed is being there.
Re: Client compile status
I'm inclined to agree with a'moaca' that trying to draw some kind of arbitrary fixed boundary around what kinds of change you'll accept at various stages is maybe going to prove a bit counter productive. I think you'd have to consider what each submission claims to do and look at it on it's merits. You could well get something that comes along during "Phase 1" and is clearly a "no-brainer" to include even though it's a bug fix or enhancement.
You could say "at this stage we'd prefer that changes are limited to..." but don't exclude other contributions if there is clear merit in earlier adoption.
You could say "at this stage we'd prefer that changes are limited to..." but don't exclude other contributions if there is clear merit in earlier adoption.
Mac_Fife
OpenUru.org wiki wrangler
OpenUru.org wiki wrangler
Re: Client compile status
Yes, I'm not a fan of zero-tolerance. I'm good with all that.
Perfect speed is being there.
Re: Client compile status
Interesting. I tried to run those outside of the directory, thinking that is what you might have tried, and the installer complained about missing *.cab files. I will put in a note saying to run them from within the directory they reside in, to be safe.rarified wrote:Some requests for clarification on the Wiki instructions. I'll add to these as I go along on my second machine setup (the build system):Still having some trouble linking in PhysX, will document that in a while.
- Build Steps:(1) Add "if installing on Win Server, needs CoreSDK-common*.cab and CoreSDK-x86*.cab files"
- Build Steps:(2) Clarify "from the SDK" with the pathnames. Possibilities include ...\Program Files\Microsoft SDK\Lib or ...\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\Lib. May also note ...\Program Files\ on older versions of windows, and ...\Program Files (x86)\ on newer versions.
_R
I do not believe we need to put path names in, because the installer prints where it is going to put the stuff in the "Select An Installation Location" dialog (and the user can also change it). Maybe we just need to change the instructions to say "get it from where you installed it" ?
I am curious to know what your platform is. I tested the instructions on Windows Vista Ultimate x64, and a'moaca' ran through them on Windows XP, and it built straight away. I have access to MSDN, so would be interested to try using the exact Windows platform you are using.
Last edited by cjkelly1 on Tue Apr 05, 2011 7:54 am, edited 2 times in total.
Re: Client compile status
I know that rarified got an executable built, running and connecting to MOULa tonight. He has a template for automated builds. So although there might be something to document and your questions to answer, things looks good.
Perfect speed is being there.
Re: Client compile status
Hmmm. Curious how that could have happened. The UruLauncher would have downloaded the manifest from Cyan, noticed that the checksums on the files were incorrect, and would have replaced itself and the other executables and DLLs with Cyan's files. Perhaps the file server check was commented out?JWPlatt wrote:I know that rarified got an executable built, running and connecting to MOULa tonight.
On the automated build template, I have to say congratulations!
That is most excellent, indeed!
Re: Client compile status
That's exactly what happened, so it may not be a server-platform issue. I had expanded the SDK on one box, and just copied the two installers (MSI).cjkelly1 wrote:Interesting. I tried to run those outside of the directory, thinking that is what you might have tried, and the installer complained about missing *.cab files. I will put in a note saying to run them from within the directory they reside in, to be safe.
I didn't go through any dialog, although I ran them through the file explorer with double-click, not in a command prompt, so I may have missed output. The problem was I saw several new directories in "Program Files" created, with "SDK" as part of their names, so I wasn't sure which one (or all) needed to be copied. Last night's success happened just by copying the "Microsoft SDK" subdirectories to the CWE area, so I guess that would be the cue.I do not believe we need to put path names in, because the installer prints where it is going to put the stuff in the "Select An Installation Location" dialog (and the user can also change it). Maybe we just need to change the instructions to say "get it from where you installed it" ?
The first time I tried was on Win 7 Professional. Got everything except the final link working which couldn't find NxCharacter.dll for some reason. The real build environment is a Win 2003 R2 server in a VM, and that's were last nights build succeeded.I am curious to know what your platform is. I tested the instructions on Windows Vista Ultimate x64, and a'moaca' ran through them on Windows XP, and it built straight away. I have access to MSDN, so would be interested to try using the exact Windows platform you are using.
_R
One of the OpenUru toolsmiths... a bookbinder.
Re: Client compile status
You know, that's entirely possible; I didn't look. I stopped using the client after the download/patch updates finished without logging in. I'll have to go back after the grand opening and see what if anything was changedcjkelly1 wrote:Hmmm. Curious how that could have happened. The UruLauncher would have downloaded the manifest from Cyan, noticed that the checksums on the files were incorrect, and would have replaced itself and the other executables and DLLs with Cyan's files. Perhaps the file server check was commented out?
_R
One of the OpenUru toolsmiths... a bookbinder.
Re: Client compile status
That you had any download/patch updates to complete means that is exactly what happened. Heh!
Still, you know UruLauncher worked long enough to replace itself.
- a'moaca'
Still, you know UruLauncher worked long enough to replace itself.
- a'moaca'