shiplist.sst info needed

[thunderchero]

Will the slot scale (00 00 80 3F) affect the phaser hob animation?

don't think it has ever been tested
so it would have to be tested,

but I doubt it would have any effect, since size of vertex is 0.0, 0.0, 0.0. increasing by 400% would still be 0.0....

EDIT; confirmed no change when hob slot scale (00 00 80 3F) edited test 5.0 all values changed on all phasers (00 00 A0 40) looked exact same in game

Hob angle data might have not effect at all?

when I change the rotation of the vertex and then re-convert to hob, the hob is byte for byte the exact same.

So I conclude you might be right, during flt to hob conversion only position/scale data is used for phaser slots.

[Spocks-cuddly-tribble]

during flt to hob conversion only position/scale data is used for phaser slots.

You mean scale is stored in the hob but not used in game?

Sadly there is many unfinished features e.g. we cannot define custom weapon animations/scale/stats for each slot.
This requires an extra hob conversion tool and extensive trek.exe overhaul.

I guess they used the 45 degree orientation bitmask workaround to avoid the effort of an extra translation matrix for each phaser slot.

[thunderchero]

during flt to hob conversion only position/scale data is used for phaser slots.

You mean scale is stored in the hob but not used in game?

that is what I am trying to figure out lol
this is slot 1 of test model hob

Code: Select all

00000084h: 86 74 68 3E AC 3C 31 3F BB 6E D9 40 00 00 80 3F
00000094h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 3F 
000000a4h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 3F 

first 4 bytes 86 74 68 3E = 0.227007 (X position from center of model)
second 4 bytes AC 3C 31 3F = 0.692332 (Z position from center of model)
third 4 bytes BB 6E D9 40 = 6.794767 (Y position from center of model)
what is forth 4 bytes for? vanilla models and models we have created is always 00 00 80 3F

same for next 32 bytes they are always the same vanilla models and models we have created.

I am thinking during conversion flt 2 hob it does not matter if we use a 3 vertex polygon or a single vertex as phaser slot
converter will only use;
if single vertex x, y, z position used in hob phaser data
if 3 vertex polygon it will use first vertex of polygon and use that position as x, y, z position used in hob phaser data.

example;
from what I know right now, if I change the first 12 bytes of any phaser slot to all 00's phasers will fire from center of model

I just tested vanilla hu_a,b,c.hob with 0x98 -> 0x1e7 (all the phaser data) filled with 00's phasers still fire but from center of model.

[Spocks-cuddly-tribble]

I just tested vanilla hu_a,b,c.hob with 0x98 -> 0x1e7 (all the phaser data) filled with 00's phasers still fire but from center of model.

Why shocked? This is just as expected, based on your above statements.

The used hob phaser slot data is only the three coordinates, for position translation from the model centerpoint.

All other data is omited or unused (like slot scale).

Leaving you with position in the hob, plus firing direction and arc via trek.exe slot bitmask.

All other features are missing/unfinished.

[thunderchero]

with that all said this was my original question.

plus firing direction and arc via trek.exe slot bitmask.

what would the best firing direction and arc via trek.exe slot bitmask

lets say for the model in this tutorial
viewtopic.php?p=59824#p59824
at 12:50 you can see where all the hard points are on the model

what bitmasks values would you suggest for those 8 slots?

my old bitmask would have been 01 02 03 04 05 06 07 08
Dafedz would have used 01 01 01 01 01 01 01 01

Dafedz way would be better but no where close to optimal.

I am lost when it come to bitmasks.

[Spocks-cuddly-tribble]

at 12:50 you can see where all the hard points are on the model

what bitmasks values would you suggest for those 8 slots?

Four straight forward (medium arc 120 degree) = 01 (could be combined with 45 degree down?)

Two aft I'd go with aft/narrow arc 0x42.

The lateral, perhaps combined with 45 degree up and narrow arc = 0x54 amd 0x58 (left/right and up/down direction bits need to be confirmed).

my old bitmask would have been 01 02 03 04 05 06 07 08
Dafedz would have used 01 01 01 01 01 01 01 01

Dafedz way would be better but no where close to optimal.

