I'm getting ready to post a new update. I haven't addressed every bug that's been reported since the last update in mid-October, but these are the big ones.

* Move delay for "zero delay" was changed from 250 ms to 100 ms in an effort to speed things up for scripters. Since that seems to be too much "zero delay", I've changed it back to 250 ms.
* I've made another attempt to fix the log viewer crash. I still can't repro that, so we'll just have to see if this does anything.
* Bigbang now guarantees that every sector can reach every other sector in less than MaxCourseLength hops
* TEDIT with password protection is working again.

I'll email beta test sites when the update is ready to go.

What about the planet move and landing delay?

What about it?

Well it interfers with the balance of the game so unless they are needed to fix another older bug more serious then what is there purpose?

For the purpose of load balancing I don't want to have any common script cycles that have zero delay. Of course I don't want the delay to be large enough that it significantly changes the flow of the game. Like the 100 ms delay that you complained feels like 0 ms, that 100 ms is enough to let other people in the game (and other applications) have a bit of the CPU, whereas having a true zero delay allows that game to run at full speed and take 100% CPU. It's not reasonable to allow some scripts to run at 100% CPU and other activities to be forced to take a backseat to those scripts. I will decrease the delays if they feel like they're too much, but they do need to be there. I hadn't heard any complaints about them so I didn't know there was an issue.

If there is a planet move delay, then you will never hit gridders. Maybe there is a delay in the current non-beta version, but it balances pretty well with the gridders - sometimes you hit them, most of the time you don't. If you try direct planet drops, you will never hit them.

               / Promethius / Enigma / Wolfen /

"A man who has no skills can be taught, a man who has no honor has nothing."

The landing delay prevents pgridding and several other functions. I understand the CPU thing please try to keep everything in balance. If 50ms need to be added to planet movement then a ship move delay of 300 would keep this in balance. If 50ms need to be added to landing then it would throw some things off so please keep this as small as possible.

IF CPU was the issue why not just add 25ms to everthing.
This would preserve to current balance in game.

Keep in mind that absolutely no design went into determining these delays. Just because it changes doesn't mean that it makes the game unplayable. Just different. I find it hard to believe that by sheer luck this game just happens to have achieved the best possible balance of delays. The reality is, the players have adapted to the conditions we have today. If there's justification to change it, players will adapt.

Of course, I don't want to change things up just to change it. I'm going to back off on these delays to the minimum possible to achieve the load balancing I want. At the minimum, what I'd like is for these actions to give other players an opportunity to process their actions as well, but I don't need anything like a 250 ms delay or even a 100 ms delay. At minimum, I'd like all scripts to experience the same delays, negligible when the server has little activity, but uniformly larger when lots of people are online. That would be enough to satisfy my goals for this version, and then I'd like to look at possibly putting in real delays and balancing the game around those delays in a new version, if I have the time.

Can it be a configurable Variable set by the Sysop?

Ok, now suppose these activities that currently have a truly zero delay, like moving a planet or landing on a planet, instead have a very small delay of 100 ms or even 50 ms (get much smaller and there isn't enough timer resolution). As people just stated about the 100 ms move delay, that's so small that you can't even tell it's there. Yet, it's not zero, so the actual pace of those activities is not tied to the speed of the CPU and the load of the server. It's very fast, but it's CONSISTENT, and that's a critically important thing.

The way it's currently done, activities that have zero delay take place in the game at the speed of the CPU, while those with a delay take place at the same speed regardless of CPU. Why is that preferable? People are talking about keeping the delay balance, but there currently isn't ANY delay balance. It's all tied to CPU. It's been changing for decades now, with some actions constantly getting faster while others stay at the same speed. That's just silly. Let's lock these delays in at small but consistent values and if there needs to be some balancing, let's do it. It just makes sense to do that, and it doesn't make any sense to make it an option. Why do you want to have the option to allow some actions to continue to get faster and faster as CPU speeds increase?

Why bother with changing anything for in game, game play other then bug fixes?

Cruncher says she wanted the ships to move faster then the planets.. Both me and sing spoke up and said “then you can’t stop a girder” you change the ship delay and what happened… now you can’t stop the girder.

You want a planet land delay added…why. So now people are sitting in the sector longer meaning if they lift in combat they are dead.

I don’t see the point in adding delays or lowering the delays. Scripts have for the most part been written now to the fastest possible point so by playing with the delays all your doing is making the scripts faster or slower. Which is going to unbalance the game… or should I say has.

But I still don’t understand why you are wanting to change the in game actions ..what am I missing?

[quote="John Pritchett"]Ok, now suppose these activities that currently have a truly zero delay, like moving a planet or landing on a planet, instead have a very small delay of 100 ms or even 50 ms (get much smaller and there isn't enough timer resolution). As people just stated about the 100 ms move delay, that's so small that you can't even tell it's there. Yet, it's not zero, so the actual pace of those activities is not tied to the speed of the CPU and the load of the server. It's very fast, but it's CONSISTENT, and that's a critically important thing.

...

quote]

It is true that the 100 ms delay is hard, if not impossible, to detect, but the balance between gridder and pdropper is currently about right - faster CPUs or not for the no move delay. The gridder still wins most of the time against an adjacent pdrop and photon. The combat scripts, for one example, are written to get every ms advantage we can. The difference in hitting someone and missing is extremely small sometimes. Speed in an unlim is equal to turn management in a turns game in regard to being critical.

               / Promethius / Enigma / Wolfen /

"A man who has no skills can be taught, a man who has no honor has nothing."

In the old version (pre-beta), we got lucky on the timings. They happened
to compliment the average user's ping very well, and the result is that
gridders and defenders tended to happen at a very similar rate. A gridder
could spend extra turns to speed up, and avoid getting torped, but that
was always a tricky decision. The result was a very careful balance.

If those things start getting changed, it could give one side a huge
advantage. The last thing you want to do is give gridders a massive
advantage. In HHT, we could grid w/o ever getting hit. We took out
over 10,000 sectors on the grid in a matter of a few days, nobody could
stop us and nobody could hide. That makes it impossible to build planets
that take longer than a day.

So the real question is: What do we need for this to re-balance?

Well, we don't know yet. We haven't tested it. A 100ms delay is a lot,
however. But it depends on what the processing delays used to be,
and whether 100ms now is comparable to what they were. 100ms could
be way too high, or it could be way too low. I don't know how small you
can make that delay, but we might be pushing that limit here.

There are a few extra bugs:
The planet pod bug (not podding until get past the prompt)
The tow landing bug

Also, if you can fix the failed plock bug, that'd be pretty sweet too.

If we can get a bug release, and if SG can put it up on the server, then
I can get a test game and test each bug issue one step at a time. I
can also work on the timing balance. We will need to do that before the
beta is viable for competitive games.

Oh, and EP ran into an "out of memory" error running extern one night.
It ran again the next night. No idea why it did that.

As a note, there is currently little to no internal processing
delay on a pwarp foton...

In my pre-beta, I ran this macro 10 times:
p5562^M y c p y 9079^M ^M q p6680^M y

Each time, it came out 0ms.

That means the entire macro's text is received in the same
packet. Too much delay here will affect things drastically.

Let's try 50 ms and see if it effects the balance. Honestly, if the timing of these events is that tight, then it's going to be highly dependent on things like CPU and connection speed, so you're not getting consistent behavior over a variety of game sites anyway. If we can get this right with some actual timing, we stand a much better chance of it being consistent and remaining consistent over the next decade.