Trade Wars 2117

If you have a new game running on your server, you can announce it in here.

JokerAce
Posts: 17
Joined: Thu Apr 27, 2017 05:01 UTC

Re: Trade Wars 2117

Post by JokerAce » Thu May 25, 2017 15:34 UTC

TheMightyDude wrote:
JokerAce wrote: Would it be easier to correct the negative using abs()

...

No negative numbers result and it wouldn't limit the math output artificially.

Would this be a viable way to simplify the correction?
I haven't looked at the code yet but I'm guessing it would mean only minor changes would be needed versus clamping.

You'll know better than I but that's where my thinking and researching took me.
While that might work in most cases, using a clamp would give you more control over the actual value range, using ABS(...) would only make all values positive, this might work ok for now, but might cause issues later on, which might be why we never used it.

Like suppose the value got that high say 1 value more than the BIGINT (-9,223,372,036,854,775,807 to 9,223,372,036,854,775,807)
Soooo using the max value (i.e. 9,223,372,036,854,775,807 + 1) that will not equal 9,223,372,036,854,775,808, in fact it would equal 9.2233720368548E+18 which is 9,223,372,036,854,800,000.

So if you have the max value 9,223,372,036,854,775,807 you could add 1 or 10 or even 1000 it would still equal 9.2233720368548E+18 which is 9,223,372,036,854,800,000.

Using a calculator on my PC 9,223,372,036,854,775,807 + 1 equals -9,223,372,036,854,775,808, sadly on PHP it doesn't it equals 9.2233720368548E+18 which is where the issue lies.

This was some of the issues we have had with large numbers.

Also using either the Clamp or ABS versions, you are not resolving the issue, you are just sweeping it under the rug.
You really need to find out what's causing the actual issue and fix that.

What needs to really be done is lower everything and stop it getting that high in the first place and also putting in an absolute max value and when it hits that value it goes no higher.
The BIGINT limitation is the reason I switched to decimal. It fixed many issues but broke a few things.
Hence, the need for a clamp or abs.

Your last point is golden though and I have been thinking about how to do that since my game really got going and the numbers went astronomical super fast.

One potential way to fix that is to simply change the parameters of the economy.
Ships hold less, things cost less, 1 credit = 10,000 of the current credits basically. Also, the autotrade routes would have to have more limitations so people couldn't count on that to get rich as hell fast as hell.
Selling ships AND upgrades would gobble up some credits to prevent out of control economic scale.
Maybe using actual decimals to reduce the delta on trades.

Ore @
$1.67 selling - $1.98 buying
for example.

That would keep the totals down and keep more numbers on the right side of the decimal point which then gives you more room on the left side too.

Thoughts?

retrodigital
Posts: 10
Joined: Sun Feb 26, 2017 21:42 UTC

Re: Trade Wars 2117

Post by retrodigital » Fri May 26, 2017 02:37 UTC

The command line for cron should work as how we show it in the INSTALL file and also what is shown above, I have always used that without any issues at all.
I agree it should but its never worked as listed.. Not sure if its just an issue with the one installed via softaculous or if its just the way the server is configured.. But it definitely never worked for me that way.

Thanks

thekabal
Posts: 100
Joined: Sat Apr 19, 2014 22:32 UTC

Re: Trade Wars 2117

Post by thekabal » Sat May 27, 2017 18:43 UTC

JokerAce wrote: The BIGINT limitation is the reason I switched to decimal. It fixed many issues but broke a few things.
Hence, the need for a clamp or abs.
Decimal has several major disadvantages. (Please note that Decimal is not the same as Double.)

First, it takes up substantially more space. One can argue that isn't a major concern, and I would tend to agree normally, but Decimal can store up to 65 digits (!), which is beyond the range of any regular data type in PHP.

Second, because of the data type difference, you have two choices: Accept that you will (regularly, often) lose accuracy (value) when pulling a value from Decimal in the DB to PHP. OR, you accept a limited size for Decimal, in which case you aren't gaining much over using BIGINT (because it is much closer to the standard PHP data types).

