opentnl-general Mailing List for Torque Network Library (Page 12)
Brought to you by:
mark_frohnmayer,
s_alanet
You can subscribe to this list here.
2004 |
Jan
|
Feb
|
Mar
|
Apr
(39) |
May
(34) |
Jun
(5) |
Jul
(5) |
Aug
(3) |
Sep
|
Oct
(8) |
Nov
|
Dec
(6) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
(2) |
Feb
(8) |
Mar
(18) |
Apr
(6) |
May
(12) |
Jun
|
Jul
|
Aug
(2) |
Sep
(1) |
Oct
(8) |
Nov
(1) |
Dec
|
2006 |
Jan
(5) |
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2007 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2008 |
Jan
(1) |
Feb
|
Mar
(10) |
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
(3) |
2009 |
Jan
(24) |
Feb
(2) |
Mar
(2) |
Apr
(26) |
May
(75) |
Jun
(85) |
Jul
(46) |
Aug
(18) |
Sep
(14) |
Oct
(24) |
Nov
(8) |
Dec
(3) |
2010 |
Jan
(1) |
Feb
(1) |
Mar
(40) |
Apr
(57) |
May
(80) |
Jun
(58) |
Jul
(45) |
Aug
(49) |
Sep
(28) |
Oct
(6) |
Nov
(1) |
Dec
(3) |
2011 |
Jan
|
Feb
|
Mar
(1) |
Apr
(1) |
May
(3) |
Jun
(10) |
Jul
(7) |
Aug
(7) |
Sep
(2) |
Oct
(1) |
Nov
(1) |
Dec
(2) |
2012 |
Jan
(2) |
Feb
|
Mar
|
Apr
(1) |
May
(2) |
Jun
(1) |
Jul
(11) |
Aug
(13) |
Sep
(8) |
Oct
(4) |
Nov
|
Dec
(1) |
2013 |
Jan
(2) |
Feb
|
Mar
(2) |
Apr
(2) |
May
(2) |
Jun
(2) |
Jul
|
Aug
(14) |
Sep
(44) |
Oct
(1) |
Nov
(1) |
Dec
(2) |
2014 |
Jan
(4) |
Feb
(42) |
Mar
(3) |
Apr
(1) |
May
(7) |
Jun
(5) |
Jul
(14) |
Aug
(2) |
Sep
(2) |
Oct
(54) |
Nov
(43) |
Dec
(36) |
2015 |
Jan
(48) |
Feb
(64) |
Mar
(52) |
Apr
(24) |
May
(52) |
Jun
(60) |
Jul
(6) |
Aug
(15) |
Sep
(1) |
Oct
|
Nov
(7) |
Dec
(12) |
2016 |
Jan
(17) |
Feb
(2) |
Mar
(6) |
Apr
|
May
(66) |
Jun
(40) |
Jul
(51) |
Aug
(42) |
Sep
(24) |
Oct
(10) |
Nov
(46) |
Dec
(7) |
2017 |
Jan
(14) |
Feb
(11) |
Mar
(2) |
Apr
(1) |
May
(31) |
Jun
(8) |
Jul
(10) |
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
From: Stephane V. <sv...@fr...> - 2004-04-26 13:39:09
|
Here is an updated configure.in that won't stop if it doesn't detect Open= GL. |
From: Stephane V. <sv...@fr...> - 2004-04-26 04:38:52
|
I had troubles compiling zap under mingw. I had to change the (ALCint*)contextData into (ALint*)contextData in sfx.cpp:218. The game seems to work so I think that could be a fix because not all ope= nal versions define ALCint, but ALint always is. It worked fine under mingw, linux and MacOS X. Stephane |
From: Stephane V. <sv...@fr...> - 2004-04-26 04:17:00
|
Hi, > Your tnlTypes.h fixes look good. One question, are the _HEAP defines=20 > possibly in some mingw header file? If so, it would be better to=20 > include that header file rather then redefine them in TNL. I agree with that, but I haven't found them in any mingw headers. Only in VC++ ones. > detect changes in header files or dependent libraries. I'd love to see= =20 > an automake solution implemented, but I don't have time to work on it=20 > myself at the moment. Would you like to? :) Sure, I may give it a try I have some time I could use for that. Stephane |
From: John Q. <jo...@lo...> - 2004-04-25 18:22:02
|
Your tnlTypes.h fixes look good. One question, are the _HEAP defines possibly in some mingw header file? If so, it would be better to include that header file rather then redefine them in TNL. As far as the Makefiles go, the ones in TNL are quick and dirty and need a lot of work. Aside from configuration, they don't properly detect changes in header files or dependent libraries. I'd love to see an automake solution implemented, but I don't have time to work on it myself at the moment. Would you like to? :) Without autoconf, you could use a scheme similar to torque for setting up the flags for different compilers. Basically the main makefile includes a top level "configuration" makefile that defines the CFLAGS and other settings specific to that compiler. So you would configuration files like conf.GCC.MINGW.mk conf.GCC.LINUX.mk And the appropriate one would be included by the top-level makefile. On Apr 21, 2004, at 9:45 PM, Stephane Vaxelaire wrote: > Hi, > >> Strangely GCC doesn't give this error on either linux or OS X. >> Perhaps >> it's a difference in the cdecl syntax? > > You got the point. In fact for both __CYGWIN__ and __MINGW32__ the > FN_CDECL > constant must be defined to nothing like under Linux for instance. > > There are also some missing constants under mingw32 so I added them > directly > in tnlTypes.h in a test to check if __MINGW32__ is defined. > Now I got everything to compile fine with standard gcc cygwin and with > gcc -mno-cygwin. > For pure cygwin, TNL_OS is defined to linux whereas for mingw it is > defined to > win32. > > Of course, for mingw compile, I had to add "-mno-cygwin" to each > Makefile (or > makefile in libtomcrypt) and I had to add -lwsock32 to the Makefiles > in the > master, masterclient and test subdirectories. > No changes to Makefiles where required for cygwin, just the new > tnlTypes.h. > > Here you will find (attached) my tnlType.h file that I modified from > yesterday's > CVS. > > Could any devel commit this patch if it proves itself to be ok ? > I dunno how to integrate the mingw32 required changes to Makefiles > though.. > I should say I haven't thought about it. Is anyone planning to use a > configure > script ? > > Regards, > > Stephane<tnlTypes.h> |
From: Ben G. <be...@ga...> - 2004-04-23 01:49:55
|
Stephane, It looks like a good fix. Nice work! We'll have to run it past Quigley, our linux build master, so that he can approve it (since MingW/Cygwin both use the same toolchain as linux), so it may take a few days to get feedback. He's currently at the Linux Desktop Summit, and thus incommunicado. :) You will also need to fill out and send to us the form located at <http://www.opentnl.org/agreement.html>. It's a joint copyright assignment; an unfortunate necessity for projects operating under dual licenses. :) If you have any questions feel free to ask (though you might want to do it off-list). Regards, Ben Garney Stephane Vaxelaire wrote: >Hi, > > > >>Strangely GCC doesn't give this error on either linux or OS X. Perhaps >>it's a difference in the cdecl syntax? >> >> > >You got the point. In fact for both __CYGWIN__ and __MINGW32__ the FN_CDECL >constant must be defined to nothing like under Linux for instance. > >There are also some missing constants under mingw32 so I added them directly >in tnlTypes.h in a test to check if __MINGW32__ is defined. >Now I got everything to compile fine with standard gcc cygwin and with >gcc -mno-cygwin. >For pure cygwin, TNL_OS is defined to linux whereas for mingw it is defined to >win32. > >Of course, for mingw compile, I had to add "-mno-cygwin" to each Makefile (or >makefile in libtomcrypt) and I had to add -lwsock32 to the Makefiles in the >master, masterclient and test subdirectories. >No changes to Makefiles where required for cygwin, just the new tnlTypes.h. > >Here you will find (attached) my tnlType.h file that I modified from yesterday's >CVS. > >Could any devel commit this patch if it proves itself to be ok ? >I dunno how to integrate the mingw32 required changes to Makefiles though.. >I should say I haven't thought about it. Is anyone planning to use a configure >script ? > >Regards, > >Stephane > |
From: Saurav M. <sa...@vz...> - 2004-04-22 16:51:49
|
also i vconvertted the casts to Item* and the other class name * mohaps ---- Original message ---- >Date: Thu, 22 Apr 2004 08:40:35 +0200 (MEST) >From: "Markus Nuebel" <nu...@gm...> >Subject: [Opentnl-general] Problems compiling the zap project with VC6 >To: ope...@li... > > >I wasn't able to compile the zap project from the source download (not the >CVS). >There were some missing link references due to the fact, that the files >item.cpp and sfx.cpp are not part of the workspace. > >After adding them to the workspace I got some compile errors, at code >places, where an SFXObject or an Item is being assigned to a RefPtr or a >SafePtr. The compiler complains about: "operator ==' is ambiguous". > >I simple casted the this pointer to the RefPtr or SafePtr, but don't know it >this is correct. >Does a simple cast work or do I have to construct a new Prt object based >upon the this pointer? > >Finally I had to the add the openal32.lib and alut.lib to the linker >directive, to make this whole compile and link. > >Anybody else seen this? >-- Markus > >-- >"Sie haben neue Mails!" - Die GMX Toolbar informiert Sie beim Surfen! >Jetzt aktivieren unter http://www.gmx.net/info > > > >------------------------------------------------------- >This SF.Net email is sponsored by: IBM Linux Tutorials >Free Linux tutorial presented by Daniel Robbins, President and CEO of >GenToo technologies. Learn everything from fundamentals to system >administration.http://ads.osdn.com/? ad_id=1470&alloc_id=3638&op=click >_______________________________________________ >Opentnl-general mailing list >Ope...@li... >https://lists.sourceforge.net/lists/listinfo/opentnl-general In order to understand Recursion, One must first understand Recursion |
From: Saurav M. <sa...@vz...> - 2004-04-22 16:51:23
|
hi, just do add files on all the files in "zap" project and it should compile fine..i think it is also missing the include/lib dir settings for openal.. regards mohaps ---- Original message ---- >Date: Thu, 22 Apr 2004 08:40:35 +0200 (MEST) >From: "Markus Nuebel" <nu...@gm...> >Subject: [Opentnl-general] Problems compiling the zap project with VC6 >To: ope...@li... > > >I wasn't able to compile the zap project from the source download (not the >CVS). >There were some missing link references due to the fact, that the files >item.cpp and sfx.cpp are not part of the workspace. > >After adding them to the workspace I got some compile errors, at code >places, where an SFXObject or an Item is being assigned to a RefPtr or a >SafePtr. The compiler complains about: "operator ==' is ambiguous". > >I simple casted the this pointer to the RefPtr or SafePtr, but don't know it >this is correct. >Does a simple cast work or do I have to construct a new Prt object based >upon the this pointer? > >Finally I had to the add the openal32.lib and alut.lib to the linker >directive, to make this whole compile and link. > >Anybody else seen this? >-- Markus > >-- >"Sie haben neue Mails!" - Die GMX Toolbar informiert Sie beim Surfen! >Jetzt aktivieren unter http://www.gmx.net/info > > > >------------------------------------------------------- >This SF.Net email is sponsored by: IBM Linux Tutorials >Free Linux tutorial presented by Daniel Robbins, President and CEO of >GenToo technologies. Learn everything from fundamentals to system >administration.http://ads.osdn.com/? ad_id=1470&alloc_id=3638&op=click >_______________________________________________ >Opentnl-general mailing list >Ope...@li... >https://lists.sourceforge.net/lists/listinfo/opentnl-general In order to understand Recursion, One must first understand Recursion |
From: Mark F. <ma...@ga...> - 2004-04-22 15:51:10
|
Right now the RPC size is limited to less than the maximum size of a packet, since 1 RPC = 1 RPCEvent. What I'd like to do at some point is have the RPC code break up the packed data into chunks, if the total size is greater than some threshold (say 512 bytes), and then reassemble those chunk events on the remote side. Anthony Green wrote: >On Thu, 2004-04-22 at 01:40, Anthony Green wrote: > > >>I'm using ByteBufferRef args for a remote procedure call. >> >>Does OpenTNL limit the size of these buffers when used as arguments? >> >> > >Ok, poking through the code I see this in tnlBitStream.h: > > /// Writes a ByteBuffer into the stream. The ByteBuffer can be no >larger than 1024 bytes in size. > bool write(const ByteBuffer *theBuffer); > >So.. is there an example somewhere of sending a larger amount of data >using OpenTNL? The RPC mechanism was really convenient :-( > >AG > > > > >------------------------------------------------------- >This SF.Net email is sponsored by: IBM Linux Tutorials >Free Linux tutorial presented by Daniel Robbins, President and CEO of >GenToo technologies. Learn everything from fundamentals to system >administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click >_______________________________________________ >Opentnl-general mailing list >Ope...@li... >https://lists.sourceforge.net/lists/listinfo/opentnl-general > > |
From: Anthony G. <gr...@sp...> - 2004-04-22 15:12:36
|
On Thu, 2004-04-22 at 01:40, Anthony Green wrote: > I'm using ByteBufferRef args for a remote procedure call. > > Does OpenTNL limit the size of these buffers when used as arguments? Ok, poking through the code I see this in tnlBitStream.h: /// Writes a ByteBuffer into the stream. The ByteBuffer can be no larger than 1024 bytes in size. bool write(const ByteBuffer *theBuffer); So.. is there an example somewhere of sending a larger amount of data using OpenTNL? The RPC mechanism was really convenient :-( AG |
From: Anthony G. <gr...@sp...> - 2004-04-22 08:40:58
|
I'm using ByteBufferRef args for a remote procedure call. Does OpenTNL limit the size of these buffers when used as arguments? For instance, I've doing four calls with buffer sizes 6935, 336, 114 and 2904024. Only the 336 and 114 byte buffers appear to make it through the RPC. Thanks, AG |
From: Ben G. <be...@ga...> - 2004-04-22 07:56:46
|
Markus, We recently ran across the operator error, and I believe a fix is in CVS. I'll make sure we update the VC6 project in CVS to build properly. :) Most of our developers work in VC7.1 or with the GCC toolchain, so our VC6 project isn't touched as often. Sorry about the inconvenience. Our next source archive should be significantly improved; we've done a lot of development in the last few days. Regards, Ben Garney Markus Nuebel wrote: >I wasn't able to compile the zap project from the source download (not the >CVS). >There were some missing link references due to the fact, that the files >item.cpp and sfx.cpp are not part of the workspace. > >After adding them to the workspace I got some compile errors, at code >places, where an SFXObject or an Item is being assigned to a RefPtr or a >SafePtr. The compiler complains about: "operator ==' is ambiguous". > >I simple casted the this pointer to the RefPtr or SafePtr, but don't know it >this is correct. >Does a simple cast work or do I have to construct a new Prt object based >upon the this pointer? > >Finally I had to the add the openal32.lib and alut.lib to the linker >directive, to make this whole compile and link. > >Anybody else seen this? >-- Markus > > > |
From: Markus N. <nu...@gm...> - 2004-04-22 07:12:07
|
I wasn't able to compile the zap project from the source download (not the CVS). There were some missing link references due to the fact, that the files item.cpp and sfx.cpp are not part of the workspace. After adding them to the workspace I got some compile errors, at code places, where an SFXObject or an Item is being assigned to a RefPtr or a SafePtr. The compiler complains about: "operator ==' is ambiguous". I simple casted the this pointer to the RefPtr or SafePtr, but don't know it this is correct. Does a simple cast work or do I have to construct a new Prt object based upon the this pointer? Finally I had to the add the openal32.lib and alut.lib to the linker directive, to make this whole compile and link. Anybody else seen this? -- Markus -- "Sie haben neue Mails!" - Die GMX Toolbar informiert Sie beim Surfen! Jetzt aktivieren unter http://www.gmx.net/info |
From: Stephane V. <sv...@fr...> - 2004-04-22 04:52:46
|
Hi, > Strangely GCC doesn't give this error on either linux or OS X. Perhaps= =20 > it's a difference in the cdecl syntax? You got the point. In fact for both __CYGWIN__ and __MINGW32__ the FN_CDE= CL constant must be defined to nothing like under Linux for instance. There are also some missing constants under mingw32 so I added them direc= tly in tnlTypes.h in a test to check if __MINGW32__ is defined. Now I got everything to compile fine with standard gcc cygwin and with gcc -mno-cygwin. For pure cygwin, TNL_OS is defined to linux whereas for mingw it is defin= ed to win32. Of course, for mingw compile, I had to add "-mno-cygwin" to each Makefile= (or makefile in libtomcrypt) and I had to add -lwsock32 to the Makefiles in t= he master, masterclient and test subdirectories. No changes to Makefiles where required for cygwin, just the new tnlTypes.= h. Here you will find (attached) my tnlType.h file that I modified from yest= erday's CVS. Could any devel commit this patch if it proves itself to be ok ? I dunno how to integrate the mingw32 required changes to Makefiles though= .. I should say I haven't thought about it. Is anyone planning to use a conf= igure script ? Regards, Stephane |
From: Ben G. <be...@ga...> - 2004-04-21 18:12:16
|
Jarrod Roberson wrote: > > Ok what I get from this is - confusion still . . . :-) > > ignoring the console code issue for right now . . . > > This is what I get from the above and Ben's response also . . . > > non-OpenTNL code contributions will require the contributor to assign > dual license rights to GG, thats fine. > Are you going to require the same dual license for contributions to > the official OpenTNL code base? Yes. That's the whole point of the joint copy right stuff - is to keep the source code legally "ours", so that people can use it for things. Open source projects all have similar issues, which is why things like the Apache Software Foundation exist - as an entity to which to assign copyright for Apache source, as much as anything else. > > So the assumptions are these > > that the OpenTNL code base and the "commercial/indie" licensed code > base will always be the same ( not counting the console code ) Yes. Console code will probably live in its own space (assuming that the licenses are such we can't put the console-specific parts up for public download) but all will be kept in synch. > that the commercial and indie license fees will just allow you to NOT > have to ship your own personal code with your product, since the GPL > includes > any code that is statically or dynamically linked in, anything that > uses OpenTNL has to be GPL also. Yes. > > Just to clarify, I fully intend on buying the indie license ( this is > really what I wanted when I bought Torque :-) ) . . . but I want to > work with the OpenTNL stuff until I get a full understanding of how it > all works. So this is more for clarification than anything, since it > is kind of a moot point once I buy the license correct? Yes. Ben |
From: Jarrod R. <ja...@ve...> - 2004-04-21 17:59:35
|
Mark Frohnmayer wrote: > The official TNL project at www.opentnl.org will be the same code base > as the indie/commercial licensed code. The only code that isn't a > part of that codebase is the console platform code which will be > seperately licensable from GG. > > As far as GPL issues go - we will only be accepting contributions to > the official TNL codebase from people who have submitted a joint > copyright assignment form, which we will have available soon. This > will allow us to continue licensing the TNL codebase under indie and > commercial licenses while at the same time protecting the rights of > the people who submit the code. > > - Mark > Ok what I get from this is - confusion still . . . :-) ignoring the console code issue for right now . . . This is what I get from the above and Ben's response also . . . non-OpenTNL code contributions will require the contributor to assign dual license rights to GG, thats fine. Are you going to require the same dual license for contributions to the official OpenTNL code base? So the assumptions are these that the OpenTNL code base and the "commercial/indie" licensed code base will always be the same ( not counting the console code ) that the commercial and indie license fees will just allow you to NOT have to ship your own personal code with your product, since the GPL includes any code that is statically or dynamically linked in, anything that uses OpenTNL has to be GPL also. Just to clarify, I fully intend on buying the indie license ( this is really what I wanted when I bought Torque :-) ) . . . but I want to work with the OpenTNL stuff until I get a full understanding of how it all works. So this is more for clarification than anything, since it is kind of a moot point once I buy the license correct? |
From: Ben G. <be...@ga...> - 2004-04-21 17:58:19
|
But this is TNL, not Torque. ;) Brenden T. wrote: > > Whoah, seriously? I assumed that Torque did support MinGW. Mea > culpa, sorry to bother you all. I'll switch to VC++. > |
From: Mark F. <ma...@ga...> - 2004-04-21 17:57:11
|
We'd be happy to support MinGW - we just don't right now (since it doesn't compile the RPC stuff)... but then, this is an Open Source project... ;) - Mark Brenden T. wrote: > Mark Frohnmayer wrote: > >> Yeah, that error is why MinGW isn't on the supported compilers list >> for Win32 :) >> > Whoah, seriously? I assumed that Torque did support MinGW. Mea > culpa, sorry to bother you all. I'll switch to VC++. > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Opentnl-general mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opentnl-general |
From: Mark F. <ma...@ga...> - 2004-04-21 17:55:33
|
Hi all, Welcome to the TNL project! Yesterday was a long day - but it sure feels good to tell the world what we're working on and to have TNL in ship shape. Over the course of the next few weeks we'll be adding more documentation to the existing codebase (mainly to the Zap example), as well as turning Zap into a more complete game. We'll also be laying out a roadmap for where TNL is going and some possible interesting side projects that people who are interested can work on. From a high-level perspective, this is what we've got planned... the next major piece to go into TNL will be a full type reflection library to be used in conjunction with RPC and NetObject ghosting. This should in theory make these functions much easier to extend to new purposes. Once the typing system is in place we'll be working on a backend server framework for a more complete community system than what the master server currently provides, as well as a sample cross-platform client. Some ideas beyond that include a new language designed specifically to make high performance secure network programming much easier, a full peer to peer information distribution system, multi-server MMP backend code and more... In any case, expect to see more news and fun stuff on the TNL front as we go forward - it should be all kinds of fun! - Mark |
From: Brenden T. <br...@rc...> - 2004-04-21 17:51:57
|
Mark Frohnmayer wrote: > Yeah, that error is why MinGW isn't on the supported compilers list > for Win32 :) > Whoah, seriously? I assumed that Torque did support MinGW. Mea culpa, sorry to bother you all. I'll switch to VC++. |
From: David W. <op...@gn...> - 2004-04-21 17:32:14
|
Anthony, I'm seeing the same results under Win98SE and WinXP SP1, release build. As every time we run the client it opens a new connection, activates the RPC and then closes the connection, perhaps we're just seeing the anti-spam code in action? I guess a good test would be to deactivate all server-side protection schemes and run the client again... - Dave http://www.gnometech.com From: "Anthony Green" <gr...@sp...> > On Wed, 2004-04-21 at 07:03, Saurav Mohapatra wrote: > > hi, > > > > as per the > > page :http://opentnl.sourceforge.net/doxydocs/simpletutorial.h > > tml > > Yes, but my point is that the _client_ does not exit. I run it a couple > of times, and the "Hello??" message gets through and I get a response. > When I run it a third time - nothing. The client just hangs. If I > CTRL-C the client, wait a bit and try again, it may work once or twice > until it decides to hang once more. > > AG |
From: Mark F. <ma...@ga...> - 2004-04-21 17:26:29
|
Yeah, that error is why MinGW isn't on the supported compilers list for Win32 :) Strangely GCC doesn't give this error on either linux or OS X. Perhaps it's a difference in the cdecl syntax? - Mark Brenden T. wrote: > Congratulations on the release of OpenTNL, now fix my bugs :-b > > Compiled with MinGW 3.3.3, MSYS umm, looks like 1.09 but I've got > binutils 2.14 for it. > > ghostConnection.cpp|746| error: syntax error before `)' token > || ghostConnection.cpp: In constructor ` > || > TNL::RPC_GhostConnection_rpcGhostAlwaysStarting::RPC_GhostConnection_rpcGhostAlwaysStarting() > > || ': > ghostConnection.cpp|746| error: `mFuncPtr' undeclared (first use this > function) > ghostConnection.cpp|746| error: (Each undeclared identifier is > reported only > || once for each function it appears in.) > || ghostConnection.cpp: At global scope: > ghostConnection.cpp|759| error: syntax error before `)' token > ghostConnection.cpp|772| error: syntax error before `)' token > ghostConnection.cpp|796| error: syntax error before `)' token > || make[1]: *** [ghostConnection.o] Error 1 > || make[1]: Leaving directory `/d/Documents and > Settings/Brenden/Desktop/Dev/Open TNL/src/opentnl-src-1.0/tnl' > || make: *** [default] Error 2 > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Opentnl-general mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opentnl-general |
From: Mark F. <ma...@ga...> - 2004-04-21 17:24:37
|
The official TNL project at www.opentnl.org will be the same code base as the indie/commercial licensed code. The only code that isn't a part of that codebase is the console platform code which will be seperately licensable from GG. As far as GPL issues go - we will only be accepting contributions to the official TNL codebase from people who have submitted a joint copyright assignment form, which we will have available soon. This will allow us to continue licensing the TNL codebase under indie and commercial licenses while at the same time protecting the rights of the people who submit the code. - Mark Jarrod Roberson wrote: > Thomas Hentschel Lund wrote: > >> First congratulations to GG for releasing TNL. >> >> Oh, and while we are at it - will the indie/commercial license >> feature features that are not in the GPL one? Or will future >> enhancement in that end also be GPL'ed? >> >> /Thomas > > > I would expect the codebases to diverge pretty quickly depending on > popularity as anything added by the "community" will be GPL and would > not be able to be put back into the non-GPL code base. Like wise any > non-GPL code can't be added to the GPL version. Interbase/Firebird is > a good example of this divergence. > > This divergency has happened with lots of dual licensed source code > bases. > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Opentnl-general mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opentnl-general |
From: Brenden T. <br...@rc...> - 2004-04-21 17:19:42
|
Ben Garney wrote: > Interesting. Do you know what version of GCC you're using? > > Ben > > Brenden T. wrote: > >> Congratulations on the release of OpenTNL, now fix my bugs :-b >> >> Compiled with MinGW 3.3.3, MSYS umm, looks like 1.09 but I've got >> binutils 2.14 for it. >> gcc 3.3.3 |
From: Mark F. <ma...@ga...> - 2004-04-21 17:19:31
|
What's going on here is actually a problem we should address soon. The server requires clients joining in to solve a client puzzle before they're allowed to connect. Part of this involves the client sending a random nonce to the server - except that since the simple example never seeds the random number generator, it always sends the same nonce value. The server rejects duplicate client nonces for security reasons. If the client detects a rejected nonce, it will attempt to connect one more time with a new random nonce - so basically the first two clients get in and noone else will until the server resets its nonce tables (every 30 seconds). Check out clientPuzzleManager.cpp for more details... So basically the solution to the problem is to seed the random number generator with good random data at program startup. We might want to end up with a Platform:: function to get random data from the OS. - Mark Anthony Green wrote: >On Wed, 2004-04-21 at 07:03, Saurav Mohapatra wrote: > > >>hi, >> >>as per the >>page :http://opentnl.sourceforge.net/doxydocs/simpletutorial.h >>tml >> >> > >Yes, but my point is that the _client_ does not exit. I run it a couple >of times, and the "Hello??" message gets through and I get a response. >When I run it a third time - nothing. The client just hangs. If I >CTRL-C the client, wait a bit and try again, it may work once or twice >until it decides to hang once more. > >AG > > > > >------------------------------------------------------- >This SF.Net email is sponsored by: IBM Linux Tutorials >Free Linux tutorial presented by Daniel Robbins, President and CEO of >GenToo technologies. Learn everything from fundamentals to system >administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click >_______________________________________________ >Opentnl-general mailing list >Ope...@li... >https://lists.sourceforge.net/lists/listinfo/opentnl-general > > |
From: Ben G. <be...@ga...> - 2004-04-21 17:12:47
|
Interesting. Do you know what version of GCC you're using? Ben Brenden T. wrote: > Congratulations on the release of OpenTNL, now fix my bugs :-b > > Compiled with MinGW 3.3.3, MSYS umm, looks like 1.09 but I've got > binutils 2.14 for it. > > ghostConnection.cpp|746| error: syntax error before `)' token > || ghostConnection.cpp: In constructor ` > || > TNL::RPC_GhostConnection_rpcGhostAlwaysStarting::RPC_GhostConnection_rpcGhostAlwaysStarting() > > || ': > ghostConnection.cpp|746| error: `mFuncPtr' undeclared (first use this > function) > ghostConnection.cpp|746| error: (Each undeclared identifier is > reported only > || once for each function it appears in.) > || ghostConnection.cpp: At global scope: > ghostConnection.cpp|759| error: syntax error before `)' token > ghostConnection.cpp|772| error: syntax error before `)' token > ghostConnection.cpp|796| error: syntax error before `)' token > || make[1]: *** [ghostConnection.o] Error 1 > || make[1]: Leaving directory `/d/Documents and > Settings/Brenden/Desktop/Dev/Open TNL/src/opentnl-src-1.0/tnl' > || make: *** [default] Error 2 > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Opentnl-general mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opentnl-general > > |