Page 10 of 14
Re: RFC: re-squared-dux ...
Posted: Wed Jun 08, 2011 9:38 am
by Simon B
Just checking how the new-style subentities are supposed to work...
Code: Select all
subentities = {
"carrier1-dock" = {
type = "standard";
position = (0 0 0);
orientation = (1 0 0 0);
is_dock = true;}
"carrier-turret" = {
type = "ball_turret";
position = (-9.48 38.99 188.07);
orientation = (1 0 0 0);}
};
Re: RFC: re-squared-dux ...
Posted: Wed Jun 08, 2011 9:53 am
by Killer Wolf
Eric Walch wrote:Simon B wrote:I've practiced docking with it - I found that I don't get to fly into the dock to, um, dock ... even though the back of the docking bay is close to the models origin ... so what determines this?
You are docked when 75% (could be eighty %, Im not fully sure) of your ship has passed the point of origin of the bay. Therefor is the origin of a bay not defined in the centre or back but always at its front.
Also make sure you defined the docking bay correct, or the system will generate a default bay in the ship centre. For to be recognised as dock with the old subentity definitions, the subentity name has to contain the word 'dock' somewhere in the name. Very user unfriendly, so better define it with the
new method and add a
is_dock key.
Eric, as per my post in the "things i wish i knew..." thread, when i built the Nuit i could only get the dock working by building the dock at the Origin and then shifting it up to the required position - is that still necessary or does the is_dock now enough to work out the positioning? The dock for one of my new stations is a much longer tunnel than normal stations, if the origin is defined at the front that's going to ruin it, i'll have to work out a way around it :-\
Re: RFC: re-squared-dux ...
Posted: Wed Jun 08, 2011 12:16 pm
by Eric Walch
Simon B wrote:Just checking how the new-style subentities are supposed to work...
Your code should work when two missing semicolons are added. And when the orientation or position has the default value, you just can ignore the entries. So, the following should work
Code: Select all
subentities = {
"carrier1-dock" = {
type = "standard";
is_dock = true;};
"carrier-turret" = {
type = "ball_turret";
position = (-9.48 38.99 188.07);};
};
Re: RFC: re-squared-dux ...
Posted: Wed Jun 08, 2011 12:39 pm
by Eric Walch
Killer Wolf wrote:The dock for one of my new stations is a much longer tunnel than normal stations, if the origin is defined at the front that's going to ruin it, i'll have to work out a way around it :-\
The origin of the dock is the position value defined in shipdata. When the dock is long enough, you could define the docks origin a bit more to the centre of the dock and use a corresponding value in shipdata. For checking if a ship is docked, the code only checks the position defined in shipdata. It is about 90% that must have past the position when I read it correct and not the 75% I mentioned before. But the code is a bit complex as it also corrects a bit for not entering perpendicular.
Re: RFC: re-squared-dux ...
Posted: Wed Jun 08, 2011 1:37 pm
by Killer Wolf
so just to clarify, cos i'm feeling a bit thick at the mo : that position attribute is just for info, it doesn't actually move the dock model itself? it's just a point in space that you have to pass to dock? The wiki suggests it's the subent position, which is why i'm getting baffled as that just sounds like the above situation, of having to build a dock at origin then shift it.
Re: RFC: re-squared-dux ...
Posted: Wed Jun 08, 2011 2:11 pm
by JensAyton
Commander McLane wrote:If you want to find out what a ship does and why (or why it doesn't do what you want it to do) AI-logging is what you need. I'm not sure how to enable it for one ship without using the JS-console, but I'm sure others will be able to help.
ship.reportAIMessages in Jibblywobblyscript.
Re: RFC: re-squared-dux ...
Posted: Wed Jun 08, 2011 8:01 pm
by Thargoid
Killer Wolf wrote:so just to clarify, cos i'm feeling a bit thick at the mo : that position attribute is just for info, it doesn't actually move the dock model itself? it's just a point in space that you have to pass to dock? The wiki suggests it's the subent position, which is why i'm getting baffled as that just sounds like the above situation, of having to build a dock at origin then shift it.
In Wings3D (or whatever) place the model so that the origin (0,0,0) is in the centre of the front of the docking bay (or to put it another way, there is nothing in the +z direction beyond 0, the whole dock is "behind" the plane made by the X-Y axes).
Then use the sub-ent position when you make your shipdata.plist file for the mother to move the position of the dock sub-ent to the correct place. So if the dock sub-ent is defined as above, then that position would be in the centre of the hole you've cut in your model for the bay.
Hope that makes it a little clearer?
Re: RFC: re-squared-dux ...
Posted: Thu Jun 09, 2011 12:59 am
by Simon B
Ah - that's more like what I thought!
When sufficient ship crosses the dock x-y plane, it docks.
It s safest to put the dock x-y plane at the mouth of the dock to avoid ships attempting to dock slamming into the back wall.
In my carrier - I have separated the bits I intended to be smoothed and consigned them to a subentity - the only major subentity. It looks like I will need to calve off the docking bay as well.
An alternative would be to create another entity either enclosing the docking bay just outside it or perhaps as a small design feature inside the bay itself - rows of lights say - I can reposition this model to make the docking process work the way I want.
Re: RFC: re-squared-dux ...
Posted: Thu Jun 09, 2011 6:22 am
by Killer Wolf
Thargoid wrote:Killer Wolf wrote:so just to clarify, cos i'm feeling a bit thick at the mo : that position attribute is just for info, it doesn't actually move the dock model itself? it's just a point in space that you have to pass to dock? The wiki suggests it's the subent position, which is why i'm getting baffled as that just sounds like the above situation, of having to build a dock at origin then shift it.
In Wings3D (or whatever) place the model so that the origin (0,0,0) is in the centre of the front of the docking bay (or to put it another way, there is nothing in the +z direction beyond 0, the whole dock is "behind" the plane made by the X-Y axes).
Then use the sub-ent position when you make your shipdata.plist file for the mother to move the position of the dock sub-ent to the correct place. So if the dock sub-ent is defined as above, then that position would be in the centre of the hole you've cut in your model for the bay.
Hope that makes it a little clearer?
that's how i used to do it, for the Nuit etc, it just seemed from the way i was reading it that things had changed. my bad. current thought is to place my tunnel w/ the origin 90% along the length of the tunnel and shift the model into position so that (i hope) you get to fly along the tunnel before hitting the dock trigget at the end.
Re: RFC: re-squared-dux ...
Posted: Thu Jun 09, 2011 9:53 am
by Simon B
Hmmm debug console ... ./DebugConsole.py ... ^M error - hell: The debug console script is in DOS format!
$ cat -e DebugConsole.py
#! /usr/bin/python^M$
#^M$
Confirmed ... okaaay: now to see if I can remember how to convert it.
$ flip -u *.py
yep - that was it.
OK - start console, it says "waiting for connection" ... start Oolite, select a commander and launch ... try to click "run" and it asks me to restart oolite ... then it just sits there.
Re: RFC: re-squared-dux ...
Posted: Thu Jun 09, 2011 10:14 am
by another_commander
You also need to install the Basic-debug.oxp. Once you have it installed, run the console, the run Oolite and you should be able to see the console establishing a connection with the game. Once that is done, you can interact with the game in realtime. You generally do not have to click the Run button.
Re: RFC: re-squared-dux ...
Posted: Thu Jun 09, 2011 11:21 am
by Simon B
Thanks AC - twas what was needed ... discovered that some scripts weren't loading as I'd renamed them on the outside but neglected to rename their references on the inside. All done now. Also treated the secondary entity as a dock, even though it aint the physical dock, and that made the docking work properly. Shot it with rear laser on the way out and got pulverized by the carrier's 5x fwd mil lasers cool AND saw it launch a defender. I'll add the glows and upload an oxp for people to play with. Prob by the weekend my time.
Re: RFC: re-squared-dux ...
Posted: Fri Jun 10, 2011 5:02 am
by Simon B
SB-Navy.oxp
... adds one large carrier (the big triangular one from before) with a naming scheme based on Norse Gods or other godlike beings.
... you need the re2dux oxp installed or the defence ships won't work - these are place fillers, I'll add dedicated navy versions later.
At the mo I'm puzzled that it wont respond to docking requests ... it doesn't need a request, but it should say so.
I'm hoping that folk here will try it out and generally destruct test it find all the holes, maybe fill a few, before I add the other carrier.
Oh - and it is crying out for a normalmap ... anyone want a go?
Re: RFC: re-squared-dux ...
Posted: Sun Jun 12, 2011 5:29 am
by Simon B
re2dux.oxp updated - added rockhermit, glows to the thargoids, that sort of thing.
Re: RFC: re-squared-dux ...
Posted: Sun Jun 12, 2011 2:22 pm
by DaddyHoggy
Simon B wrote:re2dux.oxp updated - added rockhermit, glows to the thargoids, that sort of thing.
Excellent - nice one Simon!
