Dyson Sphere (why do small?)

[Frame]

Once more into the breack...

i´ll see if i can run it at any accepteble frame rate


Edit: Weee!!!! LegoLand at 11 fps

[Frame]

Currently we are working on an inspection ship flying around the station. I had a route through the arch were he mostly survived. But in an other system (other orientation of the station), it now keeps crashing at the same spot.

Could´nt you ovecome that by using offset coordinates from the stations origin.. ofcourse coupled with the stations orientation...

At least that way you get absolute coordinates for waypoints, while i do not know of you can use these directly in an AI.plist somehow...

Similar to the way i get docking bay coordinates, like i posted in the scripters cove...

sry i´m on drugs :-S.. my foot is hurting like h***

[Eric Walch]

Could´nt you ovecome that by using offset coordinates from the stations origin.. ofcourse coupled with the stations orientation......Similar to the way i get docking bay coordinates, like i posted in the scripters cove...

I already start with an array of local station coordinates for the route and translate them to system coordinates. I think on exactly the same way you described in scripters cove. I hoped there would be a shorter calculation, but as you came with the same code, I think it is the only decent way.
I just have problems with the randomness of collisions. Somehow it feels that it can be avoided when following the right path trough the boxes. When in debugging mode I suddenly get several messages of "octrees collide", without damage, but than only on the last there is a huge damage. I don't know why the others don't give damage. In the worse case I just have to stay further away with the ships.
The positive point is that I start learning how collision detection works. (still far from it)

[Svengali]

I just have problems with the randomness of collisions. Somehow it feels that it can be avoided when following the right path trough the boxes. When in debugging mode I suddenly get several messages of "octrees collide", without damage, but than only on the last there is a huge damage. I don't know why the others don't give damage. In the worse case I just have to stay further away with the ships.
The positive point is that I start learning how collision detection works. (still far from it)

Sometimes NPCs are crashing also in the main bounding box or by hitting the border of a bounding box (main and subent) even if 'far' away from the octrees. And rotating a ship inside a bounding box seems to be dangerous too. Another thing is when watching one of our new inspection ships and it is colliding (but not dying) with the station, sometimes the player gets a momentum too - even if the player is outside the main-bounding box of the station, but close to the inspection ship.

And we have platform differences too. On my computer (WIN, Intel Core2 Duo) the NPCs are crashing at 100% (sometimes they survive the collision, but they die when trying to reach the next point) and on Erics (MAC) they are flying through the arch - sometimes :-)

We can't figure out when and why this happens. It looks randomly (it's not randomly, but we don't know the reason) and happens on different points/angles.

[nijineko]

this is all very useful! thank you. i will be on the look out for these things when i export and convert and try to make my first ever oxp out of this. ^^ then the alpha testing! =D

edit: nuts... can't seem to get the plist working, and hence the object into the game!

here's what i have so far.... i put this together after reading the wiki:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Dyson_sphere</key>
<dict>
<key>name</key>
<string>Dyson_Sphere</string>
<key>model</key>
<string>Dyson_Sphere.dat</string>
<key>density</key>
<string>100</string>
<key>energy_recharge_rate</key>
<string>100</string>
<key>scanClass</key>
<string>CLASS_ROCK</string>
<key>thrust</key>
<real>100</real>
</dict>
</plist>

of note is the fact that the plist editor cannot open this file. don't know why.

[Eric Walch]

of note is the fact that the plist editor cannot open this file. don't know why.

Every <dict> you open, needs a </dict> to close. You missed one. To see such missing endings easier you should indent the lines.

But when you have a plist editor, why not use that one to create the plist in the first place. That way you never have to worry about wrong syntax. Specially for starters in plist writing that is a much easier way. I also started that way with my plists. Now I mix it and mostly use the text editor for a better overview.

