Messages

21

Precursors / Need help with linker/Autoconfig, Stuck!!

« on: December 15, 2006, 01:53:35 pm »

Well, I appear to be stuck.
Being trying to dynamical link some exteranl apps to my planet generator for the last week and have failed utterly to make any headway. the libs in question are

ImageMagicK and RT

RT is the realtime clock and I need it for moving my moons, Second intervals are just to long. I need ImageMagick to create materials that are bigger that the screen. I have being trying to get them to dynamicaly link when I build my project by changing configure.ac but have had no success. I have looked and asked for help everywhere I can think of but getting nowhere.

revision 1082 of my sandbox is compilable and working copy of what I have done so far with the offending bits commented out. The revision description gives the line numbers of the offending bits of code. so if any of you can try get those librarys to link I would be most greatful. Send me the modified configure.ac file

I think I will spend a bit of time tring to actually create a soultion to the scale problem. This is a knotty problem but should not require any external librarys , I am open to any suggestions cause as it stands I may need to create 3 different scales to actualy get everything working right.

Regards
     

22

Precursors / Re: A possible solution to our scale issue

« on: November 23, 2006, 09:31:22 am »

23

Precursors / A possible solution to our scale issue

« on: November 11, 2006, 07:14:35 am »

well, I have been trying to work out how to get large objects and small objects on the screen at the same time. we where discussing splatting images of far objects on the skybox. but after thinking about this I spotted several large issues with this approach. these where

Generating the image, as the planets will be rotating the image would have to be generated again and again so it would present the correct face to the camera

lighting would affect how that face appeared, and would also have to be calculated 

these seemed like big coding issues that would require lots of work
then i had an idea,

If we could create 2 sectors, one for the solar system with a large scale (1 unit CS = 30,000km) and then a small scale sector ( 1 unit = 10cm ). now if we could get CS to render the large scale sector first, then render the small scale sector over it we would have both scales on screen looking right with minimal coding. Now we would have to do a bit of trickery to move objects out of the large scale sector to the small scale sector as the got close but this seem easy compared to skybox issues we would have to solve.

Anyway, I had a quick talk with thebolt on irc and he seemed to think it was possible. So I plan to look into this over the next while to see if I can figure out a way to get the two sectors rendering on top of each other.

Any comments welcome   

24

Precursors / Re: Galaxy Generator.

« on: November 10, 2006, 07:05:45 pm »

   Moving things around in RA/Dec/Dist space is a bit more complicated than I'd like, and doesn't give us much advantage... we need rectangular coords for rendering (even to the skybox) so it'd be easier to convert to the galactic scale (number 2)

I actualy disagree here, I think the RA/Dec/Dist is exactly the system we need. while rectangular cordiantes are easy to understand they require lots of calcualtions. as for the sky box , the simplest and quickest way I can think of doing it is using a sphere instead of 6 planes. Then do a orthagraphical projection onto a flat material. If there is a simpler way to do this I dont know it.
 

Just to play devil's advocate here. How does RA/Dec/Dist require less calculations? What specific calculations are you referring to? How many conversions to and from rectangular need to be done, and what about re-deriving equations of motion and translation if you aren't going to convert?

In short, What specifically are the benefits gained? And what is the range of use of these coordinates?

