Author |
Message |
John Pritchett
Site Admin
Joined: Sun Dec 24, 2000 3:00 am Posts: 3150 Location: USA
|
Next update
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.
_________________ John Pritchett EIS --- Help fund the TradeWars websites! If you open a hosting account with A2 Hosting, the service EIS uses for all of its sites, EIS will earn credits toward its hosting bill.
|
Tue Nov 09, 2010 7:52 pm |
|
|
Parrothead
Commander
Joined: Wed May 03, 2006 2:00 am Posts: 1722 Location: USA
|
Re: Next update
What about the planet move and landing delay?
_________________ Coconut Telegraph (ICQ)#586137616 Team Speak3@ 220.244.125.70:9987 Founding Member -=[Team Kraaken]=- Winner of Gridwars 2010 - Ka Pla
Jesus wounldn't Subspace Crawl
|
Tue Nov 09, 2010 7:56 pm |
|
|
John Pritchett
Site Admin
Joined: Sun Dec 24, 2000 3:00 am Posts: 3150 Location: USA
|
Re: Next update
What about it?
_________________ John Pritchett EIS --- Help fund the TradeWars websites! If you open a hosting account with A2 Hosting, the service EIS uses for all of its sites, EIS will earn credits toward its hosting bill.
|
Tue Nov 09, 2010 8:08 pm |
|
|
Parrothead
Commander
Joined: Wed May 03, 2006 2:00 am Posts: 1722 Location: USA
|
Re: Next update
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?
_________________ Coconut Telegraph (ICQ)#586137616 Team Speak3@ 220.244.125.70:9987 Founding Member -=[Team Kraaken]=- Winner of Gridwars 2010 - Ka Pla
Jesus wounldn't Subspace Crawl
|
Tue Nov 09, 2010 8:12 pm |
|
|
John Pritchett
Site Admin
Joined: Sun Dec 24, 2000 3:00 am Posts: 3150 Location: USA
|
Re: Next update
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.
_________________ John Pritchett EIS --- Help fund the TradeWars websites! If you open a hosting account with A2 Hosting, the service EIS uses for all of its sites, EIS will earn credits toward its hosting bill.
|
Tue Nov 09, 2010 8:18 pm |
|
|
Promethius
Ambassador
Joined: Mon Feb 09, 2004 3:00 am Posts: 3141 Location: Kansas
|
Re: Next update
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."
|
Tue Nov 09, 2010 8:22 pm |
|
|
Parrothead
Commander
Joined: Wed May 03, 2006 2:00 am Posts: 1722 Location: USA
|
Re: Next update
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.
_________________ Coconut Telegraph (ICQ)#586137616 Team Speak3@ 220.244.125.70:9987 Founding Member -=[Team Kraaken]=- Winner of Gridwars 2010 - Ka Pla
Jesus wounldn't Subspace Crawl
|
Tue Nov 09, 2010 8:37 pm |
|
|
John Pritchett
Site Admin
Joined: Sun Dec 24, 2000 3:00 am Posts: 3150 Location: USA
|
Re: Next update
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.
_________________ John Pritchett EIS --- Help fund the TradeWars websites! If you open a hosting account with A2 Hosting, the service EIS uses for all of its sites, EIS will earn credits toward its hosting bill.
|
Tue Nov 09, 2010 10:37 pm |
|
|
T0yman
Veteran Op
Joined: Sat Dec 29, 2007 5:06 pm Posts: 2059 Location: Oklahoma
|
Re: Next update
John Pritchett wrote: 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?
_________________ T0yman (Permanently Retired since 2012) Proverbs 17:28 <-- Don't know it, most should it would stop a lot of the discussions on here.
|
Tue Nov 09, 2010 10:44 pm |
|
|
John Pritchett
Site Admin
Joined: Sun Dec 24, 2000 3:00 am Posts: 3150 Location: USA
|
Re: Next update
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?
_________________ John Pritchett EIS --- Help fund the TradeWars websites! If you open a hosting account with A2 Hosting, the service EIS uses for all of its sites, EIS will earn credits toward its hosting bill.
|
Tue Nov 09, 2010 11:11 pm |
|
|
Kewlbreeze
Commander
Joined: Sun Aug 27, 2006 2:00 am Posts: 1419 Location: USA
|
Re: Next update
John Pritchett wrote: 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?
_________________
Founding Member of: Flying Ace's
|
Tue Nov 09, 2010 11:38 pm |
|
|
Promethius
Ambassador
Joined: Mon Feb 09, 2004 3:00 am Posts: 3141 Location: Kansas
|
Re: Next update
[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."
|
Tue Nov 09, 2010 11:59 pm |
|
|
Singularity
Veteran Op
Joined: Thu Jun 02, 2005 2:00 am Posts: 5558 Location: USA
|
Re: Next update
John Pritchett wrote: 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? 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.
_________________ May the unholy fires of corbomite ignite deep within the depths of your soul...
1. TWGS server @ twgs.navhaz.com 2. The NavHaz Junction - Tradewars 2002 Scripts, Resources and Downloads 3. Open IRC chat @ irc.freenode.net:6667 #twchan 4. Parrothead wrote: Jesus wouldn't Subspace Crawl.
*** SG memorial donations via paypal to: dpocky68@booinc.com
|
Wed Nov 10, 2010 12:39 am |
|
|
Singularity
Veteran Op
Joined: Thu Jun 02, 2005 2:00 am Posts: 5558 Location: USA
|
Re: Next update
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.
_________________ May the unholy fires of corbomite ignite deep within the depths of your soul...
1. TWGS server @ twgs.navhaz.com 2. The NavHaz Junction - Tradewars 2002 Scripts, Resources and Downloads 3. Open IRC chat @ irc.freenode.net:6667 #twchan 4. Parrothead wrote: Jesus wouldn't Subspace Crawl.
*** SG memorial donations via paypal to: dpocky68@booinc.com
|
Wed Nov 10, 2010 1:07 am |
|
|
John Pritchett
Site Admin
Joined: Sun Dec 24, 2000 3:00 am Posts: 3150 Location: USA
|
Re: Next update
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.
_________________ John Pritchett EIS --- Help fund the TradeWars websites! If you open a hosting account with A2 Hosting, the service EIS uses for all of its sites, EIS will earn credits toward its hosting bill.
|
Wed Nov 10, 2010 2:17 am |
|
|
|
Who is online |
Users browsing this forum: No registered users and 5 guests |
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot post attachments in this forum
|
|