The mac plist editor that is part of the instal software has one drawback. On saving it always defaults to XML format. Current Oolite understands also simple ascii format. With the plist editor you can choose the "save as.." and save in ascii format. Much more readable and editable with a normal text editor.

[nijineko]

thanks! it was indented, but the quote box ate the tabs. ^^

hmmm, still not finding it. ^^ how do i make an example of the sphere appear?

[JackBassV]

A dyson sphere is coll, but wouldn't a Ringworld (also by freeman dyson) be simpler? After all, you wouldn't need a hole to enter, although docking facilities on the outside would be useful (for non-aero designs.)

JBV^_^

[nijineko]

possibly, but i've already managed the sphere and the hole. ^^ now i just need to figure out how to make it appear... i'm starting to suspect that either i need something extra in the plist to make it appear, or that it's showing up in the center of the planet or sun. (i haven't made it giant yet, i wanted to test flying in and out of it first, before i tried to surround the planet and sun.

[nijineko]

i guess i should start posting the files so that others can take a gander at what i've come up with rather than shooting in the dark (pun intended...) with the advice. ^^

i'll try to do that sometime in the next month. once i figure out how to force it to show up, and find out where it is, i'll be able to check out my attempt at texturing it, and see if i managed to peg the autouv for the inside of the sphere as well as the outside. if not, i'll have to figure out how to apply textures to the inside.

i suspect (from the discussion of collision boxes above) that a dyson sphere will slow the game down considerably, as it will be constantly checking for touching faces for everything inside the sphere. unless there is a way to assign a "negitive boundary box(es)" area where it will not check for collisions inside a certain defined area of the hollow sphere....

just checking, but i'm new to wings3d as well... is the grid of squares on the xz plane one meter by one meter in measurement? i'm still poking around the interfaace and trying to figure out how to measure things. *^^* i'll probably start hitting the help files and tutorials and maybe the wings forum/wiki here shortly if i can't figure it out soon.

[bob19]

Don't know whether this will help, absolute beginner in wings myself.
Select 2 vertices in vertex selection mode and wings will display the distance between them.

[LittleBear]

To get it in game, firstly you'll need to give the object a role in shipdata, like this:-

Code: Select all

<key>roles</key>
<string>nijineko_dyson_sphere</string>

You also need to give it an AI. nullAI.plist will be fine for testing. The object will just sit there and not react to anything, but even if you don't want the object to do anything it still needs an AI like this L-

Code: Select all

<key>ai_type</key>
<string>nullAI.plist</string>

'cos nullAI is one of the built in AI you don't need to add any AIs to the OXP, but you still need to say what AI the object is using in shipdata.

You also need vaules for its max_energy and its pitch / roll. Space Stations have energy of 50,000 so might as well give it that:-

Code: Select all

<key>max_flight_pitch</key>
<real>1.0</real>
<key>max_flight_roll</key>
<real>1.0</real>
<key>max_energy</key>
<real>500000</real>

You might also want to give it a beacon on the ASC. The attributes above you must specify otherwise it won't work, a beacon is optional, but for ease of testing you might want to add one. To do that, add this to shipdata:-

Code: Select all

<key>beacon</key>
<string>D-Dyson</string>

Switching your ASC to D will now take you to the Sphere.

OK. You now have a (hopefully) valid object. But it won't actually be added to the game unless you tell Oolite to do so. The role you've given it is a custom role, so the object will only appear when your script specicaly calls it into existance. So now you need a script. For a realeased version you'd probabley want it only to appear in certain systems (maybe by tech-level or govenment type) and you probabley woudn't want it slap bang in the middle of the space-lane. But to test it this script will put the object in every system in the space-lane about half way between the w/p and the planet. :-

Code: Select all

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict> 
   <key>test_of_dyson_sphere</key> 
   <array> 
      <dict> 
         <key>conditions</key> 
         <array> 
            <string>status_string equal STATUS_EXITING_WITCHSPACE</string>
         </array> 
         <key>do</key> 
         <array> 
	   <string>addSystemShips: nijineko_dyson_sphere 1 0.5</string>
	     </array> 
      </dict> 
   </array> 

