Cores for R5

[Dogbones]

Lots of great ideas here but lets focus things. I'd suggest concentrating on
adding functionality that current core devs really wish they had as they would use it now (i.e. not future fancy stuff they may be thinking about that also require code changes), not being a core dev I am not sure what these would be /tongue.gif" style="vertical-align:middle" emoid=":P" border="0" alt="tongue.gif" /> improve the base/tech (dependency) logic (possibly rework it entirely but that is a bigger fish to fry)eliminate 'item' caps, like more tech numbers (already mentioned)
Things I'd avoid:

-'smart' weapons as in main guns on little turrets so they converge at the distance of the target. If you really want this effect make the advanced figs have a 'tight' weapon mount config. I just think this adds an unnecessary level of complexity.

-items that regen He on asteroids, there are other ways to do this like He mines that you can plant on spent He rock. And do we really want to be making the econ MORE complicated?

-'gravity' (pull or push) items. Neat idea, lots of code changes. Not really a core change aside from maybe a few minor property additions to probes. If we really want this, do the code dev first.

-more than 4 main weapons. Why? Instead of making an advanced ship that has 5 main weapon mounts why not accomplish the same thing with a stronger version of a weapon that only mounts on these ships? Or give these ships a weapon modifier that makes there existing 4 weapons 20% more powerful. Why add a 20% projectile calculation cost for a 5th stream of bullets (or missiles if we allow them)? I can see 1, 2, 3, or even 4 for firing patterns, cool looks, etc, but 5? why not 7?

Bottom line, Allegiance already has a pretty steep learning curve so lets add things that are clearly interesting/needed and not add complexity for the sake complexity (or put another way, "just because we can").

[madpeople]

QUOTE (Dogbones @ Sep 12 2007, 08:50 PM) -more than 4 main weapons. Why? Instead of making an advanced ship that has 5 main weapon mounts why not accomplish the same thing with a stronger version of a weapon that only mounts on these ships? Or give these ships a weapon modifier that makes there existing 4 weapons 20% more powerful. Why add a 20% projectile calculation cost for a 5th stream of bullets (or missiles if we allow them)? I can see 1, 2, 3, or even 4 for firing patterns, cool looks, etc, but 5? why not 7?