Yours are random with even some invalid bitmask combinations (e.g. 03 and 07 is bits for forward and aft at the same time)
Dafedz is all = Straight forward (medium arc 120 degree)

I am lost when it come to bitmasks.

It's basically a combination of four multiple choice parts with three options each (bit 1, bit 2 or neither):

Code: Select all

1 - wide firing arc (180 degree)
2 - narrow firing arc (60 degree)

3 - down ?
4 - up ?

5 - right ?
6 - left ?

7 - rear
8 - forward

Let's try to clarify this with the logic of map directions: https://en.wikipedia.org/wiki/Cardinal_direction

1.) Cardinal directions are the four main compass directions: north, south, east, and west (90 degree intervals) = Bits for forward, rear, right, left.

2.) Combining two of them you get the ordinal directions northeast (NE), southeast (SE), southwest (SW), and northwest (NW).

3.) Cardinal directions plus ordinal directions give you 45 degree intervals (8 directions in total).

4.) Now picture a 3D sphere around your model by adding up and down directions/axis. This is 26 directions in total in 45 degree intervals.

5.) Choose one of the 26 valid directions best fitting for your slot.

6.) Set bitmask and your are done (when using vanilla default arc of 120 degree).

[thunderchero]

Yours are random with even some invalid bitmask combinations (e.g. 03 and 07 is bits for forward and aft at the same time)

5.) Choose one of the 26 valid directions best fitting for your slot.

6.) Set bitmask and your are done (when using vanilla default arc of 120 degree).

I hate to even ask, but my Pakled side is showing here.

could you provide a list of the 26 valid bitmasks with direction of each one? Please please please

this would also help other Pakleds who don't understand bitmasks like me.

I also promise to do my best testing every valid bitmask value you provide.

[Spocks-cuddly-tribble]

could you provide a list of the 26 valid bitmasks with direction of each one?

I'll try (one could just add 0x40/80 for narrow/wide arc), but first we need to know:

All slots 0x44 -> is this Port or Starboard?

All slots 0x50 -> is this Up or Down?

[thunderchero]

could you provide a list of the 26 valid bitmasks with direction of each one?

I'll try (one could just add 0x40/80 for narrow/wide arc), but first we need to know:

All slots 0x44 -> is this Port or Starboard?

All slots 0x50 -> is this Up or Down?

sorry to ask, but what would be the opposite value for each.

I am just guessing here 0x48 and 0x54?

I plan on making models with 4 on left and 4 on right
then next model 4 on top 4 on bottom
in MP game both ships in combat will be same model with high shields/recharge so they will never die
use different commands to get them in different positions to see how they fire.

[Spocks-cuddly-tribble]

You don't need any new models, just edit ALL trek.exe phaser slots to the same value.

It's just about if they can fire at target in direction (own ship will be ignored as none solid).

I.e. Starboard HOB slot with wrong Port orientation in trek.exe should fire in Port direction through the own ship with no issues.


0x44 / 0x48 Port / Starboard
0x50 / 0x60 Up / Down

All -> Straight/cardinal directions with narrow 60 degree firing arc.

[Flocke]

I hate to even ask, but my Pakled side is showing here.

information overload I'd say

let me try clean up this tribble riddle
for the phaser slots, we have 16 bytes stored in trek.exe per ship model slot
makes 1 byte each for 16 phasers max

essential information, I quote it again, is:

Bits 1-8 (read from right to left):

Code: Select all

1 - forward
2 - rear
3 - right
4 - left
5 - up
6 - down
7 - narrow firing arc
8 - wide firing arc

link is broken, but "read right to left" obviously refers to the binary representation of numbers
01h = 00000001
02h = 00000010
03h = 00000011
04h = 00000100
05h = 00000101
06h = 00000110
07h = 00000111
08h = 00001000

but since it's a BITMASK and he states "Bits 1-8", what is meant is:

Code: Select all

1 = 00000001 = 01h (horizontal: forward) where the rightmost bit is the lowest bit
2 = 00000010 = 02h (horizontal: rear)
3 = 00000100 = 04h (horizontal: right)
4 = 00001000 = 08h (horizontal: left)
5 = 00010000 = 10h (vertical: top)
6 = 00100000 = 20h (vertical: down)
7 = 01000000 = 40h (narrow firing arc / 60 degree)
8 = 10000000 = 80h (wide firing arc / 180 degree)

