1.3.5.x - What is left to do?

[NiteHawk]

Fixed now. afkmode value should be grabbed when needed, thus it should solve any issues you have with warping in/out without a qdrive. Tested and seems good.

Todo 1.3.6:

-Fix 'victory' planet amount (when you list specific planets). (Has always worked up to about ID < 30 planets, and then will not work properly.) -- Ignoring until 2.0
-When you are AFK you should not be gravity pulled.
-When you AFK without a qdrive and sync up you get a 'warp transition' error/unable to move.
-Scrolling up from selecting weapons, the message such as "You can downgrade"/"You can upgrade" gets wrong input.
-Booster acceleration doesn't work as it should. Make booster 'max_accel (which is really generic acceleration + para value)
-Find out why random damage/explode occurs, (May be something to do with destroying Starbases.) - Need more information... Cannot replicate too often.
-See if you can fix 'keydown' with boosting to prevent reverse boosting
-On logout, your ship sometimes does not 'vanish' and leaves a ghost ship of yourself.
-Sometimes you get randomly booted with a 'No contact'
-Make sure "No contact" doesn't affect the 'new connection' on a rejoin.
-Find out why game crashes randomly still in non debug mode.
-Fix other generic pointer crashes. - Most are fixed related to 'in game' crashes.
-See if you can fix 'RAM CHEAT'.
-Interface gets garballed to some machines when loading a second time. (Tries to also DL the UI)
-Fix issue where IP is displayed using a long name after hitting F9.
-Check crew level its wierd when changing ships
-Tractor noises is annoying with AI trying to pick up ships, see if you can adjust AI to only call tractor once and check if its on before using it again.
-Ram doesn't vanish on warp.
-Ram is added back on you when you respawn.
-When you exit with the new current coding, game crashes. Same for server. Add 'safe' close.
-When you get captured, you lose all your credits, fix this.
-Error/Crash involving 'error log' needs to be solved
-Fix issue where client logging stops after logging in to a remote server (not local)
-Make sure all values are sending properly.
-Fix one new crash on exit.
-RAM weapon should only be able to use one at a time.
-Several RAM weapon bugs fixed.
--

Before I start going 100% on SF2.0, I wanted to know what things remain that are 'bugs'.

From this point on, I'd say 1.3.5 may be one of the 'last' versions and now we will be working on SF 2.0, which will be alot of work! We will releasing some 'test versions' here and there, but overall, I want to get the remaining normal bugs solved. I understand there are a few crashes, but most of these are solved with a new game engine becuase they relate to loading of images and such like that. Overall it seems pretty stable, SF.Net Server has been running for a bit now happily. I might name the last version 1.3.6 depending on if it is playable with 1.3.5 because of the victory changes I will be doing.

Few things I've found is:

-Fix 'victory' planet amount (when you list specific planets). If you have alot of planets, they do not work. This is because the current 'victory planets' listing setting is using a 'to the power of' setting. For example of a planet list:

Earth: 2
Mars: 4
Jupiter: 8
Pluto: 16
Luna: 32
Mercury: 64
... Those are how IDs work for planet listing, so it can call them easier. For example, if your victory condition was 66, that would be Mercury and Earth, (64+2), or if it was 56, it would be Luna, Pluto and Jupiter. See how this works? It's a system that works great if there aren't a huge amount of planets, because it can process faster by converting them into numbers to check the victory condition. However, this doesn't work when you have more then about 30 some planets because if you try to specify the '30th' planet, that number is too high for a long value. Calculators will ventually error out, but in this sense, it will LOOP back to the start, so the ID of the 30th planet will be the ID of lets say, the 1st planet, thus giving a wrong victory planet listing.

-When you AFK you are gravity pulled. I should have it not effect if your on AFK mode, trying to see if this is possibly without horrendus amounts of coding. This can be bad if lets say, your Gpulled by the sun.

-When you scroll for a new weapon the downgrade/upgrade/you have a laser equipped doesnt display properly. I'm not too sure why it is doing this either. Apparently it has always been like this though. Works get scrolling down, but when you scroll back up, things go wacko.


===

If you have any minor things/changes to bring up say so now. After the next update, you probably won't see much for a while, cept beta versions which will not be playable online until it is close/fully complete.

Do not ask for new features, I won't do them in this version, Instead, make another post and request for 2.0.