(FYI, I'm all for changing coordinate systems if it makes the calculations significantly eaiser).

Well , to be clear I am advocating the RA/Dec/Dist method for the sky box, not for everything. meshs have to have cordinates. as stuff on the sky box not likley to move much we dont realy have to worry much about those calcualtions. I will know more in a week or so.

 

25

Precursors / Re: Galaxy Generator.

« on: November 10, 2006, 07:06:17 am »

   Moving things around in RA/Dec/Dist space is a bit more complicated than I'd like, and doesn't give us much advantage... we need rectangular coords for rendering (even to the skybox) so it'd be easier to convert to the galactic scale (number 2)

I actualy disagree here, I think the RA/Dec/Dist is exactly the system we need. while rectangular cordiantes are easy to understand they require lots of calcualtions. as for the sky box , the simplest and quickest way I can think of doing it is using a sphere instead of 6 planes. Then do a orthagraphical projection onto a flat material. If there is a simpler way to do this I dont know it.

think we should only go to rectangilar cords when things have to be rendered in Crystal Space. But I will know more about this in a couple of weeks when I try code a skybox

Still the MASSIVE question regarding a thin or thick client to be answered. This is the biggest outstanding design question as it affects everything!!!! the sooner we have a answer to this the better.
 

regards


 

26

Precursors / Re: Galaxy Generator.

« on: November 08, 2006, 07:28:21 pm »

Well, lets try explain this scale issue better and get some detailed solutions on digital paper. 

   The issue
         Any mesh over 100,000 units from the origin will not render. 

   Best solution I'v heard so far. Take any object(mesh) that is over say 75000 units from the origin and remove it's mesh. then draw a scaled 2D picture of it on the sky  box.( at this range 99% of objects will be to small to see)   

  Just upping the scale we use so the solar system fits in 100,000 wont work as smaller objects (like ships )  will then be to small to draw . Example the sun is about 1,400,000 km in diameter, if we make this one unit in crystal space , A ship 1K long will be 0.0000001 units big. I have not checked this but I am sure that lots of things in crystal space will break at this scale. and our solar system will still be much bigger that our 100,000 limit.

So , here is a quick musing on a possible system

Several Cordinate systems using different scales

       1)a X,Y,Z system , with the origin at the players current location. Used to keep track of meshes and objects close to the the player.(maybe out to 10,000km with 1m units)

       2)a Right Ascension/Declination/Distance, with the origin at the players current location Used to draw faraway object in 2d on the sky box. ( this probably in AU's )

       3)And a galactic cord system that is based from some arbitrary origin.Used to initialise the first two. and also to allow navigation from star system to star system ( probably in light years ), also needed to locate 2 different players and workout if they are close to each other.

Please feel free point out problems with this as I think I already see several. But it is something to think about.

Regards
 

27

Precursors / Re: Galaxy Generator.

« on: November 07, 2006, 07:08:27 am »

Well, got a good bit of stage 2 done, I got Stargen working and it's producing planet data, here is a example of some output ( note this is a subset of the info generated )

Planet 8
   Distance from primary star:  4.685   AU
   Mass:                        6.712   Earth masses
   Surface gravity:             1.16    Earth gees
   Surface pressure:            0.059   Earth atmospheres
   Surface temperature:         -273.15 degrees Celcius
   Equatorial radius:           15341.8 Km
   Density:                     2.652   grams/cc
   Eccentricity of orbit:       0.047
   Escape Velocity:             18.68   Km/sec
   Molecular weight retained:   0.00 and above
   Surface acceleration:        1137.17 cm/sec2
   Axial tilt:                  19      degrees
   Planetary albedo:            0.151
   Length of year:              3143.21 days
   Length of day:               14.21   hours
   Boiling point of water:      35.3    degrees Celcius
   Hydrosphere percentage:      0.00
   Cloud cover percentage:      0.00
   Ice cover percentage:        0.16

this is quite a bit of info. Unfortunately it does not generate moons and I think that is what I will look into next. I did a little bit of work on rendering the info, very basic but here are some pictures.

A quick look at a sun and a few planets


A closer look at some planets



for them moment I am going to do some work on getting it to generate moons and maybe some work on creating custom materials for the planets as I am using material pinched from celestia at the moment and that does not give me much variety.

Now, I have been trying to not do any development on rendering these planets and the brings us the the whole GLP/LGPL issue. I went ahead and used stargen as it saves me a lot of time doing work that has already been done in the GPL community.

The question now is, is precursors interested in using any of this? as precursors is LGPL including the code is out, but it should be possible to use the data generated. I am going to look into getting it to create world files. The idea being that it can generate world files that can be used in precursors ( this is why I am trying not to do any work on rendering as the code would not be useful later.). The world files should be quite small, as they should only contain text. then if we code a loader/Render in CEL it would seem like a nice solution. I would appreciate some feedback on this.

