bad news :

- i didn't manage to make the rock collisionable, although I have the same controller as on my previous test (and rock was collisionable)

- the top mark is still plain black

- it's impossible to place the rock precisely in relation to the lighthouse

:damn:

We will sort it out. :03:

The controller used for making this kind of objects collisionable, is the StaticObject controller. I had placed one in the rock object, but you should explain first how you used it, and if/how you 'converted' it. I still what you meant in your previous post :doh:

This top mark issue is driving me crazy: I still don't get why the same material/texture looks okay on the lantern, but not on the mark :hmmm:

Sure it is possible but if I got you correctly when we fisrt discussed the topic a few month ago, the position of terrain objects is always dictated by the coordinates of their 3D meshes. You must estimate by how many meters the rock needs to be raised/lowered, export its meshes using S3d, move the object in Wings, and re-import them in the dat file. As I told you, a ruler object will help greatly; let me know if you still want it :salute:

A terrain object is a .dat file that is placed in data\Terrain\Locations, as the harbours. It has a .tga file with the same name which represents the aspect of the harbour on the navigation map.

I first tested with your controller, and the rock was "ghost".

Then, I realised that something was missing :

http://i.imgur.com/pz7KtW9.png

I tried with 30 and 200, but still the rock remains "ghost".

I have reworked a bit the 3D model of the rock, so now the origin point of the rock and the lighthouse are exactly on the same vertical axis. The problem is that land units and terrain objects are not using the same unit to measure the coordinates. While the land units' coordinates are measured with meters, the objects' coordinates are measured with degrees. In mission editor, coordinates of your cursor are shown in both units, but if you write them in the mission's file (in meters) and in the Locations.cfg (in degrees), both model are separated by at least 10 meters .... :nope:

So, I can place manually the land unit just on the point showing the terrain object's location in mission editor, but still it remains imprecision.

Looking at the LLH_LaPlate.dat file, there are 2 textures:-

One called LH_LaPlate.tga with label "LaPlate_Concrete"
the other called LH_LaPlate.tga with label "LaPlate_Metal".

Am I wrong in thinking the one labelled "LaPlate_Metal" should have texture
LLH_LaPlate.tga which shows as a little white square. Haven't got access to SH3 at the moment, so can't test - just an observation.

What I did do is include the rock as a node in the LLH_LaPlate.dat file, and I could easily and accurately put the lighthouse on the rock using the translation co-ordinates in S3Editor.

Not sure I follow the use of seperate models in the library directory.

Please excuse my input if completely wrong as you two are way ahead of me on this.

regards,

MLF

The texture is external (in TNormal folder).

Yes, I'm thinking about this too. Why separate rock and lighthouse ?

Yes indeed I know that, but I am pretty sure that any object can be used as a terrain object, no matter whether it is located in the Terrain folder or not.

Doh, I copied/pasted the controller from one of the Maunsell forts by Jeff without actually looking into its content. Knowing him, he probably hex-edited the file, and possibly something in the StaticObject properties went lost during the process. Thank you for tracking down this mistake!

I still see an unfixed possible error though: while digging into stock files, I have noticed that the container used for the StaticObject controller, is usually of the type 10 / 1000, not the more common 10 / -1 :yep:
Here is my fix:

http://i.imgur.com/Xj7Dfwf.jpg

I hope you get my point :)

You once told me that terrain objects' vertical position is always relative to the sea level, whereas land units get linked to the terrain/seabed. Is that correct?

If yes, no matter how good you match the two parts in wings 3D, you will still need to measure their relative (vertical) distance in game, and make the appropriate changes in Wings3D based on that measure.

With this idea in mind, I have created a ruler tool that you can use for measuring heigths in game. You can see a detail of it below:

It is 30 m long (but if need be I can do it even longer), and it is marked every 10 m, 5 m, 1 m, 50 cm and 10 cm. For ease of reading, the 5 m marks are coupled with a yellow/white banding. If you think it can ease your work, you can download it from the following link:

http://www.mediafire.com/file/9lit7l...hz/Ruler30m.7z