</dict> 
</plist>

This script is very simple and will only add the object on making a jump. If you load up Oolite (remember to hold down SHIFT otherwise the changes to your .plists will not be read), then make a jump anywhere and the object will be added. If its not there check the stdrr file. It will tell you what was wrong with the object.

[Eric Walch]

Don't put to much effort in it. I think a Dyson sphere or Ringworld will fail on the first level of collision detection. As stated before, when the player is more than 30 000 meters away there is only a check against collision of a sphere. And as these things will have a diameter of more than 30 000 meters to be bigger than planets, the player will always be at a distance of more than 30 000 meters away from the centre.

A Ringworld at this size will be seen as a sphere for collision detection. No chance you can fly in through the "open" sides.

There is just one exception: For objects of type station there is extensive collision detection at the side of the docking port. (positive Z-axis). This is to allow NPC-ships to dock, even when the player is not nearby. A player would be able to enter a Dyson sphere here but he should stay around this Z-axis. Flying to far away from this axis, inside the sphere, will trigger a collision.

This is just what I think the code will do with such big objects, but I could have missed something and things could work for a player.

Or create a Dyson sphere of 30 000 meters radius maximum and put a mini planet in it. That way you stay within the maximum limits.

[Commander McLane]

thanks! it was indented, but the quote box ate the tabs. ^^

That's what the "code" box is for, so I would suggest using that one whenever you are posting, errmm..., well, code.

hmmm, still not finding it. ^^ how do i make an example of the sphere appear?

Entities, ships, asteroids, stations, whatever, don't appear just by themselves. They have to be made appear. That's what we call spawning. And this is usually done in the script.plist or the planetinfo.plist of an OXP. The latter could be the better for your purpose.

How are ships spawned? Oolite doesn't spawn specific ships by their names, it spawns ships with a specified role. That means that you will never see your Dyson Sphere unless you have assigned it a role, i.e. added the roles-key to its shipdata. It is one of the essential keys which must never ever be omitted when creating a shipdata. So your shipdata.plist should at least look like this (note the nice indentation within the code-tags, and note that a plist-editor sorts the keys alphabetically (at least mine does)):

Code: Select all

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>nijineko_Dyson_sphere</key>
	<dict>
		<key>ai_type</key>
		<string>nullAI.plist</string>
		<key>energy_recharge_rate</key>
		<integer>100</integer>
		<key>max_energy</key>
		<integer>1000000</integer>
		<key>model</key>
		<string>nijineko_Dyson_Sphere.dat</string>
		<key>name</key>
		<string>Dyson Sphere</string>
		<key>roles</key>
		<string>nijineko_dyson_sphere</string>
		<key>scanClass</key>
		<string>CLASS_ROCK</string>
		<key>thrust</key>
		<real>100</real>
	</dict>
</dict>
</plist>

Note the other changes I made as well. The density-key is pretty much useless for your sphere, so I deleted it. But on the other hand, what do you want with a energy_recharge_rate, if you don't have a value for max_energy defined, up to which your sphere's energy is recharged? I gave it a pretty high energy, because I don't guess you want the player to be able to obliviate it with a couple of laser shots. Another essential key is ai_type, which defines what your entity will be doing. NullAI is an AI that does nothing in particular. For instance it doesn't try to move your entity, it doesn't react on attacks or anything else, it just doesn't do anything. If you want the sphere to do anything, you have to write a custom AI for it, because none of the predefined AIs would be of any use for it. If you decide to script an AI, you should name it nijinekoDysonSphereAI.plist or something of the like, and that's the string you assign to the ai_type-key.