Third, once it hits PHP land, if you choose to go larger than BIGINT, you need to use one of the PHP modules that support higher math functions (bcmath, etc). Those are INCREDIBLY slow, and you will likely see/feel the difference quickly. Further, you have to use them for every single calculation, always, or you'll end up with a bit flip, like TMD mentioned. ABS doesn't solve that, it simply solves the neg/positive issue.

We went down this very path multiple times in multiple forks. It seems like a solution to the problem, but it actually produces more problems than it solves. The root issue (the user story, if you will) is actually best expressed as "The economy in BNT was never purposefully designed, and as a result, quickly spirals beyond the (easy) calculation limits of PHP & MySQL". As you might imagine, the solution is really to redesign the economy in a meaningful way.

The key there isn't so much range, as you suggest, but adding in more "credit sinks". Once you hit a certain point in the game, the numbers just inflate and there isn't much a player has to spend them on. Adding things like more AI (which does more damage and reduces defences), or splitting ships defenses from planets (we did that in TKI), or increasing the penalties/costs and frequency of apocalypse events can all help more meaningfully. There is a ratio/factor variable that helps (in theory) reduce the inflation a bit, but that value also dramatically slows the progression of the early/mid game. It "feels" less rewarding to the player, and when we implemented a TINY change in it players HATED it. I don't blame them. It's turning a knob without adjusting the rest of the economy to match.

It's not an easy problem to solve, is the TL;DR.

thekabal
Posts: 100
Joined: Sat Apr 19, 2014 22:32 UTC

Re: Trade Wars 2117

Post by thekabal » Sat May 27, 2017 18:51 UTC

retrodigital wrote:running it via PHP directly never worked for me and no idea why at this point.
Our cron isn't meant to work running directly via PHP. It doesn't work in a CLI environment generally, and is intended to be visited by a browser, hence using lynx/links/wget/curl as that interface.

For TKI, I'm working on a completely rewritten alternative scheduler (newscheduler) which DOES run via CLI directly. Very different beast. I'm also changing the way a number of the schedulers work. For example, sched_tow will be eliminated entirely. I've located all the spots where a ship could move to a place where they could need to be towed, and simply prevented them from doing so rather than letting them and then cleaning it up afterwards.

The code is extremely similar to BNT, and should be relatively portable to it. If I have the time, I may port it for BNT as well. If not, anyone else is certainly welcome to do so.

JokerAce
Posts: 17
Joined: Thu Apr 27, 2017 05:01 UTC

Re: Trade Wars 2117

Post by JokerAce » Sat May 27, 2017 19:40 UTC

thekabal wrote: For TKI, I'm working on a completely rewritten alternative scheduler (newscheduler) which DOES run via CLI directly. Very different beast. I'm also changing the way a number of the schedulers work. For example, sched_tow will be eliminated entirely. I've located all the spots where a ship could move to a place where they could need to be towed, and simply prevented them from doing so rather than letting them and then cleaning it up afterwards.

The code is extremely similar to BNT, and should be relatively portable to it. If I have the time, I may port it for BNT as well. If not, anyone else is certainly welcome to do so.
I had looked at your project and saw that the status was that it wasn't ready for play but is that still where things stand?

Also, I noticed that it needs at least PHP7 which I don't have on the server, is that a firm requirement?

thekabal
Posts: 100
Joined: Sat Apr 19, 2014 22:32 UTC

Re: Trade Wars 2117

Post by thekabal » Sun May 28, 2017 02:28 UTC

JokerAce wrote:I had looked at your project and saw that the status was that it wasn't ready for play but is that still where things stand?
Yes. The user signup/registration process is broken. It needs a substantial rewrite, but I've been focused on cron, PDO, and data types lately.
JokerAce wrote:Also, I noticed that it needs at least PHP7 which I don't have on the server, is that a firm requirement?
PHP-7.1, in fact. We use void return types, and already have the vast majority of the function calls to use defined types and returns. It would be possible to strip the 76 lines of void return types to drop the requirement down to 7.0, but there are numerous items forcing the 7.0 requirement.

Post Reply