We are talking about horizontal position, right?

I knew that choosing to set the rock as a terrain object, though more logical, would have caused this sort of problems. That's why I asked you how you wanted me to set it. No problem is insurmontable though.

There is a linear relation in the SHIII world between lat/long degrees and metric offsets so no big problem here: despite the different system of coordinates adopted, we can place the two parts exactly at the same spot. :up:
I once had a converter by TheDarkWraith. I cannot find it anymore, but I can create something similar for you :03:

Your suggestion is not pointless at all MLF, and initially I thought to set the rock that way. At the and I opted for two separate objects, mainly for the following reasons:

- If the lighthouse is destroyed during the campaign, or if at some point it must be removed from game (according to historical data on its destruction), the rock would diasappear too, and I didn't want that: the submerged danger should keep there.

- Kendras told me that he wanted to couple each lighthouse with a colored icon. This is only possible by placing a dummy terrain object at the same position as the lighthouse land unit. Since we are at it, I thought, why not to attach the rock to it?

Kendras is right in saying that the texture is external, and the same material/texture works perfectly for the lanter; I don't see why it shouldn't work for the mark unless there are restrictions on the usage of the same material on multiple objects, but I don't think so.
By the way, this is how the illfamed top mark should look like:

http://i.imgur.com/9A1NoBM.jpg

Dark grey. Very dark, but if in game it looks pitch black it means that the texture is not rendered. On a side note: the render above is taken from S3d, just to say that everything seems okay in the file. :doh:

Stay tuned for a new beta release within the next 30 minutes :salute:

What is the LLH_LaPlate.tga file for in the Library folder for? Doesn't seem to be referenced either in LLH_LaPlate.dat, Lighthouse_Parts.dat or Lighthouse_FX.dat?

I'm trying to understand (perhaps I shouldn't :o) how this all hangs together. I've bee importing a couple of models from sketchup, but each part has individual texture files (quite laborious) rather than one big one.

interesting work! :Kaleun_Thumbs_Up:

Tourelle de la Plate alpha v5
 

http://www.mediafire.com/file/lf45bu...La_Plate_v5.7z

A few changes here. Nothing drastical:

- I have set the rock as a proper terrain object, and I have fixed its StaticObject controller as described in my previous post. Hopefully, this will make the rock collisionable as it should.

- I have created a tga mask for the lighthouse, which is linked to the rock object. The icon is inspired by modern nautical charts, no idea how beacons were marked in German charts of the 30s-40s. I hope you like it: :D

http://i.imgur.com/Pfh4gZR.png

- I have thought that in future we might need some generic day beacons similar to the Petite Vielle, so i decided to remove the light platform from the main model, and to make it into a configurable equipment, same as the lantern and top mark. You shouldn't notice any visual change in game. If you do, I messed up something :O:

- While separating the tower and the platform, I have noticed a small misalignment of a mesh in one of the beams holding the platform. The error is fixed, but I had to do some slight changes in the texture.

- I have added water reflections to the lighthouse and to all of its library subparts. The reflections models I have used, are low-poly versions of the corresponding main models. I made an automatic, quick and dirty poly reduction, and the resulting models have many distortions. Water reflections are distorted anyway, so you probably wont notice how messy are those models, but I plan for one of the next releases to reference the main models as reflection models. Supposing that this is going to be possible, that would result in excellent reflections with no extra file size :03:

For the moment, I think that's all.
My next contribution to this project, will be a lat/long converter based on an excel spreadsheet. Creating it shouldn't take too long :salute:

The name of the texture file is 'LH_LaPlate.tga', with one 'L'. If you look at any of the materials using it, it is referenced: the 'Enable explicit texture' checkbox is checked, and 'Texture name' field is set to 'LH_LaPlate.tga'. This is all it takes for the game to look for the correct texture in the unit's/object folder, or in one of the 'Textures' subfolders.

