Changing Toyland to futuristic space colony
Moderator: Graphics Moderators
@Red*Star: they're cool, but the left one looks like a Sovereign's engineering hull
I hope it's not an accident
:D:D
Edit:
BTW we should ask the patchteam if the planes (spaceships) can be stopped in the air (well, "land" at 2 levels above airport), and they have to load/unload freight/passangers by transporter beam
:D:D
"Hey Scotty! Beam me up!"


Edit:
BTW we should ask the patchteam if the planes (spaceships) can be stopped in the air (well, "land" at 2 levels above airport), and they have to load/unload freight/passangers by transporter beam

"Hey Scotty! Beam me up!"
Author of Hungarian signal set Current version: 0.2b, Semaphore drawing in progress.Linux is like a wigwam: no Gates, no Windows, Apache inside...
Do you really mean >the< Sovereign class? If so, I really don't see the similarity apart of the fact that it has two pylons and one thing that looks like a deflector (although it's actually two deflectors...) At least the warp nacelles don't have any similarity: http://users.sisna.com/roguewing1/schem ... ereign.jpg

Actually I like more the "non-fictional" ships - I mean those ships that can be seen on screen, except the NX-01. It looks lika an Akira class ship with no armature tower and somebody stepped on

Author of Hungarian signal set Current version: 0.2b, Semaphore drawing in progress.Linux is like a wigwam: no Gates, no Windows, Apache inside...
Unfortunately yes... I mean, the Akira does looks great, I have a big picture of the port view hanging above my door - but I want to know whose crazy mind came to the idea to disfigure the Akira so much as it has been done in ST:Ent...chipetke wrote:really.. forgot that the Soverign class' pylons are located at the end of the hull, and the nacelles are parallel and have a more aerodynamic shape.
Actually I like more the "non-fictional" ships - I mean those ships that can be seen on screen, except the NX-01. It looks lika an Akira class ship with no armature tower and somebody stepped on

(To say nothing about that the NX-01 looks much too modern for the time the series plays in...)
Back on topic: Thank you for the commendationon the models, chipetke

The landing/docking point is also a good idea, I also thought about how to impliment a "docking process" for our space vessels


Edit:
Have forgotten that planes have shadows. So my idea won't work - unless at least the shadows will be moved 32 px downwards, like in the spacesport-muckup I've just created.
Ouuch... that's another point which comes into my mind: We won't have diffuse light in space, so shadows will be completely black, unless other light sources are near them. But in TTD shadows are always grey... (!)
- Attachments
-
- Shadow will be a problem...
- spaceport.png (45.44 KiB) Viewed 3744 times
Floating while loading/unloading: IMHO this can be achieved by "misplacing" the sprites. This is a really reqired thing since there are very few ships that can land on surface (mostly smaller ships - Intrepid, Defiant, ...). I'm not sure if "yofs" sprite parameters have to be decreased or increased in the .nfo file.
Plane shadows are dropped by the graphic engine or they are sprites too, made up with an action colour? If they are sprites, we're saved and able to do these ST ships
Edit: Verrrry nice mockup
Would be cool, if ships could dock in for loading/unloading, but I think, it's impossible. if we draw the sprite one tile forward by "xofs" & "yofs" it can work for one docking port, but for another port it's located wrong..
and can make the sprite sorter go crazy...
The floating method seems much easier...
Plane shadows are dropped by the graphic engine or they are sprites too, made up with an action colour? If they are sprites, we're saved and able to do these ST ships
Edit: Verrrry nice mockup

Would be cool, if ships could dock in for loading/unloading, but I think, it's impossible. if we draw the sprite one tile forward by "xofs" & "yofs" it can work for one docking port, but for another port it's located wrong..

