Unused features

[A Former User]

attachment_archetype it must be in [Good] section - right?

[Thaddeus]

attachment_archetype, was this perhaps used for attaching weapon coolers and other “enhancement” models like the ge_weapon_cooler.3db which looks like it should fit over something. just a thought

[LancerSolurus]

I haven’t run a debug test but it is smack in the middle of the goods reader code….

It is called by GoodInfoList::read_Good_block(INI_Reader *,GoodInfo *)

The command above it is ‘HP_Child’ and below is ‘hull’.

 loc_6270A40:                            ; CODE XREF: GoodInfoList::read_Good_block(INI_Reader *,GoodInfo *)+403j
.text:06270A40                 push    offset aAttachment_arc ; "attachment_archetype"
.text:06270A45                 call    ?is_value@INI_Reader@@QAE_NPBD@Z ; INI_Reader::is_value(char const *)
.text:06270A4A                 test    al, al
.text:06270A4C                 mov     ecx, ebx
.text:06270A4E                 jz      short loc_6270A7A
.text:06270A50                 call    ?get_value_string@INI_Reader@@QAEPBDXZ ; INI_Reader::get_value_string(void)
.text:06270A55                 lea     ecx, [esp+0F4h+var_B4]
.text:06270A59                 mov     esi, eax
.text:06270A5B                 call    ?clear@CacheString@@QAEXXZ ; CacheString::clear(void)
.text:06270A60                 push    1
.text:06270A62                 push    esi
.text:06270A63                 call    ?StringAlloc@@YAPADPBD_N@Z ; StringAlloc(char const *,bool)
.text:06270A68                 add     esp, 8
.text:06270A6B                 mov     [esp+0F4h+var_B4], eax
.text:06270A6F                 mov     [ebp+84h], eax
.text:06270A75                 jmp     loc_6270D8E
.text:06270A7A

[adoxa]

Attachment_archetype is usually just copied from the equipment’s archetype (attachment_archetype is an alias for DA_archetype in that case). The EngClass plugin requires specifying attachment_archetype (since that’s a case where it doesn’t get copied), otherwise it won’t work right.

[A Former User]

Intresting, that:

[Loadout]
nickname = MSN01a_Large_Transport
archetype = ge_large_transport ; <- ship have self cargo space
equip = ge_s_scanner_02
equip = infinite_power
equip = sfx_rumble_ut_large
equip = ge_tl_engine_01
equip = co_transport_turret01_mark01, HpTurret_U1_01
equip = co_transport_turret01_mark01, HpTurret_U1_02
equip = co_transport_turret01_mark01, HpTurret_U1_03
equip = co_transport_turret01_mark01, HpTurret_U1_04
equip = co_transport_turret02_mark01, HpTurret_U3_01
equip = SlowLargeWhite, HpRunningLight05
equip = SlowLargeWhite, HpRunningLight10
equip = SlowLargeWhite, HpRunningLight11
equip = SlowLargeWhite, HpRunningLight12
equip = SlowLargeWhite, HpRunningLight13
equip = DockingLightRed, HpDockLight01
equip = DockingLightRed, HpDockLight02
equip = DockingLightRed, HpDockLight03
equip = cargopod_red, hpcargo01
equip = cargopod_red, hpcargo02
equip = cargopod_red, hpcargo03
equip = cargopod_red, hpcargo04
cargo = commodity_food, 1000, hpcargo01 ;<-And? cargopod_red may contain unlimited positions of cargo?
cargo = commodity_food, 1000, hpcargo02 ; -//-
cargo = commodity_pharm, 1000, hpcargo03 ; -//-
cargo = commodity_pharm, 1000, hpcargo04 ; -//

Theoretically player may extend cargo bay by buying cargopods…

[Skotty]

But that commodities are already in these cargopods. If you buy a ship with this configuration the cargopods will just once include these commidities. After they exploded, the cargopod and the commodity is gone. Theoretically they are not displayed in your cargo space.

[A Former User]

But! We have mines, cms and guns that needs ammo…

Cm as cargopod, commodity as ammo, hmhmhmhmhmhmhmhmh…

[A Former User]

