Sorry BigD, I was talking to Sing there.

To clarify, the timings will be exactly what you guys want them to be. If they need to be exactly the same, that's what I'll do.

I see no issues with either way on the explored/unexplored sectors. That is mainly used for grid scripts and probe scripts. However if it were slowed down, it might slow down probing a bit, but that can be controled by eprobe delay. If you think it would be beneficial for the cpu usage by all means add a delay.

Ok. sorry I thought you were referring to my question. I think cim (port report) should either remain or longer but definitely not faster.

I did, I just wasn't sure what you were referring to. A
lot of matching terminology going around =).

I'm happy with where CIM (both sectors and ports list)
is now on timing (6 minutes for a 30k, or 1 minute per
5000 sectors). I think that would work well for most people.



Yeh, that's fine. Are you going to add the option too?

Not sure if that would be server wide or game specific, but
in games where people pop planets for ore or use a lot of
planets it would be nice to be able to adjust up the timings
some. So game-specific multiples to prod move would be
very nice to have.

Another similar spot to consider a multiple would be with
xport. In a newly banged unlim people use world SST and
it pegs the processor pretty hard. A way to adjust that
up would help stabilize other games.

If you want to slow down the unknown warps list, you can
just match the CIM display. As long as we can hit space to
abort it, not a problem. If people need this list for something,
they can parse it during a non-critical time. It's not a very
commonly-used list.

I agree with this completely. When a lot of players are running cashing scripts like wsst and tsst at the same time, the cpu load is very high. Plus I think it may balance the blue/red cashing differential without the sysop having to enable rob/steal delay.

I'm starting the transport delay at the minimum, 2 ms. Do you have any suggestions on how high the transport delay might be set for our baseline timing? I did a quick test on 21-6.com and directly transporting between 2 ships with a 2 ms delay pulls about 20% CPU. Setting this up to 100 ms delay, it pulls about 5% CPU.

The more ships you have, the higher the CPU % is. Try
it with 20 ships.

I think somewhere between 2ms and 5ms as a baseline,
with a multiplier that could go up to 50x would rock.
Or just some way to scale between 2ms (or 5ms) and
250ms.

The first step for scaling the delays will be a single scale multiplier that will be applied equally to all delays in the game. I'd like to find a solid set of baseline delays that people are comfortable with, and then allow gameops to scale those delays uniformly in order to decrease CPU load. I'd also like to provide the ability to customize these delays individually, but there are currently 162 of them (and I might have missed a few) and it would take a lot of work to add TEDIT support for that many new fields. There may be another way to handle that, outside of TEDIT, like an INI file or something. I think there's value in having something like that because as the game continues to evolve, I think gameops could better address balance issues if they could modify the pacing of individual actions like this. I just don't think I'll have that in as a feature immediately. A game-wide scale setting I could do right away, though.

I'm going to explore the handling of ship lists for xport because I don't think it necessarily should increase much in CPU for multiple ships.

Ok, what would happen if the SPACE key didn't just abort the display of the list of ships for transport, but it also avoided doing an analysis of the ships, cutting out a lot of overhead for large ship lists. When you're doing a manual xport, you will want a list of ships and you'll want to know how many hops away each ship is from your location. But if you're running a script, do you really need that list? If you can abort the view and skip the course plot for each ship in the list, you could move things along much more quickly with far less CPU.

Sounds like a plan. Start w/ the delays you have now,
then have a CPC-style multiplier that sysops can adjust?

We don't need specific adjustment capability for 99% of
the delays. I mean nobody is going to care if xfering
shields to a corpie takes 10ms instead of 20ms. Most of
those are non-critical things that can be done when time
isn't a factor.

It's really only a handful of things that need adjusted. I
think landing and xporting are the two biggies from a
sysop perspective, simply because you have games where
those 2 things make up 90% of the system load. Then you
have balance issues like pwarp, photon, move, killing a fig,
etc.

But yeh, you could treat them like the way the menus are
done. A game-specific file that is read and can be adjusted
as needed. Just depends on what kind of time you want to
put into that.

Yeh, I've never understood why it takes so much more time
to do 100 ships over 5. A single BFS should be able to do
all of those courses.

Do we need the list or can space abort the entire process...
If we hit space, then we don't need the list, or we wouldn't
be hitting space to abort it. So yeh, you can drop that if you
want. Space can abort pretty much everything. You're still
going to check for range conditions tho, right?

Cool. If you can put together a short list of critical baseline delays, I could go ahead and drop in a screen for those. Then the game-wide scaling factor would apply to the delay that's specified in that screen for those particular actions. That way gameops would have some flexibility where it's likely to matter, but won't have to worry about the minutia of all of these other actions (every action has a delay now). But I did want to have delays for all actions so when you do scale up the delays, the entire game pace is effected, not just some actions. That way, in theory, if players do exactly the same thing in two games, one with normal delays and one with, say, 10x delays, the outcome would be exactly the same, only one game would take 10x as much playing time to complete. Of course, if this turns out not to be the case in practice, it'll be easy to rip out the delays that are irrelevant.

On the xport list, sure, I'd check to verify that the selected ship was actually within range. But that one course plot is much better than doing 20 for each ship in a 20 ship list.

If you're working with the delays you set earlier, I think
the only 2 that need adjustment is taking/leaving product
and xporting. There might be a case where others are
needed later, but those have been the biggest ones so
far. If you want the balance-related ones, I can do that
tho.

For xport, a single course search is all we need. There's
no reason, if we hit space to abort, to gather all of the
other info... at least none that I can see.

Found some timing that needs fixed...

Macro: m20102^M za99999^M m9183^M za99999^M m9724^M za99999^M m14699^M za99999^M m18317^M za99999^M
Time: 1311ms

That's 262ms per sector. That's not bad. Let's try without
the za figkill.


Macro: m20102^M m9183^M m9724^M m14699^M m18317^M
Time: 1292 ms

258ms per sector. So the za is adding 4 ms sector, even tho
its aborting with an * without saying yes.


Macro: m20102^M za99999^M fz1^Mzcdzr^M m9183^M za99999^M fz1^Mzcdzr^M m9724^M za99999^M fz1^Mzcdzr^M m14699^M za99999^M fz1^Mzcdzr^M m18317^M za99999^M fz1^Mzcdzr^M

Timing: 2579ms

So... that's 1268ms difference. Wow. A 253ms per sector
difference for just adding "fz1^Mzcdzr^M" to each sector.

All that looks like is:



There's no reason why that should be adding so much time to things.

So what if I simplify the macro...

Macro:
m20102^M za99999^M f1^Mcd m9183^M za99999^M f1^Mcd m9724^M za99999^M f1^Mcd m14699^M za99999^M f1^Mcd m18317^M za99999^M f1^Mcd

Timing: 2559ms

Not much difference. The basic figlay is adding a crazy amount
of time. 2559-1311=1248. 1248/5=249.6 so right around 250ms
per sector.

The only thing that's being done there that has a delay is the act of actually dropping the fig, and that delay should be only 5 ms per drop. So I'll take a look at that.