On a side note, I have already run into scale problems ( lighting appears to stop working at 100,000 units from the origin, 3 of my planets are past this even in my seriously squashed up model . This is still a hard technical problem we need to over come. and the discussion of it has seemed to miss the point, the problem is not storing large numbers, it is rendering objects that are far apart in crystal-space.   

Anyway, look forward to and comments

Regards 

28

Precursors / Re: Precursors, Open Source, GPL and community?

« on: October 28, 2006, 10:02:48 am »

Ok, does that mean that all of the precursors code has to be LGPL, cause that makes verly little sence to me and is going to create a huge amount of work. If precursors is going to be destributed like it's GPL, why not use all the GPL stuff that is out there. You can still have core parts of precursors under the LGPL and have no issues using GPL for parts of it ( I think, not a solistiter ).

Regards

29

Precursors / Galaxy Generator.

« on: October 27, 2006, 07:41:32 pm »

   Well, after a bit of effort I got to my first goal, which was a class structure that could load some data and render one star. Now I start on phase 2, which is generating planets/moon's and as much other information as I can.
   Got a couple of questions,

1.I was planing to use the star.txt list from celestia for the basic star map, it's got planty , about 100,000. was wondering how people felt about that. comments welcome .
2.There is also a dead open source project that I found called mostly-harmless, that is exactly what I need. It's got so much stuff in it I want to use. you can check it out at http://sourceforge.net/projects/mostlyharmless/. I plan to strip out the database stuff but leave as much of it intact as possible. Was wondering what people thoughts where on that.

So,
   Stage 2 is getting the generator working. give it a star and a bit of general info and generate planets and moons with orbits and as much other stuff as I can come up with.
   Stage 3 is getting a simple render class working to get all this stuff moving.
   Stage 4 is making it look cool.

I hope it gets easier, lol, had a few dark moments already dealing with Crystal Space. So whoever is in charge of  precursor's let me know what you think as coding is moving along.

Regards

30

Suggestions / Hyper-Drive implementation idea

« on: October 20, 2006, 11:15:12 am »

Here is an idea for implementing hyper-drive that would be more interesting that just load star map/ click / engage drive. I'll try keep it short.

   Ok, Idea is that we simply create some tubes that represent hyperspace. You can look at your star map and get an idea of whats around, but you cannot select you destination.                 

   When you engage you hyper driver you are sucked into a tube which you travel down very fast(add some fog and flashing lights and the tube is far from straight, remember we are bending space  ). Depending on what suns are nearby branches are formed in the tube, if you really drive you ship towards any of these branches they will suck you in and you will now be heading to another star.

   So, the simplest trip is to point your ship straight at the star you want to go to and dont take any turns in the hyper-tube. you get where you are going.

  So this is simple enough, to make it a bit more interesting we add some dangers
   1) The longer you spend in hyper space the move it drains you shields, you run out of shields you explode.

          2) The longer your trip the more hyperspace fuel you use, run out of fuel and you are dropped out of hyperspace in the middle of nowhere and have to use you system drive to finish you trip.

   3) A hyperspace tunnel when opened leaves a residue, if another ship engages it's drive near where someone else engaged one shortly before they get sucked the same tunnel with you. they can then follow or attack.

        4) Tubes exit in suns , as a tube gets close to a sun it should take on the suns colour and get bigger. It's up to the pilot to disengage the drive close to the system without nose diving into that sun .

Well thats it, you could keep adding little extra things to this but I think i got the main parts covered.

regards

31

Precursors / Re: Scale, Physics, etc..

« on: October 18, 2006, 02:43:05 pm »

Well my thoughts

Traveling over Interstellar distances is boring

I agree, think we should just skip the interstellar spaces, hyper-drive anyone! This also provides a good place to load and unload game resources. Could also allow the splitting up the game into different servers if user population becomes a problem. Hyper-drive should be limited to a certain range ( possibly by ship size as well ) to make travelling long distances at least some sort of a chore. also to make certain systems important as re-fuelling points (sun scoop ect). Also ,A big ships can travel farther that little ships.

Population density can be a game killer. By nature all the players will gather in certain areas, and areas further away from that will have less players. This is to be expected and is normal. Unfortunately if you have too much space, many areas will be underutilized, if not outright empty. That detracts from the game experience and leaves the player feeling like they are playing a single-player game.

I think we need to concentrate on giving players reasons to both go exploring and to congregate. What i think will be the biggest problem is when to many players congregate in one place as it will cause problems with the net code.

