Topic: Big maps and SFB style disengagement rules?

[el-Karnak]

...
http://www.eek-scripts.com/ftp/Kar_ePatrol_warp.zip

This mission can run in a single-player campaign dyna or a reg. D2 dyna.

Will be working in putting a big map and skirmish missions this weekend.

Coolness - say, let me know if you find the ascii map works out for you at dimensions bigger than 256x256 chars - I'm wondering if Taldren has hardcoded something there.  I've tried a couple of larger ones, but those have crapped out in weird and wonderful ways.

dave

One issue that kept me up late last night was the fact that this call ship->mGetHealthOnSystem(HardPoint) and ship->mGetMaxHealthOnSystem(hardpoint) kept crashing. I was surprise cuz the get status calls on stores always worked. If these 2 functions don't work then we will never be able to figure out engine damage.

[FPF-DieHard]

Observation:

The Warp speed ain't fast enough.   These maps are huge, maby go with speed 216 (Warp 6) and 512 (Warp .

The time taken to accelerate to warp speed "feels" a little long but I guess that will prevent abuse from using it too "Tactically" in Combat.

This is VERY interesting, almost like we have a new game on our hands   

[KBF-Kurok]

Dave while playing the disengagment on (skirmish) i noticed that you could  drop out of warp.just turn your speed down to 0 and wait. Dont know why any one would do this tho because you cant get back to yellow or red alert or go back into warp.

[FPF-SCM_TraceyG_XC]

Well, this looks like an interesting thread

[NuclearWessels]

Well, this looks like an interesting thread

GREAT TO SEE YA TRACEY!!!!!!!!!!!!!!!!!!!!!!!!

dave

[FPF-SCM_TraceyG_XC]

Well, this looks like an interesting thread

GREAT TO SEE YA TRACEY!!!!!!!!!!!!!!!!!!!!!!!!

dave

Thanks Dave... ;-)

This is a very long thread, can someone summarise for me? Any coding issues?

[NuclearWessels]

Lesseee ... we've been trying very large maps (around 2500x2500 instead of the usual 350x350) and letting players go to tactical warp either (a) strictly to disengage from a mission, or (b) to zip around the map during combat

The big issues code side have been tracking the current state of the player ship (must have enough engine power and sufficient speed built up to jump to the next warp speed) and disabling weaponry, repairs, recharging etc so the player can't effectively use the high-warp time to rearm then drop out of warp and clobber someone.

What has it involved ... turning off the ability to repair, tractor, load weapons, fire drones or other weapons ... then turn them back on once the player drops back down to combat speeds.  We've been toying with forcing the player to drop to lower alert status (yellow/green) for a time while they prep to go to warp.