horizontal orientation can be combined for forward+left/right and rear + left/right giving the 45 compas orientation degree of

Code: Select all

00h = invalid / no orientation specified
01h = North
02h = South
03h = invalid (not set)
04h = West
05h = North East
06h = South East
07h = invalid (not set)
08h = East
09h = North West
0Ah = South West
0Bh = invalid (not set)
0Ch = invalid (not set)
0Dh = invalid (not set)
0Eh = invalid (not set)
0Fh = invalid (not set)

the firing arc has the following modes:

Code: Select all

00h = 00000000 = defaults to 120 degree
40h = 01000000 = narrow firing arc / 60 degree
80h = 10000000 = wide firing arc / 180 degree
C0h = 11000000 = turret / 360 degree

from a programmer perspective I wonder why not to use 8Ch for the turret, doubling the 180 degree firing arc
then why not also have a forwared-rear and a top-down turret and allow limit the turret firing arcs with narrow or default arc
then even combinations of 7h = forward/rear/left could be made valid and be the remainder of the east firing arc

but it would make code implementation more complex and SCT checked ASM code for combinations above:

0h = not set
1h = 0
2h = pi
3h = not set
4h = 1.5pi
5h = 1.75pi
6h = 1.25pi
7h = not set
8h = 0.5pi
9h = 0.25pi
Ah = 0.75pi
B-F= not set

0h, 3h, 7h, Bh and all above are not supported

I hope this is more Pakled conforming. And I already see next request to somehow integrate editing options to UE

---

0x44 / 0x48 Port / Starboard
0x50 / 0x60 Up / Down

@all Pakleds around, this is a combination of the narrow firing arc 40h with 04h=west, 08h=east, 10h=top and 20h=down, all to be confirmed
narrow angle I guess is proposed for better visibility

edit: list updated for exchanged left / right
edit2: fixed turret firing arc

[Spocks-cuddly-tribble]

Thanks Flocke, but as told some directions needed to be confirmed (left/right was wrong and therewith your list) plus turret is C0 not 0C.


I tested this using a vanilla Sovereign HH3 and got all direction values.

Note; due to a bug ships might occasionally misfire forward at the beginning of a battle even without any slots in this direction

List of the 26 valid direction values: (default firing arc 120 degree, for narrow 60 degree add 0x40, for wide 180 degree +0x80)


Straight Directions & Initials:

01 F - Fore
02 A - Aft
04 S - Starboard (right)
08 P - Port (left)
10 U - Up
20 D - Down

Combos:

05 FS
09 FP
11 FU
21 FD
15 FSU
25 FSD
19 FPU
29 FPD

06 AS
0A AP
12 AU
22 AD
16 ASU
26 ASD
1A APU
2A APD

14 SU
24 SD

18 PU
28 PD

narrow angle I guess is proposed for better visibility

It affects possible firing solutions i.e. blind angles for enemies to hide in and/or might fit better to the ship hull area.

Judging from other games it was meant for dual- and heavy cannons.

[Flocke]

Thanks Flocke, but as told some directions needed to be confirmed (left/right was wrong and therewith your list) plus turret is C0 not 0C.

fixed already was about to ask about firing arc 11000000

But then what happens when you specify some invalid orientation? Do they all default to fire from center of model with 360 degree firing arc?

[Spocks-cuddly-tribble]

But then what happens when you specify some invalid orientation? Do they all default to fire from center of model with 360 degree firing arc?

Position is still defined in the hob, but it loads some random crap data from esp into FPU for orientation calculations, so you get random firing directions or an occasional crash due to invalid values: https://www.youtube.com/watch?v=yBRZSD3RgKI&t=234s

[thunderchero]

see what happens when an old man goes to sleep...

now I have a lot more angles to test out...

thanks guys

I hope this is more Pakled conforming. And I already see next request to somehow integrate editing options to UE

well then you would also have to load model into hobview or something to load positions of phaser hard spots

hell while you are at it allow movement of hard spots lol

btw this is not a request

plus turret is C0

does the C0 have any "combos" example turret 360 up or turret 360 down?