Either I didn't get your point, or you are confusing texture linking with texture embedding. When the latter method is used, textures are stored directly in the dat file, and no external texture is required. I din't want embedded textures though, because in my model multiple materials share the same texture; if I embedded it multiple times, one for each material using it, I would have unnecessarily increased the disc and RAM memory usage. The way I have it, in theory the texture is loaded in memory only once (if devs made a clean job).
Moreover, using texture linking over texture embedding enables an higher degree of flexibility. SHIV and SH5 modders are familiar with linked textures which are set as configurable (similar to sensors and equipments). Unfortunately, this feature is reportedly supported by SHIII (ask Jeff Grooves on that) but unknown to most modders, and not used at all in stock game.

I know. Those sketchup guys must be crazy :doh: :D

Thank you for the encouragement Captain! :salute:

Yes, with placement nodes in the .dat file located in the Locations folder.

Mmhh ... not yet. :o

Yes, I aligned both models on the verticals axis : I mean both are exactly on the vertical axis, but not at the same place on this axis of course (separated by 1,7, so 17 meters, as you already did). The problem was that the rock was not adapted with the base of the beacon, so I moved it a bit. And yes, it was hard for you to understand what I was meaning. Sorry for that.

Cool ! :)

IMHO, it's not a big deal if a submerged rock is deleted somewhere in the sea.

Maybe for SH5, but it will be hard, and probably impossible to have it on the SH3 navigation map. The pic will be totally pixellised and not readable at all.

Just so you know : I won't be here the next few days.

:salute:

No problem, RL takes the priority :up:

I don't think that placemet nodes are essential: they are just an echomomic way to build harbors and town by assembling many common buildings. We might use them for complex rocks, but unless you have a practical reason for having them, let's keep things simple for the moment.

Have you downloaded the latest alpha? If you look into the rock file and you compare it with the previous version, you will understand at once :03:

I got you now :up:

Weird: I thought the two models were already "on the same axis", but I might have done some mistake. I will check my files

I am working on the unit converter now :up:

What's the point of navigation beacons, if not marking some hidden obstacles. How funny if the beacon is gone, and we ram the obstacle :D

So, what kind of icon did you have in mind?

SH Coordinates Calculator
 

Here it is:

http://www.mediafire.com/file/wff9pj...alculator.xlsx

This simple Excel spreadsheet does what the title says: you enter the world coordinates in degrees/minutes/seconds, and it returns the equivalent coordinates in decimal degrees and as in metric format, as used by the SH map projection. It should work for all the Silent Hunter games starting form SHIII

A note on SHIII: Decimal coordinates used for terrain object placement, have a precision of six decimals. In the cylindrical SH world this corresponds to a degree of accuracy of ±12 cm. For our purposes, this is more than enough. In theory, units' placement can be even more precise, but I have decided to round the results of my formulas so to ensure an exact match among the two notations.

The preset coordinates that the spreadsheer is coming with, are relative to the Tourelle de la Plate (measured in Google Earth).

@ Kendras
When you are back from your break, let me know if this tool solves your problems please :salute:

I for one thank you gap for the worksheet. It will be put to use as soon as I log out... |;^)

Thank you too mate. Whatever you are trying to accomplish, I am glad if my spreadsheet will ease your task :up:

Oh yes. Trying to split the Nav Map into increments of Lat / Long versus -242786.54326, etc... :lol: I've got the Lat & Long, just need to do the math for what the game uses, and this is ~SO~ much easier. I don't know where my brain was that I didn't think of something like this... :har: Thanks again. :salute:

I can update my calculator with a map projection in SH style that the deisired coordinate is plotted on for visual reference. Let me know if it can make your job easier :salute:

Do you mean like a "picture" overlay of a Nav Map representation - aka: BigMap.dds in SH4?... It probably would help to visualize, but not really necessary, I don't think... It would be cool though, sort of "Mod Tool" release worthy...

Exactly, but I took the overlay map from SH5

http://www.mediafire.com/file/3q83vc...ulator_V2.xlsx

There are two maps: one small map on the same sheet used for data input, useful for making sure that no input errors were done, and a big map in a separate worksheet that one can pan for checking how input coordinates match the SH world :)