Code Release

(or rather a limited transport capacity over x period of time)

Yes, this is the idea. Transport capacity is determined by number of transport stations (shipyards, repair stations, wharehouses and the like).

If we assume that little SNRVs can LDS pods around the same system very quickly, then capacity really just needs to be system to system. It would follow the jump lines. Pricing can also be calculated only once per system.

One key assumption: No station is allowed to starve. If you are willing to pay enough, you can always purchase a pod. This really simplifies things, and keeps the simulation from going wildly unstable (someone kills the only agri orbital - all stations in the cluster die, might be truthful, but hell to keep working).

With that assumption, production and consumption just change pricing. So a first step simulation just lowers (increases) pricing system by system - and transportation is not simulated at all.

Later, we can shuttle goods around, and give smooth pricing gradients from supply to demand. But that is more work.

-Gtrout

I just noticed the collisionhull used for the player tug lacks the 'legs'. I'm going to try doubling the size of a station. It may just be field-of-view, but I always thought they seemed a little small (or maybe the cockpit in the command section is just too big).

Mehrunes: good to see you around again, even if it was you that first suggested save-anywhere, which I think it was:D. That shipyard does look nifty.

EricMan's and my loadout approaches aren't wildly different (the central problem for any loadout system is making lws data visible to pog, so they'll always look similar at a low level), but one of my initial requirements was that the loadout system has to work with prefitted ships, which leads to enough divergence of implementation details that I figured it'd be easier to keep trundling along with what I've got than have to rework stuff I did before my Christmas sabbatical. Not that I won't shamelessly cannibalise EricMan's interface:).

Anyway, the point is that 'default loadouts' should be one of the Epic world's few non-issues, since all Shane's ships are prefitted anyway -- I auto-generate the implied mount data in the sim ini files with a script that should work on any roughly standard tree of ini and lws files. This might complicate pricing somewhat, as the default price should include the default loadout; maybe we should provide the option of buying a stripped hull (just remove all subsims) at a lower price and loading it out yourself separately.

Postponing dock-on/hangar-launching fighters doesn't worry me -- incorporating them will require scripty stuff that we don't necessarily want to be debugging at the same time as testing rebalanced ships, ordinary loadouts, mission generators...

I'm quite against including T-Fighters at all, not so much for balance (I personally never found as much use for them as for an extra neutron PBC and some missiles, anyway), but because they were supposed to be experimental in EoC, and we're set earlier than that. Dock-on or hangar-launched fighters of some sort would be good at a later stage.

Right now the player gets whatever comes out of the base ini file (which is nothing but mountpoints and dockports). Including any real subsims in the price is easy enough, unless the loadout has to change after creation to accommodate the player. Same with offering empty hulls. I can also offer the player the option of selling a ship as is, or stripping it first.

And yes, I think I did suggest save-anywhere first. Sorry about that.

Oh, and I have a pic comparing the comsec cockpit with the windows on double-size stations. I think I'll do this with all of them.

mywebpages.comcast.net/Mehrunes/newsize.jpg

I think what needs to happen here is a comparison of work hours remaining on Flamenoes path and the amount of work needed for EricMans. Remember that we have 25 - 50 new ship ini files on the way. If everyone requires a half page of code - this could be a fair amount of work.

If it choosen to change directions at this point, then those taking us this new direction will need to be willing to put in that effort, rain or shine.

You guys know the details better than I do. Flamineo I leave this call up to you. I will be glad to support what ever you choose.

Mehrunes: Cool station. Can we get a far shot? How do the textures hold up stretched?

Should asteroid stations also be scaled? If your in the station creation buisness - consider attaching a couple of asteroid base structures to a really big asteroid (like 20km). It always bothered me that the structures seemed larger than the asteroids.

-Gtrout

originally posted by GrandpaTrout
Remember that we have 25 - 50 new ship ini files on the way. If everyone requires a half page of code - this could be a fair amount of work.

This was my main concern: the code to shuffle subsims around isn't overly complex -- most of the work is in getting the necessary data to do it into the shuffling functions, which has to be done for every player-valid ship (ie, in Epic, every ship). I've automated this to a decent degree of reliability for the 'virtual' hardpoints you suggested a while back, and going back to do it differently could well take longer than plunking a user interface in front of what I've already set up. Less critically, ships floating around with mountpoint subsims under their real systems would create a little extra work for the damage package's already fairly taxed main loop.

originally posted by Mehrunes
Right now the player gets whatever comes out of the base ini file (which is nothing but mountpoints and dockports). Including any real subsims in the price is easy enough, unless the loadout has to change after creation to accommodate the player.

There shouldn't be any special requirements: we've (I think) entirely removed the unmodded distinction between player and non-player ships, apart from which 'install pilot' function they're initialised with, obviously. Dockports still exist, and are always welded on; mount point subsims have been replaced with a hardpoint[] entry in the sim ini matched to each subsim's template[] entry. I'll export a StripSim() to take everything off a ship that's on a user-configurable hardpoint, if it'd be useful. Because we're not using mountpoint subsims, there's no need for separate 'flyable' and 'load-out-able' versions of ship files, so all ship inis look something like the '*_prefitted.ini' ones from the unmodded game.

I'm still a week or three away from releasing a prototype (I'll include a copy of the unmodded sims with the necessary changes to work with it); let me know if there's any details that'd be useful to you in the meantime.