lgt_time_scale <- effects.ini [effect] - time of lightning
jump_done_effect_nonplayer <- jumpeffect.ini [JumpShipEffect] - effect when jump is done for NPC?
jump_done_effect_player <- jumpeffect.ini [JumpShipEffect] - effect when jump is done for Player

[RimShot]

CollisionGroup types:

Engine
Port_Engine, Middle_Engine, Starboard_Engine
Top_Engine, Bottom_Engine

docking_sphere property:

pad

[AestheticDemon]

dpcking property ‘pad’ works just like ‘berth’ except the radio messages are ‘i need to land’ and ‘you are cleared to land’

berth docking ships can use pad dockmounts without editing their mission props, you would only use the pad reference in the xml for your dockable solar, not in the actual ships…

there is also a small moor type (not used in vanilla fl) that needs adding to the xml for your dockable solar, and to the ships meant to use the new moors

on the gun front…

gun_elevation =
gun_azimuth =
dispersion_angle =

[w0dk4]

gun_elevation =
gun_azimuth =

What do these do?

[A Former User]

Elevation - angle of a barrel.
Did tried to setup it vertically (90 degrees) - no luck.
May be i take not right turret.

Azimuth - dirty saying certain degrees to left or right.

[adoxa]

They’re read, tested for validity and stored, but not accessed, so they do nothing.

[AestheticDemon]

So it’s a question of what SHOULD they do…

Elevation, at a guess should set the default elevation of a gun, so for example if you mounted a hardpoint on an angled part of the hull, rather than the barrel starting parallel to the hul, you could set a default elevation os it pointed forward rather than upwards or downwards.

Azimuth is the same thing for rotation, old naval term, angle of bearing, you use an ‘azimuth mirror’ to take bearings and elevation angles when doing observational fixes in coastal navigation, top of the lighthouse is elev x degrees, bearing y degrees, etc, so you can plot the stuff on your chart to fork out a ‘fix’ (accurate calculated position rather than a ‘dead rekoning’ estimate based on heading and speed).

[RimShot]

i guess they should override the limitations set in the archetype file.
if i remember correctly elevation limit is in the Rev node, and azimuth in the hardpoint min/max.

[AestheticDemon]

Erm, not really… it’s setting the ‘gun not doing anything so park it at’ settings WITHIN the limits set in the hardpoint…

So, hypothetically, if they worked…

You mount hpturret01 on a part of the hull that slopes down at 30 degrees to the ships nose, so the default ‘rest’ position of the gun would be pointing down at 30 degrees towards the ships nose, barrel angle relative to turret base 0 degreres plus turret angle relative to hull its mounted on 0 degrees plus angle of hull -30 degrees…

Assuming the commands worked, you would use elevation=30 azimuth=0 to set the barrels rest position so the gun pointed straight forward relative to the ship, rather than aiming downwards past the nose… just a cosmetic feature really.

[A Former User]

goto_guide
dock_guide
patrol_guide

Seems to be behaviour of an encounter, but gives instant server crash

[A Former User]

Got new_encounter_example.ini in vanilla ))

If someone does not know yet:
ship_by_npc_arch = <nickname from=“” npcships.ini=“”>area_defend.ini example:

[EncounterFormation]
ship_by_npc_arch = 1, 1, gd_bh_bh_elite2_d19
pilot_job = defend_leader_job
make_class = wanderer
ship_by_npc_arch = 1, 2, gd_bh_bh_elite2_d19, -1
pilot_job = defend_job
make_class = wanderer
formation_by_class = fighters
behavior = wander
arrival = all, -tradelane, -object_jump_gate,
allow_simultaneous_creation = yes
zone_creation_distance = 0
times_to_create = infinite

[Creation]
permutation = 0, 3

As bonus:
object_capital - what does this mean? From station which is capital or from capital NPC? oO</nickname>

[A Former User]

const_effect_delay = <float>seems to be no effect</float>

[A Former User]

Under [CollisionGroup]:

linked_equip = <float>Not tested. State of glue to the parent part?

destoy_parent = <bool>Jeider’s research:
destoy_parent = true - destroys whole object if this part is destroyed instead of root_health_proxy = true that gives only damage to the root which have more hit points than this part</bool></float>