I was more thinking of feedback/requests concerning ICE because I can make these happens in a matter of days since I'm 100% in control of ICE.
I'd take requests that implies game code changes too but I have 0 control here, we depend on the 'FAO chain of command' which is currently stuck somewhere in a nebula. But I can code the changes if the demand is strongly motivated, then you'll deal with the administration to get the changes published.
QUOTE -one (or more) additional classes of teleport receiver for ships beyond "smallripcord" and "ripcord"[/quote]
this will require a core format change and quite some code changes too. Adding a ripclass mask (so 8, 16 or 32 different classes) is the way to do this. Should RipTime and RipCost remain unique or be different for each ripclass ? We can even add that ripclass to stations.
I guess adding a 'UseEnergyToReceiveRip' flag (one per class) on the receiver (ships only unless we add an energy pool to stations too) will be needed ? (or not depending on RipCost values) ? one could also imagine to have a separate energy pool for ripping (or drain shields).
Speaking of rip, one thing I never checked is that if 'NoRipcord' superseeds or not 'Rip To Small Ripcord'. Can anyone try this ? That is: is the current code handling correctly a ship that can't do normal rip but can rip to small ripcords. Check if it works and how autopilot code behaves. check for drones AI too. (design miners that only rip to a smallrip for instance). If the code already works fine that will be less work to implement the rip classes.
Also I've never checked what a negative RipCost value does...(does it recharge the receiver ? should it?)
Such change is quite some work and should really be motivated by a motivated demand. Spending hours of devs and tests to finally not use more than 2 classes 99% of actual game time, would piss off a lot of people
I never really complained (except of boredom) about the 'one-sided rez' feature not been used only because it took me a few minutes to code. But spending hours on something that in the end won't be used is more that frustrating. Well you guys know that, it's like spending hours on your core and finally no one play it (or don't use fancy stuff in your core you spend lot of time designing).
Whatever, that ripclass thingy requires careful 'design on paper' 1st, then some kind of proof (examples, real game situations, etc) it'll be used in core(s) before any coding work been actually started. Such thing is that this requires its own thread. Go open it.
QUOTE -making negative values in base paydays work - as in if i set that a base gives a payday of -100 to make it reduce paydays by that amount it doesn't explode the core[/quote]
as long as the total payday doesn't go negative it should work (we can add quick fix to prevent negative paydays, it's just a line code).
What you do mean explode the core?
QUOTE -adding the possibility of having negative values in development items - as in being able to add a piece of research that, instead of costs money, gives you money when it is researched[/quote]
that's odd but should be easy to code.