Just to state, the new game engine is about 30% complete, and does work with bmp/png. However, the current BMP settings do not work with the new version because SF uses a wierd compression that only some programs can actually do. It's a older thing I believe. Most times when you save a bmp in a up to date program with NO compression, it leaves 'black' around the ship, gets messed up, crashes the game, etc. This new one supports proper saving of indexed bmps. with no extra work/compression. I've also fired about.. Well, 1000 missiles with trails, and there is no degrade of performance what so ever, it's great! Right now the worst thing apparently is that text rendering is slow, which is going to be changed/improved because as it stands, you lose some FPS to that. You won't see a huge different in DX for HIGHEST framerate, but you will see a huge difference in the degrade that happens when action is happening. Thus it has a better 'balance'.

[Eklei]

I was intending to address some current limitations and issues after finishing a small mod, but the mod has been on hold because I've been busy. Since development is apparently progressing so fast on SF 2.0, I had better jump the gun and start commenting now. I was hoping to have a completed mod as proof of concept, to illustrate limitations, and to reacquaint myself with the system. At this point I can't necessarily offer 100% certainty for some of the things I'll be saying.

I'll start with the most pressing issue, and that which is least a "feature request": boost.

Boost has been, let's face it, brutally nerfed, and I understand the reasoning. However, I don't agree with it. Am I the only one noticing that ships move more sluggishly now? The secret is that boost doesn't just increase your maximum velocity; it also increases acceleration, or at least it used to^[1].

Boost is, conceptually, your main thruster. When you fire your big rear thruster, boost is the specific and only reason your ship travels faster forward than in any other direction^[2]. Without boost, you accelerate just as slowly forward as you do in other directions. The result is either that ships handle like a cow (as they do now) or that they handle like a first person shooter character.

Why can't I just modify the boost? Well, see, that's the problem. So far, new functionality (like the cloaking time) has been implemented in an extensible manner. When it came to boost, though, this didn't happen. The values could have just been lowered in the SEC file, but instead the function was changed in the engine. Since boost has always been the most absurdly expensive component, with an exponential price curve, it's impossible for me to replicate the old boost by increasing the numbers without also making it cost more credits than a player can actually hold.

I would recommend returning to the old boost function, and just tweaking the SEC files, as the simple solution. However, I'll go even further and point out that the existing physics model is itself questionable. What follows may be something to think about for SF 2.0.

That boost increases maximum speed at all is wrong, not just from a gameplay standpoint (which may be debatable), but from a physical standpoint (which is not). Objects in a vacuum don't have a "speed limit", except for the speed of light, which is approached asymptotically. A dreadnought should have the same "maximum speed" as a corvette: 1 c, which can be approached but never reached. The difference in handling should only come about as a result of acceleration and turning. A "slow" ship won't move as fast as another not because it physically can't pass an arbitrary line, but because it would take prohibitively long to reach the same speed.

I don't personally care about accurately modeling relativity or anything. The easiest implementation would be for every object to store only a relative velocity that can go well above 1 c, which is then scaled down by the game engine to represent its absolute velocity, the one you actually see in game. The simplest function that springs to mind is 1-(1/(1+x)), where x is relative velocity. At relative 0.500 c, you'd be travelling at absolute 0.333 c in game. At relative 1.000 c, absolute 0.500 c. At relative 2.000 c, absolute 0.667 c. It's not a great approximation of relativistic velocities, but then it doesn't need to be.

Along this line of reasoning, I think a third decimal place should be added to fractional values. If 0.5 becomes a kind of practical maximum due to diminishing returns, we'll want more precision with smaller numbers. There's an argument to be made for more precision even with the current system. A starbase for example only has 10 "steps" of speed resolution.



[1] In a frigate, with an engine5, not using boost, to go from 0 to 0.66 c takes 3 seconds. Using boost, to go from 0 to 0.66 c takes 3 seconds. Using boost, to go from 0 to 0.83 c takes 4 seconds. So the acceleration bonus is basically gone now. I now often remove boost to free up volume with no tangible loss.

[2] Speaking of other directions, in addition to moving backward, you can also move sideways using the numeric keypad. However, there's a problem. These maneuvering functions can't actually be used for any maneuvering more demanding than lining up a distant shot, because the keyhandling is broken. Whenever two movement keys (turning doesn't count as movement keys) are pressed, the second movement direction overwrites the previous one. In a fairly amusing glitch, only the direction is overwritten; the properties of the old movement are retained, so you can actually boost backward by first pressing and holding forward and then backward. The practical limitation is that your ship can't move diagonally. However, because the glitch only overwrites direction, and not actual thrust state, the moment you release the first key, you lose all thrust. This means you can't even seamlessly move orthogonally, because your keypresses will be lost.

[NiteHawk]

Interesting about 2).