The floating method seems much easier...
Author of Hungarian signal set Current version: 0.2b, Semaphore drawing in progress.Linux is like a wigwam: no Gates, no Windows, Apache inside...
Kewl, nice ship Killer 11
.
The problem with all our ships is: If we render them too big, it will cover too much tiles and cause problems with clipping when docked, if we render them too small, you can't see anything of the details
.
I think we must find a scale for each single ship that is a compromise between these two poles...
@chipetke:
Plane shadows are made by the graphic engine by using the transparent blue of the sprite as a mask: The non-blue area is made transparent grey (I think the same way transparencies of station roofs are done).
(So it won't make sense to adapt the sprite xofs and yofs, because the shadow will move with the plane... and we probably will become problems with the clipping.)
Because also the shadow color is not sufficient to our needs (as I already said, it has to be completely black for the space mod) we so or so have to ask a developer to code us a space mod.

The problem with all our ships is: If we render them too big, it will cover too much tiles and cause problems with clipping when docked, if we render them too small, you can't see anything of the details

I think we must find a scale for each single ship that is a compromise between these two poles...
@chipetke:
Plane shadows are made by the graphic engine by using the transparent blue of the sprite as a mask: The non-blue area is made transparent grey (I think the same way transparencies of station roofs are done).
(So it won't make sense to adapt the sprite xofs and yofs, because the shadow will move with the plane... and we probably will become problems with the clipping.)
Because also the shadow color is not sufficient to our needs (as I already said, it has to be completely black for the space mod) we so or so have to ask a developer to code us a space mod.

Neither. yofs is the location in the PCX.chipetke wrote:Floating while loading/unloading: IMHO this can be achieved by "misplacing" the sprites. This is a really reqired thing since there are very few ships that can land on surface (mostly smaller ships - Intrepid, Defiant, ...). I'm not sure if "yofs" sprite parameters have to be decreased or increased in the .nfo file.
Neither. Shadows are the exact same sprite as the plane. So a airplane set to "land" to units above the ground will also cast a shadow two units above the ground.chipetke wrote:Plane shadows are dropped by the graphic engine or they are sprites too, made up with an action colour? If they are sprites, we're saved and able to do these ST ships
Correction "it won't make sense to adapt the sprite xofs and yofs because then the sprite will have to be moved in the PCX too, unless you want nasty white blocks in the sprite."Red*Star wrote:(So it won't make sense to adapt the sprite xofs and yofs, because the shadow will move with the plane... and we probably will become problems with the clipping.)
But even if you change the correct metadata (xrel/yrel), you'll still have the same problems.
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
/me thought about the sprite positioning ingame not the pcx coordinates 
But if it's impossible
... but I still want'em 


But if it's impossible


So the shadows are calculated from the current height of plane, and the plane sprite itself... no goodDaleStan wrote:Neither. Shadows are the exact same sprite as the plane. So a airplane set to "land" to units above the ground will also cast a shadow two units above the ground.chipetke wrote:Plane shadows are dropped by the graphic engine or they are sprites too, made up with an action colour? If they are sprites, we're saved and able to do these ST ships

You are possibly wrong. As I remember the wiki well (and some forum posts) station roofs are made with a special "semi-transparency-yellow" action colour. But they are made up with two sprites, the normal roof graphic, and the semi-transparency mask sprite which contains only that special (?) yellow colourRed*Star wrote:Plane shadows are made by the graphic engine by using the transparent blue of the sprite as a mask: The non-blue area is made transparent grey (I think the same way transparencies of station roofs are done).
Author of Hungarian signal set Current version: 0.2b, Semaphore drawing in progress.Linux is like a wigwam: no Gates, no Windows, Apache inside...
Yes, I am wrong, if you interpret what I said in this way. But that's my fault because I expressed myself unclear
However, I /meant/ that the /transparency/ is done in the same way, not that the pixels which /are transparent/ are calculated the same way.
I know that for the stations the magic yellow is used (and, I have made the experience that it is so while I tried to code my own station) to determine transparent pixels.
Hope now it's clearer

However, I /meant/ that the /transparency/ is done in the same way, not that the pixels which /are transparent/ are calculated the same way.
I know that for the stations the magic yellow is used (and, I have made the experience that it is so while I tried to code my own station) to determine transparent pixels.
Hope now it's clearer

That is NOT, repeat NOT, a special color. Transparency is a function of how the sprite is drawn, not which colors are in the sprite. (http://wiki.ttdpatch.net/tiki-index.php ... oordinates and http://wiki.ttdpatch.net/tiki-index.php ... lorSprites)chipetke wrote:special "semi-transparency-yellow" action colour.
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
I (think I) understand... without patch programming the whole idea with ST ships is impossible.. but I can suspect that on the asteroids there are some dust that makes some diffuse light, and I can believe
that all of them can land on surface. Because they are so beautiful 
My english is very far from perfect, so I could misunderstood it even if you said it perfectly

I only hope that the rest of my post was correct. OK, it's not a special color. simply this was chosen to draw the mask... 
I'll go and get deeply into the wiki..


My english is very far from perfect, so I could misunderstood it even if you said it perfectly


okay, okay, okay... please calm down...DaleStan wrote:That is NOT, repeat NOT, a special color. Transparency is a function of how the sprite is drawn, not which colors are in the sprite. (http://wiki.ttdpatch.net/tiki-index.php ... oordinates and http://wiki.ttdpatch.net/tiki-index.php ... lorSprites)chipetke wrote: special "semi-transparency-yellow" action colour.


I'll go and get deeply into the wiki..
Author of Hungarian signal set Current version: 0.2b, Semaphore drawing in progress.Linux is like a wigwam: no Gates, no Windows, Apache inside...
No problemchipetke wrote:My english is very far from perfect, so I could misunderstood it even if you said it perfectly


DaleStan: It's right, cool down a little bit. Just because you are deeper in the TTD programming structures then we are you don't have to shout. Just relax and don't be so harsh - please - that makes the atmosphere here much more pleasant

I've been fighting that misconception for over a year now, and I thought it had finally vanished.
Discovering that something like this has, in fact, not vanished, makes me a rather unhappy camper, and results in posts that probably should not have been posted.
It's not personal. Basically everyone who speaks falsehoods gets corrected. Some more harshly than others, but that's more a function of the falsehood than the speaker.
Discovering that something like this has, in fact, not vanished, makes me a rather unhappy camper, and results in posts that probably should not have been posted.
It's not personal. Basically everyone who speaks falsehoods gets corrected. Some more harshly than others, but that's more a function of the falsehood than the speaker.
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Who is online
Users browsing this forum: No registered users and 5 guests