So far most of it seems fairly mechanical, just getting all the pieces in the right order.   There are a couple of glitches still to be solved:
  - determining if a ship is at it's maximum attainable speed before jumping to the next warp speed (without reading the shiplist and computing the ship's speed manually I haven't seen a way to do this)
  - repairing a weapon automatically starts arming it even at green alert, haven't instituted a good cure for this yet
  - when we've sent a player's ship to high warp speed they can manually set their speed lower (to use the engine power for something else) and the current implementation allows this (maybe I'll just stick in a cludge that automatically resets their engine speed whenever they try that)

I think those are the biggies script side ... the gameplay issues that come out of this are another kettle of fish entirely

PS - I sent you an email about what that #$%@ hotmail did to the attachment (ARRRRRRGGGGGGHH!!!!!!)

dave

[NuclearWessels]

....

One issue that kept me up late last night was the fact that this call ship->mGetHealthOnSystem(HardPoint) and ship->mGetMaxHealthOnSystem(hardpoint) kept crashing. I was surprise cuz the get status calls on stores always worked. If these 2 functions don't work then we will never be able to figure out engine damage.

Arrrrrggggggh!!!!    Same here - regardless of the hardpoint chosen I'm getting a crash on those.   Bummer - I'd assumed that since the stores version worked so did the damage version (stupid me).

If that's the case then we might be stuck with saying you have to get to speed X first.

dave

[FPF-SCM_TraceyG_XC]

Lesseee ... we've been trying very large maps (around 2500x2500 instead of the usual 350x350) and letting players go to tactical warp either (a) strictly to disengage from a mission, or (b) to zip around the map during combat

Fascinating. The thing is, you can't turn the ship beyond about speed 50, I think. Would be fun in an asteroid field. lol

The big issues code side have been tracking the current state of the player ship (must have enough engine power and sufficient speed built up to jump to the next warp speed) and disabling weaponry, repairs, recharging etc so the player can't effectively use the high-warp time to rearm then drop out of warp and clobber someone.

I havent seen the API for nearly a year and unfortunately I dont have it installed on my system at the moment, but from memory I think the ship->mSetStatus() function doesnt work. Getting hardpoint health and maximum is also a problem because I think the functions werent updated from EAW (they are still expecting the EAW enumerated type and OP has a lot more hard points). Worth a try experimenting to see if you can get the functions to work with other hard points. If so, then write a simple function that converts the enumberated type to the expected, this was necessary with the hull class enumerated type (you'll know what I mean when you see my script code)

What has it involved ... turning off the ability to repair, tractor, load weapons, fire drones or other weapons ... then turn them back on once the player drops back down to combat speeds.  We've been toying with forcing the player to drop to lower alert status (yellow/green) for a time while they prep to go to warp.

Getting and setting spares works. When a ship goes to warp, record the number of spares it has then set it to zero, when they exit warp, restore the previous value, that should stop repairs in warp, unless the player starts a repair before going into warp, but then at the most they can only repair one hard point.

So far most of it seems fairly mechanical, just getting all the pieces in the right order.   There are a couple of glitches still to be solved:
  - determining if a ship is at it's maximum attainable speed before jumping to the next warp speed (without reading the shiplist and computing the ship's speed manually I haven't seen a way to do this)

Tough one, would need to look in the API for that one

  - repairing a weapon automatically starts arming it even at green alert, haven't instituted a good cure for this yet

I think there's a mSetWeaponStatus function (or something like that), but I dont think it works

  - when we've sent a player's ship to high warp speed they can manually set their speed lower (to use the engine power for something else) and the current implementation allows this (maybe I'll just stick in a cludge that automatically resets their engine speed whenever they try that)

From memory, I think there is mSetSpeed, and mSetImmediateSpeed (or something like that), the former sets the ships speed selector, the latter changes the ships speed immediately. While in warp, you could  trigger a timer to go off every second to set the ship speed selector to maximum, not a very good way of doing it though.

I think those are the biggies script side ... the gameplay issues that come out of this are another kettle of fish entirely

PS - I sent you an email about what that #$%@ hotmail did to the attachment (ARRRRRRGGGGGGHH!!!!!!)

dave

I resent the email to your home email :-)

[NuclearWessels]

Coolness!  Thanks Tracey - I'll try out the idea of a translator from the OP to EAW hardpoints and see how that goes.

The players start out in a vast tract of empty space -- a good distane from terrain -- if they go to wrp they've been warned to take a careful look ahead and keep their eyes peeled

I was hoping to avoid monkeying with the player's spares as a means of avoiding the repair issue, but since turning the repair officer off didn't help ...

Cool ideas, thanks muchly!

dave

[FPF-SCM_TraceyG_XC]

I think the repair officer only works for AI

[el-Karnak]

Observation:

The Warp speed ain't fast enough.   These maps are huge, maby go with speed 216 (Warp 6) and 512 (Warp 8 ).

The time taken to accelerate to warp speed "feels" a little long but I guess that will prevent abuse from using it too "Tactically" in Combat.

This is VERY interesting, almost like we have a new game on our hands   

OK, we now need to get some speed terms straight if we are going to be realistic about implementing warp-outs.

As you may have noticed in the above posts I have been doing some research into how to fit all these warp specs. in the game. First, we need to use the Okuda Warp Factor tables because they are the most canon and fit in with both the TOS and TNG series. Info on this can be found here: http://en.wikipedia.org/wiki/Warp_factor

Basically, the Okuda scale uses the following equation:  speed in C = (warp factor)^(10/3) for warp factors 1 thru 9. Then an asymptotic scale is used for 9 thru 10 where warp factor 10 is the highest attainable velocity. Anything faster requires a Borg trans-warp drive. Some examples are:

1) Fight of the Phoenix in 2063 AD achieve warp factor 1 which is (1)^(10/3) = 1C

2) Rommies warp tech. were stuck at warp factor 3 until Klingon assistance in 2260s which is (3)^(10/3) = approx 39C.
(Fictional distance between Romulus and Earth according to "Star Trek: Star Charts" is 50 light-years and this fact stands up with any references in Star Trek: Enterprise. So, a Rommie WB at warp factor 3 = 39C (and, yes Scotty was most definitely drunk-on-the-job when he said the WB could only go sub-light) would take about 467 days to reach Earth so this keeps the Rommies away from Earth until the TOS era, but it's feasible for them to sneak in a spy or two to Vulcan like was done in StarTrek:Enterprise season 4).

3)  Star Trek: Enterprise's premise is about the discovery of the warp 5 engine which is (5)^(10/3) = 214C. This means that during the Earth-Romulan War of 2156-60 Earth vessels could go the 50 light-years to Romulus in about 85 days
So, it fits with this war being pre-dominantly in Romulan space.