About 1): Boost being modified, I don't think acceleration was changed. Boost max speed was just changed. I don't think boost holds a acceleration bonus value at all.

Ships have the same acceleration, for example, I have 1.2RC7 old SF version, so tested a scout ship: 0.0gu to 0.78gu took just under 4 seconds. Going to 0.90ish gu in the new ship version, might take a tad longer. But what I'd like to point out is that boost doesn't affect acceleration, though generally, I think it should have a modifier in the end. Dunno, give it a go yourself if you want and equip a boost:3!

As for modifying the SEC value, if you just lowered the value in the SEC file, it would end up being the same since it uses one value. Technically you could just up it and it would be the same in the end too.

But I do agree, something needs to be done about the boost/movement system, ships are rather 'sluggish', they have been in 1.2 however too. Though it was less apparent due to the less 'max speed'. But it was noticably the same acceleration.

[Sandtrooper]

Acceleration speed is controlled in the data_game.sec file, it determines how FAST a ship can go from 0 to its max speed as defined in it's design. It doesn't take boost into account.

Code:

  max_acc                      50

A REEALLY low number makes a ship speed up like a slow tank
A high number makes the ship go from 0 to 60 (or max speed defined in design_ships.sec) in less than a second. Bases would achieve .10 C within a tap of the thruster key.

[NiteHawk]

Acceleration speed is controlled in the data_game.sec file, it determines how FAST a ship can go from 0 to its max speed as defined in it's design. It doesn't take boost into account.

Code:

  max_acc                      50

A REEALLY low number makes a ship speed up like a slow tank
A high number makes the ship go from 0 to 60 (or max speed defined in design_ships.sec) in less than a second. Bases would achieve .10 C within a tap of the thruster key.

Ships should have a acceleration rate and boosters have a 'accel bonus' I'd think

[Eklei]

boost: [energy capacity/power]  [max. vel. pct.]  [max. accel. pct]

boost*1000*150*30

The second number is "max vel. pct.", or max velocity percentage increase. When it says 150, that means increase the maximum velocity by 150% (to 250%). Since it no longer behaves that way, the fix is itself a bug. This is not debatable. I shouldn't have to set it to "25000%" to have it be 250%. Worse, I may not be able to, because the number can overflow.

Regarding price, maybe I was unclear. The game automatically calculates the price from the literal numbers defining the module or weapon. If I multiply these values by 10, the cost skyrockets.

boost*1000*1500*300
boost*1200*2000*500
boost*1400*2500*700

Now boost1 costs exactly 45,000,000, boost2 costs exactly 180,000,000, and boost3 costs exactly 11,503,270. Hint: boost3 basically just overflowed twice. It looped back around into the negatives, but didn't stop until it came back out in positives again. I estimate that the cost it wanted to produce was in the vicinity 4,306,470,566. Don't tell me this behavior is kosher. This is what I meant when I said it was impossible for me to just increase the values. The boost change needs to be undone, and then reimplemented in the SEC file.

The third and final number is max acceleration percent increase. This is bizarre, and you're correct in your observation that boost doesn't seem to confer acceleration anymore. I don't know what version this first started in, but I know that it used to work at some point in the past.

If I add two digits to acceleration, there's still no change. But if I add a third digit, it overflows and causes boost to actually lower my acceleration tremendously. This says that the code is still functional, but something is preventing it from taking effect. My wild guess is that it has something to do with max_acc (in sf_data_game.sec), but I can't verify this because the setting is itself buggy. Rather than just setting a limit on max acceleration, this value scales the whole acceleration system. If I change it from 50 to 5000, everything accelerates 100 times as fast.

[NiteHawk]

boost: [energy capacity/power]  [max. vel. pct.]  [max. accel. pct]

boost*1000*150*30

The second number is "max vel. pct.", or max velocity percentage increase. When it says 150, that means increase the maximum velocity by 150% (to 250%). Since it no longer behaves that way, the fix is itself a bug. This is not debatable. I shouldn't have to set it to "25000%" to have it be 250%. Worse, I may not be able to, because the number can overflow.

Regarding price, maybe I was unclear. The game automatically calculates the price from the literal numbers defining the module or weapon. If I multiply these values by 10, the cost skyrockets.

boost*1000*1500*300
boost*1200*2000*500
boost*1400*2500*700