I think that creating a good economy and allowing players to develop their own systems is the way to go. Dont forget some people will be quite happy to go exploring, and if other players want to clump together well there is nothing stopping them.   

eg

Player joins game. plays in our main system till he has got a wad of cash from completing certain tasks ( whether generated by other players or quests ). He gets a ship, and starts exploring. He finds a asteroid rich in ores/minerals somewhere. So he goes back to a high tech system , buys a mining rig and transports it to his asteroid and sets it up. the rig starts mining and creating ore.

He returns sometime later, Collects the ore produced from the mining ring and take it back to the high tech system and sells it. After awhile he realise that he would get more money transporting processed ore ( metals and  refined minerals ) so he buys a refinery and takes it out to his asteroid. Now the ores are processed on the asteroid creating more high value/smaller cargo. Our trader is quite happy.

He returns after a while to discover that his little mining operation has been blow to bits and raided by another player. He is not a happy trader . He goes back to the high tech system, buys a new mining rig/refinery but adds a lots of defensive gear as well ( hyper drive detector, Magnetic force shield, AI turbo lasers).He talks to a couple of other players about the bloody pirates who are stopping an honest trader like himself making lots of money and asks if they would like to form a clan. they agree. And the Van Maanen's Star Mining and Trading Company is formed. ect.

Now, if we are smart we would set the game up that the whole production system is trade based.  If a high tech system produces ships, the materials for those ships have to be delivered to the shipyard .The price of ships would be based on the cost to the ship yard of producing them plus a hefty mark up. Now some basic ships would be always available but higher class ships would have to be ordered from a shipyard. Also the sale price of particular raw materials would also depend on the quantity available, If a producer is short of a particular raw material its price is high, but a flooded  market the price drops till the producer just will not buy it any more.

The gaol it to make player's develop there own solar systems into high tech systems that will produce ships for them( and targets for other players). We also make professions like Trader/Raider, a trader is allowed to travel to other players bases and buy and sell, but not steal or do damage to a base. A raider is identified on entry to a system, the raider would have a bounty on him that anyone who destroys him can collect if he kills the raider. If the raider attacks a base the AI fights back, the raiders goal it to make the base defenceless while causing as little damage as possible. More damage less stuff to steal.     

This is very complex but should be what we are aiming for in the end. It give players reasons to travel and to form groups. Not that I think we should try this right away but should have it in mind.

To start with we should just work on a single star system till we have the million other things working.

What I would like to hear is idea's to deal with travelling within a solar system!! some sort of FTL drive that only works outside gravitational fields, can get you near a planet or star quickly perhaps. 

Just some ideas.

32

Precursors / Precursors, Open Source, GPL and community?