4) Kronos is approx. 75 light-years from Earth (cf. "Star Trek: Star Charts" ) and in the TOS era most ships were topping out at warp 6  or warp 7 which is (6)^(10/3) = approx 392C or (7)^(10/3) = 656C. This means travel time for Kirk from Earth to Kronos about 70 days which fits with the going-ons of the TOS era.

5) In the TNG era, there is a reference from Janeway  stating that TOS era ships could only go half-speed of TNG era ships. What she is referring to is that TNG ships top out at warp 8 to 9. So, warp 8 is ( 8 )^(10/3) = 1024C (a little ironic for us programmers ).  Warp 6 at 392C is definitely less than half of warp 8 at 1024C.

6) Star Trek:Voyager's premise is about it taking 75 years for USS Voyager to travel 75,000 light-years from the far reaches of the Delta Quadrant to reach Federation which fits with USS Voyager doing an avg. of 1024C or warp 8 per year.

Then, there are the anomalies like Enterprise NX-01 going from Earth to Kronos in 4 days which is explained in "Star Trek:Star Charts" that the Vulcans found some sub-space corridors to help out, etc. Kirk going to the galactic core in Star Trek V is more sub-space stuff, etc. So, we just have to dispense with those exceptions in order to keep everything in order.

Next, we need to translate all this into the game speed used in the SFCOP missions. The SFCOP manual explicitly states in the glossary for the "Speed" entry that all combat is done at sub-light speeds which negates all the SFB warp factors 1,2, 3 at less that speed 31 stuff. In addition, the manual is very clear about 1 unit of speed takes the ship 10,000km per turn. So, what is a turn. At game speed 8, it is approx 30 seconds, At game speed 11 it is approx. 10 seconds.

You can then figure out what the SFC game speed should be for warp factor one by taking the classic physic equation of:

v = d / t.

So, at game speed 8, a ship is going :  v =  (10000KM) / (30 seconds) = 333333 m/s.  Compare this to the speed of light (ie. C = 3 x 10^8 m/s) and your ship is going (333333) / (3 x 10^8) = 0.0001111 C.

Not very fast is it?  You can invert this value ( 1 / 0.0001111) = 9000. 9000 would be warp factor 1 in the game when using game speed 8.

How about at game speed 11? Crunch the numbers:  v = (10000KM)/(10 seconds) = 1000000 m/s. Compare this to the speed of light (ie. C = 3 x 10^8 m/s) and your ship is going (1000000 ) / (3 x 10^8) = 0.0003333 C.