Now boost1 costs exactly 45,000,000, boost2 costs exactly 180,000,000, and boost3 costs exactly 11,503,270. Hint: boost3 basically just overflowed twice. It looped back around into the negatives, but didn't stop until it came back out in positives again. I estimate that the cost it wanted to produce was in the vicinity 4,306,470,566. Don't tell me this behavior is kosher. This is what I meant when I said it was impossible for me to just increase the values. The boost change needs to be undone, and then reimplemented in the SEC file.

The third and final number is max acceleration percent increase. This is bizarre, and you're correct in your observation that boost doesn't seem to confer acceleration anymore. I don't know what version this first started in, but I know that it used to work at some point in the past.

If I add two digits to acceleration, there's still no change. But if I add a third digit, it overflows and causes boost to actually lower my acceleration tremendously. This says that the code is still functional, but something is preventing it from taking effect. My wild guess is that it has something to do with max_acc (in sf_data_game.sec), but I can't verify this because the setting is itself buggy. Rather than just setting a limit on max acceleration, this value scales the whole acceleration system. If I change it from 50 to 5000, everything accelerates 100 times as fast.

Musta been changed since 1.2. In general though the second number was the only affected number. I'll see about setting it back and fixing the accel value if it is a easy fix for now. The only real issue is the fact that if I lower the boost in general, the cost will be cheap as dirt. I'll have to see about adjusting the credit value to not skyrocket so high and start at a higher inital..

[NiteHawk]

     temp = (-power * par[0] / 100 * par[1] * par[2]) / 10;


That's the 'cost' of the module. Par[0] is the first number, par[1] second, etc.

Seems kinda steep to me. Again, I'm not any math wiz, so feel free to come up with a better setting.

I set back the boost, and lowerd the values

Scout
No boost: 72C
Boost 1: 79C
Boost 2: 84C
Boost 3: 93C

   [race]   *    100   500 -100      100     thrust4        none   boost*1000*15*30           [nr]9201
   [race]   *    140   700 -150      100     thrust4        none   boost*1200*25*50           [nr]9202
   [race]   *    160   800 -180      100     thrust4        none   boost*1400*35*70           [nr]9203

Are the values now, 15/25/35 basicly..

[Mars]

Man what brains you guys have..  """"" So the acceleration bonus is basically gone now. I now often remove boost to free up volume with no tangible loss."""""


thats been done for a while its called the boost bug drop the boost to save room as it for a long time dident seem to matter.  but in reality it does i find now ships minus the boost are limited at usually around 65 but in the old days they could go the limit or faster. 

my issue is the cost of it.

overall however Night has the game working so good i havent found any bugs other than sometimes the darn ram cheat bug will go off several times at once.  when it does that like three times fast then it will boot you. but once or twice wont. 

I say hes really got the game as bug free as it can be and im thrilled and proud that you have done so much work on the game thus far. 
 

[NiteHawk]

Man what brains you guys have..  """"" So the acceleration bonus is basically gone now. I now often remove boost to free up volume with no tangible loss."""""


thats been done for a while its called the boost bug drop the boost to save room as it for a long time dident seem to matter.  but in reality it does i find now ships minus the boost are limited at usually around 65 but in the old days they could go the limit or faster. 

my issue is the cost of it.

overall however Night has the game working so good i havent found any bugs other than sometimes the darn ram cheat bug will go off several times at once.  when it does that like three times fast then it will boot you. but once or twice wont. 

I say hes really got the game as bug free as it can be and im thrilled and proud that you have done so much work on the game thus far. 
 

Ram cheat still needs work becaue apparently a laggy system will trigger the values improperly for some reason. I will have to see...

Genreally if you drop a boost in 1.2 though, you kept your boost acceleration. which 'was' a bug. You cannot do that any longer, fixed that awhile ago

[NiteHawk]

I will fix acceleration for the next quick version. This should make boost worthwhile anyways.

Boost will be max_acc + whatever par[2] is, for now. max_acc is more 'inital_acc'. Which I'll probably remove or actually create a propre max_acc when I add acceleration 'per ship'. I might even do that this time around, depends how difficult it will be.

[NiteHawk]

I need to add acceleration to ships however, I will do this in 2.0.

For now values are:

boost*1400*15*10
boost*1600*25*18
boost*1800*35*26