« on: October 18, 2006, 08:18:14 am »

        I have a very basic question about precursors. What is you development model with regards to GPL and open source. Are you going to just use Crystal Space as a engine and have everything else copyrighted?

   If so I think you are making a mistake as a game of this size a complexity will prove nearly impossible to create with the resources you have. Many people have tried this before and failed. There are middle options that I think would serve you better. Go check out the PlaneShift licence  (http://www.planeshift.it/pslicense.html ). While this may not suit you, if you are realistic you should realise that to achieve the precursor universe you will need all the help you can get. and the more restrictive you copyright the less help you will get.

   I personally think that plane-shift have the right idea. By keeping copyright of all the content but making the code GPL. This has many advantages, and few disadvantages. The question is what are you gaols. Do you want to create the greatest space game ever, or are you trying to create a game development company?
   
   To make my position clear, If I manage to create a good solar system generator I plan to make it GPL. So that I can use all the open source resources that can help me and also so as many other people can benefit from it as possible. It would also allow other people to easily contribute to it as well.

   As a suggestion I would suggest that you make precursors a Non-Profit entity, with open source code and copyrighted content. The aim being to create a game for a community with a commitment to making it the best game ever while charging very little with all moneys generated being invested back into the game ( to cover equipment, wages for staff and developers ect.), this would also allow a community to form and support the game. Also it would give the game a long term survivability. I believe that most of the precursor team is currently in collage, when you finish your studies you will find it very difficult to give the time necessary to complete a project like this.

   There are literally hundreds of people who will contribute to a project like this if it is setup correctly. I suggest that a lot of though should be given to these issues.     
 
Regards

33

Precursors / RE: Models, screenshots, etc... in Developers' Discussion

« on: October 12, 2006, 07:14:59 am »

Hi,
  Was reading the post http://forums.g33xnexus.com/index.php/topic,639.0.html in the developer discussion forum and though I should let you know what I am up to. I am still very green using C++ and wanted to do something that I found both interesting and useful that could help Precursors.

  Having read the forums and the development WiKi I thought that making a procedural solor system generator would be a good goal as it's not scheduled anywhere and seem a relativity simple piece of coding. Now I cant guaranty I will manage to make this or if it will be any good but I going to give it a try anyway. If I get to a stage where I feel it might be useful I will let you know.

  So, on to some details. I did a few test first just trying to mock up a solar system and immediately had problems with scale. I found that a lot of things stopped working as expected when the position of a mesh was greater than 100,000 from the 0,0,0 position, both lighting and collision detection seem to stop working. ( example world file at
http://www.uploading.com/files/Z38R0FY5/world.zip.html ).

  This world file is quite simple, has 2 camera positions , one near 0,0,0 and one near 100000,0,0 . and a couple of meshes, start walktest at the 0,0,0 position and it works , at the other position nothing is visible and you fall through meshes. So some method of getting around this will be required and I have not thought of one yet.

  So, I decided to continue anyway as generating a solar system to a smaller scale is still useful. Plan to create a class that will generate suns/planest/moons ect using a seed for each solar system and a simple rule base ( something like http://www.geocities.com/TimesSquare/2691/formula.txt ). Plan to shameless use the textures from Celestia for graphics and give each object a orbit and other information. I think that doing all this client side rather that server side is the best approach and using server system time to keep everything synchronised for different clients. (ie when a client logs onto a server, the server gives the client the current server system time, the client then used this to calculate all positions.)

  It's slow going but my C++ is improving the more I use it. And if I can manage to generate a simple solar system with orbits and graphics in Crystal Space I feel I will have managed to achieve something useful.

Regards

34

Bug Reports / Re: Error when trying to start local server

« on: September 22, 2006, 10:35:39 am »

Nope, know almost nothing about network programming. Mostly know stuff about database. So I douth I would be much help other that suppling C code for you to laugh at . Not much database stuff done with C now days.

You might want to look up some of the people from this tread

http://community.crystalspace3d.org/forum/index.php/topic,1236.0.html

They all seem to be interseted in networking for CS atm and doing work with it. Might be an idea to try get everyone working on one soultion.

Best I can offer is to keep playing around tring to make some simple stuff in CS and give lots of uninformed opions. Hopefully as spend more time using CS my skills will incress. But it's slow going, espically as I am trying to get to grips with C/C++, CS , moddeling, Blender and its conversion scripts all at the same time. All over the place  in other words. ( and blender conversion is a real problem for me atm, Most moddels I make eather dont come out the same or just dont export ).

But best of look with it and I will defenatly keep watching you progress and give whatever help I can.
 
Regards   

35

Bug Reports / Re: ODE INTERNAL ERROR 2: Bad argument(s) in dxSphere()

« on: September 22, 2006, 09:55:06 am »

No, he just said that it was interesting and good to know!

36

Bug Reports / Re: Error when trying to start local server

« on: September 21, 2006, 12:29:46 pm »

Well, doing a
jam distclean; ./configure ; jam ;
in cel and then in precursors fixed this problem

thx Rosencrantz.

Can start a "Local Server:" and fly around.
Can start a second client and login to the local server.
Then things stop working so good, clients cant see each other. and the second client suffers from random movment.

Anyway, all the CS bits seem to be working right now.
Regards

37

Bug Reports / Re: Error when trying to start local server

« on: September 21, 2006, 08:49:58 am »

well went to have a look at cel and it's got problems to

Code: [Select]

mec@mec-desktop:~/development/cel$ ./wheeledtest
SCF_NOTIFY: class crystalspace.cegui.wrapper (from /home/mec/development/CS/cscegui.so) has already been registered in a different context: '{none}' vs. '{none}' (from /home/mec/development/CS/cegui.so); this message appears only in debug builds

crystalspace.canvas.glx2d:
  Opening GLX2D
  Creating Context
  Video driver GL/X version (direct renderer)
  Visual ID: 0x00000023, 24bit TrueColor
  R8:G8:B8:A8,
  level 0, double buffered

crystalspace.canvas.openglcommon.driverdb:
  Applied: Broken ATI point sprites (NV)

crystalspace.canvas.openglcommon:
  OpenGL renderer: GeForce 6600 LE/AGP/SSE2 (vendor: NVIDIA Corporation)
  version 2.0.2 NVIDIA 87.62
  Using windowed mode at resolution 640x480.
  Pixel format: Color: 24 Alpha: 8 Depth: 24 Stencil: 8 AccumColor: 48
  AccumAlpha: 16 MultiSamples: 0
  Multisample: disabled
Assertion failed: *(CookieType*)p == startCookie
Segmentation fault


mec@mec-desktop:~/development/cel$ ./walktut
SCF_NOTIFY: class crystalspace.cegui.wrapper (from /home/mec/development/CS/cscegui.so) has already been registered in a different context: '{none}' vs. '{none}' (from /home/mec/development/CS/cegui.so); this message appears only in debug builds
Segmentation fault


mec@mec-desktop:~/development/cel$ ./celstart
SCF_NOTIFY: class crystalspace.cegui.wrapper (from /home/mec/development/CS/cscegui.so) has already been registered in a different context: '{none}' vs. '{none}' (from /home/mec/development/CS/cegui.so); this message appears only in debug builds
Segmentation fault


So I guess I got bigger/other problems that anything to do with precursors.
lol , got to stop using svn update.

38

Bug Reports / Error when trying to start local server

« on: September 21, 2006, 07:22:38 am »

Get this when I click "Start Local Game"
Rev 1013

Code: [Select]

mec@mec-desktop:~/development/precursors$ ./precursors
preClient version 0.3.4 Build 1004 by G33X Nexus Entertainment.
SCF_NOTIFY: class crystalspace.cegui.wrapper (from /home/mec/development/CS/cscegui.so) has already been registered in a different context: '{none}' vs. '{none}' (from /home/mec/development/CS/cegui.so); this message appears only in debug builds
WARNING: could not load plugin 'crystalspace.sound.render.software'
WARNING: could not load plugin 'crystalspace.sound.loader.multiplexer'
WARNING: could not load plugin 'crystalspace.modelconverter.multiplexer'
WARNING: could not load plugin 'crystalspace.mesh.crossbuilder'

crystalspace.canvas.glx2d:
  Opening GLX2D
  Creating Context
  Video driver GL/X version (direct renderer)
  Visual ID: 0x00000023, 24bit TrueColor
  R8:G8:B8:A8,
  level 0, double buffered

crystalspace.canvas.openglcommon.driverdb:
  Applied: Broken ATI point sprites (NV)

crystalspace.canvas.openglcommon:
  OpenGL renderer: GeForce 6600 LE/AGP/SSE2 (vendor: NVIDIA Corporation)
  version 2.0.2 NVIDIA 87.62
  Using windowed mode at resolution 1024x768.
  Pixel format: Color: 24 Alpha: 8 Depth: 24 Stencil: 8 AccumColor: 48
  AccumAlpha: 16 MultiSamples: 0
  Multisample: disabled

gne.Precursors:
  Joystick support enabled. Loading joystick plugin.

crystalspace.device.joystick.linux:
  No operable joystick found


crystalspace.pluginmgr.loadplugin:
  failed to initialize plugin 'crystalspace.device.joystick.linux'

gne.Precursors:
  Attempt to load plugin 'crystalspace.device.joystick.linux' failed
  Application initialized successfully.
Loading window 'Root'.
Loading window 'Main'.
Adding level 'flightsim'.
Adding level '/precursors/levels/Jamfile'.
Done adding levels.

crystalspace.bugplug:
  BugPlug loaded...

precursors.addon.window.main:
  Hold on, the hamster is working...
Loading window 'Progress'.
Loading window 'Hud'.

precursors.addon.windowmanager:
  Loading the server.

cel.networklayer.server:
  Starting server on port 60600.

precursors.addon.windowmanager:
  Starting the server.
  Creating level entity...

precursors.addon.contentloader:
  Loading level '/precursors/levels/flightsim'...

precursors.behaviourlayer.c++.level:
  Start loading level.
  Loading region 'space2'.
  Loading entities in sector 'Scene', region 'space2'.
  Start loading level.
Not Deleted 0x8b61c80 '(null)' ref=1
Not Deleted 0x8b7bda8 'flare_center' ref=1
Not Deleted 0x8b6af68 'flare_spark1' ref=1
Not Deleted 0x8b7d7e8 'flare_spark2' ref=1
Not Deleted 0x8b7c088 'flare_spark3' ref=1
Not Deleted 0x8b7bfd0 'flare_spark4' ref=1
Not Deleted 0x8b7a5e0 'flare_spark5' ref=1
Not Deleted 0x824aa68 'Scene' ref=1
Not Deleted 0x824ac88 'Lamp.011' ref=1
Not Deleted 0x824ae98 'Lamp.010' ref=1
Not Deleted 0x824b0a8 'Lamp.009' ref=1
Not Deleted 0x8b7aaf8 'Lamp.008' ref=1
Not Deleted 0x8b7ad08 'Lamp.007' ref=1
Not Deleted 0x8b7af18 'Lamp.006' ref=1
Not Deleted 0x8b7b128 'Lamp.005' ref=1
Not Deleted 0x8b7b338 'Lamp.004' ref=1
Not Deleted 0x8432100 'Lamp.003' ref=1
Not Deleted 0x8b7d438 'flare_center' ref=1
Not Deleted 0x8469c00 'flare_spark1' ref=2
Not Deleted 0x8b6a200 'flare_spark2' ref=2
Not Deleted 0x824b300 'flare_spark3' ref=4
Not Deleted 0x824b3f0 'flare_spark4' ref=3
Not Deleted 0x8b7b740 'flare_spark5' ref=3
Not Deleted 0x8432310 'Lamp.002' ref=1
Not Deleted 0x8432700 'Lamp.001' ref=1
Not Deleted 0x8432940 'Lamp' ref=1
  Loading region 'space2'.
  Stop loading level.
Mass: 25000.000000; Center: 0.000000,0.000000,0.000000

precursors.addon.contentloader:
  CreateEntity: Successfully loaded entity 'Archigos1'.
Assertion failed: *(CookieType*)p == startCookie
Location:         libs/csutil/ptmalloc_wrap.cpp:97
Message:          Memory block has wrong cookie (was probably allocated in another module)
Call stack:
/home/mec/development/precursors/nlserver.so [0xb5ed4c08]
/home/mec/development/precursors/nlserver.so(Precursors::Networking::celServerNetworkLayer::CreateEntity(iCelEntity*, unsigned int, char const*, iSector*, iCelRegion*, iCelParameterBlock*)+0x183) [0xb5eade47]
./precursors(Precursors::ContentManager::CreateEntitiesFromMap(iSector*, iCelRegion*)+0x2ba) [0x8166010]
./precursors(Precursors::BehaviourLayer::Level::LoadEntitiesInRegion(iCelRegion*)+0x1c5) [0x815af23]
./precursors(Precursors::BehaviourLayer::Level::SendMessage(unsigned long, iCelPropertyClass*, celData&, iCelParameterBlock*, char*)+0x16f) [0x815b0e1]
./precursors(Precursors::BehaviourLayer::Base::SendMessageV(char const*, iCelPropertyClass*, celData&, iCelParameterBlock*, char*)+0x5f) [0x815c603]
./precursors(Precursors::BehaviourLayer::Base::SendMessage(char const*, iCelPropertyClass*, celData&, iCelParameterBlock*, ...)+0x41) [0x815c59b]
/home/mec/development/cel/pfzone.so [0xb20e0efe]
/home/mec/development/cel/pfzone.so [0xb20e18a8]
/home/mec/development/cel/pfzone.so [0xb20e24da]
/home/mec/development/cel/pfzone.so [0xb20e9994]
/home/mec/development/cel/pfzone.so [0xb20f9e8a]
./precursors(Precursors::ContentManager::LoadLevel(char const*)+0x536) [0x816725e]
/home/mec/development/precursors/nlserver.so(Precursors::Networking::celServerNetworkLayer::StartLevel(char const*)+0x4c) [0xb5eadb42]
./precursors(Precursors::ContentManager::StartLevel()+0xf0) [0x816500e]
./precursors(Precursors::ContentManager::StartServer(bool)+0x6a9) [0x8165725]
./precursors(Precursors::ContentManager::StartServer(int, char const*, bool)+0x56) [0x8160406]
./precursors(preWindowMain::Action(CEGUI::String)+0x2fff) [0x81811fb]
./precursors(preGUIWindow::OnClicked(CEGUI::EventArgs const&)+0x179) [0x81898e5]
./precursors(CEGUI::MemberFunctionSlot<preGUIWindow>::operator()(CEGUI::EventArgs const&)+0x5b) [0x81795af]
/usr/local/lib/libCEGUIBase.so.1(CEGUI::Event::operator()(CEGUI::EventArgs&)+0x48) [0xb7dfa6d8]
/usr/local/lib/libCEGUIBase.so.1(CEGUI::EventSet::fireEvent_impl(CEGUI::String const&, CEGUI::EventArgs&)+0x4f) [0xb7dfbaf1]
/usr/local/lib/libCEGUIBase.so.1(CEGUI::EventSet::fireEvent(CEGUI::String const&, CEGUI::EventArgs&, CEGUI::String const&)+0x49) [0xb7dfbb41]
/usr/local/lib/libCEGUIBase.so.1(CEGUI::Window::onMouseClicked(CEGUI::MouseEventArgs&)+0x3c) [0xb7e3ff7e]
/usr/local/lib/libCEGUIBase.so.1(CEGUI::System::injectMouseButtonUp(CEGUI::MouseButton)+0x17c) [0xb7e37206]
/home/mec/development/CS/cegui.so [0xb649c916]
/home/mec/development/CS/cegui.so [0xb64b034c]
/home/mec/development/CS/cegui.so [0xb64b06ff]
./precursors [0x80ec988]
./precursors [0x80d3928]
./precursors [0x80d3a35]
./precursors [0x80aa75d]
./precursors(csApplicationFramework::Run()+0x13) [0x809a051]
./precursors(Precursors::preClient::Application()+0x2045) [0x809979d]
./precursors [0x80abdc8]
./precursors [0x80abf9a]
./precursors(csApplicationRunner<Precursors::preClient>::Run(int, char**)+0x34) [0x8095200]
./precursors(main+0x5d) [0x8094bad]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xd2) [0xb7b52ea2]
./precursors(__gxx_personality_v0+0x71) [0x8094ad1]
Trace/breakpoint trap

Not sure how stable this meant to be as it's todays SVN.
But in general I am slowly getting the hang of C++ and CS.

Can anyone tell me what is the best version of blender to use with CS. I have been using blender 2.41 but get strange results when I try export meshes (Blender2CS).was wondering what other people used?

anyway
regards

 

39

Bug Reports / Re: ODE INTERNAL ERROR 2: Bad argument(s) in dxSphere()

« on: September 21, 2006, 06:58:36 am »

Well after getting on IRC with jorrit for a couple of min we fixed the problem. It was the ODE configure option "--enable-double-precision" causing the error.

Used
./configure --with-opcode --enable-debug --with-cylinder --prefix=$HOME/development/output

on ODE and recompiled , then recompiled CS, precursors is now running with out the DXSphere error. Think i will start a new tread for my next error

Regards

40

Bug Reports / Re: ODE INTERNAL ERROR 2: Bad argument(s) in dxSphere()

« on: September 07, 2006, 01:12:25 pm »

Yep, tried to revert ODE and it did not help eather. Also the problem is showing up in other programs. Tried the wheeledtest in CEL and got same error. Cant be sure it's not just a problem with my system as no one else has reported it. 

So , Pritty much just waiting around for a update to fix it. Posted a message on the CEL forum so not much else i can do.

Regards