Loadout implementation issue

More
21 years 8 months ago #5119 by Mehrunes

Originally posted by Flamineo

<sigh> Why can't even one thing be simple?


Careful, rumor has it Murphy died from sighing. [|)]

Please Log in or Create an account to join the conversation.

More
21 years 8 months ago #5124 by EricMan64

What it actually does is create an icWeaponLink subsim for each linkable weapon, with the same name as the parent real weapon. There must be some link between the icWeaponLink subsim and it's parent, but it looks to be buried where pog can't see it -- apart from making Sim.FindSubsimByName() potentially unreliable for weapons, I don't think these extra subsims do anything as far as pog's concerned.

I guess I'm going to have to try and see if I can make an icWeaponLink subsim. There doesn't seem to be any template with that class, so I'll see if I can make one that works.

Please Log in or Create an account to join the conversation.

More
21 years 8 months ago #5136 by Flamineo

originally posted by Shane
The ships are created by the Sandbox through

Thanks: that eliminates iShip.CreatePlayerShip(), which is what I'd been most nervous about. That increases the likelihood that the problem, whatever it is, is somewhere we can get at it and fix it. If I get sufficiently irritated with trawling 15k-character strings for errors, I might test a couple of possible causes over the weekend.

originally posted by Mehrunes
rumor has it Murphy died from sighing

The only Murphy I can think of off-hand exploded when someone accidentally turned on the gas in his garret, IIRC -- or, more succinctly, eh?

originally posted by EricMan64
I guess I'm going to have to try and see if I can make an icWeaponLink subsim.

I'm not sure you need to create the subsims explicitly (or that you could get them to work properly if you did) -- iMultiplay.LinkShipWeapons() adds the icWeaponLink subsims, and iMultiplay.UnlinkShipWeapons() destroys them. Incidentally, you need to be careful around them -- trying to Subsim.Destroy() them (or their associated weapons -- not sure which) can crash the game.

Further follow-up on the avatar issue: I had a look in the Avatar and SetupScene files for a couple of ships; this is from the storm petrel avatar:
Code:
[i]item 23[/i] LoadObject Objects_IW2\Human\Cal_Adult\RTO\Adult_Cal_JB_T.lwo ParentObject 51 [i]item 51[/i] AddNullObject <switch channel=adult_cal> &#91;...&#93; [i]item 52[/i] AddNullObject <switch channel=young_cal> &#91;...&#93; [i]item 53[/i] LoadObject Objects_IW2\Human\Cal_Kid\RTO\NewYoungCalJB_T.lwo ParentObject 52
I'd guess we could add similar switches to ships on which we want toggling weapon representations, make them parents of the LoadObject <weapon.lwo> objects, and manipulate them using pog channels. That's largely guesswork, since I don't have lightwave, and don't know what a lot of the values on scene objects mean (ShowObject? LockedChannels?).

The other question, of course, is whether we really care enough to bother -- it'd be a reasonably quick and easy job to remove all external weapon avatars, but adding scene objects and scripting switch controls would take rather longer, particularly if we start trying to add them on ships that don't currently have them.

Please Log in or Create an account to join the conversation.

More
21 years 8 months ago #5137 by Shane
Replied by Shane on topic Loadout implementation issue

item 23
LoadObject Objects_IW2\Human\Cal_Adult\RTO\Adult_Cal_JB_T.lwo
ParentObject 51
item 51
AddNullObject <switch channel=adult_cal>
[...]
item 52
AddNullObject <switch channel=young_cal>
[...]
item 53
LoadObject Objects_IW2\Human\Cal_Kid\RTO\NewYoungCalJB_T.lwo
ParentObject 52

I'm no Lightwave guru but it seems those lines are for placing the Cal_adult and Cal_kid into the cockpit of the storm petrel. These are only seen when the player is using an external view of his own ship and he zooms in very close.

There seem to be a liberal amount of switches scattered about EoC. There's even switches in the html encyclopedia documents, so that the quotes from the team do not show up in Act 0 (when young Cal had not met them yet).

The other question, of course, is whether we really care enough to bother -- it'd be a reasonably quick and easy job to remove all external weapon avatars, but adding scene objects and scripting switch controls would take rather longer, particularly if we start trying to add them on ships that don't currently have them.

