Code Release

Setting the module to icInertSim removed it from the contact list, but prevented normal docking with it (which I forgot about initially, ships docking to the station won't automatically dock on the module at all). I suppose dockports could be added to the station itself at the appropriate points with pog. I'm beginning to think that once the loadout package is available modular stations would be best handled by a modified version of that. Even without a collisionhull I still flew into something, making me think that a collision box is generated based on a sim's dimensions if no collisionhull is provided.

Things begin to get tricky. So what happens when you shoot the module? Can you destroy it? Does the damage transfer to the station as a whole?

We would need some kind of code to notice the module was gone and remove the docking port.

How about this idea instead: The player base is made up of a reactor, pod spewer, and docking arm (perhaps two empty cannon mounts). You can purchase habitation modules, garden modules, processing modules, manufacturing modules. None of those modules have docking ports or other annoying items.

Given the player is getting 1000x the features he had before, I cannot see reason for complaint. And it makes life much easier.

Ok, so if you add a processing module, and we want to sabotage it - do we attach a subsim and damage that? Or do we blow up the module?

Even without a collisionhull I still flew into something, making me think that a collision box is generated based on a sim's dimensions if no collisionhull is provided.

I so hope you are right. This could make things much, much easier. Not as realistic mind you, but far simpler.

Instead of having loadout handle ships and stations seemlessly, how about a special station construction screen. Just put down buttons where new modules can attach. And let the player press one to select it, then press a new module type, then hit build (or something).

Perhaps this same screen would let you turn on and off station modules (if you cannot afford to run one). Or pay for repairs on damaged modules.

-Gtrout

originally posted by GrandpaTrout
Instead of having loadout handle ships and stations seemlessly, how about a special station construction screen. Just put down buttons where new modules can attach. And let the player press one to select it, then press a new module type, then hit build (or something).

Sounds fun. I'll second the idea that dockports should just stay on whatever you're really docking to: you might want, say, an administration module to which the player has to dock specifically in order to visit some official -- if so, though, just make the module a separate HUD contact. I don't see a problem with stations being multi-targetable if they have multiple modules with distinct functions. Sensor-invisible modules would make sense for sections the player can't interact with.

Building lego stations is way outside the current scope of the loadout package, and would have to be handled separately. If you want each module's child sim to have its own configurable subsims, though, it shouldn't take that much unique work, as long as they're not icStation sims.


Time to overload the thread even more...I have a few questions on connecting loadout to cargo and inventory:

-Do we want to make buy/sell functions available to the player other than through the Trade GUI? I'm not fussed either way, but this'll be necessary if shipyard, loadout, etc screens are to allow direct buying and selling of equipment. If so, could you export tEpicTrade's availabillity and price functions?

-Do we have agreement that ammo-based subsims (magazines, slug throwers and probably RU) should go to inventory as ammo counts, not pod counts? I'm open to alternatives that don't introduce annoying complications to inventory handling, but haven't thought of any yet.

-I'm assuming you don't want to limit loadout to using only legitimate cargo (or do you?). Should I attach a cargo_faction property to subsims to make them stolen?

-What's the proper way to go about adding new cargo types? I can make a start on a replacement iCargoScript.Initialise() (assuming that's where the default game's iCargo.Create() setup calls are coming from) if we still need one. On a related note, can we add a 'subsim_url' entry to ini:/cargo_data?

For adding cargo, as far as Epic Online goes:

I was hoping you could use:
iInventory.Add( eCargoType item, int quantity );
which should show up marked as new cargo?

The script for "Epic Online" provides a list of eCargoType in flux .ini.

I would use iShipCreation.CreateCargoPods(cargo_type, 1);
to create them.
That gives you a "complete" ready made pod with the correct name, a given value for the pod as defined in the games stock inventory (or by Gtrouts new economy values (?)) as well as an empty slot for the shipping agents name that you can add as the faction ObjectProperty.
Thats all the standard information thats scrolled through in the UCP scan of the pod.

Instead of the enum, I could provide a string with the pod name as defined in
iCargo.Name ( iCargo.Find ( cargo_type ) );
That name is different for each language localisation however!

Using the url/ini method and iSimCreate, you'll have to add the values, cargo name, faction yourself, won't you?
Assuming Gtrouts new economy values for the pods don't dictate otherwise, the only advantage I see for url/ini creation is, you could use different pod types (avatars). (iShipCreation always uses the dice shaped pods)


EOC/IWar2 Multiplayer Fansite

Children get damaged and destroyed seperately. I need the math to modify the module's position based on orientation of the attachment point (if it's not 0,0,0). God I hate math.

To quote Val Kilmer in Red Planet: "This is it... That day they told you about in school, when algebra could save your lives" .

The thing I hated about school, is that we'd spend most of the year learning the "hard way", and then in the last 6 weeks, they'd cough up those wonderful eye-opening shortcuts.

Anyway... I have a vacation to get back to...