You should also right from the beginning of your scripter's career internalize that identifiers have to be unique. Who knows, perhaps somebody else is working on an OXP with a Dyson Sphere as well? So if you create a shipdata.plist with a <key>Dyson_sphere</key> and he creates a shipdata.plist with a <key>Dyson_sphere</key>, they will kill each other. Not nice. Therefore you better use a unique name. One way of achieving this is to preceed all strings that have to be unique with your own name or avatar. The chances that anybody else who is also called nijineko will create another dyson sphere are pretty small.

The same applies for your dat-file, and of course for the texture.png as well. Make their names unique, or any equally named .dat or .png may overwrite and erase yours. Do you want that? (Note: If you rename your .png, you have to open your .dat with a text editor and change all appearances of oldname.png to newname.png as well. Then resave.)

Oh, and by the way: I don't think that you want an underscore in the name-key of your entity. This is the string that is displayed next to the bounding box and in your HUD when you target the entity. Usually you would have "Cobra MK. III" there, not "Cobra_MK._III". Looks ugly.

Now your entity is properly defined. But that doesn't yet make it appear in your game. For that--as mentioned earlier--you need to spawn it. I suggest you do that via planetinfo.plist. This consists of general information about Oolite systems (and also interstellar space) and information about specific systems. I take it you don't want to create dyson spheres everywhere, but just in one system. You do this by creating a planetinfo.plist-entry for this specific system. So you have to create another file with your plist-editor, name it planetinfo.plist, and put it into the Config-folder of your OXP.

Then you have to decide in which system you want the dyson sphere to appear. This information you have to put in the entry name, by the order <key>galaxy_number planet_number</key>. For Lave that would be 0 and 7, respectively (have a look at the planet lists for other locations).

The only thing you need inside the dictionary is the method to spawn your entity. This is a script action, so it has to go inside a script_actions-array. The syntax for the various spawning methods you find in the wiki. I suggest the addShipsAt-method, which does what it says: Adding a specified entity (to be precise: an entity with a specified role) at specified co-ordinates. For that it needs the role of the object you want to spawn as defined in shipdata.plist ("nijineko_dyson_sphere"), the number of objects with that role you want to spawn ("1"), the co-ordinate system relative to which the following co-ordinates are to be understood (as the sphere shall be centred around the sun, in your case any co-ordinate system that is centred around the sun will be sufficient, I chose "spm"), and finally the co-ordinates themselves relative to the chosen system ("0 0 0", because you want the sphere to be dead center around the sun).

So here's what your planetinfo.plist should look like:

Code: Select all

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>0 7</key>
	<dict>
		<key>script_actions</key>
		<array>
			<string>addShipsAt: nijineko_dyson_sphere 1 spm 0 0 0</string>
		</array>
</dict>
</plist>

Important note: This will create the final, big Dyson Sphere. Any small object created this way will simply be inside the sun. So for your testing purposes you need some other way. The best thing is to use the Debug-menu (install the OXP first). That is an additional pull-down menu for Oolite that allows you to do all kinds of things. In your case: spawn entities. Launch from the main station, choose "Create ship..." from the menu and enter your ship's role "nijineko_dyson_sphere" in the pop-up box. Your small test-sphere will appear somewhere close to the station. Locate it on your scanner and fly towards it. Voilà!

And one last thing:

i suspect (from the discussion of collision boxes above) that a dyson sphere will slow the game down considerably, as it will be constantly checking for touching faces for everything inside the sphere. unless there is a way to assign a "negitive boundary box(es)" area where it will not check for collisions inside a certain defined area of the hollow sphere...

No, that was not the issue of the discussion above. The issue was that probably everything inside the big dyson sphere (including you) will blow up instantly as soon as the sphere is spawned. So maybe your OXP won't do anything else than producing a PRESS SPACE COMMANDER screen as soon as you load it. But we'll have to test and see before we can definitely know.

[nijineko]

thank you very very much for these very helpful responses. =D i will go poke at my files now and see what happens. thank you again! be back soon!