allegiance used to support more than 4 guns, R3 broke it, so now you crash if you get the TF ass fig on RPS (which has rn out of pre/def numbers, so you can't add extra dual gat 1,2,3,4,5


oh, and allow guns to shoot more than one type of projectile.

and allow mixed missile packs.

e.g. make a missile that only damages hull, and one that only damages shields, but make it so that you can define in the core that both can be mounted at once, and when you fire, it fires 2 missiles, one of each type

[Dogbones]

QUOTE (madpeople @ Sep 12 2007, 03:48 PM) option to allow a missile you have fired that has lost its target to lock onto the next ship you lock onto.
so if you fire the missile, but kill the ship it was fired at, then lock onto someone else, the missile in the air will then go attack them (if it has lost its target, it will immediately start tracking your new target, but its lock strength will be your current lock strength (then the highest lock strength you get, if your lock strength starts to fall again, or max lock if you fully lock on)
also allows you to fire a missile with no lock off to the side of a rock, then lock onto someone on the other side, and then the missile will head towards them, making it easier to shoot around stuff

Very interesting idea but wrong thread /blink.gif" style="vertical-align:middle" emoid=":o" border="0" alt="blink.gif" />

Aside from maybe one additional flag for a missile for the code to check if a missile can do this or not, this is all server/client development.
We could do this now without a core change. For the above to be workable the missiles would need to have a very long life/range, we could key 'retargetting missiles' based on a range threshold or some combo of existing missile properties. A specific flag/mask/property for the missile would be a nicety.

[Cadillac]

More AoE.

eg. AoE EMP mine

Also, you should take damage when flying through another ship's/base's explosion. (AoE)

[Dogbones]

QUOTE (Cadillac @ Sep 12 2007, 04:01 PM) Also, you should take damage when flying through another ship's/base's explosion. (AoE)

Again a good idea but more of a code change than a core change. Sure you can add a property to the base in the core such that the core dev can decide if a base blowing up does AoE damage or not and if it does how much, but is this something we really want in the core? I'd think either exploding bases do damage or they don't. We should make this a game play decision and not a core dev decision. I am ALL FOR flexibility in cores but somethings should be consistent across cores.

[Ramaglor]

How about allowing a game size modifier? Things that cost money don't scale well against increasing team sizes. As teams get larger, cheaper things get better faster then expensive things. For example: galvs and tp2 are absolutely killer in large games, while cap ships are absolutely killer in small games. I suggest that the health and shields of bases and cap ships can be automatically modified by changing a game setting, or link it to game size. +add a flag in cores for modifier

[KGJV]

QUOTE (Dogbones @ Sep 12 2007, 10:09 PM) Again a good idea but more of a code change than a core change. Sure you can add a property to the base in the core such that the core dev can decide if a base blowing up does AoE damage or not and if it does how much, but is this something we really want in the core? I'd think either exploding bases do damage or they don't. We should make this a game play decision and not a core dev decision. I am ALL FOR flexibility in cores but somethings should be consistent across cores.

yeah well i thought about this when tuning missile explosion. Actually would be nice to have explosion for station destruction.

But we dont want an outpost exploding doing same damage as an adv tech base for instance. So may be use the 'station hitpoints' and to set the explosion power and 'station scan range or scale' for the explosion radius. OR add new values in the core for this. I'm rather for adding explosion values in the core , this gives more freedom to core devs such as allowing 'decoy bases' that can be easily killed but yield a devasting explosion. We could still use hitpoints and scan range/scale if these new values are unitialized.

Also to avoid too much gamplay change with station explosion,we could introduce a delay before the explosion so that the attackers (and defenders) have a chance to take cover but the base will be considered 'dead' immediatly (so no "keep tech/can launch" delay between the destruction and explosion). Once again, that delay could be a core value.

More generally, explosions could be threated like projectiles in fact and have their own entries in core. Then we could link or not any "object that can be destroyed" with an explosion. This would give great flexibilty in cores and much simpler code for explosions. Also we could add new textures for explosions this way.

After all, do we really want/need consistency across cores ?

[KGJV]

QUOTE (Ramaglor @ Sep 12 2007, 10:23 PM) How about allowing a game size modifier? Things that cost money don't scale well against increasing team sizes. As teams get larger, cheaper things get better faster then expensive things. For example: galvs and tp2 are absolutely killer in large games, while cap ships are absolutely killer in small games. I suggest that the health and shields of bases and cap ships can be automatically modified by changing a game setting, or link it to game size. +add a flag in cores for modifier

Scaling is a complex issue in Alleg. It has been discuted numerous times.

For sure some 'things' dont scale well in Alleg. The difficulty is to know what and how to scale /smile.gif" style="vertical-align:middle" emoid=":)" border="0" alt="smile.gif" />

This issue deserves its own topic , feel free to open one.

[Adaven]

I think I've got something for the weapons convergence at a fixed range or target range. I agree with dog it is really low priority, but it gives me something to keep myself occupied during class. I've got to clean it up a bit and I'll toss it out here later.

[madpeople]

QUOTE (Dogbones @ Sep 12 2007, 09:01 PM) Very interesting idea but wrong thread /blink.gif" style="vertical-align:middle" emoid=":o" border="0" alt="blink.gif" />

Aside from maybe one additional flag for a missile for the code to check if a missile can do this or not, this is all server/client development.
We could do this now without a core change. For the above to be workable the missiles would need to have a very long life/range, we could key 'retargetting missiles' based on a range threshold or some combo of existing missile properties. A specific flag/mask/property for the missile would be a nicety.

QUOTE (KGJV @ Sep 8 2007, 06:39 PM) Well all core changes require code changes ... /laugh.gif" style="vertical-align:middle" emoid=":lol:" border="0" alt="laugh.gif" />

i'm putting them here because they will need a change to the core, even though they are mostly code changes.

perhaps someone should go through this thread and click the mluti quote button on every idea that is mostly a code change, then start a new topic on them...