Which gives about the same 'max boost' as it does now currently, perhaps a tad more. I lowered SB back down to 10GU for this reason.
As for acceleration, boost:3 grants you well.. Lets say I did a test, 0-0.72 with no boost is about 4.3-4.5 seconds, and 0-0.72 with boost:3.0-3.2 (*30)... Since boost is at '50' you take '50' and add the second par number, which is 30, so total acceleration would be 80. Sound good for now? I'll adjust this even more in SF2. Your weight also has some effect on your acceleration (always has) but overall still needs changes.

So 26 would be at least a 50% increase with default settings. I believe this also works the same was as boost does, as boost depletes, so does the acceleration. This is why I've increased the capacity of boost so it depetes slower, I've always felt boost depleted too fast. This sound good or should it be more?

In the future I can see boost depeting faster due to weight and such, and as well the smaller ships benifiting a bit better then they currently do now, and having like I said, a accel rating on each ship. Basicly this should allow some interesting settings since bigger ships will be alot tougher, so the little ships will need to be able to zip around them

[NiteHawk]

Okay Boost Acceleration is in place now and working.

I found a bug in the 'booting old connection' that would boot you due to someone else logging in, normally happening to you during login or when someone logs in. This is now solved so it should be OK for that matter if sometimes you had trouble logging in and had to restart the client.

People were getting dced? I'll have to look at that. Were you guys just sitting around, or playing? Or was this actually the CTD? that I will talk about below. Let me know.

People also said there was a random CTD? Is this constant? Or just on my server? Etc. Any issues triggering it. If you don't know what it is I'd like someone who gets it constantly to message me.

I know ram cheat is borked still, It does do its job though however it likes to boot when your computer lags up or something big happens for some reason. Possibly because the values don't get updated and the server thinks you are cheating. I will have to see what I can do about this.

As well, ST someone said something about you warping constantly when unafking, was that on YOUR screen or just others? The bug I fixed involved when you didnt have a warp drive it would keep trying to unwarp you, so if thats the case, thats a totally different bug to begin with. I've seen a bug with generic 'warping' that does that, so if it was just on other computers, there out of sync probably and I'll have to figure out some error coding there to prevent the bmp warp image from a endless loop.

Thanks.

[AdmiralTigerclaw]

To help with the RAM cheat checking, perhaps when it gets a 'possible cheater' flag, it checks ping first.

If it finds high ping, it will run a check every few seconds to see if the ping has come back down.  Then take three 'cheater' checks when the ping is low to cross-examine the results.

Essentially:

Possible cheating  >  Lag 1200 ms....  >  Mark and check lag once per sec... >>>>
Lag dropped to 300 ms > Cheat Review 1:  Clean, wait one second.  > Cheat Review 2: CLEAN, wait one second.  > Cheat Review 3: CLEAN, unmark and continue as normal.

Essentially, the best way to deal with this is to take multiple 'samples' and test the suspect multiple times.  If you fail one of the tests, that's okay... but if it fails say, multiple times like... two out of three. Boot them.

[NiteHawk]

To help with the RAM cheat checking, perhaps when it gets a 'possible cheater' flag, it checks ping first.

If it finds high ping, it will run a check every few seconds to see if the ping has come back down.  Then take three 'cheater' checks when the ping is low to cross-examine the results.

Essentially:

Possible cheating  >  Lag 1200 ms....  >  Mark and check lag once per sec... >>>>
Lag dropped to 300 ms > Cheat Review 1:  Clean, wait one second.  > Cheat Review 2: CLEAN, wait one second.  > Cheat Review 3: CLEAN, unmark and continue as normal.

Essentially, the best way to deal with this is to take multiple 'samples' and test the suspect multiple times.  If you fail one of the tests, that's okay... but if it fails say, multiple times like... two out of three. Boot them.

Well techically by lag is a bad idea. Some people lag like crazy mofos. I could see 16 tests (1 second) of frames to test on, currently it is done via every frame. There is an issue with doing it with long checks because a player can change there stats quickly and be done with it.

The issue with doing multiple test as well is that they can just toggle there ammo to full lets say, and thats only ONE check needed. They don't need to freeze it, they just simply need to change it 'once'.

I think there has got to be a better way. Checksum should work, I don't understand why it's doing as its doing now. I am wondering if theres a server Checksum check. Which generally is not what I wanted, only client side. Not needed for the server to do extra checks that can be embedded and hidden in the client. In coding perspectives, just because the game is going 'slow' shouldn't affect, it should just check slower, like most games would if the game is lagging, it is STILL doing the checks properly, but might be lagging.

So this is why I'm wondering that it could be something to do with online.

Though it might be better to check every second 'in general' instead of every frame.. Not sure. I'll still see.