1
General / Re: Three Word Story [[Game]]
« on: May 08, 2008, 02:03:02 pm »
taken with cinnamon
 |
 |
News:
Forums live again! After five years of being offline, the forums are back! Come for the nostalgia, stay for the awesome!
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
2
General Discussion / Re: DON'T JUST SIT THERE!!! GET TO THE THEATER NOW!!!
« on: May 08, 2008, 01:50:20 pm »
I saw it during the day on Monday. Seriously, go see it. See it once, see it twice, whatever. It's awesome.
3
General Discussion / Re: Back...
« on: May 30, 2007, 12:00:15 pm »Kansas, here we come!
Ha ha!
No. Nadda, no way in hell.
Not going back to live near my parents.
4
General Discussion / Re: Back...
« on: May 29, 2007, 04:46:12 pm »
Aye, marriage is a wonderful thing, but also it can be fragile. I'm out of pithy statements other than that. 'Course that may be because of my current situation of on the road to divorce, so take things I say with a grain of salt. Anyway, I'm starting to hit the back thing as well. I wouldn't say life has calmed down quite yet for me, but I'm done moving into my own place now, so now I have to get my life back in order and figure out where the heck I want to go.
5
Bug Reports / Re: Rev 1154 , runtime segfault
« on: May 03, 2007, 05:16:55 am »
Sorry, life's been alot crazy for me recently, I probably won't be caught up with anything until June or so.
6
Bug Reports / Re: Rev 1154 , runtime segfault
« on: April 19, 2007, 07:42:02 pm »
I'll try to look into this as well when I get back to work (but I may not have time until Saturday).
7
Bug Reports / Re: More compile problems
« on: March 27, 2007, 02:24:00 pm »
Is that the latest CEL? I think we had problems similar to that earlier and fixed it by updating CEL. I'll be able to test on it this weekend though, currently away from home.
--Rosencrantz
--Rosencrantz
8
Precursors / Ship Interiors?
« on: March 08, 2007, 10:57:47 am »
Are we making the interiors of large ships useable?
9
Bug Reports / Re: terminate called after throwing an instance of 'std::bad_alloc'
« on: January 08, 2007, 02:30:53 pm »
More details.
It looks like the bitstream for the Ares entity is fine, it's just when it moves to dealing with the Archigos entity that it barfs.
What happens for the "Ares" is that it ends up setting the unsigned char version of the count to \005.
With the "Archigos" the first half of the read sets it to \004 and then the second half actually executes and sets it to \a (and then new barfs because that becomes something absurdly huge).
Second half is from
RakNet::BitStream::ReadBits at BitStream.cpp:467
Specifically line 488.
It looks like the bitstream for the Ares entity is fine, it's just when it moves to dealing with the Archigos entity that it barfs.
What happens for the "Ares" is that it ends up setting the unsigned char version of the count to \005.
With the "Archigos" the first half of the read sets it to \004 and then the second half actually executes and sets it to \a (and then new barfs because that becomes something absurdly huge).
Second half is from
RakNet::BitStream::ReadBits at BitStream.cpp:467
Specifically line 488.
10
Bug Reports / Re: terminate called after throwing an instance of 'std::bad_alloc'
« on: January 06, 2007, 09:18:13 pm »
Hmm, interesting it looks like the bitstream borked on the read and set the count to something absurdly huge, and then new barfed. Odd.
11
Bug Reports / terminate called after throwing an instance of 'std::bad_alloc'
« on: January 06, 2007, 08:33:39 pm »
Got this one after I got precursors compiling on the amd64. I'm mostly just posting this for reference while I figure out what's causing this. It happened while connecting to a dedicated server, same error whether I connected to kashmir or locally.
Code: [Select]
terminate called after throwing an instance of 'std::bad_alloc'
what(): St9bad_alloc
Program received signal SIGABRT, Aborted.
[Switching to Thread 47026429997440 (LWP 29038)]
0x00002ac5315e66c5 in raise () from /lib/libc.so.6
(gdb) where
#0 0x00002ac5315e66c5 in raise () from /lib/libc.so.6
#1 0x00002ac5315e78ce in abort () from /lib/libc.so.6
#2 0x00002ac5313686c4 in __gnu_cxx::__verbose_terminate_handler () from /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/libstdc++.so.6
#3 0x00002ac531366846 in std::set_unexpected () from /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/libstdc++.so.6
#4 0x00002ac531366873 in std::terminate () from /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/libstdc++.so.6
#5 0x00002ac53136695a in __cxa_throw () from /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/libstdc++.so.6
#6 0x00002ac531366c39 in operator new () from /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/libstdc++.so.6
#7 0x00002ac531366ce9 in operator new[] () from /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/libstdc++.so.6
#8 0x00002aaaace42b2e in celGenericParameterBlock (this=0x1184930, count=2926213956668227591) at stdparams.h:98
#9 0x00002aaaace33ce7 in Precursors::Networking::celClientNetworkLayer::DeserializeParameterBlock (this=0xfac0e0, bs=0x1189bf0, data=@0x7fff7a1f7e80)
at celClientNetworkLayer.cpp:1120
#10 0x00002aaaace37cc1 in Precursors::Networking::celClientNetworkLayer::Receive (this=0xfac0e0) at celClientNetworkLayer.cpp:578
#11 0x00002aaaace3335e in Precursors::Networking::celClientNetworkLayer::TickEveryFrame (this=0xfac0e0) at celClientNetworkLayer.cpp:1012
#12 0x00002ac5349738f3 in celPlLayer::HandleEvent (this=0x7a8be0, ev=@0x2aaaac106b18) at pl.cpp:122
#13 0x00002ac53498db91 in celPlLayer::EventHandler::HandleEvent (this=0x7a9ed0, ev=@0x2aaaac106b18) at pl.h:261
#14 0x00000000004ca4b9 in csEventTree::Dispatch (this=0x7a6e90, e=@0x2aaaac106b18) at cssubscription.cpp:576
#15 0x00000000004ca574 in csEventTree::Notify (this=0x7a6e90) at cssubscription.cpp:546
#16 0x00000000004b225e in csEventQueue::Notify (this=0x730440, name=@0x72a248) at cseventq.cpp:277
#17 0x00000000004baac9 in csEventQueue::iTypedFrameEventDispatcher::HandleEvent (this=0x72a238) at cseventq.h:262
#18 0x00000000004ca4b9 in csEventTree::Dispatch (this=0x721f60, e=@0x892d98) at cssubscription.cpp:576
#19 0x00000000004ca574 in csEventTree::Notify (this=0x721f60) at cssubscription.cpp:546
#20 0x00000000004b225e in csEventQueue::Notify (this=0x730440, name=@0x7305b8) at cseventq.cpp:277
#21 0x00000000004b231d in csEventQueue::Process (this=0x730440) at cseventq.cpp:293
#22 0x000000000047ebf5 in csDefaultRunLoop (r=0x730238) at runloop.cpp:91
#23 0x000000000045f1b0 in csApplicationFramework::Run () at csapplicationframework.h:330
#24 0x000000000045aa64 in Precursors::preClient::Application (this=0x7fff7a1f9230) at preClient.cpp:558
#25 0x00000000004825b3 in csApplicationFramework::Start () at csapplicationframework.cpp:71
---Type <return> to continue, or q <return> to quit---
#26 0x0000000000482921 in csApplicationFramework::Main (this=0x7fff7a1f9230, argc=1, argv=0x7fff7a1f9498) at csapplicationframework.cpp:131
#27 0x0000000000455eda in csApplicationRunner<Precursors::preClient>::Run (argc=1, argv=0x7fff7a1f9498) at csapplicationframework.h:441
#28 0x0000000000455670 in main (argc=1, argv=0x7fff7a1f9498) at main.cpp:55
12
Bug Reports / Re: Unable to load dynamic executable
« on: January 06, 2007, 07:22:11 pm »
Found it, fixed it, and commited. Updated the mk/autoconf scripts. They were setting the PLUGIN.LDFLAGS to -shared on x86, but not amd64. Updating from the latest CS Ext Package stuff worked. Now there's a new problem, *sigh* (only with networking though).
13
Bug Reports / Re: Unable to load dynamic executable
« on: January 06, 2007, 04:32:22 pm »
Ok, there is something here at work amidst the jamfiles that is *very* *very* wierd.
Exhibit A) On kashmir, "jam -d x pcnetworkentity" with rev 1114 shows that it is being compiled with -shared. This is good.
Exhibit B) On my amd64 "jam -d x pcnetworkentity" with rev 1114 shows that it is being compiled without -shared. This is not good.
Exhibit C) http://gne.pastebin.ca/308553. Causes everything to work normally, but I've no idea if that's safe to change.
Any thoughts?
Exhibit A) On kashmir, "jam -d x pcnetworkentity" with rev 1114 shows that it is being compiled with -shared. This is good.
Exhibit B) On my amd64 "jam -d x pcnetworkentity" with rev 1114 shows that it is being compiled without -shared. This is not good.
Exhibit C) http://gne.pastebin.ca/308553. Causes everything to work normally, but I've no idea if that's safe to change.
Any thoughts?
14
Bug Reports / Re: Unable to load dynamic executable
« on: January 05, 2007, 12:50:20 pm »
Well I found how to get the -shared option added in correctly. I used the Crystal Space External Application configure script generator and diffed some of the jam rules until I found something useful. Found the appropriate jam file, tried it out on 32-bit, and commited it. Works fine on my work box, I'll see if it actually fixes the problem when I get home.
15
Bug Reports / Re: Unable to load dynamic executable
« on: January 03, 2007, 09:54:38 pm »Well, then I guess the only thing to do, is to put that version in precursors, and see if it works. All you should need to do is to put the headers in include/raknet and everything in source wherever the current raknet source is in our repo.
That was my thought as well, but no go. Still the most up to date version in the repo.
I'll fiddle around some and see what else I can find, if anything.
16
Bug Reports / Re: Unable to load dynamic executable
« on: January 03, 2007, 04:29:14 pm »
Minor update:
RakNet does work on 64-bit linux, or at least the latest version does. I downloaded it, compiled it and the test chat program, which works fine (Other than not being robust enough to accept localhost as a valid IP to connect to).
RakNet does work on 64-bit linux, or at least the latest version does. I downloaded it, compiled it and the test chat program, which works fine (Other than not being robust enough to accept localhost as a valid IP to connect to).
17
Bug Reports / Re: Unable to load dynamic executable
« on: January 01, 2007, 04:24:52 pm »
Ok, found why it won't load.
All of ther other .so's are the same up to the ">".
Does anyone have any idea what this means, or why it might be different? Changing the \2 to a \3 makes it load, but it still segfaults when it tries to use the network plugin.
Code: [Select]
open("/home/ryan/current/precursors/pcnetworkentity.so", O_RDONLY) = 31
read(31, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\2\0>\0\1\0\0\0\0\254@\0"..., 832) = 832
^
open("/home/ryan/current/cel/pfmechanics.so", O_RDONLY) = 31
read(31, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0p\206\2\0"..., 832) = 832
^
All of ther other .so's are the same up to the ">".
Does anyone have any idea what this means, or why it might be different? Changing the \2 to a \3 makes it load, but it still segfaults when it tries to use the network plugin.
18
Bug Reports / Re: Unable to load dynamic executable
« on: December 31, 2006, 06:45:10 am »
There were some warnings when RakNet was compiling both here at work and at home. Not sure if they're the same warnings or not, mostly just virtual destructor warnings and some signed/unsigned stuff in RakPeer (on x86).
One thing I forgot to check was the executable format of the pcnetworkentity.so file. Ooops, must've been tired.
--Rosencrantz
One thing I forgot to check was the executable format of the pcnetworkentity.so file. Ooops, must've been tired.
--Rosencrantz
19
Bug Reports / Unable to load dynamic executable
« on: December 30, 2006, 08:51:37 pm »
After I got everything compiled on my new Athlon 64 at home I got this error.
Hrm... any thoughts?
Hrm... any thoughts?
Code: [Select]
Attempt to load plugin 'crystalspace.device.joystick.linux' failed
DLERROR (/home/ryan/current/precursors/pcnetworkentity.so): /home/ryan/current/precursors/pcnetworkentity.so: cannot dynamically load executable
SCF_WARNING: factory returned a null instance for cel.pcfactory.pcnetworkentity
if error messages are not self explanatory, recompile CS with CS_DEBUG
crystalspace.pluginmgr.loadplugin:
could not load plugin 'cel.pcfactory.pcnetworkentity'
crystalspace.cel.physicallayer:
CEL 'cel.pcfactory.pcnetworkentity' property class factory plugin missing!
gne.Precursors: Error loading cel.pcfactory.pcnetworkentity factor
Code: [Select]
ryan@darth-puter ~ $ uname -a
Linux darth-puter 2.6.18-gentoo-r4 #1 SMP Thu Dec 21 15:47:42 Local time zone must be set--see zic x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ GNU/Linux
20
Precursors / Re: A few game design questions!! and a bit more :)
« on: December 20, 2006, 08:02:04 pm »
One addon thing about the sector lengths that I just thought of.
What are the pros/cons of separating a solar system into N chunks where each chunk is a CS sector?
And N is dependant on the size of the systems? One of the benefits I see to this is that we can set the unit size to something
useful. The other benefit is that we can use the sectors as actual in-game navigation. To navigate in maps you have to have some sort of reference point with measurement axes. And "sectors" are sterotypical units in sci-fi for this sort of thing.
What are the pros/cons of separating a solar system into N chunks where each chunk is a CS sector?
And N is dependant on the size of the systems? One of the benefits I see to this is that we can set the unit size to something
useful. The other benefit is that we can use the sectors as actual in-game navigation. To navigate in maps you have to have some sort of reference point with measurement axes. And "sectors" are sterotypical units in sci-fi for this sort of thing.