Until a decision was made on this, I had planned to use the AI ships unchanged (avatar wise) in the game and use the player ships as different models (for example: the player's tug is represented as a different hull model than the AI tug).

Where possible, I've added the weapon null points so that they match up with something on the hull which looks like the muzzle of an internally mounted weapon. For instance, the puffin tug has the four wing-mounted launcher looking things. It does not seem so strange to see beams/bolts/missiles emerging from these points. The nulls don't always match up with something, but most of the time I can find a halfway decent point for a weapon avatar to exit.

Turrets will be far easier, and take a large amount of the burden on this. They are represented in-game and even animated. It should be possible to place them anywhere upon the ship where we place a null.

No confusion; just wrong or right ... Only Solutions

Please Log in or Create an account to join the conversation.

More
21 years 8 months ago #5140 by EricMan64
I think I may have found a problem with iMultiplay.LinkShipWeapons(). Take a ship with multiple beam weapons and try to use the function on it. Does the game crash for you too?

If it's not just me, the iMultiplay function might not be compatible with ships carrying multiple beam weapons.

Please Log in or Create an account to join the conversation.

More
21 years 8 months ago #5142 by Flamineo

originally posted by EricMan64
I think I may have found a problem with iMultiplay.LinkShipWeapons(). Take a ship with multiple beam weapons and try to use the function on it. Does the game crash for you to?

It's not just you. Bugger. Ok, back to trying to figure out what the normal game has initialised that Epic doesn't...

On a more cheery note, one of my dumbass ideas actually worked ('twas but a matter of time). While I remember how to do it, here's a speedy tutorial on using channels to control sub-object visibility; note that I have no real clue what I'm doing and haven't tested this elsewhere, so it may be missing critical information.

Find, add, or create and add the lightwave object representing your sub-object in the sim's setup file. For this example, I'm looking for the left-hand guns and missile launcher on the prefitted adv patcom. Sub-objects may have separate representations for each level of detail; I'm just looking at LOD0 for the moment. Scene files contain a bunch of stuff I don't understand at all (it looks like it's animation and lighting settings), and a series of blocks, each of which defines an object. These blocks are numbered, starting at 1, from the top of the file. In lws:/avatars/fastattackship/setup_prefitted, block 50 loads the avatar for the PBCs:
Code:
LoadObject Objects_IW2\Weapons&Effects\Pbc_cannons\<...> <...>RTO\LOD0_RTO_StandardPBC_T.lwo ShowObject 8 7 ObjectMotion (unnamed) 9 1 -24.45001 0 0.4 0 0 0 0.93 0.93 0.93 0 0 0 0 0 EndBehavior 1 LockedChannels 2 ParentObject 3 ShadowOptions 7
I still don't know what LockedChannels means, but I'd guess it's a hard-coded reference to a channel that the original loadout code uses to toggle whether the PBC avatar is visible or not. The parent of object 50 is object 3, the detail switch for LOD0:
Code:
AddNullObject <detail_switch min=0.1 max=1.0> ShowObject 4 7 ObjectMotion (unnamed) 9 1 100 0 0 0 0 0 1 1 1 0 0 0 0 0 EndBehavior 1 LockedChannels 6 ShadowOptions 7
To get pog control over object 50, we need to insert a switch object into the tree in between these two. Add this at the end of the object blocks (I've put it in before the 'AddLight' entries, which I think is safe; no idea if the object numbering continues into the AddLight entries -- if so, it might cause problems if the numbering of the lights matters):
Code:
AddNullObject <switch channel=left_pbc_vis> ShowObject [b]8 7[/b] ObjectMotion (unnamed) [b]9[/b] [b]1[/b] 0 0 0 0 0 0 1 1 1 0 0 0 0 0 EndBehavior 1 ParentObject 3 ShadowOptions 7
That's largely based on the young_cal switch in the storm petrel's setup.lws. I haven't the faintest idea what the bold items mean; their values are just copied. They do vary from file to file, though, so they may matter for something. 'ParentObject 3' is the most important bit -- this is the original parent of the PBC avatar.

Next, change 'ParentObject 3' on the PBC avatar to point to your new switch -- in the above case, to 'ParentObject 71'.

If you load the game and launch a player ship with this new setup file in place, it'll initially have no visible PBC. Also missing are the weapon latch linking the PBC to the ship, and the pylon-mounted missile launcher (this is because the PBC avatar is their parent object, so switching it off loses them, too -- I'll come back to that in a sec). You need to issue this pog command to make them visible again:
Code:
Sim.AvatarAddChannel ( iShip.FindPlayerShip(), "left_pbc_vis", 1.0 );
The string name of the channel in pog has to match the string name you've given the switch in the setup file. You can now toggle the visual representation of the PBC and its children with 'Sim.AvatarSetChannel(ship, "left_pbc_vis", [0.0/1.0])', and query it as 'Sim.AvatarChannelValue(ship, "left_pbc_vis")'.

That's fine, but you still can't hide the missile launcher without also hiding the PBC. To do that, create a second switch as object 72, with its parent set to 50 (the PBC), change the missile launcher's parent to 72, and initialise another sim avatar channel (called 'left_ml_vis', or whatever) as above; you can now toggle the PBC (which cascade-toggles the missile launcher), or leave the PBC visible, and toggle only the missile launcher using the new switch.

I now entirely disown and disavow all knowledge of the above, on the grounds I have enough do already without getting embroiled in modifying a bunch of ships to display special effects.

Shane: if you do want to make any use of this for loadout, let me know. We could add an avatar_switch_name[] value to the hardpoint data, which wouldn't require much more effort at my end. My personal take on this is that it's too cosmetic to be worth the extra time; it's the sort of polish item that'd be nice to return to later if we still have the momentum, but not before clearing to-do's that're required to get the game playable at all, never mind looking cute. If there're specific things anyone'd like done with it, though, I'll try to deal with them now (if nothing else, we could finally get rid of the accursed Cal avatar).

Please Log in or Create an account to join the conversation.