That's a little better. You can invert this value ( 1 / 0.0003333 ) = 3000. 3000 would be warp factor 1 in the game when using game speed 11.


To conclude: I am pretty much saying that it would be hard to accept any game speed less than 3000 as being "faster than the speed of light".  So, if  we are going to use the step ladder approach of going to speed 125  then 343, etc.  that's cool. However, just don't call it warp factor 5 and warp factor 7.  Warp factor 5 quotes as speed 125 is really something in the area of 40% (ie. using game speed 11) of the speed of light.


Going speed 9000 is probably too fast to goto warp, so I will go with speed 3000 and just explain the game speed difference between 8 and 11 as some voodoo time dialation stuff. If I need to bump it down somemore then I will put more pins in the warp speed voodoo doll, but I don't think we can go lower than speed 2000 in-game and still call it FTL travel.

[Capt_Bearslayer_XC]

Thank you for the dissertation....

I always hated the SFB combat at warp speed thing... by the time you said, "Fire" the ship would be out of range at warp speeds....

[Hexx]

Thank you for the dissertation....

I always hated the SFB combat at warp speed thing... by the time you said, "Fire" the ship would be out of range at warp speeds....

SFB has never really done anything that makes any sort of sense as background info..

[el-Karnak]

Thank you for the dissertation....

I always hated the SFB combat at warp speed thing... by the time you said, "Fire" the ship would be out of range at warp speeds....

Yeah, Kirk having drunken Scottish engineers can wreak so much havoc.

[FPF-DieHard]

Thank you for the dissertation....

I always hated the SFB combat at warp speed thing... by the time you said, "Fire" the ship would be out of range at warp speeds....

Agreed, the time distortion thingy was simply retarted.

SFC combat it at impulse, for easy of use and to prevent my head from explding from reading Karnak's post again, I think we should go with speed 100 being the speed of light.   Speed 200 for Yellow allet, 800 for Green should work on these maps.

PS I found another exploit, it you hit "Red Alert" EXACTLY when the ship accelerates to warp,  your weapons will start to arm while you mantain the high speed.   Timing this is very difficult but still possible.

[el-Karnak]

Thank you for the dissertation....

I always hated the SFB combat at warp speed thing... by the time you said, "Fire" the ship would be out of range at warp speeds....

Agreed, the time distortion thingy was simply retarted.

SFC combat it at impulse, for easy of use and to prevent my head from explding from reading Karnak's post again, I think we should go with speed 100 being the speed of light.   Speed 200 for Yellow allet, 800 for Green should work on these maps.

PS I found another exploit, it you hit "Red Alert" EXACTLY when the ship accelerates to warp,  your weapons will start to arm while you mantain the high speed.   Timing this is very difficult but still possible.

Speed of Light would have to be in the 3000 plus range. Lower to 2000 if we have to. You can use speed 100, 200, and 800. but call it 1/4 impluse power, 1/3 impluse power , 3/4 impulse power or 1/3000C, 200/3000C, 800/3000C or whatever  sub-FTL term speed you like. In the ST movies, they loved to use 1/4, 1/2 impluse power like in Star Trek III when the Enterprise and Excelsior are leaving space-dock.

In SFC3 there are ship that can go speed 100 so we have to keep that in mind to make a lasting realistic speed standard regarding FTL travel. We should also try to figure out what in-game speed Taldren used for SFC3 tac. warp.

[FPF-DieHard]

What was "Warp" in SFC3, 200?

[el-Karnak]

What was "Warp" in SFC3, 200?

If you use my test warp mission that posted, the ship will go speed 1000. That feels a bit slower than the tac.warp used in SFC3. 2000 is my guess right now without running some SFC3 tests.

[Hexx]

I know I'm going to hate myself for asking ..well OK I could never hate myself..
but why do we care?

Let's call it "mommy" speed (I believe coined by J'inn)  and leave it at that