Dynaverse.net
Taldrenites => General Starfleet Command Forum => Topic started by: TarMinyatur on December 26, 2014, 06:13:03 pm
-
I've figured out the offsets for several variables in the game, including weapons' accuracy, damage, and a few energy costs. I've also fixed the F11 hover bug (the top-layer target info has one extra character which makes it illegible).
My question is this...
Should this information be kept secret?
We, the fans of this great series, modify the shiplists, scripts, strings, textures, sounds, models, etc. But nobody, AFAIK, has released a modified Starfleet.exe.
I don't think it is a violation of the EULA to tinker with assembly-level code and freely let others try it. Nobody can play SFC with a stand-alone 8MB modified exe. As long as the checksum and CRC are enforced, I think fair play can be ensured. (Although nowadays SFC is 99% single-player, so this is barely an issue.)
Thoughts?
-
I am not using any special tools. HxD is a free hex editor. At first, the data in a Starfleet executable looks totally meaningless -- just a bunch of stuff like E9 E2 04 00 F0 E2 08 00. [Shrug]
But then you find gems like this: 09 08 07 06 05 05 04 03 02 01 01
What is that?
If it were 09 08 07 06 05 04 03 02 01 00, it could be a count down, a list, or anything generic. But the former series is far too specific to be anything random.
You need to learn how to read numbers in hexadecimal form. (It temporarily hurt my brain learning this!) If you're looking for a ten, that may be written as a "0A" byte. (It may be written as "0A 00 00 00" for a 4-byte integer. Why not "00 00 00 0A"? That's little-endian format. Yes, another brain twister to resolve.) The Windows calculator in programmer mode can do part of this for you, once you understand the concept. HxD has a search function that finds little-endian values.
Let's say I want to find the damage that Large Drones do. That's 24, right? I need to search for 24 in hexadecimal format. That's 16 plus 8, which is "18" in hexadecimal (don't say eighteen, say one-eight). But if I search for "18", I'll find several thousand of them! I need to be more specific and use the clues that are found in human-readable hex. And also try 4-byte (32-bit) values like "18 00 00 00" which greatly narrows down the search.
Scattered throughout the .exe are strange words like AVtDrone, AVtPhoton, AVtHellbore, etc. These can be helpful indicators of what's nearby.
I began exploring the Starfleet2CE.exe because I wanted to fix the misleading version number in the splash screen. 2.6.6.0 was wrong, it should be 2.6.7.0. Okay, I found that 7 times in the code! One of them must affect the splash screen. Trial and error found the relevant address to be 0065FA28. You can change 2.6.6.0. to A.D.A.M. if you want. (Use the human-friendly right column of the HxD screen to more easily change alphabetical stuff.)
-
According to Frey, the SFC2 series is considered abandoned, so as long as you don't try to make money from it you should be alright to modify it any way you like.
-
Huh, I wonder just how far we can change the game with this? For that matter if we can reverse engineer SFC OP to fix the multiplayer. Any info we can get might also help Exeter.
-
Javora, there is no theoretical limit to what can be done through editing Starfleet2OP.exe. However, it gets extremely difficult to do anything sophisticated by changing a few bytes here or there. Such as improving the AI's logic.
Exeter has the C++ code for EAW and CE. He has the easy (and sane) way to change the values of variables and such. I have no idea how to address complicated things, such as Gamespy's networking stuff in Orion Pirates.
I can make the Suicide Overload Fusion Beam do 2x damage (instead of 3x damage). That's easy.
I might be able to display the scanner damage on the HUD (which has always been unknown). That's not easy but I want to do that.
Stuff like expanding the player slots from 6 to 8? Probably close to impossible.
If anyone gets onboard the Hex Editing of the game. Let me know. It would be a shame to duplicate our efforts. I already have a good chunk documented. I guess I'm waiting to see if anyone can present an argument that it is not a good idea to experiment with the executable.
-
Thanks Tar, I guess I was being a little to optimistic about cracking into SFC OP as it seems that no one has that particular code. I was thinking if we can figure out what OP has that is over and above SFC II then we can port it over to SFC CE. Oh well it's still a great idea Tar.
-
Exeter basically refused to even look at the old code due to its apparent lack of organization and poor formatting. He prefered to start from scratch in all areas with the exception of graphics, in which he is not an expert. Maybe you can get him to change his mind.
-
2.679 is the latest unofficial patch. A 2.690 mauler/bolt mod is available too.
-
Slow missiles back to speed 8 :)
-
StarfleetOP.exe is similar. The tables are usually followed by the name of the system, such as AVtAntiDroneRack@@ or AVtDisruptorTube@@.
Look at address 445AE4 to get started with AMDs. The other weapon systems follow.
Adam, you could mod the Heavy Phaser-A to start at 30 (?) damage for a TNG ship, instead of mounting Phaser-4's, for example. It's all up to you.
-
Slow missiles back to speed 8 :)
I haven't found the speed variables. (SFBMode=1 will give you Speed-8 Drones and Speed-32 Plasma in Community Edtion.)
I've looked for obvious hexadecimal representations of 40, 36, 34, 32, 24, 22, 20, 16, 12, 8 in various sequences...no luck yet.
-
Slow missiles back to speed 8 :)
I haven't found the speed variables. (SFBMode=1 will give you Speed-8 Drones and Speed-32 Plasma in Community Edtion.)
I've looked for obvious hexadecimal representations of 40, 36, 34, 32, 24, 22, 20, 16, 12, 8 in various sequences...no luck yet.
Have you tried switching to SFB mode and seeing what changes? It might take some searching, but it will be in there if it is swapped out.
-
Slow missiles back to speed 8 :)
I haven't found the speed variables. (SFBMode=1 will give you Speed-8 Drones and Speed-32 Plasma in Community Edtion.)
I've looked for obvious hexadecimal representations of 40, 36, 34, 32, 24, 22, 20, 16, 12, 8 in various sequences...no luck yet.
Have you tried switching to SFB mode and seeing what changes? It might take some searching, but it will be in there if it is swapped out.
I don't think the executable is self-modifying. The speed of plasma may be determined at runtime. The value of 36 (as a float or integer) is found several times, but changing those to 60 (one-by-one) didn't result in ultra-fast torpedoes. Maybe the speed is actually 36.000001? That would have a different representation in float format and would be laborious to search for. But it makes no sense to set the speed to anything mysterious. Dave or Zach or Erik would have typed 36.0f in the C++ code.
Your logic is good, Corbomite. But I don't know how to detect the difference in memory between SFBMode=0 and SFBMode=1 with regard to seeking weapon speed. Perhaps if I view the .exe while it is running, then maybe I can find the location of Plasma's speed on the heap. I'll check out the game with a debugger.
-
The Fusion Beam (and, in fact, all weapons) can be given a byte value between zero (00) and 255 (FF) for its damage.
Assuming you're using StarfleetOP.exe...
Search for AVtFusionCannon. You should find it near address 456580.
Just above that in the "open" area, are the Fusion Tables.
----------------Range-----------------
0 1 2 3-10 11-15 16-24
4564A4: 0D 08 06 04 03 02 // This is the damage of the Fusion Table if you "roll" a 1.
13 8 6 4 3 2 // This is the damage in regular numbers.
4564AA: 0B 08 05 03 02 01 // Damage if you "roll" a 2.
11 8 5 3 2 1 // Damage in regular numbers.
etc.
So if you wanted to make Standard Fusions do a flat 32 points of damage ("20" in hexadecimal) across its entire range, you could do this:
4564A4: 20 20 20 20 20 20
4564AA: 20 20 20 20 20 20
etc. (for the other four rows, i.e. for "rolls" of 3, 4, 5, and 6)
Then you get to the Overload Table.
(View the attachment for the first row of Fusion Table for StarfleetOP.exe.)
-
Well, Adam, it only took 15 years! Someone must have "cracked" the code a long time ago, simply because it isn't terribly hard to do. I never wanted to modify weapon accuracy or damage, so I never bothered. I assumed that 14DegreesEast/Taldren had encrypted the charts and other sensitive mechanical data.
If you try, however, to give a weapon extended range (or remove a myopic zone) you will not succeed. The weapons' limitations are defined elsewhere. The 1-byte charts are only used to determine damage. They do nothing to influence AI behavior. The AI will probably "think" that a Phaser-3 is just a little pea shooter, even if you modify it to deal out 50 damage.
Merry Christmas.
(Interesting ESG find this morning.)
(I found the locations of the numbers that define Range Brackets. A Disruptor4, for example, can theoretically fire up to a distance of 256 k.)
-
Adam, the range brackets can indeed be changed.
The programmers used floating point numbers. They also multiplied SFB's units by ten. So when we think of Range 30, they wrote 310.0f. Why not 300.0f? That would not enable the decimal values of 30.01 to 30.99 to be valid ranges. So it is 310.0f non-inclusive.
View the attachment for the first range bracket for the Disruptor.
738BF8: 00 00 21 41 // This the highlighted value for 10.0f.
Floating-point number bytes are weird. Figuring them by hand is hard. I downloaded a free IEEE Calculator to help me. But I have to rearrange them for little-endianness.
00 00 21 41 is first rearranged to 41 21 00 00 and then condensed to 41210000, which you can put in a special calculator to get an ordinary number. In this case it is 10.
Examples are always helpful...
Common floats in little-endian format:
960 = 00 00 70 44
800 = 00 00 48 44
680 = 00 00 2A 44
640 = 00 00 20 44
610 = 00 80 18 44
480 = 00 00 F0 43
440 = 00 00 DC 43
410 = 00 00 CD 43
400 = 00 00 C8 43
390 = 00 00 C3 43
360 = 00 00 B4 43
330 = 00 00 A5 43
310 = 00 00 9B 43
250 = 00 00 7A 43
240 = 00 00 70 43
230 = 00 00 66 43
160 = 00 00 20 43
120 =00 00 F0 42
110= 00 00 DC 42
90 = 00 00 B4 42
60 = 00 00 70 42
55 = 00 00 5C 42
50 = 00 00 48 42
45 = 00 00 34 42
40 = 00 00 20 42
36 = 00 00 10 42
35 = 00 00 0C 42
30 = 00 00 F0 41
25 = 00 00 C8 41
20 = 00 00 A0 41
15 = 00 00 70 41
10 = 00 00 20 41
5 = 00 00 A0 40
The ADD is unusual. It won't fire beyond 3.99 even if its max range is set to "00 00 70 42" (60.0f), for example.
So search for floats which are 10x the numbers you seek.
Plasma speed (36) might be stored as 360.0f. Slow Drone speed (16) might be stored as 160.0f. (Edit: Nope. But I may have found the location of certain Weapon Arcs, such as 15, 55, 120, 210, 240, 270, 310, 330, and 360.)
-
I'll be happy if you can just give the TRL and TRH a real graphic to point to, but that may not be in that file.
-
Speaking of TR beams, does anyone remember how to code them into the shiplist? It's been so long since I turned them on I've forgotten. I've tried all the combinations that I can think of and nothing. IIRC they show up with the PPD icon.
-
Thanks. The HP display won't matter as I'm putting them on non-player races. I'd be surprised if it controls the sprites file at all though.
-
The TB texture would be best, but since it doesn't do damage I can't see why TB's would be in there at all except for range. You never know though. PHA for TRBL and PHB for TRBH would suffice though as long as those Phasers retain their graphic as well.
-
I haven't yet found the variable that defines the Overload Range as 8.99. Maybe it is stored as 90.0f. I've looked at those, but they are related to game speed. I'll keep looking...
I can enter damage values in the charts for a theoretical Range-15 Overloaded Disruptor, but it cannot be fired. The HUD info shows that the weapon is ready to fire (i.e. red font), and it correctly shows the max, min, and estimated damage.
-
Some values such as max overload range may have been programmed as constants in one location. I don't know how this would translate to the binary but I'm sure it has some type of effect (not a programmer but know some theory).
-
Tried changing the fusion range but it didn't work. Still couldn't fire passed its usual range.
Let's say we want to extend its maximum range from 24 to 32. We need to locate its terminal range bracket, the one that is 16-24 by default.
That bracket has the 4-byte float value of "00 00 7A 43", which is 250.0 in ordinary numbers. Are you with me, Adam? You should find that sequence shortly before the word "AVtFusionCannon@@". (Please check out the attached .jpg image.)
If you change those 4 bytes to "00 00 A5 43", then the bracket has grown to 330.
00 00 A5 43 is rearranged to 43 A5 00 00. Then it is condensed to 43A50000. And that's how the number 330.0 is represented as a 4-byte "floating point number".
Since the on-screen range is one-tenth of the internal number, the Standard Fusion will be able to fire up to, but not including, 33. In other words, your maximum range is 32.99. (Overloaded Fusions will not be able to fire beyond 8.99.)
Edit#1: Something unknown is enforcing a maximum range of 24.99 on the Fusion Beam! So the previous modifications are insufficient at the moment.
Edit#2: I found a secondary maximum range limiter. It is peculiar because it is 249.9f, not 250.0f. Also found the OL range limiter, which is set to 89.9f, not 90.0f.
-
Confirmed. The maximum range for
Fusion Beams, Hellbores, and ADD's is limited by a constant that hasn't been located yet. [Fusion and ADD limiters have been found.]
The maximum range for ESGs and Disruptors can be increased.
I was able to hit a target with a Standard Photon from range 38. (I increased the 13-30 bracket.)
I can't, however, fire Standard Photons in an incompatible bracket. So if I want to modify the maximum bracket for a Standard Photon, I change the next-to-last bracket, not the final one (which was intended for Range-55 Proximities). This concept should apply to Disruptors of Type 1, 2, and 3, as well.
I'll check out other weapons...
I reduced the range of the Phaser-3/G so that it is a defensive weapon, not a anemic sniping weapon. Holy smokes! One Hydran Hornet was essentially missile-proof. This is truly how Gatlings are supposed to work.
I changed the Ph-3/G's inefficient outer brackets (3, 4-8, 9-15) to be functionally identical to the Range-2 bracket. So now it hurts to get close to a Gatling-equipped vessel, everytime. There is a strange feature that allows players to fire in futility at range 15, even though the fire button never gets highlighted lower-left HUD shows the Ph-G data in purple font, not red, at 0-0 (0). The AI, so far, cannot waste its Phaser-G shots.
Phaser-3/G Chart:
----Range----
1d6 0 1 2
1: 4 4 4
2: 4 4 4
3: 4 4 4
4: 4 4 3
5: 4 3 2
6: 3 3 1
Nice chart, IMO. Only took 15 years to get it!
-
Slow missiles back to speed 8 :)
It's not an ideal solution, but the endurance of the missiles can be reduced. A speed-16 missile has a range of 48. A speed-8 missile has a range of 24. Endurance, however, is stored as an integer, not a float, so the range can't be set to half. Type-I's and Type-IV's each have a value of 3. Dogfight missiles have a value of 1. The so-called large missiles carried by fighters have an endurance of 2 turns.
Speed 16 for two turns (instead of three) yields a range of 32, still a bit high if you're shooting for 24.
Unfortunately, this would affect medium and fast missiles too, taking a big chunk off of their range. A fast missile would travel only 64, instead of 96. Not an ideal means to an end. Nope.
The speeds of seeking weapons will be found sooner or later...
-
On a good note, I managed to have the disruptor beam take its texture from a different bmp other then the one it shares with the mauler. Currently the mauler and Disruptor beam share a texture. Pain in the butt if you want to change one color it changes the other. I just maintained the mauler at its usual white and made another texture of it red and had it read it. The result. Woohoo red Disruptors and white maulers. Just for fun to see if it would work.
So you're saying that it does interact with the sprites file then? When you say Mauler and Disruptor Beam I assume you mean the Heavy Disruptors since the normals have the pulse action? Hmm, since there is no texture file for the TR Beams (that I know of) I wonder what they reference to get that plain blue beam. Both of you are making impressive progress. Why has no one realized this before? Were the simple tools not available then?
-
9-12 is Photon range. Dizzys have worked as advertised. They're all the same weapon with better targeting scanners. There is no difference between a Dis1 and a Dis4 except one has better eyesight than the other. For game code purposes they may be different objects, but as far as game play goes there is no difference as they go (usually) by ship size. You can put Dis4's on anything though. Some ranges/limits may be hard coded elsewhere and can not be affected since there is no code to read in those instances, but that wouldn't stop the HUD from giving the "correct" information about range and damage should the weapon actually go that far.
-
The number of fields for each weapons chart may have been amalgamated into one type for coding. You would then get overlapping damage and range information as each weapon would take up the required fields to make their charts. This is just a guess though.
-
IIRC, SFC OP handles plasma tracking differently than SFC II. Any way we can figure out how that works?
-
I did find out that you can change the Phaser B's overall damage to the hull. The damage that only interacts with the shields seems to be coded in such as its 1/3 of the bare hull damage. So we can't as of yet make any changes to the shield damage apart from the overall damage. They are linked.
True. But I think we can eventually make the Phaser-B use any of the existing conversion constants. This data can be found through a Hex Editor: 0.25, 0.33, 0.67, 1.33, 1.5, 1.67, 1.875, etc. If the Phaser-B strikes a shield, it uses a conversion constant of 0.33 (represented as a 4-byte float) and applies that to the chart's damage value. But if we simply change 0.33 to 0.17, for example, that will affect every system that happens to reference this constant! Not good.
The call to the constant needs to be adjusted, not the constant itself. The Phaser-B can be directed to look in the memory location containing the value 0.17. So let's say 0.17 is stored at 0x00123450 and 0.33 is stored at 0x00123454. I can hypothetically subtract 4 bytes from the call so that the Phaser-B will read the value of 0.17 instead of 0.33.
-
Found the speed of Disruptor Bolts and Photon Torpedoes!
Again, there is a multiple of ten that we aren't used to. The value for a Photon is 5000.0f. I changed it to 2500.0f. I love speed-250 torps. The game is cinematic, like TWOK.
I'll continue to update the offsets on Page 1.
-
I'm editing SFC 2.670 Community Edition. I don't think Plasma-X is in this game, unless Bonk and Strat and company were highly optimistic. I guess it may be a reference to the earliest days of SFC1 in which Plasma was extra fast, 40? Maybe there is a variable that is subtracted from 400.0f to get 360.0f, and thus we never see that particular 360.0f in the hex code...
-
Found the secondary limiters to ADD range. ADDs can fire at a range of 0 to 255 (Not that that's a good idea).
Found the data that determines Plasma Torpedo arming costs (F, G, S, EPT-G, EPT-R).
Found Phaser firing rate and automatic Tractor range (ship-to-ship).
Adam, can you post a screenshot of your Hex Editor showing the area that controls Plasma Speed?
Your data doesn't list any memory addresses and I don't know what the parentheses mean.
Edit: Nevermind. I figured out your data for EAW. Nice find, man! Searching for 360.0f did the trick. Plasma D,F,G,S,R all traveled at a leisurely speed of 20 in my ancient galaxy here.
Community Edition has SFBMode=0 in the sfc.ini file which may be the reason I can't set any custom torpedo speeds. It's either 32 or 36. Hmm...
-
I'm editing SFC 2.670 Community Edition. I don't think Plasma-X is in this game, unless Bonk and Strat and company were highly optimistic. I guess it may be a reference to the earliest days of SFC1 in which Plasma was extra fast, 40? Maybe there is a variable that is subtracted from 400.0f to get 360.0f, and thus we never see that particular 360.0f in the hex code...
None of the X weapons were in SFC II. I remember Eric Bethke crowing about the new weapons features and X ships. This would have been coded into OP after SFC II release. I also remember that how a plasma round persuited a ship was fixed as well in OP. I would think that code may have been ported over to missile as well. IIRC one of the original coders on the SFC II put a comment line stating that it wasn't finished.
-
:D :D :D :D :D :D :D :D :D :D :D :D :D :D
TAR, I LOVE YAH!!!
I was just thinking about the 250 torps back in SFC1 days I loved it
I burst out laughing like a nut at 3 a.m. when a Kzinti Medium Cruiser fired wonderful slashes of Disruptor fire across my bow. Try 3200.0f instead of 12500.0f for their speed sometime. Press F9 and you're in a movie. (They still sometimes disappear.)
-
Corb, found what I was talking about..
It was the DisH range chart.
112 00 00 00 00 0
116 41 20 00 00 10
120 41 A0 00 00 20
124 41 F0 00 00 30
128 42 48 00 00 50
132 42 B4 00 00 90
136 43 20 00 00 160
140 43 66 00 00 230
144 43 9B 00 00 310
148 43 CD 00 00 410
The chart we currently have says 5-15 then 16-22 but the game has it as 5-9,10-15... :crazy2: :crazy2: :crazy2:
But I cant say I care :angel:bc Im excited about the news of the speed being found :D :D
That's just a bunch of nonsense to me. Are you saying that the values change between these two fields? As long as the two fields that encompass 5-15 are consistant there is no change in gameplay effect. I have seen no evidence of change in to hit/damage over these ranges. It might need further testing though, and there is the matter of leaking damage which may account for that chart as it may be done on a different chart for that weapon.
-
Your Chart for Heavy Disruptors
Range: 0 1 2 3-4 5-15 16-22 23-30 31-40
To Hit: 100%83% 83% 67% 67% 67% 50% 33%
Damage: 10 10 8 8 6 4 4 4
What I gather from the exe code
Range: 0-1 1-2 2-3 3-5 (5-9)(9-16) 16-23 23-31 31-41
Damage: 10 10 8 8 6 6 4 4 4
Damage: 10 10 8 8 6 6 4 4 4
Damage: 10 10 8 8 6 6 4 4 0
Damage: 10 10 8 8 6 6 4 0 0
Damage: 10 10 8 0 0 0 0 0 0
Damage: 10 0 0 0 0 0 0 0 0
then it continues with overloaded values. what do you think corb? any significant difference
That looks a lot like the PHB chart structure, which is a Range of Effect type chart, where Dizzys are a To Hit/Damage weapon. I got my X-Weapon info from Dave Farrell. I suppose it could have been erroneous, but gameplay has not produced any reason to doubt it. I guess testing might be in order.
-
But that chart has six entries to simulate a D6 being rolled, then you calculate damage (which can be none) based on range. To Hit/Damage weapons roll a d6/2d6 to determine if the weapon hit or not, then damage is assigned based on several factors (like Phots not degrading over distance and Dizzys/Hellbores doing so).
-
If you find the regular dizzy chart it may give us some insight as to what is really going on.
-
Another thing I'd like verified is the OP cloak seeking weapon damage reduction chart. Dave said it was "SFB specs", but I had to assume that. We would need the % damage reductions for tractored and non-tractored ships.
It'll look something like this and when found SFC-CE/EAW can be brought up to specs:
_Cloaked Ship Status_ _Chance of Normal Damage_ _Chance of 1/2 Damage_ _Chance of 1/4 Damage_
Non-Tractored 33.3% 33.3% 33.3%
Tractored 66.7% 33.3% 0%
-
I can't read hexidecimal so it is all just number sequences to me.
-
It'd be nice to check the seeking weapon reduced damage due to ECM chart too. All the games should be the same in that regard, unless something is broken/unfinished in EAW.
-
DesireGameSpeed....DesireTurnRate....DesireChargeRate
I have no clue what this is.
32 43 96 00 00 300
36 43 34 00 00 180
40 43 20 00 00 160
These might be the turn modes for all ships, but not shuttles/fighters, PF's (AA) or FRD and DEFSATS (F) or bases (G) which might be handled elsewhere.
44 42 F0 00 00 120 Either Turn Mode A or E?
48 42 B4 00 00 90 Either Turn Mode B or D?
52 42 70 00 00 60 Turn Mode C?
56 42 20 00 00 40 Either Turn Mode D or B?
60 42 0C 00 00 35 Either Turn Mode E or A?
These could possibly be charge rate by turn since nothing takes more than three turns to charge.
64 41 F0 00 00 30 3 Turns?
68 41 C8 00 00 25 2.5 Turns? (I think the ESG takes 2.5 turns, but I haven't used one in awhile)
72 41 A0 00 00 20 2 Turns?
76 41 20 00 00 10 1 Turn?
-
AFAIK acceleration can be set to any positive integer. Here's the one's that I pulled from OP+: 2,3,4,5,6,7,8,10,15,18,25. I don't see a pattern match here.
-
You know it could be as simple as game speed 1-11 and pause. There are 12 entries anyway.
-
Your Chart for Heavy Disruptors
Range: 0 1 2 3-4 5-15 16-22 23-30 31-40
To Hit: 100%83% 83% 67% 67% 67% 50% 33%
Damage: 10 10 8 8 6 4 4 4
What I gather from the exe code
Range: 0-1 1-2 2-3 3-5 (5-9)(9-16) 16-23 23-31 31-41
Damage: 10 10 8 8 6 6 4 4 4
Damage: 10 10 8 8 6 6 4 4 4
Damage: 10 10 8 8 6 6 4 4 0
Damage: 10 10 8 8 6 6 4 0 0
Damage: 10 10 8 0 0 0 0 0 0
Damage: 10 0 0 0 0 0 0 0 0
then it continues with overloaded values. what do you think corb? any significant difference
But that chart has six entries to simulate a D6 being rolled, then you calculate damage (which can be none) based on range. To Hit/Damage weapons roll a d6/2d6 to determine if the weapon hit or not, then damage is assigned based on several factors (like Phots not degrading over distance and Dizzys/Hellbores doing so).
Unless they used a common function to handle the roll for all weapons. Then this chart would be needed for reading out the damage in the same format as all direct fire weapons. If so then there should be a chart for all such weapons even the attack probe.
-
Let's assume Nem is right and see what we have here.
The whole range numbers probably mean to .99, where 0-1 really means 0.00-0.99 etc. So at range 0 you have a 100% chance to hit, which means 10 points of damage because you are eligible to light up all the selections in column one of the coded chart.
From ranges 1-3 you have an 83% chance to hit so you are eligible to light up five out of six selections in columns two and three, with their respective damages based on range.
From ranges 3-23 you have a 67% chance to hit so you are eligible to light up four out of six selections in columns four, five, six and seven, with their respective damages based on range.
From range 23-31 you have a 50% chance to hit so you are eligible to light up three out of six selections in column eight, with its respective damage based on range.
From range 31-41 you have a 33% chance to hit so you are eligible to light up two out of six selections in column nine, with its respective damage based on range.
I'm beginning to think that the extra bracket at the OL juncture has something to do with interacting with the OL cuttoff for range.
Heavy Disruptor:
Arming Rate: 1 Turn
NOTE: Heavy Disruptors are able to occasionally "leak" a small amount of damage through shields. O/L Heavy Disruptors fired at range 0 will do a feedback damage of 4 to the shield facing your target.
| Range:_____ | ___0___ | ___1___ | ___2____ | ___3-4___ | ___5-15___ | ___16-22___ | ___23-30___ | ___31-40___ |
| Normal |
| To Hit: | 100% | 83% | 83% | 67% | 67% | 67% | 50% | 33% |
| Damage: | 10 | 10 | 8 | 8 | 6 | 4 | 4 | 4 |
|
|
|
|
|
| Range:_____ | ___0___ | ___1___ | __2-4___ | ___5-8___ |
| Overload |
| To Hit: | 100% | 83% | 83% | 83% |
| Damage: | 20 | 20 | 16 | 12 |
Sample of exe code:
| Range: | 0-1 | 1-2 | 2-3 | 3-5 | (5-9) | (9-16) | 16-23 | 23-31 | 31-41 |
| Damage: | 10 | 10 | 8 | 8 | 6 | 6 | 4 | 4 | 4 |
| Damage: | 10 | 10 | 8 | 8 | 6 | 6 | 4 | 4 | 4 |
| Damage: | 10 | 10 | 8 | 8 | 6 | 6 | 4 | 4 | 0 |
| Damage: | 10 | 10 | 8 | 8 | 6 | 6 | 4 | 0 | 0 |
| Damage: | 10 | 10 | 8 | 0 | 0 | 0 | 0 | 0 | 0 |
| Damage: | 10 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
-
You know it could be as simple as game speed 1-11 and pause. There are 12 entries anyway.
I will have to experiment and evaluate what I see. How long does one turn take at speed 7. But you may be right.
Default for game speed 7 is 35 seconds per turn. Speed 8 is 30 seconds per turn.
-
It'd be nice to check the seeking weapon reduced damage due to ECM chart too. All the games should be the same in that regard, unless something is broken/unfinished in EAW.
In EAW, single-player mode uses a chance-of-reduced-damage chart, but multiplayer doesn't. When I find the bytes in Community Edition, I'll try to enable it for multiplayer...
As a refresher: Roll a d6. Add the Attack Shift to it. Consult chart.
Total | Damage Multiplier
1-6 | 1.00
7-8 | 0.50
9-10 | 0.25
-
You know it could be as simple as game speed 1-11 and pause. There are 12 entries anyway.
I will have to experiment and evaluate what I see. How long does one turn take at speed 7. But you may be right.
Default for game speed 7 is 35 seconds per turn. Speed 8 is 30 seconds per turn.
Let's assume Tar is right and see what we have here.
32 43 96 00 00 300 Pause, it might indicate Speed 0, but I wouldn't know why.
36 43 34 00 00 180 Speed 1
40 43 20 00 00 160 Speed 2
44 42 F0 00 00 120 Speed 3
48 42 B4 00 00 90 Speed 4
52 42 70 00 00 60 Speed 5
56 42 20 00 00 40 Speed 6
60 42 0C 00 00 35 Speed 7
64 41 F0 00 00 30 Speed 8
68 41 C8 00 00 25 Speed 9
72 41 A0 00 00 20 Speed 10
76 41 20 00 00 10 Speed 11
-
I believe the AI's great reluctance to use electronic warfare (EW) can be improved in Community Edition. Dave Ferrell, 12 years ago, wrote that the game's internals multiply the external speed and range by ten. I had forgotten that nugget of info. Something may be off by a magnitude of ten in the EW department.
I suspect that the AI uses 30.0 (instead of 3.0) to determine the range at which to abandon ECCM and ECM. Most weapons are probably going to hit at ranges less than 3, so the AI seems to invest in shield reinforcement instead (which is guaranteed to absorb damage). But the AI thinks you're at range 1.5 when you're really at range 15, and it has therefore given up the EW game. Pull away to range 35, and it will start to generate ECM.
However, at ranges greater than 30, and with abundant energy, the AI is excellent at the ECM/ECCM game. First, it will negate your ECM, point-for-point. Second, any remaining EW power will go towards ECM. Third, it checks to see if it is wasting energy. If you put up 6 ECCM, it will never maintain 6 ECM, so it stops using ECM. If it can't quite gain a +2 shift, it reduces its ECM to be exactly 1 more than your ECCM. Very efficient. Well programmed.
I could, of course, be completely wrong.
I'll look for the low-hanging fruit in the binary...
-
Adam, 31 isn't the top speed for all ships. Battleships can only reach 30.5.
Warp energy is somewhere restricted to whatever amount is needed to reach a speed of 30.
Impulse engines can add 0.5 to a Battleship's speed. Smaller vessels can gain 1 when they are at maximum tactical warp speed. (In fact, a frigate lacking warp engines can move at a speed of 3 instead of 1.)
I found the location which controls the capacity of the speed control. Search for 31.0f. Since it is a gauge, it doesn't get multiplied by ten.
-
Some values such as max overload range may have been programmed as constants in one location. I don't know how this would translate to the binary but I'm sure it has some type of effect (not a programmer but know some theory).
I figured it out tonight. There is no constant for [some] overloaded weapons! The programmers defined the maximum overload range as a specific bracket for each weapon, not a specific distance. I haven't yet located the bytes that determine the displacement in the array of floats. (Some OL weapons are indeed limited in range by the constant 90.0f)
I am able to fire Overloaded Disruptors from range 11.99 by modifying the existing 5-8 bracket to encompass 5-11. Reducing the maximum overload range is also possible. Lots of moddability here.
In other news, the rate-of-fire for Phasers has been located. It is defined as turns per shot, rather than shots per turn. The icons that show the state of charge aren't proportional.
-
You guys are awesome. I wish I had time to try this out. It's amazing how fast you all are unraveling all the threads to this game.
-
Wow! That was quick in breaking the 31 barrier. Reverse? That would be intriguing. Blackholes somewhat work in that manner...
Here's the Community Edition section that determines Phaser cycles. 4-byte floats of 00 00 80 3F (1.0f). I set Phaser-2's to 0.5 and they could fire every 15 seconds. Its icon's state of charge would jump from 50% to 100% on the final split second.
Like you wrote, the charge cost for Phasers needs to be found so that low-power, low-yield, rapid-fire weapons can be created. The Ph-G exists, but it obeys Shift-Z, so it isn't quite the same.
-
I noticed that my ship can't turn at speeds greater than 31.99 because that turn mode is currently undefined. Actually, I like this consequence. If you want to sail really fast, you lose your rudder. Feels like emergency warp.
-
Id like to also find the shield regeneration which if memory serves me is associated with the labs. Not sure but hopefully I can get that too.
That matches my memory too.
-
Id like to also find the shield regeneration which if memory serves me is associated with the labs. Not sure but hopefully I can get that too.
That matches my memory too.
Each Shield arc regenerates 0.3 + (0.1 * Labs) per turn. As a ship's labs get destroyed, the rate decreases until it reaches the minimum of 0.3 per turn. This formula is for EAW, so OP could be different. (The number 0.1f is in the binary file as "CD CC CC 3D".)
So the Enterprise, with her 8 labs, regenerates up to 6.6 shield "boxes" per turn, 1.1 per arc. Not too shabby for the 2 points of power required to raise shields. A ship like the War Eagle, with her 2 labs, only regenerates up to 3 shield boxes per turn, 0.5 per arc.
-
If you increase the 0.3f base then that levels the playing field. If you increase the 0.1f lab multiple, that favors ships with many labs.
So, if you double the lab multiple...
0.3 + (0.2 * Labs) = 1.9 per arc for the Enterprise which has 8 Labs.
If you double the base regeneration rate...
0.6 + (0.1 * Labs) = 1.4 per arc.
If you double both...
0.6 + (0.2 * Labs) = 2.2 per arc.
The last one could make the ship a really tough nut to crack using any long range sniping. Only crunch weapons could overcome that sort of regeneration. The Enterprise can present 3 different shields and still keep the enemy in its crosshairs, spreading damage across all three facings.
SFC1 had a maximum regeneration rate of 2 points per arc per turn. Ships with 4 or more Labs got a +1 bonus. All ships had a base rate of 1.
-
You are welcome, Adam.
I unexpectedly found the Maneuverability constants while looking for the shield regeneration rate.
I added Warp Tacs and Sub-light Tacs by modifying the speed 5 entry. (Ships that devote the Warp energy required to move at a speed of 4 plus 1 Impulse engine can instead make five 60 degree pivots instead of moving linearly.)
Look for this sequence in the binary: CD CC 4C 3E CD CC 4C 3E 9A 99 99 3E CD CC CC 3E
Those are the first four rotational constants ( 0.2f, 0.2f, 0.3f, 0.4f ), for non-inclusive speeds 1, 2, 3 and 4. Again, this means 0.99, 1.99, 2.99, and 3.99. The next 29 floats are for speeds 5 to 33.
Each "turn class" has a currently unknown value (AA, A, B, C, D, E) that is multiplied by these rotational constants. Thus a frigate turns a little quicker than a destroyer. And a destroyer turns a little faster than a cruiser. The difference is about 10% from class to class.
Orion Pirates may be different because of Plasma-X. It may have an entry for speeds up to 40.
-
shipstacking=1 is a clue in the sfc.ini under [3D].
-
Oh yes b4 I forget. The only reason I think reverse is possible is bc when I changed all the 310.0f values, my ship refused to go beyond 31.0 bc the speedometer was locked. But once the speedometer was unlocked it worked. So my thinking is if we can get the speed start (0) to shift to te right in the speedometer, just maybe when I press A beyond the 0, it will reverse. Hope that makes sense. Lol
My only concern is that the ships start each mission flying in reverse towards the edge of the sector. However setting the speedometer to a negative value shouldn't be an issue.
-
Also, wanted to ask you, what we are doing with the exe; can it be done with missions scripts?
Yes. Objects (asteroids, planets, blackholes) can be added to the maps. Ships' starting positions can be changed. I don't know if more complicated stuff can be modified. The Fleet Mission Script Editor (FMSE) could do this for EAW, but not for OP or CE.
-
Yes, there is a way. You need Microsoft's Visual C++ 6.0 compiler to be associated with Taldren's Orion Pirates programming interface (API). A steep learning curve awaits you (assuming you can obtain the old & expensive C++ 6.0 software.)
With Community Edition, making mission scripts should be at no cost because you use Visual Studio Express 2012 (maybe 2013 too?), a free download. There is an API for Community Edition...somewhere. It isn't currently available on Dynaverse.
Hex Editing of the mission scripts in OP might do the trick. Turning a 00 to a 01 to enable something is simple. But finding that specific byte is not a piece of cake.
-
You are welcome, Adam.
Look for this sequence in the binary: CD CC 4C 3E CD CC 4C 3E 9A 99 99 3E CD CC CC 3E
Those are the first four rotational constants ( 0.2f, 0.2f, 0.3f, 0.4f ), for non-inclusive speeds 1, 2, 3 and 4. Again, this means 0.99, 1.99, 2.99, and 3.99.
Read it like 4x, my hangover may be interfering with my absorption of this data. :huh:
Change the CD CC CC 3E (0.4f) to 00 00 20 40 (2.5f) and you'lll definitely understand what's going on in the game. Accelerate slowly while turning. You'll notice that you can essentially do a continuous HET at a speed of 3.00 to 3.99. But when you reach a speed of 4, regular maneuverability returns.
-
Fixed the Hydran UI for Plasma Torpedoes tonight.
Had to Hex Edit sprites.q3 and add new entries to aaStrings.txt and quicktips.txt.
aaStrings:
|HH_a6_plas_nor|~F:hydran7~normal
|HH_a6_plas_envx|~F:hydran7~enveloping
quicktips:
|A6_PLASMA_OFFLINExx|Turn OFF these Plasma Torpedoes
|A6_PLASMA_NORMALxxxx|Turn ON these Plasma Torpedoes
|A6_PLASMA_ENVELO|Arm in Hellbore Mode
|A6_PLASMA_DEFENSI|Arm in Shotgun Mode
The Hex Edit required renaming the internal identifiers to match the UI data.
HH_a6_plas_***
1st occurence: def -> off
2nd: env -> nor
3rd: norm -> envx
4th: off -> def
...and then renaming the internal quicktips to match the byte spacing (and thus the use of x's as fillers and the truncated words).
Very confusing, but worth the effort. Gorn vessels serving in the Hydran fleet have working controls. They are still in an unconventional order, but they are accurate and so are the tips.
(A much easier approach is to ignore the erroneous quicktips and simply edit aaStrings.txt, inverting the order of the descriptions.)
-
Wow.
This is awesome, if not 10 years too late!!! :)
-
while searching for the damn phaser colors lol I ran into this tid bit
48 40 80 00 00 4
52 40 00 00 00 2
56 3F C0 00 00 1.5
60 3F 80 00 00 1
64 3F 40 00 00 0.75
68 3F 00 00 00 0.5
it must mean something, at first glance I thought move cost, but its missing, 0.33, 0.25 etc etc
Whatcha think Tar
Shield or life support costs?
-
My 2 cents for SFC3 hex editing... In SFC3.exe I found the location of the shuttle hardcoding, I could change the names listed there, so for example I could make the Klingons use the ship called "Ferengi Shuttle" (so for mods like DW that swap the Borg for the Dominion having a shuttle called "Dominion Shuttle" is possible), but it won't let you add more shuttles, so you can't add shuttles for the Ferengi and Species 8472, at least when I tried it the shuttles of all the races disappear. Oh, very important: SFC3.exe uses a checksum, when you change the number of characters when editing you have to compensate by adding or removing null characters ("00" in hex format, "." in text format). I couldn't find stuff like weapon hit probabilities. In Sprites.q3 there are a lot of references to .bmp files that are not in the textures folder, so they must be the hardcoded bitmaps. Unfortunately they seem to be encoded: I can't find any headers which would allow me to isolate the images.
It really sucks that even after 13 years no tools have been released. Whose bright idea was it in the first place to hard code shuttles, the race icons and half of the Romulan disruptor texture?
-
while searching for the damn phaser colors lol I ran into this tid
4
2
1.5
1
0.75
0.5
Any ideas, Tar?
Hmm, too general to fit any SFB system. I'd just be guessing. Any clues nearby? Set the 4.0f to 40.0f and see what changes in the game.
I fixed the buttons on the Lyran's Fusion panel. It is nice that we can edit sprites.q3 without crashing the game.
-
while searching for the damn phaser colors lol I ran into this tid bit
48 40 80 00 00 4
52 40 00 00 00 2
56 3F C0 00 00 1.5
60 3F 80 00 00 1
64 3F 40 00 00 0.75
68 3F 00 00 00 0.5
it must mean something, at first glance I thought move cost, but its missing, 0.33, 0.25 etc etc
Whatcha think Tar
Shield or life support costs?
I found the shield activation costs yesterday as "06 04 02 01". That's for size class 1, 2, 3, and 4 respectively. I'm trying to fix the misreporting (i.e doubling) of them in "Other" energy. I'll need to find the instruction that adds a value to itself (or multiplies it by two). The good news is that a ship doesn't actually pay double. It's an annoying bug from eons ago that nobody fixed.
Life Support costs would be 2?, 1.5, 1, 0.5 for the four largest size classes. PF's (size 5) don't pay life support, IIRC.
-
I know nothing about the compressed data in sprites. I can, however, see references to entries in aaStrings.txt and quicktips.txt.
I think the Starfleet.exe handles combat colors and textures (like disruptor-burst.bmp and red-plasma.bmp) all on its own.
Sprites.q3 sends requests to the aaStrings and quicktips assets. I can rearrange them as long as I maintain the byte lengths. Frankly, I'm running out of interest with sprites and UI's, now that I've fixed the Lyran Fusions and the Hydran Plasma. I'm looking at the references for Romulan Photons, so that I can perhaps fix the Overload and Proximity buttons.
-
I have repaired the Romulan Photons.
The sprites file had incorrectly inserted PPDStatus (instead of PhotonStatus) within the Romulan Photon section. No wonder they didn't work properly! I could only overwite the bad data as "PhotonSta" so I therefore shortened the one reference found in Starfleet2CE to "PhotonSta" as well. Fired up the game and here's a screen shot...
-
There are three parts to the Romulan Photon UI Fix.
Part1: Open the sprites.q3 and find the four PPDStatus references within the Romulan Photon section. (You've already done that, Adam.)
Manually overwrite the word "PPDStatus" with "PhotonSta". (Don't do a find-and-replace. There are others that we don't want to modify yet.)
-
We know that impulse is "broken" since we don't get the obligatory one unit of movement for one point of impulse, regardless of size and number of impulse engines generating power since they tied all propulsion into one function; might this be the impulse size class conversion rates?
48 40 80 00 00 4
52 40 00 00 00 2
56 3F C0 00 00 1.5
60 3F 80 00 00 1
64 3F 40 00 00 0.75
68 3F 00 00 00 0.5
-
Part 2: We need to replace all occurences of "Starfleet.PhotonStatus" with "Starfleet.PhotonSta" 00 00 00. Those zero bytes keep everything in order. They are essential. They are not periods. They are nulls. 22 bytes in total.
53 74 61 72 66 6C 65 65 74 2E 50 68 6F 74 6F 6E 53 74 61 00 00 00
I used the find-and-replace tool to do this 23 times in the sprites file, confirming each modification so something unexpected didn't get overwritten. (No surprises here.)
-
Part 3: Romulan Photon Fix.
Now we need to open Starfleet2CE/OP.exe and find the function named PhotonStatus. There is only one. There are similar names such as PhotonStatus1, PhotonStatus2, etc. But we don't want to modify them.
Rename "PhotonStatus" to "PhotonSta" 00 00 00. Again, remember to insert null bytes for each missing letter. Don't use periods.
50 68 6F 74 6F 6E 53 74 61 00 00 00
These three parts together should enable the Overload and Proximity modes for Photons while using the Romulan UI.
-
We know that impulse is "broken" since we don't get the obligatory one unit of movement for one point of impulse, regardless of size and number of impulse engines generating power since they tied all propulsion into one function; might this be the impulse size class conversion rates?
48 40 80 00 00 4
52 40 00 00 00 2
56 3F C0 00 00 1.5
60 3F 80 00 00 1
64 3F 40 00 00 0.75
68 3F 00 00 00 0.5
Seems to fit.
What about a ship like the old Federation CL? We would need a 1.33 in there, right? 4 hexes for 3 energy, or, 1 Impulse Engine can move it 4/3 of a hex, 1.33. Maybe that's nearby.
I'll check it out. If it's only found in OP, then it might be an Orion Engine Damage thing. Thanks, Corbomite.
-
Can these fixes be applied to CE? Now that we have more eyes combing over the code maybe we can fix the many bugs that plagued this game over the years. Or get the OP code into CE even. Can we put these programs up for download once these guys are done?
-
It seems to me to be two different projects. It would seem simpler to try to correct the stuff in OP rather than trying to convert CE into OP, that is, without having someone go directly into the source code, which doesn't seem like it's going to happen. Mapping the entire structure the way you guys are having to go about it will take much time.
-
Just discovered that the SFC3 romulan disruptor isn't entirely hardcoded: inside SFC3.exe there's a reference to fx_mauler_beam.bmp in the texture folder, this doesn't exist but you can create it. If you copy the phaser1.bmp file and rename the copy to fx_mauler_beam.bmp you can manipulate the thickness of the beam, if you apply a color to the texture you can somewhat manipulate the color of the beam.
-
We know that impulse is "broken" since we don't get the obligatory one unit of movement for one point of impulse, regardless of size and number of impulse engines generating power since they tied all propulsion into one function; might this be the impulse size class conversion rates?
48 40 80 00 00 4
52 40 00 00 00 2
56 3F C0 00 00 1.5
60 3F 80 00 00 1
64 3F 40 00 00 0.75
68 3F 00 00 00 0.5
Seems to fit.
What about a ship like the old Federation CL? We would need a 1.33 in there, right? 4 hexes for 3 energy, or, 1 Impulse Engine can move it 4/3 of a hex, 1.33. Maybe that's nearby.
I'll check it out. If it's only found in OP, then it might be an Orion Engine Damage thing. Thanks, Corbomite.
The more I think about it the more I don't think I'm right. If all propulsion is tied to the changeable speed/size conversion formula used in the shiplist, then static conversions for impluse are irrelevant and the amount of movement you get from one point of impulse will vary just like warp. Impulse is just limited to one point allowed for movement. It very well may be something tied to pirate ships though. Seeing it/not seeing it it CE will be a clue.
-
Can these fixes be applied to CE? Now that we have more eyes combing over the code maybe we can fix the many bugs that plagued this game over the years. Or get the OP code into CE even. Can we put these programs up for download once these guys are done?
Putting OP's features into CE is going to be difficult to impossible. I can't make more room in CE for OP's extra features -- not even a single byte (unless there is dead wood in the binary). Players can, however, add an approximation of one of OP's weapons to CE. But they have to sacrifice an existing system. For instance, I can imagine an alternative role for the Disruptor4. It gains strength the further away it's fired from its target (harvesting energy from the traces of matter along the way, E=MC^2). It has excellent performance at long range, but up close, it does no damage. The Disruptor3 is still there for regular duty. At the moment, all Disruptors inherit the same energy costs and rates-of-fire. That might be changeable.
As far as distribution of modified executables....?
I guess it would be similar to getting Firesoul's OP+ or Bonk's SFB_04 or Chris Jones' TNG. Download and use at your own risk. And then you're free to modify them as you see fit. This community has maintained high standards for more than 15 years. Nobody worries that fan-made modifications to Starfleet Command's assets are malware. Adam and I want these games to thrive, nothing more.
-
Interesting.
A default Plasma-R costs 3 points to charge and to hold. It requires three turns to charge fully.
If it is modified to require just one turn to arm. Do the arming and holding costs triple? Both go from 3 to 9?
Or perhaps you simply changed the arming cost? If the launcher sees 9 energy flowing in, it obeys, and finishes the torpedo in one turn. You may have fast-loaded that Plasma-R via a higher energy input rather than through a modification to a timer.
-
Adam, you changed one number and the power of the ship increased by 24?
What was the original value? What is the new value?
How many Warp, APR, and Impulse does that ship have?
-
Just discovered that the SFC3 romulan disruptor isn't entirely hardcoded: inside SFC3.exe there's a reference to fx_mauler_beam.bmp in the texture folder, this doesn't exist but you can create it. If you copy the phaser1.bmp file and rename the copy to fx_mauler_beam.bmp you can manipulate the thickness of the beam, if you apply a color to the texture you can somewhat manipulate the color of the beam.
Nice discovery, Jan.
-
Thanks for that example. You increased the Plasma-R charge cost from 3 to 9. You may also have affected any other system that happens to use that constant. What else might use a 3? I can't think of any systems...the old Hellbore, but the new Hellbore uses 2.5.
-
I'm sure you'll find the Plasma cycle. It may be one of the 0.33 or 0.33333333 floats. We know phasers use periods. So I think it is likely that Plasma and Hellbores, and Photons all use the same convention. Bigger numbers = shorter cycles. What's the longest weapon cycle in the game? Nothing takes four turns.
Plasma = 3
Photon, Hellbore, Phas-A/B, Plas-F in a larger launcher, PPD = 2
Fusion is weird, 1 to charge, but 1 turn to cool off.
ESG = 1.5
Disruptor and Phaser = 1
So the inverse of those are: 0.33, 0.50, ??, 0.67, 1.00.
Maybe that sequence will show up someday, or it could be scattered.
(Found the Wild Weasel launch speed tonight. They don't have to be launched at top speed. I recommend 3.5 so they don't detonate mines. Suicide Shuttles also use this speed.)
-
Corb, can you please tell me the cost to charge and hold plasmas, all the OP ones, my book says the R cost 9 for 3 turns and holding is 5. Is the book accurate.
All costs are per turn over three turns except fast F-Torps which are over two turns. Repeating decimals are rounded since the energy display shows two values for energy used, one rounded, one not. I'll leave it to you guys to discover just exactly which is reading correctly based on the actual usage cutoff:
| | ___Normal Charge___ | ___Normal Hold___ | ___Overload Charge___ | ___Overload Hold___ |
| Type: |
|
|
| X | 3 | 5 | NA | NA |
|
|
| E | 2.5 | 1 | NA | NA |
|
|
| R | 3 | 3 | 4.67 | 5 |
|
|
| S | 2.67 | 2 | 4 | 4 |
|
|
| G | 2.33 | 1 | 3.33 | 2.5 |
|
|
| F | 1.67 | 0 | NA | NA |
|
|
| Fast F | 2.5 | 1 | NA | NA |
-
I'd like to find the numbers that control the firing rate so that a modified Plasma-"R" which has a charge cost of 9 doesn't charge in one turn. It would take 27 total energy to arm. So somewhere the conversion rate (if there is one) would need to be divided by 3 in this case. Or perhaps the total energy is stored somewhere...
Plasma, Total energy
F = 5
G = 7
S = 8
R = 9
EPT-G = 10
EPT-S = 12
EPT-R = 14
I'll look for these.
-
I found the Plasma arming rate in an indirect manner. There are two numbers that are involved. The first is the per turn charge cost (3.0f for a Plas-R) that you know about.
The second is the total energy required to complete the torpedo(14.0 for an EPT/Defensive Plas-R, the biggest torp).
I found the second component by searching for 14.0f. There aren't many of those.
I also found 12.0f adjacent to it, probably the EPT/Def Plas-S total energy.
So the little plasma icon compares the current energy deposited, let's say 3.0f, with the total energy needed, let's say 9.0f for a regular Plas-R. It divides 3/9 to determine the fraction complete. Thus the icon will show about 1/3rd in full color, the rest will be pale.
Tested in game an EPT-R that had a total energy requirement of 24. It took about 5 turns to finish. The icon was accurate.
-
Yes, EPT means Enveloping Plasma Torpedo. Defensive means Shotgun.
If you increase the total energy requirement, then the torpedo is going to take longer to complete.
For example, the Plas-R has a total energy requirement of 9.0f. I get that number by multiplying the charging cost (3.0f) by the default amount of turns (3) needed to arm the torpedo. I don't know the location of that 3. I know it from playing the game, just as I know Photons take 2 turns to finish charging.
The charging icon looks at the amount of energy accumulated so far. It compares it to the total requirement. If it has 4.5 energy in the bank, then you still need to contribute another 4.5 energy. It will show as halfway there, 50%.
If I modify Plas-R to require a total investment of 18.0f energy, then it will take 6 turns to complete. You follow? Every turn it puts in a default of 3.0f. After 6 turns, it will have 18.0f energy.
So in this example, the charging cost hasn't been modified. The time needed to charge the torpedo has tripled doubled. The amount of energy invested has also tripled doubled. This is a bad situation for the War Eagle! The Plas-R's damage hasn't increased at all.
---
New situation. If I lower the charge cost for the Plas-R from 3.0f to 1.0f, the War Eagle can charge a default torpedo (which needs the regular 9.0f of energy) at nearly top speed while cloaked. It will, however, take 9 turns to do so! (1.0f per turn * 9 turns = 9 energy invested). That's the trade off -- less energy per turn means more turns to finish the job. The icon will be at 11% after one turn, 22% after 2 turns, etc.
Clear as mud?
I know it's confusing.
[Edited for a mistake.]
-
OK, I have a fun one for you guys to try and find...
OP limits the shiplist to 16 (8 empire + 8 pirate). Any chance that's coded somewhere in the editable stuff? Also, I seem to remember there being an absolute cap on the number of ships that can be on any given empire's shiplist...
I bring this up for those Tholian and Andromedan lovers out there. We may not be able to get webs and PA panels, but I'm seeing some interesting options for Andros (giving them a buttload of labs to increase their shield regen rate, as a poor man's simulation of PA panels bleeding energy off, also giving Andros some sort of movement advantage in place of the Displacement Device).
Since OP has the 'X' weapons, some of those could be repurposed as other weapons that function in a similar fashion to the existing weapons, i.e. replacing the 'cheese weapons' with other unique weapons. While I don't necessarily see someone wanting to introduce Seltorians, etc, well this kinda opens up the door for exactly something along those lines...
-
EoJ,
I'm guessing that certain limits in the shiplist may be imposed by the type of data that stores it. Some variables can only accept 256 values, they are 8-bit. I don't believe I can change that variable to be 32-bit, able to hold billions of values. (Firesoul might know.) Even if I tweaked that number, the program wouldn't be able to process a billion or a thousand Frigates. I think any FF after the first 256 would be ignored.
Adding an extra empire to the game is close to impossible. There is no interface to access the Seltorians or Jindarians. You'd have to remove an existing faction. Years ago, I replaced every reference to Mirak with Kzinti. That doesn't require any .exe editing.
Maybe the .exe could look for Andromedans in the shiplist so that they aren't mingled with a host empire. That would be neat. But I can't envision a way to scroll though more than 8 empires, well...there is that "none" slot...which makes a one-time appearance. Hmm.
I'm beginning to see more shared constants than I had hoped for. You can't change the Overload cost for Photons without it affecting the cost of OL Disruptors and standard PPDs. This also affects the rate-of-charge of the standard Photon and UL PPD.
Even so, there's a boatload of mods to be created.
Accuracy and Damage Tables are better isolated.
-
Could one of you email me the SFC2 exe and sprites.q3 files (zip or rar them so they don't get mistaken for malware)? I'd like to compare parts of them to the corresponding parts in the exe and sprite files from SFC3, especially considering there are more stock shuttles in SFC2 than SFC3, but also in general a comparison between these versions might be useful to spot certain patterns. If any of you like to have the SFC3 files I could email them to you in return.
-
Gotta got to work, but anyways, if memory services me, Corb, Need your brain, these numbers multiplied by 100 represent the HB percentages on the chart
64 3C E3 BC D3 0.0278
68 3D AA CD 9F 0.0834
72 3E 2A B3 68 0.1667
76 3E 8E 3B CD 0.2778
80 3E D5 59 B4 0.4167
84 3F 15 59 B4 0.5834
88 3F 38 E8 A7 0.7223
92 3F 55 59 B4 0.8334
96 3F 6A AC DA 0.9167
100 3F 78 E8 A7 0.9723
Corb, last column, 97,92,83,72,58,42,28
Am I right
Mostly a match, but lines 64, 68 and 72 seem to be part of a different data block.
Hellbore:
Range:___ ___0-1_______2___ ____3-4_______5-8_______9-15_______16-22____ ___23-40
To Hit:______97%___ __92%___ __83%______72%______58%___ ____42%________28%
Normal
Damage:__ __ 20_______17_______ 15_______ 13_______ 10__________8_______ ___4__
Overload
Damage:_____30_______25________22___ ____19____ ___NA_________NA_____ ____NA_
-
Jan, you may be better off downloading a working copy of EAW, CE, or OP. Then you can manipulate data and observe the results.
There are backups of the EAW and OP exe on this website under "Downloads" on the root page.
-
If so, then you should find a corresponding range/damage generator that has entries in those fields. It may well be so that the HB's can go farther than 40, but are just limited from firing by another mechanism.
-
I think the 2d6 values go below 28% because of ECM attack shifts. The game needs to know what to do with a range 40 Hellbore fired into an attack shift. It can't subtract 16.6% for each shift because it is based on 2d6, not 1d6.
-
Except those numbers only have allowances for a shift of 3 when 4 is the total shift OP can have (19pts of ECM). Any shift at a range of 23-40 should automatically miss anyway. It may just be that you must complete a random number generator (for the computer) even if you won't be accessing all the data points in the spread.
-
Except those numbers only have allowances for a shift of 3 when 4 is the total shift OP can have (19pts of ECM). Any shift at a range of 23-40 should automatically miss anyway. It may just be that you must complete a random number generator (for the computer) even if you won't be accessing all the data points in the spread.
A Hellbore can hit against a +2 shift at range 40. It isn't an automatic miss.
-
Except those numbers only have allowances for a shift of 3 when 4 is the total shift OP can have (19pts of ECM). Any shift at a range of 23-40 should automatically miss anyway. It may just be that you must complete a random number generator (for the computer) even if you won't be accessing all the data points in the spread.
A Hellbore can hit against a +2 shift at range 40. It isn't an automatic miss.
How exactly, when a shift against a To Hit/Damage weapon shifts brackets to the right when adjusting for ECM (at least in SFB)? Jamming past 23-40 should trick the scanners into thinking the target is too far away to hit. If the game does it differently then there is no reason to assume any SFB rules are really enforced.
-
Hellbores tested in game. I hit with 10 out of 104 shots against a +2 shift at range 38. That's about 9.6%.
I don't remember any rule to "shift to the right" in SFB. If a Hellbore needed a 5 to hit, you needed to roll a total of 2, 3, or 4 on your 2d6 against a +1 shift.
I never shifted to the right for Disruptors. What's the point of attaining an EW shift if a Range 5-8 Disruptor gets shifted to 9-15? There is no penalty in that case. They both hit at 67%.
-
Your right, but it is effectively the same thing. Shooting at range 0-1 with a 2 shift is essentially the same as firing at range 3-4. I forgot about the last bracket since no one but the AI fires that far away anyway. Those numbers would indicate a tollerance up to a 3 shift, which could still be achieved on a roll of 2 at range 23-40, but a 4 shift should be an automatic miss.
-
Your right, but it is effectively the same thing. Shooting at range 0-1 with a 2 shift is essentially the same as firing at range 3-4. I forgot about the last bracket since no one but the AI fires that far away anyway. Those numbers would indicate a tollerance up to a 3 shift, which could still be achieved on a roll of 2 at range 23-40, but a 4 shift should be an automatic miss.
Think about Range-13 Proximity Photons...
If a +1 shift is supposed to put them off the chart, they become useless for players, not just the AI. I have intentionally fired Range-13+ Proximities into a +1 shift on occasion. I don't think they should automatically miss.
A more serious issue with SFC is that overloaded weapons will always miss if the effective range is greater than 8.99. I hope I can adjust that feature someday. Damage for direct-fire weapons could use true range. In the meantime, the z-key ought to do nothing if your maximum damage is zero, for, let's say, an OL Photon fired at a cloaked target at a range of 2.2.
2.2 * 2 + 5 = 9.4
At 9.4, the OL Photon chart is fully loaded with zeroes. There aren't any 16's in there.
Edit: I placed 7's in the first three rows of the Overloaded Photon chart for Range 9-12. Naturally, I could not fire them at range 9-12 in ordinary combat. All seems well. However, when my effective range was 9-12, those 7's were used. So my attacks on a cloaked vessel at range 2.2 were 50% accurate and did 7 damage. (My choice of 7 was arbitrary for testing purposes.)
This probably applies if your scanners are sufficiently damaged. I need to make scanner damage visible to the player as an on-screen number. So if your scanners show "0" (in green), everything's okay. If they show "1" (in red), you need to get to range 14.9 instead of 15.9 for the Disruptor's sweet bracket. If they show "3", you'd need to get to range 12.9.
-
Yes. You do so by changing the default OL bracket. Let's look at Photon torpedoes.
Normally they are like this:
Bracket | On-screen range
1st = 0 - 1.99
2nd = 2 - 2.99
3rd = 3 - 4.99
4th = 5 - 8.99
5th = 9 - 12.99
6th = 13 - 30.99
7th = 31 - 55.99
The 4th bracket defines the maximum Overload range.
Let's say I want to reduce the Overload range to 6.99. I can do that by changing the 4th bracket from 90.0f to 70.0f. (70.0f results in 6.99.)
Be sure that each bracket has a higher limit than the preceding one. I don't know what would occur if you gave the 4th bracket a limit of 27.99, while the 5th had a limit of 12.99.
-
Locating the mysterious range limit on Fusion Beams is my current task. Phaser-3's may have one too.
I found the holding costs for Hellbores. They are a different data type. They are double-precision floating point integers, also known as "doubles". 8-bytes, unlike 4-bytes for a float. The programmers may have used doubles when Orion Pirates was written. If your search for floats comes up dry, try searching for doubles.
4012000000000000 represents 4.5 very precisely. The holding cost for OL Hellbores is stored this way: 00 00 00 00 00 00 00 12 40
I've looked for the 8-byte representation of 250, and found one, but it had no effect on Fusion Beams. I've looked for the 4-byte integer representation of 250 (FA 00 00 00). Found a few, but none unlocked the limit.
The search goes on...
-
You can arm a normal Photon in 0.5 turns if you change its total energy from 4.0f to 2.0f. But this might also change the charge cost of an OL Photon from 4.0f to 2.0f, if it is a shared constant.
I'll look into OP's code...
-
Adam, it looks like I'll be abandoning further work on Community Edition. There are too many linked variables -- I guess the compiler optimization scheme is to blame. [Edit: I have learned how to break these links, so I can continue my work on CE.] The OP executable, so far, doesn't have them, which is proper and logical.
Working on OP right now...
I modified the total energy of an OL Plasma-S and it did not change the total energy of an OL PPD! I was also able to modify the total energy of an OL Plasma-G. It did not affect five other unrelated systems, as it would in Community Edition.
If I start to find linked variables in OP, then I'll make a decision as to where to focus my efforts. I really want CE to be given a chance. I think it is the best software for multiplayer in the series, although it has been largely ignored. OP is clearly the best software for singleplayer mode -- the mods are endless.
-
I must be seeing something it messed something up bc I couldn't understand why the 8.0 was there. Only 8.0 for overloaded heavy photons not standard. Please take a peak. It's in the 0001e something section before the Plasmas
The relevant 8.0f floats begin in E04B2.
StarfleetOP.exe offsets
E04B2: Heavy Photon total energy // 8.0f (includes Proximity mode)
E04BC: 4.0f ? Not Phaser-A/B.
E0487: OL Heavy Photon total energy // 16.0f
E0491: 8.0f ?
E04B2: 8.0f ?
---
E0E55: OL Hellbore total energy // 9.0f
E0E75: Hellbore total energy // 5.0f
---
E4CB8: 4.0f ? Not Phaser-B.
---
E6B44: OL Photon total energy // 8.0f
E6B4E: 4.0f ? Not Phaser-B.
E6B6F: Photon total energy // 4.0f (includes Proximity mode)
---
E737E: 9.0f ?
---
E8AF7: Plasma-R total energy // 9.0f
E8B17: OL Plasma-R total energy // 14.0f
E8B3A: Plasma-S total energy // 8.0f
E8B5A: OL Plasma-S total energy // 12.0f
E8B61: 4.0f ? Not Phaser-B.
E8B7D: Plasma-G total energy // 7.0f
E8B9D: OL Plasma-G total energy // 10.0f
E8BC7: Plasma-F total energy // 5.0f
---
EAB69: 4.0f ? Not Phaser-B.
EAB97: OL PPD total energy // 12.0f
EABC6: PPD total energy // 8.0f
EABD0: 4.0f ? Not Phaser-B
---
EB3A6: 4.0f ? // Not Phaser-A or Phaser-B.
---
395BF4: 4.0f ?
---
396EB4: 4.0f ?
---
39BC28: 6.0f
39BC30: 5.5f
39BC34: 4.5f
39BC38: 4.0f
39BC3A: 6.6f
---
39EA40: Suicide OL Fusion charge rate // 7.0f
---
3A08D0: 64.0f
3A08D4: 10.0f
3A08D8: 320.0f
3A08DC: 4.0f
---
3A0A6C: 4.0f
Obviously I'm searching for Phaser-B, with no success yet.
-
Let's say you earn $2 an hour scraping space-barnacles from the hulls of Orion pirate ships...
You want to buy a standard Photon Torpedo. They cost $4 at Tar Industries, Inc. How many hours do you need to work to be able to purchase one torpedo?
Two, of course. (You don't pay Federation taxes and you certainly don't contribute to a retirement fund.)
But scraping space-barnacles isn't much fun, so you think, "How can I get a torpedo for less of my labor?" Since Captain Morgan isn't giving any raises this year to his crew, you'll have to find a Photon Torpedo that's selling at a discount. Fortunately for you, Corbomite's Salvage Co. has them for just $2 each.
So, Adam, that's what you've done. You've hex-edited the cost of a Photon to be on sale at half price. That is why you can get them (i.e. arm them) in half the time.
-
I won't find a number, such as "3", anywhere in the code that determines how many turns Plasma Torps take to complete.
The programmers used two ideas: total energy and continuous charge rate. You can change one or both.
If you want to charge a Plasma-R quickly, you can increase the charge rate:
Turn Progress
-----0-----0.5-----1-----1.5-----2-----2.5-----3-----
0 1.5 3 4.5 6 7.5 9 // accumulated energy, default charge rate of 3/turn
0 3 6 9 (holding...) // accumulated energy, modified charge rate of 6/turn
When it gets to 9 total energy, it's ready to launch!
Or you can reduce the total energy required. The Plas-R would be armed in 1.5 turns if its total energy were set to 4.5, while using the default charge rate (3.0/turn).
If you also double the charge rate (6.0/turn), that half-energy Plas-R can be completed in 3/4 turn.
Note that none of this affects the damage dealt by the torpedo. That data has not been located.
-
Corbomite's Salvage Co.
Don't trust this guy. His torpedoes have been known tho explode inside the tube.
-
I found where the race images for ships (the image you see when you lock onto a ship and click on the transporter menu) are handled in the SFC3 sprites.q3 file. I can move them around for all races except those that have the blank (black) image, namely "Species8472" and "Neutral". I think this blank image is the "default" case in a switch statement or the "else" in an if statement. It's not really an image either, more like a lack of one.
The image below displays the relevant section in sprites.q3. The parts indicated in red tell you what image is shown for what race: 2A 0E points to the Federation logo, if you replace this with 2B 0E Federation ships will use the Klingon logo, this goes on until 31 0E, which is the Rakellian logo iirc. Some time after 31 0E comes 29 0E (there's a 01 in between which might indicate it's a "default" or "else"). You can switch these around no problem, if you replace 29 0E with 2A 0E then Species 8472 and Neutral ships use the Federation logo. The part indicated in yellow is an example of what these codes point towards. There seems to be nothing for 29 0E which is why you get a blank image in game. there is one for 32 0E but it seems to be an invalid code for the logos because when you point 2A 0E or 29 0E to it, the game crashes as soon as you look at the respective logos.
I have two questions:
1) can any of you make heads or tails of the codes these logos point to (like the one indicated in yellow), are they (encoded) addresses inside the sprites.q3 file, if we can figure out wht they mean we may be able to divert the logos to bitmaps in the texture folder (just like some of the buttons)?
2) can any fo you send me the sprites.q3 file of another SFC game so I can see how to expand the number of logo entries or the number of codes, i know the other games ave a different number of logos (more or fewer races)?
P.S. I've also found somewhat similar structures for the race logos used in the vessel library and the images (a Borg Drone, Starfleet, Klingon and Romulan officers) used in the campaign slection menu. I can switch all of those around but not much else yet.
Update: I think I found how to increase the number of entries: changing the 08 00 09 part before 2A 0E into 09 00 0A should result in having one more entry, and the 01 in front of 29 0E does indeed seem to indicate the "else"/"default" value (at least the same pattern appears in many similar structure throughout the sprites.q3 file). The problem is the sprites.q3 file uses a checksum and it's very hard for me to find places where I can delete null characters without anything getting screwed up (in the .exe that's a lot easier for some reason).
Update 2: Does anyone know where the checksum is stored in the sprite.q3 file or which algorithm it uses (I want to try and edit the checksum manually so I won't have to worry about file length anymore)?
-
Jan, I don't know much about logos or CRC checks. I do know that Starfleet2CE.exe can use the sprites.q3 from Orion Pirates. I guess the .exe doesn't verify by file-length or content. The .exe sends a request to whichever sprites.q3 is found in the ../assets/sprites folder. If the sprites engine understands this request, it responds with bitmaps and strings. Those incoming strings and bitmaps, if they make sense, are used by the .exe (or some external asset) for the game's UI, or perhaps they are sent back to the sprites engine to build the UI.
In short, communication occurs between the main StarfleetX.exe and the sprites.q3. Neither element seems to care about the other's identity. (Or maybe Starfleet2.exe and StarfleetOP.exe have identical ID's from the perspective of the sprites.q3.
Much to be learned here.
Have you read the long thread on Q3 documentation, Jan? You may find some useful information there.
http://www.dynaverse.net/forum/index.php/topic,163347881.0.html (http://www.dynaverse.net/forum/index.php/topic,163347881.0.html)
-
well I figured it out, its the Mauler. 0-6 7-11 12-20, damage is 2x, 1x 0.5x
003A7CA0/08 thru 003A7D20/0B
Found them at 3A7D14 through 3A7D28. Six consecutive floats.
60.0f, 120.0f, 210.0f, 2.0f, 1.0f, 0.5f
-
Rolling a 5 (or less) on a 1d6 (5/6) for Photons should be identical to rolling a 9 (or less) on 2d6 (30/36) for Hellbores..
5/6 = 30/36
You are right. They should use the same number.
The programmers probably used "modulo" 6 to simulate the 1d6 disribution of Disruptors and Photons.
Modulo 6 will produce 0, 1, 2, 3, 4, or 5. The first row of the weapon hit charts may be assigned to 0, the second row to 1, the third to 2, etc.
It's possible that there is no 1.00, 0.833, 0.667, 0.5, 0.333, 0.167 series in the code.
-
Jan, I don't know much about logos or CRC checks. I do know that Starfleet2CE.exe can use the sprites.q3 from Orion Pirates. I guess the .exe doesn't verify by file-length or content. The .exe sends a request to whichever sprites.q3 is found in the ../assets/sprites folder. If the sprites engine understands this request, it responds with bitmaps and strings. Those incoming strings and bitmaps, if they make sense, are used by the .exe (or some external asset) for the game's UI, or perhaps they are sent back to the sprites engine to build the UI.
In short, communication occurs between the main StarfleetX.exe and the sprites.q3. Neither element seems to care about the other's identity. (Or maybe Starfleet2.exe and StarfleetOP.exe have identical ID's from the perspective of the sprites.q3.
Much to be learned here.
Have you read the long thread on Q3 documentation, Jan? You may find some useful information there.
[url]http://www.dynaverse.net/forum/index.php/topic,163347881.0.html[/url] ([url]http://www.dynaverse.net/forum/index.php/topic,163347881.0.html[/url])
In retrospect both the .exe and .q3 files probably don't use checksums, it's just that when you change the lenght of a section everything that comes after it becomes offset, the .exe simply has a lot more redundant null characters in its sections, making editing easier. I've read the long thread you linked to and it seems someone called "marstone" has written a program that can decrypt images in the .q3 file to bitmaps and recrypt bitmaps to fit in the .q3 file, and he possible knows how to make everything work with sections of a different size. He hasn't posted on Dynaverse since 2013, but I'll try to contact him. If he has the goods my goal of changing/adding ship race icons would be simple enough.
-
So my theory that there isn't a checksum is correct: I can paste additional content at the end of the sprites.q3 file without anything breaking. I've isolated some of the images, pasted a disfigured copy of one (the asteroids on the skirmish mission selection screen) at the end of the sprites.q3 file and changed the location link of asteroids_bmp to it, et voila, disfigured asteroid logos on the skirmish mission selection screen. I'll keep you guys updated...
Update:. Tar, I pulled the Gorn logo from the SFC2 CE sprite file you gave me and pasted it to the end of the SFC3 file, attachment shows how it looks in game. It's distorted but somewhat recognizable. I think the distortion comes from differences between the engines of the two games. In any case the distortion doesn't really matter since I'm not planning on using SFC2 images but I now have a way to add an unlimited number of images to the sprites.q3 file to replace stock images. Now it really is only a matter of figuring out how the bitmap compression of the .q3 system works, so we can make our own images, I've asked marstone about it but if he doesn't answer I can try to figure out some things myself.
-
Then I found this
40 C0 00 00 6
41 30 00 00 11
41 A8 00 00 21
40 00 00 00 2
3F 80 00 00 1
3F 00 00 00 0.5
IDK, the first one was 60/120/210 2/1/0.5 now this, what could it be
I found that too, Adam. It is similar to the Mauler specs. I tested various values, but didn't notice anything.
-
I found and reported the charge rate (7.0f) for Suicide OL Fusion Beams in OP. I believe that their total energy is defined as the charge cost, so you'll never find that data. TotalEnergy = ChargeRate. You may not be able to mod them to fire faster than once per turn. (I'm not saying it's impossible. Maybe there's a 1.0f that affects the rate of fire.) The same idea may apply to Disruptors.
The hold cost, however, is defined as 1/2 of the charge rate. So you'll never find a particular 3.5f associated with Suicide Overloads. I modified the charge rate to be 14 and the resultant hold cost was 7. It charged in one turn.
The odd thing about Fusions is that they have a range 3-10 bracket. This exceeds the regular overload range by 2. Something is shortening this bracket to 3-8 for Overloads (but not for SOL's). I guessed that maybe the 3rd bracket was being subtracted from the 4th, but that isn't the case.
-
Nice to see the Gorn logo in SFC3, JanB! I'm glad you're making good progress. That's excellent.
Adam, I was able to break the link between OL Plasma-S and OL-PPD. They shared a total energy of 12.0f. So I overwrote some nulls with 14.0f and then changed the first reference to the original data to the segment address of the new data. Tested this in-game...the weapon systems are truly independent now. :-)
I didn't understand segment addresses until tonight. They are little-endian.
I can continue my work on Community Edition.
-
On a side note I tried to fix some minor SFC3 issues. I wanted to change the default skirmish game points level (65000) and I wanted destroyers and battlecruisers to have their own DD and BC logos on the map. SFC3.exe mentions a max skirmish points object, but no value (I also looked for instances of 65000 in hex and none of them changed the value, I guess the value could be stored like 65.000 or 6500 or 64999.99 or something) and although I can change the ship logos for destroyers and battlecruisers the logos for light and heavy cruisers automatically changes with them. I'm also stuck on the shuttle front, the other SFC games handle shuttles completely different. If only we had the source code of the .exe...
-
Well, when you figure all the details out on how to separate the phaser texture and/or add weapons :smitten:, please share the info, I'd love to add more weapons to SFC2OP.
You'll be my savior!
For now can you show me what exactly you did?
Adam
PS
In SCP2OP, the PPD and PlaS aren't linked bc I have tested both the PlaS and PPD, both in unique areas so I'm assuming you are referring to SFC2EAW.
Right, I broke the link between OL Plasma-S and OL PPD in Community Edition. We don't have this problem in Orion Pirates, [too].
The fix is complicated and demanding. First, you need to find 4 consecutive bytes to hold a new variable. To do this accurately, you need another tool called IDA which examines the data for references to the assembly code so you don't overwrite important data. Then you follow the references (by clicking on the shared variable) to various subroutines. You make a guess as to which one affects Plasma or PPDs. You overwrite the original segment address reference with the new segment address reference (which is different than its HexEdit address). Launch the game and hope you found the right one. Check for bugs.
All Plasma Torpedoes now have independent variables for total energy! (Plas-I and Two-Turn-F's are treated as Plas-F for total energy purposes -- they require an investment of 5 energy.)
(Fixed the Klingon Phaser UI this morning. For 15 years it referred to Overloaded Fusion Beams! Its area in sprites needed to be cleaned up. Same for the quicktip references for the Hydran OL Hellbore and Romulan Phaser. Edited sprites to include quicktips for Mirak Disruptors and Romulan Photons. Discovered some numerical assignments to the UI layout...10-13)
-
Been awhile since i visited older semi-abandoned 1 haunts, but based on a reading of the thread, you peeps are GREAT!
Slogging through code....finding things, testing, re-testing- take a bow.
I may have to reinstall OP and the SFB mods and dream the big dream again of all the things Taldren could have done if the plug was'nt pulled.
-
Thanks.
The binary files are strange and difficult at first. But once you get the hang of little-endianness and segment addresses, things get easier.
I've segregated most of the weapon data in Community Edition, but some data I've kept linked. The rate-of-fire and charge cost of Photons is the same for Normal and Proximity modes. This convention could be changed by a player who wants to experiment. I had to laugh out loud when I could fire hundreds of Plasma-F's per turn! All due to a single typo...a '6' instead of a 'C'.
-
There is no TRBLStatus or TRBHStatus in StarfleetOP.exe. We need to add these new functions. I don't know how to add functions. The easiest approach may be to link individual TRB's to the multiple weapons UI. Or just add the word "TRBeamStatus" where it should probably be, and see what happens.
StarfleetOP.exe does have TRBeamStatus1/2/3/4. So Taldren worked on the weapons' UI.
Sprites.q3 doesn't mention TRBeam, TRBeamStatus, or TRBL/H.
Maybe a section of sprites can be copied and pasted to the end of file. Then it can be edited to accomodate this Andromedan weapon. There are no TR bitmaps, icons, or buttons. They'd have to use the Phaser panel or something and they'd need new strings. (At this moment, it seems like a lot of work for little gain. The multiple-weapon UI works ok for TR Beams.)
Yeah, the range 15.99 range limits are mysterious. None of the 160.0f's seem to affect this limit...
-
My first contribution, I bring you the PLASMA SPEEDS, just made mine 72.0 whoop whoop
search for
1st : 00 (00 00 B4 43) 59 DF E0 9E 75 0A B8 00 19 00 00 Controls Plasma Speed for PlaR Only
2nd : 86 60 02 00 00 (00 00 B4 43) 59 DF E0 9E 75 B6 B8 Controls Plasma Speed for PlaF/I & G
3rd : 24 D8 1D 1C 56 79 00 59 C7 86 60 02 00 00 (00 00 B4 43) 59 DF E0 9E 0F 85 69 FF FF FF B8 00 05 00 Controls Plasma Speed for PlaD
4th : 00 00 (00 00 B4 43) 59 D9 45 24 D8 1D 1C 56 79 00 Controls Plasma Speed for PlaS & E (SFC2OP)
Now you can look for Plasma Damage, Adam. I found them together in CE, just before "PlasmaRLauncher."
Hexadecimal: 32 1E 14 14 14 0A
For types: R S G F I D
Since OP has Plasma-X and the Snare, there will be another number in there.
Hexadecimal: 32 1E 14 14 14 0A 28 14
For types: R S G F I D X E
(Regular damage numbers: 50 30 20 20 20 10 for CE + 40 20 for OP)
(I noticed that there are 3 seemingly disabled Plasma arming-modes. Maybe they were put in the code to allow larger launchers (R/S/G) to charge a Plas-F for 1.66/turn * 3 turns instead of 2.5/turn * 2 turns.)
-
Awesome!!!!
I will take a look. This sounds promising.
Now to locate Plasma's degradation. ;)
I'm looking for this:
Plasma-G
Range: 10.99 15.99 18.99 19.99 20.99 21
Damage: 20 15 10 5 1 0
Mult: 1.0 0.75 0.5 0.25 0.05 0
-
EAW and OP do not use the same scheme as Community Edition uses for determining Plasma's range. EAW/OP Torpedoes will match their chart-based damage with a mere +0.05 extension. A Phaser-1, on the other hand, has an extension of +0.99, such that it does the same damage at range 5.00 through 5.99. We are all very accustomed to that convention.
But EAW/OP Plasma doesn't work this way. If your G-CA fires at a nominal range of 10 (let's say 10.92) from an immobile target, you will not do 20 damage per Plasma-G. You'll do 15 instead, as if you were firing at a nominal range of 11.
In Community Edition, I believe the coders might have tried to give Plasma the same +0.99 extension that all direct-fire weapons have. It makes sense to me... But I've discovered that this new extension is too big (or perhaps the rate of decay is slightly low).
The Plasma-G can do 20 damage at a range of 11.5. It's over-reaching by 0.5.
At range 21.7, it can do 1 point of damage. It's over-reaching by about 0.8.
The Plasma-R, however, gets a bigger extension due to its great endurance, over-reaching by up to 3.4. The Plasma-R should not do 10 damage after travelling 32.6 hexes! It should stop doing 10 damage at range 28.9. And be completely exhausted at 30.9.
There's a slight error that's being compounded. It's trivial for Plasma-D/F, but substantial for larger torpedoes.
(The attached image shows the movement of plasma that is properly not counted against it in CE because the models are 6000 miles long. Range in SFC is determined shield to shield, not center to center. This peculiarity may influence the Plasma "charts", wherever they may be.)
-
NOTE: this post has been made obsolete by new information: http://www.dynaverse.net/forum/index.php/topic,163394152.msg1123048180.html#msg1123048180 (http://www.dynaverse.net/forum/index.php/topic,163394152.msg1123048180.html#msg1123048180)
Wow, I finally got somewhere with the shuttle problem in SFC3. A program called Ida Pro was very helpful and now I've managed to give Species 8472 it's own shuttle and I've decoupled the Ferengi shuttle from the Federation shuttle. Unfortunately this did mean forcing the pirates and Rakellians to use the same shuttle as the Ferengi (they're now coupled), but I'm sure it's not a stretch for pirates to use bought Ferengi shuttles and most people find Species 8472 more interesting for a mod than they do the Rakellians (you could also raceswap if you don't use Species 8472 and want a unique Rakellian shuttle). Neutral vessels now use the Ferengi/pirate/Rakellian shuttle isntead of the Federation shuttle. All the other races keep the shuttle they already had.
Here's how you do it:
- open up SFC3.exe (I worked with version v354b) with a hex editor and navigate to offset 000061B08 (that's the hexadecimal address)
- REPLACE the following 27 bits:
48 74 34 48 74 2A 48 74 20 48 48 74 15 48 48 74 0A 48 75 39 BB 78 66 94 00 EB 21
has to become
48 74 34 48 74 2A 48 74 20 48 74 0F 48 74 13 48 78 3B 79 00 BB 78 66 94 00 EB 21
- now look for the string "Klingon Shuttle" (without the parentheses), you'll find the area where the shuttle names are defined.
- change the names as you see fit, but that you compensate with null characters (. in text, 00 in hex) for longer or shorter names, for example replace "Rakellian Shuttle" with "Dominion Shuttle." and ".Pirate Shuttle" with "Ferengi Shuttle". there are limits to how far you can move the names before they start to interfere with each other and once you're out of null characters you can't choose longer names. Just play with it and you'll see.
-
I really would have liked to find a solution to increasing the range of ph3/g/ESGL/fusions etc
Look for 249.9f and 89.9f. Fusion Beams in CE are limited by those unusual constants for maximum range and regular overload range, respectively.No range limit was implemented for Suicide OL's. The AI tends to use them at long range and thus squanders them.
-
Stumbled onto a feature of PPDs tonight. They fire one pulse for every two points of energy invested. The 2, 4, or 6 pulses with which we are familiar, aren't stored in three variables.
So a modified, long-range, high-energy PPD could fire 10 consecutive pulses after an investment of 20 total energy. The energy cost would be 4/turn for 5 turns. The hold costs, which are not proportional, haven't been found yet.
-
Here is the data for an Overloaded PPD for Orion Pirates. If you increase its total energy from 12.0f to 24.0f, it will take twice as much time and energy to arm. However, it should fire twice as many pulses.
-
If you guys could find the cause (and fix) of the PPD fire hose, that would be a considerable boon.
-
I'm guessing the 4xPPD hardpoint doesn't deduct energy as it should. Have you ever seen a PPD fire hose coming from a 1x or 2x hardpoint? Intermittent problems, such as this, will be the most difficult stuff to address. If a 4xPPD couldn't fire at all, I could focus on that function and maybe find the flaw in the logic (or an incompatible data type).
Currently, there's much to learn about fundamental game mechanics.
-
No, SFB doesn't have HP's. Taldren knew about it, yet never made a fix. There may be a reason you can't put more than two PPD's on a HP.
-
Investigating this in Orion Pirates...
The fire hose is not intermittent. Every time I fire a single PPD from a 4xPPD hardpoint only one quarter of it discharges. The array won't decrement below 2 (the 3rd element) without shift-z. I might possibly be able to do something about this, Corbomite.
Stay tuned...
-
Have you ever seen a PPD fire hose coming from a 1x or 2x hardpoint?
No, only the unmentionable PPD bug, which would be good to fix too if you stumble across it. I'm pretty sure three PPD's on a HP do it too, but it has been years.
-
Investigating this in Orion Pirates...
The fire hose is not intermittent. Every time I fire a single PPD from a 4xPPD hardpoint only one quarter of it discharges. The array won't decrement below 2 (the 3rd element) without shift-z. I might possibly be able to do something about this, Corbomite.
Stay tuned...
IIRC it only happens when you fire all of them at once, but again it's been years.
-
I'm able to exploit this
bug feature on a 3xPPD hardpoint. I can fire unlimited pulses as long as I press "Z" on every third pulse. Fire a fully charged 3xPPD, press "Z" when the third pulse strikes (instantly recharging the two status "bars"), repeat. I don't know if wavelock is involved here... If you miss with 3+ pulses the fire hose may be turned off.
If you fire while the 4th pulse is on its way, it's too late. The hardpoint readiness gets reduced by one.
(Also found in SFC:CE.)
-
StarfleetOP.exe
---
395BF4: OL Disruptor charge cost // 4.0f
---
3977C0: Disruptor charge cost // 2.0f
Firing rate is once per turn. I haven't found the location of the variable that determines the rate.
-
OL Fusions, OL Disruptors, and Heavy Disruptors all use the same variable for charge costs!
This can be overcome by adding 3 new variables and by updating the references within these weapon systems' functions. Something more sophisticated than HexEdit, like IDA Free, would be helpful. Finding functions via HexEdit alone is very challenging.
Anyways, here's the offset of that overburdened variable: 395BF4
Any instruction that refers to this variable (currently containing 4.0f) will include the reference F4 5B 79 00.
How do we determine the reference? For Orion Pirates, we do addition. 0x00395BF4 + 0x00400000 = 0x00795BF4. This must be rearranged to F4 5B 79 00 in the binary. The 0x400000 has something to do with the data segment.
-
IIRC, SFC OP handles plasma tracking differently than SFC II. Any way we can figure out how that works?
It seems that Plasma will always seek the center of its target. They do not obey so-called "turn modes". They can instantly change directions, unlike ships. If Plasma, however, had a tight turn mode, a Plas-D might orbit small models, such as missiles or fighters, instead of striking them.
Plasma is better without so-called "lead tracking". They relentlessly whack that crucial #4 shield. If they tracked some point slightly ahead of center, they'd more often strike the more-or-less expendable #3 and #5 shields.
There may be a variable in the game that can modify the seeking point. If I find it, I'll put it in the database. Pseudo Plasma-R seems to lead-track by about +0.2 from center of model.
-
It seems that Plasma will always seek the center of its target. They do not obey so-called "turn modes". They can instantly change directions, unlike ships. If Plasma, however, had a tight turn mode, a Plas-D might orbit small models, such as missiles or fighters, instead of striking them.
I remember seeing plasma doing that before when a ship speeds up before the plasma hits a WW and then goes back after the ship. Something I think Taldren got right.
There may be a variable in the game that can modify the seeking point. If I find it, I'll put it in the database. Pseudo Plasma-R seems to lead-track by about +0.2 from center of model.
I always thought pseudo plasma tracked differently than regular plasma in the game. Even started a thread about it on the old Taldren forum. Nice to know all these years later that I was right.
BTW has anyone found the missing marine bug yet? lol
-
From Khoromag's release notes of OP 2.525.
"Marines - Mysterious Marine Loss Fix:
Ships with 32 or 64 marines used to mysteriously lose a marine 7 seconds into the simulation. The bugfix required to correct this problem, which was a floating point rounding error, caused all older game films to be unplayable with the new version of the game."
-
I've managed to make the ultimate shuttle mod (IDA Pro is fantastic!): every race, from Federation to Neutral now has its own shuttle, they'll look for the following objects in the defaultloadout file:
Federation: Federation Shuttle
Klingon: Klingon Shuttle
Romulan: Romulan Shuttle
Borg: Borg Shuttle
Species 8472: Species 8472 Shuttle
Cardassian: Cardassian Shuttle
Ferengi: Ferengi Shuttle
Rakellian: Rakellian Shuttle
Pirate: Pirate Shuttle
Neutral: Neutral Shuttle
You can change these names by opening the attached SFC3exe with a hex editor and searching for the right string. For example say you have a mod with the Dominion instead of Species 8472: you open SFC3exe with a hex editor, search for the string "Species 8472 Shuttle" (without the parentheses) and when you find it you replace it with "Dominion Shuttle....", where the dots (make sure they are represented as 00) are used as padding to make sure everything in the exe file stays in the right place.
I've attached the new SFC3exe, as a bonus it also sets the default game points limit in skirmish from 65000 to 999999.
Have fun!
P.S. Always make back ups before messing with the game and make sure to credit me (JanB) if you use thise modified exe in your mod.
P.S. Now that we know new functions can be created in empty portions of the exe, basically anything is possible, including adding new weapons, but I'm probably going to leave that for someone else to do.
-
Quite interesting using IDA. I like how you can generate a chart to see where things come from or lead to.
Let's see what I find.
Thanks
Adding lots of comments (via the semicolon hotkey) as you go through the data segment is very, very, helpful. Even if you're guessing, a comments are good. A 14.0f should get an "Overloaded Plasma-R energy?" comment, for example.
-
The IDA will analyze an .exe thoroughly once. After that, it should load quickly. You don't need to re-run the analysis every time. It stores all that info in a database, like StarfleetOP.idb. You load the "previous" database when you want to look at it and add comments. Use HexEdit to make physical changes, as you've been doing. IDA lists the segment address and the absolute address (that HexEdit also uses) in the lower-left corner. It takes practice to accurately keep HexEdit and IDA on the same page, viewing the same byte. There's almost too much information.
It took me at least a week to make any sense of IDA. It only began to be valuable when I was able to add comments in SFC terms and in regular English right next to the data. Only then, would useful patterns emerge...even though the assembly programming language was almost meaningless.
-
In terms of copying weapons. I was originally going to do the phasers but it appears they are more complicated and It'll be better to copy a stand alone weapon such as the PhA or DisH. Seems like a better idea until I can really grasp all this data.
Phasers will be a bit more involved since they have to be slaved to the capacitor, and a particular set of fields in the shiplist, in order to recognize the weapon as a phaser and change the size of said capacitor to charge it with the full amount of energy required. I suppose you could make a stand alone phaser that isn't slaved to the capacitor (like PH-A and PH-B), but it will go down in the pecking order of weapons charged first with available power, and you will no longer be able to manipulate the charge rate in game.
-
Oh, I thought you wanted to create a new weapon. Try a different texture that isn't bound to fx1. ESG Lance or HDisruptor maybe. Even the Mauler texture would do, but that is tied to fx1 right? I guess you haven't found the Tractor Beam graphic sequence yet?
-
Well, Exeter did tell me that the EAW code is full of dead ends because it appeared that they started to create several systems and features that were either abandoned due to time or were setups for later patches/expansions that never came to light. If OP is the same way, a lot of what you are looking at amounts to so much gibberish; in any language.
-
:help: :banghead: :drink:
-
Well, Exeter did tell me that the EAW code is full of dead ends because it appeared that they started to create several systems and features that were either abandoned due to time or were setups for later patches/expansions that never came to light. If OP is the same way, a lot of what you are looking at amounts to so much gibberish; in any language.
OP code should be much cleaner than SFC II for the simple fact that OP only had one physical CD disk where as SFC II had two CD disks. Likely all of that stuff you are describing were removed to cut costs by eliminating that extra CD.
-
Well, Exeter did tell me that the EAW code is full of dead ends because it appeared that they started to create several systems and features that were either abandoned due to time or were setups for later patches/expansions that never came to light. If OP is the same way, a lot of what you are looking at amounts to so much gibberish; in any language.
OP code should be much cleaner than SFC II for the simple fact that OP only had one physical CD disk where as SFC II had two CD disks. Likely all of that stuff you are describing were removed to cut costs by eliminating that extra CD.
We have absolutely no way of knowing that, but it is a good hope to have.
-
I remember Eric Bethke bragging about that shortly before OP's release. Something about cleaner tighter code that allowed them to fit OP on one disk. That's how I would do it anyway. Seems like there were extra models to IIRC.
-
Yeah I remember that too, but I always thought he meant that they saved space by giving all of the pirates the same Flintstones interface. :)
-
Nice work, Adam! I wonder if the Heavy Disruptor's ability to leak through shields is inheritable by other systems. I think I saw a 0.1667 in there. That might be the fraction that bypasses the shields.
I finally figured out the Plasma and Missile speeds for CE tonight.
Plasma uses one of the 32.0f constants. There's a "hidden" +4.0f modifier too. So to get a Speed-32 torp, you need to set it to 28.0f.
Medium and slow missile speeds are odd too. They use signed bytes, which then undergo addition (+8 for slow, +4 for medium) and multiplication by ten.
If you set that byte to 0xF4 (-12), your slow missiles will travel at a speed of -4.0. They don't fly backwards, but they do flee from their targets. Quite amusing.
-
After testing it; it appears to be the 149.999999f value. It must be shared with others systems.
The phasers don't penteate shields. After a shield is knocked out by regular fire any subsequent weapons fire bypasses all other remaining shields. Doesn't matter how the vessel maneuvers or where you fire from. If the damage roll intended on hitting the target, usually shields, it bypasses the shields and strikes the hull.
The first time I changed the value, I changed it to the further phaser 1 setting which is 760.0f then I removed all changes, then tested it at ph2 limit of 500.0f. Same result. Idk what type of other systems could have bee affected. This one was just noticeable.
Oh well. So much for hoping I could changed the ph3 into a klingon Disruptor beam. Ehh.
Using IDA you can figure out how to create a new variable in some empty spot and point the phaser function to it.
Has either of you had any luck in getting IDA to read something useful from the sprites.q3 file? For me it doesn't recognize any functions or variables, except when I force analyze but then it just produces garbage (trying to interpret strings as functions, etc...) I really want to figure out how and where the exe uses stuff from the sprites file, but so far no luck. I did find out that a lot of the "names" (both words such as "metabigship" and terms such as 57 01) in the sprite file are meaningless (you can change them and nothing happens so they're not crucial to functions and are not locations), which leads me to believe the sprite file is almost all data with no, or a very small number of functions, meaning the exe does all the work.
-
Adam, I believe the best way to learn is to directly solve a problem in Orion Pirates. Let's give Overloaded Fusion Beams their own variable for charge cost. They currently share that variable with Overloaded Disruptors. You can't change one without affecting the other. We want to remove this limitation.
The shared variable is stored at 0x395BF4.
Let's find a spot for our new OL Fusion variable...
Using IDA, .rdata:00795BF8 looks good to me.
Using HexEdit, I overwrite those 4 bytes for our OL Fusion Beams as "00 00 80 40". (While I'm there, I can overwrite the next 4 bytes to whatever I want -- such as "00 00 00 00".) The new data has a segment address of 0x795BF8. (Its HexEdit address is 0x395BF8.)
Now I need to find the instruction that loads the shared data. I can search IDA for this series of bytes: D9 05 F4 5B 79 00.
The "D9 05" opcode means "load the value found at" the following address. In our case, it's F4 5B 79 00, the shared segment address in little-endian form. There are only two search-results (out of 38) that make sense for Fusion Beams. One is definitely for setting the charge cost, the other might be for setting the total energy, and thus the rate of fire is mysterious.
Using HexEdit, I modify the instruction at 0xDE898 from D9 05 F4 5B 79 00 to D9 05 F8 5B 79 00.
I'll see what this does...
...Tested in-game. My OL Fusion Beam's charge costs were indeed set to the value of the new variable. They still, however, took one turn to charge. I don't yet know how the instruction at 0xDE990 affects the game.
-
The instruction to load the value of a variable from a specific location has been modified. The CPU obeys the new instruction. It will load our new value, let's say 6.0f, at 0x395BF8 instead of the old one, 4.0f, at 0x395BF4. In fact, the CPU cannot load the old value as it creates the Fusion Beam object. It does exactly what it is told to do.
-
If you edit the instructions within a specific subroutine to look for, let's say, "fxAdam.bmp" instead of "fx1.bmp", then the system should obey your custom setting. Anything outside of that subroutine should still use "fx1.bmp", so default stuff will still look the same. I don't know if a Phaser can use a Plasma torpedo effect or any effect that shows a HUD speed. Phasers don't seem to have a speed characteristic.
It's possible that all Phasers might have to use the same bitmap. You might be able to alter the specific coordinates within a common bitmap. Good luck.
-
But if I'm understanding this correctly, then I can do what I want and copy weapons. For instance, if I want to copy the Phaser 1, change the name to Phaser 5, then everything the same in terms of charging, cost etc... Same icons and panels, bc I can just change the letter 5 in the strings folder, then with what you are showing me I can change where it locates the file for texture to another one, let's say fxa instead of fx1. I just need to learn how.
Yes, in principle this is possible, as long as there is unused space left in the exe, you can keep adding copied functions. It's just that weapons could be very deeply rooted, or not; you might have to rewrite a lot of functions or just edit one, we simply don't know. I'm interested in the subject because I want to make Dominion polaron beams (for SFC3), but if it looks ot be too much work I'll have to pass (starting a busy new job in February).
-
Slow missiles back to speed 8 :)
You may select any speed from -119 to 135.
I flew a Kzinti Cruiser last night... After all these years with 16 being considered "slow", speed-8 drones are indeed slow. I'm trying to find the hitpoints for missiles so I can make armored drones that would zoom along at a speed of 6.
-
When IDA "unpacks" StarfleetOP.exe it organizes it into a text segment and a few data segments. It gives them new addresses that are different from those shown by HexEdit.
IDA adds 400000 to HexEdit's addresses. So 395BF8 becomes 795BF8 as a segment address. Yes, it is confusing!
Segment references have to be made little-endian, thus: 0x00795BF8 -> F8 5B 79 00
So the instruction "D9 05 F8 5B 79 00" loads the value that is referenced by rdata:795BF8 as shown in IDA.
IDA rdata:00795BF8 = HexEdit 00395BF8
-
Oh, I think I know what you're asking. The binary file (StarfleetOP.exe) will contain 09 05 79 xx xx xx many times. Not all of them are instructions to load. It can just be a coincidence.
Look at this sequence of bytes: 75 09 05 79 12 34 56 78.
That "09 05" in there may be completely unrelated to the load instruction!
Those numbers could represent three commands:
75 09 (Jump 9 bytes ahead if a condition is met)
05 79 12 (add 12 to a register)
34 56 78 (subtract 78 from a different register)
IDA will show the instructions by highlighting them in its own hex viewer. It is sophisticated, identifying rules written by Intel about the valid sequences of specific bytes to tell the CPU what to do.
HexEdit does not group related bytes. If you search for "09 05 79" it will find them all, maybe hundreds. There is no guarantee that most of them are load commands. But if you search for "09 05 58 5B 79 00", the chances are good that many of the results will be true instructions. Just like searching for "00 00 00 41" will find 8.0f. Not all will be 8.0f. You'll have false positives with HexEdit.
09 05 must be followed by four bytes (as a typical address) to make any sense as a load command.
-
I found the HET and Erratic Maneuver costs. They aren't cumulative. If you HET while using Erratics, it doesn't cost anything extra. It's like this in SFC1, EAW, and OP.
In OP, your chances for HET success are not reduced because of Erratics nor do you slow down any. But in CE, the HET% is penalized 16%.
Also found the HET turn rate, which is 6x normal.
These variables need to be segregated before they can be properly modified. I always thought the free-angle HETs in SFC were comical. If I set them to a lower rate, they just seem right to me. [Edit: HET turn rate has been isolated. 3.0f seems good.]
-
Adam, earlier you mentioned something about phaser colors, how did you find them?
-
Found the function for the range of seeking objects, including Plasma, Drones, Probes, Suicide Shuttles, Scatterpacks, Marine Shuttles, and WW's. Plasma was using 32 (instead of 36) for its range calculation, which accounts for its extended reach in Community Edition. I used 31/36, 26/36, and 21/36 for Plasma-R, S, and G endurance, respectively, conforming to EAW/OP standards. The Plas-F needed 17/36 instead of 16/36 to match its expected range.
Isolated more variables -- many, many more to do. Pretty much all the non-chart data will need new variables...but this work will only need to be done once.
-
So Tar, have you had any luck in finding out how/where the weapon colors are handled, or how a specific weapon is connected to its texture?
Btw, wasn't there someone on this forum with access to the source code (of SFC2 I believe), can he not give us little hints or answer direct questions about little things such as the location/value of a weapon color, you know little bits that we could feasibly eventually find out ourselves, without help so it wouldn't be the same as giving us the source code, it would just save us a lot of time?
-
So Tar, have you had any luck in finding out how/where the weapon colors are handled, or how a specific weapon is connected to its texture?
Honestly, I haven't looked for weapon colors or textures. Eventually, I would like to fix the corrupted sun graphic, which has an incorrect bitmap inserted consistently into every cycle. At the moment, I'm isolating variables to maintain the integrity of the game. If I specifically change the Disruptor-1, it must not affect the damage allocation scheme or the size of planets, for example. The good news is that Taldren frequently put 8-byte pi between groups of related variables, so there's room for two new 4-byte items.
-
Ok, I kinda expected those answers but I had to try....
My problem with the phaser colors is that I can't look for them because I don't know their values. Do you reckon the colors we see in game are "unfiltered" (not influenced by ambient lighting settings and such)? If they are I might just be able to get the color values by studying the pixel values of a lossless screenshot.
-
Found the Photon/Heavy Photon Overload Limitation.
Still can not locate the Hellbore and Fusion (limitation).
For Fusion Beams, try this section, Adam: .text:004DF200
I extended the OL range to 109.9f to check it out. I can indeed fire from 9.00 to 10.99, but the weapon doesn't seem to do any damage...
The Hellbore range limits are likely in this function: .text:004E102C
-
Ok, I kinda expected those answers but I had to try....
My problem with the phaser colors is that I can't look for them because I don't know their values. Do you reckon the colors we see in game are "unfiltered" (not influenced by ambient lighting settings and such)? If they are I might just be able to get the color values by studying the pixel values of a lossless screenshot.
Tried that, didnt work. :'(
Did you remove the fx files from the texture folder (they're mixed with the hardcoded colors to produce what you would normally see ingame, I believe)?
-
So the colors in them don't get mixed with the hardcoded colors from the exe. I once removed them to see what change, and the the federation phaser became more yellowish and less orangish, (this was in sfc3). So the hardcoded color is more yellowish than what you would initially expect it to be, now that I think about it it may actually be "pure" ff ff 00 yellow. Lots of stuff for me to test tomorrow...
-
While I was inspecting OP's Fusion Beams, I fixed a significant bug.
Regular OL mode gets a typical Range-8.99 limit, as we would expect. If the mode is different, however, the range is unlimited. This logic puts Suicide OL's in the same class as Normals! So I changed the comparison from JNZ (not equal) to JS (negative sign). The AI should be unable to sacrifice its Fusions in hopeless long-range attacks (9 to 24).
HexEdit 0xDF230: Change one byte (75 -> 78) to enforce a range limit on SOL Fusions.
-
This will affect players too (should any of them attempt to fire in futility). Changing that one byte of logic specifically affects the SOL Fusion Beam.
This could have been written as:
if (FusionMode == OL) {
setFusionMaxRange(89.9f);
} else {
setFusionMaxRange(249.9f); // includes Suicides because their mode (SOL) is not the same as OL.
}
My StarfleetOP.exe now has code essentially like this:
if (FusionMode == Normal) {
setFusionMaxRange(249.9f);
} else {
setFusionMaxRange(89.9f);
}
-
Good idea. That might somehow work. Photons Torpedoes use a specific function to determine range and damage. I wonder if it is possible to selectively call, let's say, the Hellbore's range and damage function instead. I guess it depends on the inputs. If the Photon has the right stuff to send in, maybe the Hellbore instructions would respond usefully. Hmm...I don't know! That's advanced modding. Although, success seems more probable in that example than in importing the behavior of Plasma torpedoes to the ESG or other vastly different systems. Photons and Hellbores are both direct-fire weapons with speed indicators on their projectiles, and they both take two turns to arm.
-
If you mean the speed reduction stats, then you lose five points of (maximum) movement for one turn for every torp that hits. I always wondered what would happen if you got hit by six torps at once, but that is hard to test without help.
-
I just struck a Speed-31 target with 6 Plasma Snares. It's highest speed for the next 30 seconds was 11.0. There appears to be a limit of 4 Plas-E that can affect speed simultaneously. This could be modified, Adam. Changing the "04" to a "06" for maximum snare effect is easy, but finding it in the binary might take some time.
-
Good luck to us all. The range/damage/recharge tables of weapons are easy enough to find, but other than that weapons seem ridiculously complicated in the SFC games. I'm having a hard time finding out how the relevant functions are connected: IDA doesn't find direct links between them but there have to be indirect links.
-
I just struck a Speed-31 target with 6 Plasma Snares. It's highest speed for the next 30 seconds was 11.0. There appears to be a limit of 4 Plas-E that can affect speed simultaneously. This could be modified, Adam. Changing the "04" to a "06" for maximum snare effect is easy, but finding it in the binary might take some time.
Make sure that it isn't because some of them hit simultaneously and the game recorded one effect for two (or more) hits. Did you stagger the shots? Did it last a full turn?
-
Corbomite, I tested it both ways. Six staggered Plas-E reduce the top speed of the target by 20. The snare effect persists for 30 seconds (at game speed 8) per torpedo, independently. So as each snare wears off, the target can increase its speed by 5. There's not much of a difference between staggered attacks and a massed simultaneous strike...unless you're hitting hull instead of shields, hoping to influence damage allocation.
Depending upon the arcs of the Plas-E, the ideal firing opportunity doesn't usually persist for a quarter turn against a human who would probably parallel your vector if you choose to go fast with high ECM. Your opponent could get to range 5.9, whack you with Phasers and easily outrun even a Plas-R or Plas-X. If you starcastle under EM to gain a defensive shift of at least 2, you'll still get worn down unless your opponent gets impatient. All depends on the ships' power curves, of course.
-
I always thought that PlasE was a good idea with a bad implementation. Considering the ships it's supposed to face, it is too short range and too slow to be of any real use. If you can hit an X2 ship with (effectively) a PlasG with PlasS range without a tractor lock, then you're either fighting the AI or a newb. To hit you need a tractor lock. If you have a tractor lock, the PlasE is pointless. The thing should go 40 (or more) like the PlasX.
-
True.
Plas-E make sense against ships that can barely keep the lights on at a speed of 31. Against XCA's they are marginally effective.
I'd rather modify the Plas-E to have extended range than increased speed. I'd keep the weak 20-point warhead but give it a range of 60. The target XCA will have to use PD phasers to avoid the snare effect. Its pair of Ph-G's will probably accomplish this, but the ship will likely be retreating and exposing the crucial #4 shield.
(1 turn / 36 hexes) * 60 hexes = 1.67 turns that the Plas-E is on the map
If the Plas-E gains a minimum of 5 hexes/turn, it will eventually gain at least 8.33 against a spd-31 XCA. So you could launch the Plas-E as the target approaches and the torpedo won't dissipate until 50 seconds has passed. That's a significant threat.
My numbers could be horribly unbalanced, but worth an experiment.
Edit: Plasma-S and Plasma-E share endurance and speed characteristics. This is deep mode-level sharing. This will be more challenging to address than anything I've worked on so far. The Plasma-E seems to be a Plasma-S with two extra flags: a 2/3rd damage modifier and a snare byte. I may be unable to separate the shared endurance & speed.
-
That way the Romulan Fast torp is 40.0 for Speed/Damage.
But the E is 40.0 speed but 30.0 damage & the snare effect.
Unfortunately, this would increase the speed of Plasma-S to 40. I don't know how to make the Plasma-E look in a different location for its speed & endurance info. Working on this now...
OK. Made some progress. I can assign the Plasma-E's speed and endurance to any other Plasma.
.text:0041E5F2 db 0 ; 0 Plas-R
.text:0041E5F3 db 1 ; 1 Plas-S
.text:0041E5F4 db 2 ; 2 Plas-G
.text:0041E5F5 db 3 ; 3 Plas-F
.text:0041E5F6 db 3 ; 4 Plas-I?
.text:0041E5F7 db 4 ; 5 Plas-D
.text:0041E5F8 db 5 ; 6 Plas-X
.text:0041E5F9 db 1 ; 7 Plas-E
So I'd change the byte at .text:0041E5F9 from 01 to 05 to give the Plas-E the speed & endurance of a Plas-X. The Plas-S remains at standard specs.
Adam, you know where to modify its warhead.
The number in the comment is the internal "code" for each object. So when a Plasma-E is used, a quick "07" is sent instead of the word "Plasma-E" or something bulky -- 1 byte vs. 8 bytes.
This area of the code needed to be turned into plain data (press "d") to make sense. IDA was trying to convert it to opcode instructions. The font was red, indicating the problem IDA had interpreting it.
(In this manner, Heavy Photons can be assigned a speed of 1000, while normal Photons travel at 500, for example.)
-
I'd try giving the PlasE the endurance of a PlasR (since these things are linked and making new weapons is problematic at this point) and leaving the speed for now, then test other configs. Giving it more speed and range may be too much. The damage really isn't the point of the weapon, so I'd hesitate to raise it any.
-
The more I see you all pulling this thing apart byte by byte, the more I think this game is salvageable. With all of the damage and range charts that have been found, is there anyway that the OP code can be moved to the CE project? If that stuff can be moved and with some updating to multiplayer the CE would be everything Taldren promised.
-
I'd try giving the PlasE the endurance of a PlasR (since these things are linked and making new weapons is problematic at this point) and leaving the speed for now, then test other configs. Giving it more speed and range may be too much. The damage really isn't the point of the weapon, so I'd hesitate to raise it any.
Sounds wise.
Open StarfleetOP.exe with HexEdit. Change the byte at 0x0001E5F9 from 01 to 00. Save. Your Plas-E will have a range of about 30.5 instead of 25.5.
-
I'd actually like to suggest something different for the Plasma E (only because I like the Tholian Snare)
Giving it a godawfully high speed (say 1000), but a very short range. So if you are say within 5 hexes of the target, you fire the babies at an enmy ship and it drops significantly in speed in the next couple of seconds, after the warhead quickly travels to the target (at phtoon torpedo speeds).
Of course, along with this I'd want to see the actual damage inflicted dropped a LOT (i.e. mainly a speed drop), with perhaps an increase to the drop in movement, depending on how quickly the Plasma E will recharge.
I don't have a lot of experience with Plasma E's though, so I'd need to play with them a bit to see what they actually do ingame.
A longer range version could sorta kinda simulate a web caster...
Of course, what I really want is actual Tholian Webs, but yeah I'm sure that is a much more involved endeavor than a simple change to the .exe
Oh, and on a related note, if anyone is really really brave, can the Plasma E be 'inverted' to give a ship a HUGE boost in speed (like speed 500 for a few seconds)?
I'm thinking Displacement Device here...
:D
-
We have the Displacement Device; it's called lag ;)
That's a cool idea for the Snare though. If you keep it at a three turn arming rate and the expensive cost, then I'd say a max range of six (like the ESG Lance which is another always hit weapon if in range) for 10 points of damage per hit. You get a little damage and a slower target (assuming they are running at top possible speed). If you turn it into a more traditional DFHW and make it a two turn charge rate with a little less arming cost, then I'd do a variable 4-6 damage per hit.
I just thought of something:
The Envelope/Defense sections of this weapon are not used. Could we turn them into a second/third function and not have to mess with the standard torp at all? We have the UI already and we might be able to change the wording if it can handle it.
-
Adam, the 1st attachment shows the data for Plasma endurance in OP.
The 2nd attachment shows the assignment of objects to their speed (and endurance if applicable). The red box shows the result of changing the data from 01 to 05, such that Plasma-E uses the default Plasma-X data.
-
And the example you gave above turning the PlaE endurance into PlaR; does it also degrade like the PlaR as well extend that far or does it still use the PlaE degradation formula.
The Plas-E will use the endurance of Plas-R. It will, however, begin with a 20 point warhead, not a 50 pointer.
Modified Plas-E which uses default Plas-R endurance of 0.8611d.
Distance traveled | Damage potential
10 hexes = 20
15 hexes = 14
20 hexes = 10
25 hexes = 8
28 hexes = 5
29 hexes = 2
30 hexes = 1
-
...can the Plasma E be 'inverted' to give a ship a HUGE boost in speed (like speed 500 for a few seconds)?
I'm thinking Displacement Device here...
:D
All ships share a maximum speed limit of 31. I don't know how to selectively increase the limit for one ship. But somehow a ship that gets snared has a different maximum speed. So some unknown function may be overwriting the 31 with a 26, after one Plas-E strikes.
The challenge with a 500 boost in speed is that the ship needs to power that increase. I wouldn't choose to increase the warp engine values... We could, just possibly, temporarily reduce the mass of the ship, such that it could attain a speed of 31 for, let's say, 3 energy. I don't know where the mass (move ratio) is stored during runtime. I doubt the .exe is reading shiplist.txt when the battle is underway.
Good ideas.
-
The Envelope/Defense sections of this weapon are not used. Could we turn them into a second/third function and not have to mess with the standard torp at all? We have the UI already and we might be able to change the wording if it can handle it.
That would be great.
My initial concern is that plain old Plas-F torps as well as the Plas-X could be set to Envelop or Shotgun mode. There is no "E" or "X" on the Plasma UI buttons, only an "F".
-
...can the Plasma E be 'inverted' to give a ship a HUGE boost in speed (like speed 500 for a few seconds)?
I'm thinking Displacement Device here...
:D
All ships share a maximum speed limit of 31. I don't know how to selectively increase the limit for one ship. But somehow a ship that gets snared has a different maximum speed. So some unknown function may be overwriting the 31 with a 26, after one Plas-E strikes.
The challenge with a 500 boost in speed is that the ship needs to power that increase. I wouldn't choose to increase the warp engine values... We could, just possibly, temporarily reduce the mass of the ship, such that it could attain a speed of 31 for, let's say, 3 energy. I don't know where the mass (move ratio) is stored during runtime. I doubt the .exe is reading shiplist.txt when the battle is underway.
Good ideas.
Yeah, bumping to speed 31 isn't going to simulate a displacement device. The DD can move you 1-6 hexes in a random direction in one impulse... My idea was that (if it could work) that the sudden massive increase in speed (to 500 or whatever) would move a ship extremely quickly across the map for a short time, so that the player would massively overshoot their target or whatever, screwing up their attack run...
Photons have an assigned speed variable that is very fast (which is why, if you are on your toes, you can sometimes turn enough to bring an adjacent shield to bear while the photon is en route), which is why I thought that this just MIGHT work, but c'est la vie...
-
Shoot. While we at it.
Can the Hellbore's formula be changed so that its shield effect is amplified.
I don't know.
Are you looking for a Hellbore that does more damage to shields than it would otherwise do to hull? In that case, the Phaser-B could be modified such that it does 15 to shields but only 5 to hull. Turn that 1/3 modifier (when you find it) into a 3 and rewrite the Phaser-B chart with 1/3 damage values.
Phaser-B "Shield Cracker" vs Hull
Die | Range
Roll | 0-1 2-4 5-6 etc.
1 | 5 5 4
2 | 5 5 4
3 | 5 5 4
4 | 5 5 3
5 | 5 5 3
6 | 5 0 0
Not much better than a Phaser-2 at a range of less than 4.
The effect of Phaser-B "Shield Cracker" vs Shields (no chart exists)
Die | Range
Roll | 0-1 2-4 5-6 etc.
1 | 15 15 12
2 | 15 15 12
3 | 15 15 12
4 | 15 15 9
5 | 15 15 9
6 | 15 0 0
An unconventional weapon, no doubt. It gets weaker as the battle goes on.
-
Yeah, bumping to speed 31 isn't going to simulate a displacement device. The DD can move you 1-6 hexes in a random direction in one impulse... My idea was that (if it could work) that the sudden massive increase in speed (to 500 or whatever) would move a ship extremely quickly across the map for a short time, so that the player would massively overshoot their target or whatever, screwing up their attack run...
Sounds like we need to add players' ships to the list of transportable objects. You beam your target to a random location (instead of your transporter room). This is pretty much a dream. I cannot accomplish this without a much greater understanding of the code.
-
I need the exact values of how the HB distributes it's damage so I can locate those values.
Hellbore damage procedure
5 or 6 shields equally weak:
0.1666 to each // 100% (same idea as Enveloping Plasma)
4 shields equally weak:
0.2 to those four // 80%
0.1 to the strong two // 20%
3 shields equally weak:
0.25 to those three // 75%
0.08333 to the strong three // 25%
2 shields equally weak:
0.3333 to those two // 67%
0.08333 to the stronger four // 33%
1 weakest shield: // This is typical after the first exchange of fire.
0.5 to it // 50%
0.1 to the stronger five // 50%
For example, if a 20-point Hellbore strikes a ship with 3 equally weak shields this is how the damage gets dealt:
Forward hemisphere shields 6, 1, and 2 are strong --- typical of many Heavy Cruisers.
rear hemisphere shields 3, 4, and 5 are equally weak -- an essential refit for Klinks.
Shields 3, 4, and 5 take 0.25 of 20 damage each. So that's 5 damage each.
Shields 6, 1, and 2 take 0.08333 of 20 damage each. So that's 1.666 damage each. (I forget how Magnum dealt with rounding numbers up/down/alternately.)
Sub-totals:
3 shields @ 5 each = 15
3 shields @ 1.666 each = 5 (or 3 if rounded down)
Grand total = 20 (or 18 if rounded down)
-
Some years ago Marstone had nearly cracked the graphics end of this nebula, and then pretty much left the community. It would be nice to come up with an UI for the TR Beams, and rewrite the buttons. "Normal" should read as "Standard" on all weapons. "Normal" just doesn't sound like military lexicon.
-
Adam,
I think this would benefit from more eyes, so I am posting this here instead of in our PM's.
Most of this Hellbore code makes sense (if I got the right code chart and am reading it right), but there seems to be extraneous and/or missing information:
0B 0A 09 08 07 06 05 00 14 11 0F 0D 0A 08 04 00 0A 09 08 06 00 00 00 00 1E 19 16 13 00 00 00 00
0B 0A 09 08 07 06 05 00 = 11 10 9 8 7 6 5 0 = 97% 92% 83% 72% 58% 42% 28% 0% (all % rounded to nearest whole#) - These are your To Hit chances. The numbers represent what you need to roll on two d6 to score a hit. The "00" may just be a placeholder or represent an absolute miss under the proper conditions.
14 11 0F 0D 0A 08 04 00 = 20 17 15 13 10 8 4 0 - This is normal damage, but again the "00" seems to be a placeholder or represents a miss, but is extraneous if that is taken care of in the chance to hit.
0A 09 08 06 00 00 00 00 = 10 9 8 6 0 0 0 0 - This is half of the damage applied to the weakest shield before the other half of the damage is distributed across the other five, but I don't know why it stops at 6 (and the 6 really should be a 7). It may be that Taldren isn't using all of the SFB specs for some reason. There should be code somewhere that handles the rest of the distribution.
1E 19 16 13 00 00 00 00 = 30 25 22 19 0 0 0 0 - This is overload damage. The last "00" may be a placeholder because it serves no purpose since there is no bracket there. There should also be more information like in the set of numbers above for the division of damage onto the weakest shield, but for OL's. It should look something like this: 21 0D 0B 0A 00 00 00 00 if they are being consistant in their format.
-
So what happens when you put a value other than 00 in that spot? Also if I have time I'll try to find my old assembler text books and try to find anything to do with colors and how it handles changes.
-
It may be that PPD, Hellbores and Enveloping Plasma are linked in some way.
The only other in game weapon that uses 2d6 is the Mauler.
-
Remember page 9, I had the values posted. You commented on how lines 64/68 weren't apart of the 2d6 percentages.
I have to check that out later when I come back from work. Maybe it's linked.
These?
64 3C E3 BC D3 0.0278
68 3D AA CD 9F 0.0834
72 3E 2A B3 68 0.1667
76 3E 8E 3B CD 0.2778
80 3E D5 59 B4 0.4167
84 3F 15 59 B4 0.5834
88 3F 38 E8 A7 0.7223
92 3F 55 59 B4 0.8334
96 3F 6A AC DA 0.9167
100 3F 78 E8 A7 0.9723
They're just exactly what Tar said they were. They are the To Hit % for rolling a 4, 3 or 2 on 2d6, i.e. 17%, 8% and 3%. I assume that they are there to account for ECM at long range since HB can withstand a shift of 3 and still hit at range 40.99.
Another interesting thing is there don't seem to be any range brackets. How does it know how far away it's firing? Unless that other jargon does that.
-
0A 09 08 06 00 00 00 00 = 10 9 8 6 0 0 0 0 - This is half of the damage applied to the weakest shield before the other half of the damage is distributed across the other five, but I don't know why it stops at 6 (and the 6 really should be a 7). It may be that Taldren isn't using all of the SFB specs for some reason. There should be code somewhere that handles the rest of the distribution.
That is the damage for a Fighter-based Hellbore. Its default maximum range is 8.9, the 4th bracket.
-
0A 09 08 06 00 00 00 00 = 10 9 8 6 0 0 0 0 - This is half of the damage applied to the weakest shield before the other half of the damage is distributed across the other five, but I don't know why it stops at 6 (and the 6 really should be a 7). It may be that Taldren isn't using all of the SFB specs for some reason. There should be code somewhere that handles the rest of the distribution.
That is the damage for a Fighter-based Hellbore. Its default maximum range is 8.9, the 4th bracket.
Your'e right. I'd completely forgotten about them being half strength. Cool, at least you found where we can shorten the range, which I always wanted to do. That leads creedence to the idea that all the multiple shield weapons are somehow linked or in a similar place in the code (I hope).
-
Last night I changed every value that may represent the phaser b shield damage. I found (2) 0.333333, (1)0.33 and several 0.3's. I change it to 3 as you mentioned but I found no 45 damage to shield impact.
Maybe Taldren used a 3.0f as a divisor instead of a 0.333 as a multiplier.
15 * 0.333f = 15 / 3.0f
There will be many 3.0f, so you need to search in the code that references the the first row of the Phaser-B damage charts. Look for a divide instruction.
-
One instruction out of many is this:
fdiv ds:flt_123ABC
The "f" means use floating-point math (instead of strange integer math in which 5/2 = 2).
The "div" means divide.
The ds:flt_123ABC is where your data is stored, such as 3.0f.
It could alternatively be ds:dword_123ABC if your data in IDA is shown as a dword, 40400000h, instead of a float, 3.0.
(I like to turn all the dwords into floats when they make sense. Press "D" in IDA to cycle, "Alt+D" to set up the cycle of data types --- Byte, Double Word, Float.)
So the instruction above would divide whatever is presently stored in the floating-point processor by the value referenced by ds:flt_123ABC. If there is a 15.0f in there already, it will get divided by, let's say, 3.0f. And we get a result of 5.0f.
I'm curious about the Phaser-B so I'm presently looking for that elusive damage modifier vs shields.
-
I went to work with the race logos again after I got too trustrated looking for the weapon textures controls.
Anyway, I figured out how to work with the textures in sprites.q3m at least the 16 bit ones. A crude Dominion logo (48x48, 16bit) I made can be seen in the attachment.
I'll try to explain the process through the example of this race logo in SFC3.
At offset 03 5F AE EB of the SFC3 sprites.q3 you'll find the following bytes: 2A 0E 00 00 99 00 00 00 00 00 00 00 00 00 0C 2D 00 00 A7 D7 44 03 FF 00 01 00 these control the Federation race logo. 2A 0E is just a name for this particular logo and I'm not sure what all the other bytes do but I do know that A7 D7 44 03 is the address of the image (in reverse, because little-endian, you'll find it at offset 03 44 D7 A7), 0C 2D (again, this is 2D 0C = 11532) is the size of the image plus its "header" in bytes (if you add that to the offset of the image you get the offset of the next image in sprites.q3).
Now since we do not want to move stuff in sprites.q3 we are going to add a new image to the end of the file and direct the control byte address to it. We can create crude images ourselves even without access to the custom color palette of the sprites.q3 file (see EDIT 2, below). We now to add 22 null characters (00) to the end of sprites.q3 (this will come in handy later). The next byte would be byte 03 61 5C AC so we go back to our 2A 0E control area and change A7 D7 44 03 into AC 5C 61 03. In crude drawing style we just need 48x48 pixels x2 (because 16bit colors take two bytes) = 4608 bytes for the image itself, plus 20 bytes for the header, but the game will want more (probably related to the custom color palette thing), so we actually need something like 4800 bytes, plus 20 bytes for the header. So in the 2A 0E control section we change 2D 0C into D4 12.
Now we must set up the header. Starting from byte 03 61 5C AC we type in: 30 00 30 00 18 00 18 00 00 00 10 00 FF 00 01 00 C0 12 00 00 The 30 00 30 00 part tells the game the image is 48 by 48 pixels, the 18 00 18 00 part tells the game to center the image at its center (24,24), 10 00 tells the game it's a 16but image, 01 tells the game to use some form of RLE compression that happens to work for our scheme (sadly, just choosing 00 doesn't make the game accept normal, uncompressed bitmap images), the C0 12 part just means 4800 bytes will follow the header (if you set this too low the bottom part of the image won't be rendered, it has to be larger than 48x48x2=4608).
We're now ready to construct the actual image. We must select 4800 bytes of data from somewhere in the sprites.q3 file (or any other binary file), copy and paste it behind the header we just made, then turn all the bytes into FF (FF FF makes a pixel black, not the usual 16bit color palette, but we can work with it). Because we've conveniently placed 22 null characters between the original end of the file and the image header the beginning of the image will align with the right side of the screen when we set the number of columns in our hex editor to 96. We can now start to "paint" our image: the first two bytes beyond the header are the pixel in the upper left corner of the image, every row of 96 bytes is exactly one row of 48 pixels in our image. I found that 0F 0F gives greenish color, and 0D 0D a blueish color, these are the only colors I used to create the image in the attachment.
And we're done!
EDIT: I found that FF 30 gives a nicer Dominion shade of purple, replace 0D 0D with it. Also 1F 00 works as deep blue, when you need that for another image.
EDIT 2: I found a program that produces images that can almost directly be put into sprites.q3. GIMP (available for Windows and Linux) allows you to export images as 16 bit BMPs with the X1 R5 G5 B5 advanced option. With compression set to 00 or 01, sprites.q3 will accept this, including the color palette, but you still have to vertically flip the image first and you have to move the color palette generated by GIMP to the back of the data. For a 64x64 16bit bitmap GIMP produces a file of 8330 bytes, you can work on it with a hex editor. The first 54 bytes are a bitmap header that you should not copy into sprites.q3 (which uses the custom 20 byte header header system I explained above), the next 84 bytes are the color palette, you should cut this and paste it at the back of the file. The actual data consists of 8192 bytes. Copy everything except the header (so 8276 bytes and paste it after the custom header you made at the end of sprites.q3. Of course the header should be adjusted for a 64x64 image size, centered at 32,32. The data size should be set to 8276 bytes (so for example change the C0 12 from the above example into 54 20). The compression byte should be set to either 00 or 01, but not 02. The control section (2A 0E in our example) needs to be updated too, so going with our example, turn D4 12 into 68 20.
This should work for all the 16bit images in sprites.q3, and in principle all 8bit images (some of the map icons and buttons, I believe) could be replaced by 16bit images if those are placed at the back of sprites.q3.
The result of this latest successful experiment can be seen in the second attachment, enjoy!
-
Changing all the 9A 99 99 3E into 00 00 40 40 has an effect on the appearance of Federation phasers in SFC3, thanks for the tip!
EDIT: it ONLY affects Federation phasers, it's caused by the 9A 99 99 3E at 00 44 BA A0 (00 84 BA A0 in IDA).
-
Well, in SFC3 there are a lot of functions referencing that value, usually multiple times per function. In SFC3 it changes the spread of the constituent color beams that make up a normal phaser. I took multiple screenshots and definitely saw that there are two kinds of color beams: a thin yellowish beam and several thicker orange beams with color
EF5921 (this color was very consistent among the beams), but that code (as well as its little endian equivalent) is nowhere to be found in either SFC3.exe or sprites.q3. They may be using 16bit or 256color colors or they've done something mean like picking a different color and then adding some value to it to get EF5921 (now that I think about it using a 256color color is pretty mean as well, we'd be looking for a single byte of data).
-
Yeah, it's a pain...
I did just find the range limit for starbase weapons: 00 80 18 44 (610.0f) at 00 44 6D 08, but then again I never looked for it before. Right behind it there is 00 00 B4 43 (360.0f), the range of primary ship weapons.
-
Worked on range validation functions tonight. The maximum range of the Light Hellbore and Light Fusion Beam are determined by offsets from the first element in the range table (an array of brackets). Hydran Hornets will fire their newly offset Hellbores at ranges greater than 8.9 if the damage table has non-zero values in it. Hydran Wasps, however, seem to have another layer of code that prevents them from firing their Fusion Beams beyond range 2.9, even if the 4th bracket is enabled.
For the first time, I moved a small chunk of code in Starfleet2CE. It was only one byte downstream to replace a 2-byte command with a 3-byte command. A unused flow control in the subroutine provided room for the tiny expansion. I needed to adjust the chunk's references by -1 byte. Seems to be ok.
Another odd thing in CE... H-Wasp.III's are the only fighters not available in Late Era. To enable them, I reduced their year first available from 23 to 19 in ftrlist.txt.
-
I changed the value that is multiplied by 4 to calculate the offset to the desired bracket.
Let's say we're looking at Light Hellbore brackets...
0x1234 HB_Brackets dd 10.0f // Only the first bracket has a reference to the Hellbore's range validation function
0x1238 dd 20.0f // 2nd is at +4 bytes
0x123C dd 50.0f // 3rd is at +8 bytes
0x1240 dd 90.0f // 4th is at +12 bytes (Normal limit for Light Hellbores)
0x1244 dd 160.0f // 5th is at +16 bytes (Let's say we want this one instead...)
etc.
When we look at that external reference, we'll eventually find instructions to get the data of the 4th bracket, via +12 bytes. It helps to give your charts recognizable names in IDA, like HB_Brackets.
mov ecx, 4 // Load ecx with 4.
imul ecx, 3 // Multiply ecx by 3, to get 12.
mov edx, [ebp+var_4] // Load some sort of reference.?
movss xmm0, dword ptr [edx+0DCh] // Load current range.
comiss xmm0, HB_Brackets[ecx] // Compare current range to HB_Brackets[+ 12 bytes].
jb short loc_5678 // Jump to loc_5678 if current range is less than the calculated bracket's value.
loc_5678:
xor eax, eax // Set eax to zero. Which means the range is valid, it has zero restrictions, and the Hellbore can fire.
So if I change that imul instruction to "imul ecx, 4" we'll get a result of 16, for an offset of 16 bytes. I do this through HexEdit, and change 6B C9 03 -> 6B C9 04. The new max bracket will be the 5th; Range 9.0 to 15.9.
(Edited to hexadecimal memory addresses)
-
I can now say with near certainty that sub_500AC3 controls the Federation phaser graphics in some way in SFC3, no other weapons seem to be affected by it. It is a long function, but it does contain the crucial link to 9A 99 99 3E at 00 84 BA A0, the only link to that location that actually affects the Federation phaser beam spread. Changing the only rdata piece that (indirectly) calls this function only affects Federation phasers (the game crashes when you fire them).
-
Adam, I haven't found the Point Defense subroutines. I don't know how to stop the AI from using Wild Weasels. Been busy isolating variables...amazing how many systems share a particular 2.0f.
In theory, the AI could be instructed to never fire Phaser 1's and 2's at Plasma unless no enemy is within, let's say, 15 hexes. This would be a great enhancement. The AI should simply assume that a torpedo is fake (let's say 75% of the time) on Admiral level, and ignore players' Psuedoes.
New players (and the AI) can also be vastly helped by changing the maximum range of the Phaser-3/G from 15.9 to 2.9 (or even 1.9). It is a long overdue change. Not even the AI should be so inefficient and reckless.
-
I didn't get any further on the phaser thing. I've turned my attention to the only other hex-editing side project I haven't completed yet: fixing the "bug" (though from the help menu in campaign mode it seems like they planned it that way, but why?) of SFC3 not showing separate map symbols for DD and BC hull type ships (it also uses the F symbol for shuttles but shuttles never show up on the map so I don't care). The symbols are in sprites.q3. I found that sub_559C84 assigns the ship symbols (it pulls them from sprites.q3 via byte_F7D1E8). This function is told by some other function or something that it should give DD and CL ships (or CA and BC) the same map symbol. Hull types are stored near 00 97 CA 94 in IDA, or 00 54 CA 94 in a hex editor (there is also an identical set of definitions a shrt distance below it, but that doesn't influence anything), which is referenced by sub_6B018D. Sub_6B018D definitely pulls these definitions (from SH until NONE) using a loop, but alas it is also not the function that tells the game to use the same symbols for DD and CL, nor is it the function that tells the game which hull types can be used as ships (so no listening posts, defense platforms, etc...) I cannot just simply turn all destroyers from DD into BIO (which would work in principle, they'd get the "M" map symbol but I can easily change that to the "DD" symbol in the MetaBigShip section in sprites.q3) because I haven't found the function that determines which ships are available to players and AI in campaign mode (and the vessel library). How can something so simple be so deeply hardcoded...
-
Fixed a very old, but never documented, bug tonight. Unique among weapons, OL and SOL Fusion Beams would always do zero damage if fired at range 8.01 to 8.99. The code uses 80.0f instead of 90.0f to enforce a restriction on the methane-breathers' weapon. There was already a maximum range limit for OL, and I've recently enabled one for SOL.
Many years ago, in the early days of EAW, a player (whose name I've forgotten) advised me how to win as Hydran with neither Hellbores nor Hornets, but with abundant Fusion Beams. The strategy involved the frequent use of OL Fusions at ranges greater than 6 exclusively upon the opponent's rear shield. Well, this never worked for me, in part, because I figured 8.9 was as good as 6 or 7 (or better because reinforcement/ECM tended to decrease as the opponent accelerated to get to the safety of range 9+.
Well, now your overloads will be true to range.
If Phaser-3/G's were limited to range 1.9 and tractors grabbed at 1.9 (instead of 2.5), the performance of the Hydran AI would be significantly affected.
-
The unofficial 2.671 patch will include the bugfixes that I've posted in this thread.
I believe two enhancements should be included:
Warp Tacs -- Ships at speed 4 can turn approximately 240 degrees per standard cycle. Warp Tacs are helpful if you're low on power or have dropped a WW.
Sane Phaser-3/G's charts -- maximum range of 2.9.
Of course, each can be restored to historical values by changing the floats.
But changing the tractor engagement range is too big of a change to be considered vanilla. Same goes for limiting Phaser-1's and Phaser-2's to range 15.9 and 8.9, respectively, or for reducing the speed of WW's.
I'm wondering, however, about increasing the PD range of Phaser-1's and Phaser-2's, something I discovered how to do tonight. It is difficult to protect another ship with PD phasers unless you're almost in the same spot. If you want your PD to only activate close up, you can hit the PD hotkey when a threat is at range 1.9. Fleets with AMD have a pretty good common defense with little effort, but for those fleets without it, they can struggle. Manual PD is a chore, often impractical at typical game speeds, and it's bugged by the host's ECM.
Many 3v3 battles would have had different outcomes if automated PD was able to reach a little further. T-bombing your wingman isn't ideal, but it has been done when neccessary. All this needs play-testing.
-
I'm all for making the AI smarter about certain game functions, but I am not for doing it by way of limiting the players' options to do it. Phasers work the way they do. Deciding not to fire stupidly is a player decision. Sometimes you do want to fire a PH-3 at range 15, however rare an occurance it is and regardless of whether it is a good shot or not. If the PD routines could be modfied w/o hampering the live fire options of phasers, then I say go for it.
-
Corbomite, I would indeed like to maintain the long-range capabilities of all Phasers. Yes, once in a while they can be useful against bare hull. But I don't know how to allow a Player to fire at range 15, yet prohibit the AI from doing so. Figuring that out may take months or longer. In the meantime, would you sacrifice that average Ph-3 damage of 0.16 to gain better AI performance?
In my opinion, the AI is greatly improved with optimized phaser charts. The game is much more fun for me to play. Not for one second do I miss the weak outer brackets. I can no longer bear to see another Hydran vessel get whacked in the nose by a missile when it's supposedly protected by Gatlings. (I won't modify the Ph-1 or Ph-2 in 2.671.)
As soon as I learn how to modify AI behavior directly, I'll do so, and restore the Ph-3/G to historical specs for veteran Players. Starfleet2CE.exe has 43,000 functions -- it takes time to examine them...
-
If the PD routines could be modified w/o hampering the live fire options of phasers, then I say go for it.
I found the function that determines the range of PD. It has two branches based on the threat: Plasma and Non-plasma. I can set the max PD range for each Phaser type to any range bracket, including the null byte after the 6th Ph-3/G bracket.
None of these has an effect on manually fired Phasers.
I also found the global limiter. So if you want to disable all PD, you can do so by changing its value to 0. The default is 1000.0f, which should be sufficient for just about any mod.
-
See, that wasn't so hard after all. ;) ;D
No really, good find there. I'm sure you'll figure it out at some point.
-
Ooooh please keep us updated, very interesting and exciting news. Once you have gathered both branches I'd love to learn how to manipulate the ranges in which the PD phasers fire.
The PD code is a mess! With good luck, I found a distant puny function that overruled the changes I made in the obvious PD function.
It seems that fighters are grouped with missiles afterall. It's pretty neat to see your Ph-1's automatically pick off drones and fighters from range 4.9. It's also great to see them ignore Plasma. When I sort out the PD variables, I'll certainly share the info.
-
PS, I forgot to mention the Mauler recharging mess, when you reinforce shields its difficult to recharge batteries and fire the mauler again.Anything in there that would help the recharge
To really fix that you would have to be able to place Batteries in the power priorities list so players could manipulate them like other power systems. They are currently at the bottom of the list and unmanipulatable. Maybe linking them with the phaser capacitor might work, or completetly break the game, who knows.
-
Oh, it's from SFB, but in SFB you have about a thousand fold more minute control over power than you do in SFC. You can place small increments of power anywhere you like or put most all of it into one thing if you want. You can do partial overloads and use both General and Specific shield reinforcement at the same time. You can charge batteries and weapons and have both kinds of reinforcement up just by dividing it the way you like. There are no sliders. You fill out an Energy Allocation form at the start of each turn and all of that energy is at your discretion. You can even opt not to power life support and kill your crew.
-
Batteries don't work right in SFC anyway. A favored tactic of dizzy users was to charge regular warheads and when they got into striking range to use the batteries to OL some or all of them at the last minute. You can't do that in SFC. Instead you will slow down or lose power to other systems and have to wait for the HP to get to full again. The only thing I have been able to use Batts for (other than the Mauler) was some short EW points until they run dry, which isn't usually very long or to charge a Probe.
-
Just did a battle against a F-BCF...
I am finally no longer annoyed by point-defense! I set my phasers to ignore plasma but to attack missiles and shuttles. How often does the BCF unload its psuedo-F torp just when you really need your PD to kill missiles or a nearby scatterpack? I can give the PD hotkey a well deserved break.
I'd like to allow the player to discriminate between shuttles and missiles, but for now they are in the same group. I'll look at Orion Pirates tomorrow, Adam.
Starfleet2CE.exe:
177DFC: 6B D2 [00] // Ph-1 PD vs Plasma. Change the 00 to 2E to disable.
177E11: 6B C0 [00] // Ph-2 PD vs Plasma. Change the 00 to 17 to disable.
177E26: 6B C9 [00] // Ph-3 PD vs Plasma. Change the 00 to 07 to disable.
177E3B: 6B D2 [00] // Ph-G PD vs Plasma. Change the 00 to 07 to disable.
177E50: 6B C0 [00] // Ph-4 PD vs Plasma. Change the 00 to EB to disable.
[00] means the 1st bracket (range 0.99)
[01] means the 2nd bracket (range 1.99)
[02] means the 3rd bracket (range 2.99) -- but it is overruled by an external function
You can still press spacebar to target plasma (like an R-torp that's nipping on your heels) and fire at it with your phasers.
-
I'm a little lost. Just why exactly is PD vs plasma bad?
-
Well, that's kind of what the point of that type of assault is. There is no way to determine if the torp is real or not without letting it hit. They programmed the AI to never doubt that the torp is real since it is too stupid to understand plasma defense tactics. Therefore it always drops a WW if it has one and will always fire PD phasers at a torp. Turning it off will also force players to adopt only one strategy against plasma or have to go through the bother of manually targeting a torp and taking their attention off of the enemy. You can castle vs plasma if you know what to do and know when to stop. No plasma PD would make this much harder.
-
If you think that letting the AI take a face full of plasma is better than reducing damage, then it's your mod, so go for it. Chances are it's going to lose some of those phasers to damage and never get to fire them.
-
Modding things as you like is part of the fun of messing with things, but always look at it as an entire system and consider what the changes will do to all aspects of play. It sounds like you are doing this so have at it.
-
I'm a little lost. Just why exactly is PD vs plasma bad?
Back in the Starlance days, Croc or Zorlord and I would fight 2v2's against teams consisting of a K-D5D and an R-SPA or similar. Of course our opponents knew that PD doesn't ignore plasma. So at critical moments, the R-SPA would send in a pseudo torp. We all knew it was a fake torp, but it gave the initiative to the D5D/SPA. If you turned off PD, you could get a face full of large drones. If you kept PD on, you could get a face full of large drones as your phasers fired at the torpedo. Our opponents were exploiting the unrefined PD, rather than using a brilliant tactic. If I want to get whacked by plasma, shouldn't I have that choice? Should I use my PD phasers to take out 6 drones or weaken that plasma (if it's real) by about 7?
I welcome the duty of manually firing at Plasma. There usually aren't too many of them flying around at any given time. Shooting down six drones at typical game speeds is almost impossible.
In my opinion, the battles are more engaging if the AI ignores plasma. One PPT doesn't grant you a free pass. The AI needs a lot of work...especially in power management, as you've mentioned, Corbomite.
-
Adam, I checked out StarfleetOP.exe for PD. The code is different from CE -- more compact, cleaner, but harder to read.
Look at this possibly PD-related function with IDA:
.text:004E36F4 fld [ebp+var_4]
.text:004E36F7 fsub ds:flt_7962F8 ; 10.0f
.text:004E36FD fst [ebp+var_4]
.text:004E3700 fcomp ds:flt_7962FC ; 20.0f
.text:004E3706 fnstsw ax
.text:004E3708 sahf
.text:004E3709 jnb short loc_4E371D
.text:004E370B mov [ebp+var_4], 41A00000h ; 20.0f
.text:004E3712 jmp short loc_4E371D
This is a large function, referring to all Phaser types. That 10.0f above may be the general PD engagement range. That 20.0f may be for Phaser-3/G against missiles. It could be completely unrelated. Both floats are shared with other systems. The 41A00000h isn't shared with anything, it's an immediate value.
-
Adam, I'd bet anything done in CE can be done in OP. It will take time to figure it out. To find the master range limiters for manually fired Phasers in OP, search for 150.0f, 500.0f, 750.0f, and 1000.0f in the same subroutine.
I've decided to not put optimized Phaser charts in the first unofficial patch. With them, I'm concerned that the game might be too difficult for newer players. I've been battling the AI (as if I were a novice -- no hotkeys, no ECM priority, no trac & pack) in a K-D6D with 4 reloads of Type-I missiles. I don't easily defeat a L-CA. It is so damn refreshing to see the AI protect itself. The Tiger's six Ph-3's and tractors can resist a missile bombardment. I tried to kill a H-DE+ from afar...it is impossible with Type-I missiles, as it should be.
Look for 2.671 tomorrow!
Look for 2.672 with optimized Phaser charts (and more) by the end of the week.
-
I'm a little lost. Just why exactly is PD vs plasma bad?
Back in the Starlance days, Croc or Zorlord and I would fight 2v2's against teams consisting of a K-D5D and an R-SPA or similar. Of course our opponents knew that PD doesn't ignore plasma. So at critical moments, the R-SPA would send in a pseudo torp. We all knew it was a fake torp, but it gave the initiative to the D5D/SPA. If you turned off PD, you could get a face full of large drones. If you kept PD on, you could get a face full of large drones as your phasers fired at the torpedo. Our opponents were exploiting the unrefined PD, rather than using a brilliant tactic. If I want to get whacked by plasma, shouldn't I have that choice? Should I use my PD phasers to take out 6 drones or weaken that plasma (if it's real) by about 7?
I welcome the duty of manually firing at Plasma. There usually aren't too many of them flying around at any given time. Shooting down six drones at typical game speeds is almost impossible.
In my opinion, the battles are more engaging if the AI ignores plasma. One PPT doesn't grant you a free pass. The AI needs a lot of work...especially in power management, as you've mentioned, Corbomite.
At lot of how you react is up to the situation and the options you possess and you are removing some of those options. Again, it's your work so you may do as you like, but Drones can be WW, tractored and mined, as well as out run. Plasma is not so forgiving.
-
Another thing is that IIRC the AI in OP is different from the AI in EAW after Dave did some patching. The AI in OP many times actively avoids you after you damage them, so them retreating from plasma actually happens and those points against the warhead can matter.
-
Another thing that irks me is the transport distance. The standard orbit is like btwn 9/10 but transport is 5. Either the distance should be increase allow for 10.0 transport or the distance in orbit has to be reduce. Why should I nearly have to have a collision with a planet to transport a diplomat. Seems quite weird since all the shows can orbit and transport at the same time.
Why not just get rid of collisions? In SFC3 you can turn off collisions with planets in the defaultcore file (set the attribute of planet classes to "ship" instead of "ship:Planet"). At least in my mod all the missions that have planets in them still function properly after this change. For starbases the collision depends on an object being classed as "SB" (which is a hull class/type, not an attribute) and sadly base assault missions don't function properly without this classification. Anyway, hopefully this gives you guys a clue about how and where collisions are handled in SFC2.
-
Well, I don't want to touch the planet, shouldn't be that way, just a slight tweaking in transporting distance and the tweaking with vertical distances when hovering over a target. Eventually it'll be found. Im in no rush, small potatoes at the moment.
It should be a 51.0f value ( 00 00 4C 42 ). With non-solid planets you don't have to influence capturing dynamics and you'll lose fewer AI0allies to collisions, but it's your mod, you should choose how to change things.
-
Well Tar did say the initial release will be vanilla so no major personal changes just the needed ones. And then the alternate releases will be optional. I say we give it a try and see if the challenge will appeal to us.
It's good to get out of your comfort zone every now and then and spice it up. Now that some tactics might not work; it may intrigue you to develop new ones or relying on others. Nothing to lose. And you'll still have a copy of the vanilla release. ;)
Well, I don't want to turn this into a tactics discussion, but based on what Tar offered up as an example of why it needed changing, I can think of at least three things that could be done to fix that problem that are severely less radical than changing the game code:
1) Have a WW ready.
2) Move faster.
3) Both of these things.
As a corollary if the situation involved a tractor beam:
1) Don't get tractored.
-
There is no controversy, just opinion. I would question that mode of play for anyone and any purpose. I'm not specifically approving or discouraging any patch or change. I just think the answer lies elsewhere.
-
No, all I am on about ATM is turning off PD for plasma in an AI environment based on an example given for PvP combat. Making PD phasers smarter would be an improvement as long as its not at the expense of manual fire options.
Changing the transporter range to 10 would be a mistake because of T-Bombs and Boarding Parties, but if you could isolate the the standard orbital distance down to 5.99 the problem would be solved.
-
There is no controversy, just opinion. I would question that mode of play for anyone and any purpose. I'm not specifically approving or discouraging any patch or change. I just think the answer lies elsewhere.
A hotkey might be able to toggle PD vs Plasma torpedoes. Default would be "on". I don't have the ability to do this yet, but it's something I want to do. In the meantime 2.671 is normal -- if 6 missiles are approaching, but a dying Plasma gets to your ship first, your PD phasers will attack the torpedo.
-
There is no controversy, just opinion. I would question that mode of play for anyone and any purpose. I'm not specifically approving or discouraging any patch or change. I just think the answer lies elsewhere.
A hotkey might be able to toggle PD vs Plasma torpedoes. Default would be "on". I don't have the ability to do this yet, but it's something I want to do. In the meantime 2.671 is normal -- if 6 missiles are approaching, but a dying Plasma gets to your ship first, your PD phasers will attack the torpedo.
If you could set up a Shift function like the Mine/NSM function where hitting the hotkey will turn off/on all PD like it does now and hitting Shift + (key) will only turn off/on Plasma PD, that would solve your issue and give finer control of that system. Of course the AI will still not use it correctly...
Speaking of which, can you guys teach the Rom AI to use NSM?
-
Well, I don't want to turn this into a tactics discussion, but based on what Tar offered up as an example of why it needed changing, I can think of at least three things that could be done to fix that problem that are severely less radical than changing the game code:
1) Have a WW ready.
2) Move faster.
3) Both of these things.
As a corollary if the situation involved a tractor beam:
1) Don't get tractored.
Chekhov to Kirk: One of the enemy wessels has launched nuclear missiles!
Kirk: Do we have phasers ready?
Chekhov: Yes, of course, sir. I'm reserving them for defense.
Kirk: Good. Fire at optimum range. Scotty, increase power to negative tractor beam.
Scotty: Aye. It's already strong, but I can add a wee more.
Spock: The Sparrowhawk has launched a plasma torpedo.
Sulu: It must be fake, Captain. We nearly outran their last torpedo, only sustaining minor damage.
Kirk: Agreed... Ignore that plasma, Chekhov. Take out those missiles!
Commander Corbomite: Captain, I suggest we need better tactics.
Uhura: ::)
-
Well, I don't want to turn this into a tactics discussion, but based on what Tar offered up as an example of why it needed changing, I can think of at least three things that could be done to fix that problem that are severely less radical than changing the game code:
1) Have a WW ready.
2) Move faster.
3) Both of these things.
As a corollary if the situation involved a tractor beam:
1) Don't get tractored.
Chekhov to Kirk: One of the enemy wessels has launched nuclear missiles!
Kirk: Do we have phasers ready?
Chekhov: Yes, of course, sir. I'm reserving them for defense.
Kirk: Good. Fire at optimum range. Scotty, increase power to negative tractor beam.
Scotty: Aye. It's already strong, but I can add a wee more.
Spock: The Sparrowhawk has launched a plasma torpedo.
Sulu: It must be fake, Captain. We nearly outran their last torpedo, only sustaining minor damage.
Kirk: Agreed... Ignore that plasma, Chekhov. Take out those missiles!
Commander Corbomite: Captain, I suggest we need better tactics.
Uhura: ::)
LOL, Umm, yeah, you do. I can't even imagine how much team coordination would be involved with timing that precisely right unless you were pretty much stopped, in which case you need two WW in the bay. You could also target the nearest seeking weapon repeatedly and when the plasma overtakes the drones, turn off PD until the torp hits and then reinitiate PD at the last second. I've done that before and it works if you are on your game.
-
I've fought very good teams who did exploit the PD's one-size-fits-all system. The MoK guys knew it, and we GSG knew it. It was done once a game, not during ordinary peeling or weaving or castling with missiles approaching manageably. If I had time to turn PD off, I'd do so. My fingers do work. It's when you're pouncing at a closing rate of about 50, late in the battle, with a good negative tractor. The Sparrowhawk's can't-be-ignored plasma can bail the D5D out, at best, and possibly get you killed. All due to a UI flaw. Chekhov was forced to fire at that pathetic plasma, and the Enterprise lost the initiative.
This is pointless. Arguing about a battle from 15 years ago with someone who wasn't a participant!
Time to get back to work on the bytes. :-X
-
I've fought very good teams who did exploit the PD's one-size-fits-all system. The MoK guys knew it, and we GSG knew it. It was done once a game, not during ordinary peeling or weaving or castling with missiles approaching manageably. If I had time to turn PD off, I'd do so. My fingers do work. It's when you're pouncing at a closing rate of about 50, late in the battle, with a good negative tractor. The Sparrowhawk's can't-be-ignored plasma can bail the D5D out, at best, and possibly get you killed. All due to a UI flaw. Chekhov was forced to fire at that pathetic plasma, and the Enterprise lost the initiative.
Most everyone tried to do that, but that was the game. Knowing it was like that allowed you to try to not get into that situation in a way that left you at a disadvantange. We couldn't change the game then, just our tactics, therefore there is a way to control that, even if it is advanced tactical.
This is pointless. Arguing about a battle from 15 years ago with someone who wasn't a participant!
Quite, but you gave very little info at first. :-X
-
I finally found my old assembler text books. From the looks of what I am seeing on this thread, Taldren used either a MASM or TASM 5.1 compiler. This is based on four main scratch pad 16 bit registers (AX, BX, CX, DX) which is themselves broken up into two 8 bit registers (AX --> AH {15 --> 8} and AL {7 --> 0}). Colors are handled by the INT 10h, INT 16h, and INT 21h interrupts as apposed to INT 13h which handles common programming functions. So looking for these interrupts should give you a clue as to where the colors are handled in the program. Although IIRC, INT 21h was also used in old virus programming so I'm guessing you won't see any of that here. I think I found some of the ASCII values in hexadecimal if you need them. The book says that display memory is fixed in the first megabyte of the PC's memory which the book is saying is B800:0000 and that this information can be transferred using the MOV instruction. Hope this helps.
-
The Point Defense hotkey in Orion Pirates works as a toggle.
Action PD status
Go to Red Alert: On (except for Ph-4)
Press hotkey: Off
Press again: On (including Ph-4)
Press again: Off
This lessens micromanagement. I like this system. Usually, I want all or nothing.
---
The PD hotkey in EAW/CE is a semi-toggle.
Go to Red Alert: On (except for Ph-4)
Press hotkey: Off (except for Ph-3 and Ph-G)
Press again: On (including Ph-4)
Press again: Off (except for Ph-3 and Ph-G)
I don't like it, but other players might. Your Ph-3/G's are going to fire at valid targets unless you raise the Defense Panel and click on the PD icon. Very tedious and far too slow for critical moments. It is, however, an easy way to toggle your Ph-1's and Ph-2's.
---
In SFC1 there is another system. The PD hotkey, big surprise, activates Point Defense. It can only turn PD on.
Go to Red Alert: On (except for Ph-4)
Press hotkey: On (including Ph-4)
Press a thousand more times: On
If you want to turn off PD, you have to raise the Defense Panel and click on the PD icon. I think this is a good scheme for new players. Via hotkey, you can never turn PD off by mistake. It is however, tedious and inadequate for quickly needed changes in PD status.
---
So my question to the folks here is this: Should CE adopt OP's pure toggle system? Or something else?
-
Speaking of which, can you guys teach the Rom AI to use NSM?
If I can find the function that prohibits certain AI actions, I can perhaps change those ones to zeroes. If the AI action doesn't exist, a lot of work will be needed to create them.
The AI seems to be prohibited from using Erratic Manuevers, NSMs, Plasma-I in modes other than "main", Suicide Shuttles, EPTs, Shotgun Plasma, ESGs at ranges other than 1, and probably others.
Magnum said that the AI is programmed to never use EM. My guess is that there is no code to compute when it should be activated or deactivated.
if (AI_tactic == self_protection) {
set_ECM(6);
if (defense_shift < 2) set_erratics(on);
}
if (AI_tactic == anti_plasma) {
setECM(1);
set_erratics(off);
set_speed(phaserboat_speed);
}
etc.
Of course a computation must first be done to select an AI tactic. It gets complicated unless it is a 1v1 battle. What if the AI is facing a War Eagle and a D6? Go fast, go slow, use OL? What are the AI's weapons? I can imagine a matrix to select a not-too-terrible AI tactic. Getting that matrix into Starfleet2CE.exe via Hex Edit may be impractical. I first need to find any function that allows me to predictably modify AI behavior. No luck yet.
-
I know you haven't found the OP PD code as easy as the CE...
Try changing the 2nd range bracket for Ph-3's from 20.0f to 29.0f. If your Ph-3 PD continues to activate at 1.9 (instead of 2.8) you'll know there's a master PD range limiter of 20.0f.
Finding that exact 20.0f isn't easy, I know. You might be able to follow its external references to the code that descriminates between plasma and missiles.
-
if (AI_tactic == self_protection) {
set_ECM(6);
if (defense_shift < 2) set_erratics(on);
}
if (AI_tactic == anti_plasma) {
setECM(1);
set_erratics(off);
set_speed(phaserboat_speed);
}
etc.
Of course a computation must first be done to select an AI tactic. It gets complicated unless it is a 1v1 battle. What if the AI is facing a War Eagle and a D6? Go fast, go slow, use OL? What are the AI's weapons? I can imagine a matrix to select a not-too-terrible AI tactic. Getting that matrix into Starfleet2CE.exe via Hex Edit may be impractical. I first need to find any function that allows me to predictably modify AI behavior. No luck yet.
Since the AI can already detect missiles and plasma, it's just a matter of the AI finding out which is closer to the AI. Then adjust tactics to better fit depending on difficulty level selected.
-
Corbomite, if a ship uses Erratic Manuevers, does its SFB turn mode get worse? I see no evidence of this in SFC.
A Fed-CA travelling at speed 11 or 15, took 20 seconds to complete a U-turn regardless of EM status. There's a branch in the EM code that multiplies the speed-cost of EM (6.0) by only these four values: 1.2, 1.1, 0.75, or 0.5. I can't think of a reason for it.
-
Without looking it up I believe it increases turn mode by 1, but it does increase it. It always seemed to me that turns took longer, but I never timed it. It's supposed to add to your HET breakdown too, but doesn't (I'm pretty sure).
EDIT: Looked it up, it is 1 and 1 to HET Breakdown.
-
Thank you.
I also had a feeling that EM makes a ship more sluggish. I swear it did in SFC1. If OP has a penalty, I'll attempt to add it to 2.672.
OP doesn't penalize your HET% while under EM. Community Edition does at -16.6%.
Thought I found the PPD fire-hose bug tonight...Nope. I found a function which looks similar to a normal range checker but with an opposite return value. So if you've moved out of range, it gives a green light. Maybe it's a function to break the wavelock.
-
I wonder what the thinking behind that was. OP should have the penalty too as well as increased turn mode, especially since we have regenerating HET % and no tumbling.
-
With regard to EM, I thought one or more of the anti-pirate missions in original sfc has the hostile orion ships use em. Is that mission scripting? I guess it doesn't matter, because SFC volume I and SFC volume II: EAW/OP are probably too different from each other for code in one to be much help in the other.
-
The Point Defense hotkey in Orion Pirates works as a toggle.
Action PD status
Go to Red Alert: On (except for Ph-4)
Press hotkey: Off
Press again: On (including Ph-4)
Press again: Off
This lessens micromanagement. I like this system. Usually, I want all or nothing.
---
The PD hotkey in EAW/CE is a semi-toggle.
Go to Red Alert: On (except for Ph-4)
Press hotkey: Off (except for Ph-3 and Ph-G)
Press again: On (including Ph-4)
Press again: Off (except for Ph-3 and Ph-G)
I don't like it, but other players might. Your Ph-3/G's are going to fire at valid targets unless you raise the Defense Panel and click on the PD icon. Very tedious and far too slow for critical moments. It is, however, an easy way to toggle your Ph-1's and Ph-2's.
---
In SFC1 there is another system. The PD hotkey, big surprise, activates Point Defense. It can only turn PD on.
Go to Red Alert: On (except for Ph-4)
Press hotkey: On (including Ph-4)
Press a thousand more times: On
If you want to turn off PD, you have to raise the Defense Panel and click on the PD icon. I think this is a good scheme for new players. Via hotkey, you can never turn PD off by mistake. It is however, tedious and inadequate for quickly needed changes in PD status.
---
So my question to the folks here is this: Should CE adopt OP's pure toggle system? Or something else?
Barring the opportunity to mod the toggle to do the opposite of EAW, i.e. all on/off and micro-control of the phasers for Plasma defense with a shift function, I'd go with OP. The games should be standard in these "automatic" functions. Finer control is available in the MFD panel, although I never reallly knew anyone who used it since there wasn't time to do so. I suppose playing at a really slow speed to simulate actual turns could find the time.
For OP I'd really like to untie the PD toggle from OL Ph- X's. I find it stupid that when I OL phasers that my phaser PD shuts off. I realize that they didn't want to have OL firing for PD, but why can't phasers still fire at normal strength for that purpose?
-
A function in OP suggests that Ph-4's might be able to fire as Ph-3's against missiles, perhaps up to four times. Of course I could be wrong in my guesswork. Obviously, this doesn't happen in the game. But Taldren may have begun to implement this advanced ability.
Didn't X-technology allow a Ph-1 to fire twice as a Ph-3?
I agree that OL Phaser-X's in Orion Pirates should fire at seeking weapons if you want them to. It may be wasteful to do 12 points of damage against a single missile, but you're in command. I'm all for finer control of ship systems.
From what I've seen so far in the code, having the Ph-X operate in OL mode for offense but in standard mode for defense is impossible. I suppose PD could force your Ph-X panel into standard mode when threats are in range, fire at them, and then restore your panel to overloaded mode.
We need more people looking at the code. I'm still isolating mundane stuff, like weapon hold costs...
-
With regard to EM, I thought one or more of the anti-pirate missions in original sfc has the hostile orion ships use em. Is that mission scripting? I guess it doesn't matter, because SFC volume I and SFC volume II: EAW/OP are probably too different from each other for code in one to be much help in the other.
Interesting. The mission script can place numerous restrictions on the behavior of objects in a battle. Maybe it can enable certain functions, such as EM. I don't know.
The SFC1 code appears to be entirely inside SFC2. There are many references to obsolete items. SFC2 was not written from scratch. EAW is more-or-less a large patch for SFC1, and OP is a medium patch to EAW. Things get moved around, but a lot of it is identical. (I'm not slighting the work of the Taldren crew. They buillt upon what they had -- I'd do the same.)
-
In SFB you can fire any phaser as a lesser version if you choose (IIRC, I'll look it up later), but to fire more than once with the same phaser in the same turn as a lesser type was an Aegis function IIRC (again, I'll look it up later), and only fpr PD.
-
I was right about downloading any phaser to a lesser phaser. I was wrong about Aegis; it only allows you to step fire weapons in a single impulse, not fire one weapon more than once per turn. Tar was right about X Phasers being able to fire two (or more) smaller shots in the same or subsequent impulses and I was right about it only being good for PD, but in SFB all phaser types become X-Phasers and can be OL, so yes an X PH-4 can fire as four normal or four OL Ph-3's or two normal or two OL Ph-1's. This is from the rules I have, which may not be the most current as they keep changing thier minds about X-Tech.
-
I finally found my old assembler text books. From the looks of what I am seeing on this thread, Taldren used either a MASM or TASM 5.1 compiler. This is based on four main scratch pad 16 bit registers (AX, BX, CX, DX) which is themselves broken up into two 8 bit registers (AX --> AH {15 --> 8} and AL {7 --> 0}). Colors are handled by the INT 10h, INT 16h, and INT 21h interrupts as apposed to INT 13h which handles common programming functions. So looking for these interrupts should give you a clue as to where the colors are handled in the program. Although IIRC, INT 21h was also used in old virus programming so I'm guessing you won't see any of that here. I think I found some of the ASCII values in hexadecimal if you need them. The book says that display memory is fixed in the first megabyte of the PC's memory which the book is saying is B800:0000 and that this information can be transferred using the MOV instruction. Hope this helps.
Very interesting... What do you mean by the hexadecimal forms of the ASCII values, are they colors or the hexadecimal forms of the interrupts?
-
I'm talking about ASCII values of symbols on the keyboard converted into hexadecimal. I'm in town so I don't have them in front of me at the moment. IIRC all interrupts are in hexadecimal, the most common is INT 13h. My thinking is since the books said colors in Assembler are handled by INT 10h that finding that code would be as simple as doing a search for that interrupt.
-
Search for Int 10h and Int 16h in the program and we'll go from there. I'm not eager to jump back into this since it's been 20 years now. What little I remember is rusty.
-
When I say search for INT 10h, I mean just that. Look for the instruction: INT 10h
If you find it, look at the code just above it and try to find addresses where the offsets are loaded into one of the registers, probably the DX register. It's possible I am sending you on a wild goose chase, but if the hex edit program you are using has a find function then it should only take a minute or two.
-
The pictures you attached aren't loading and I can't see them. Can you copy/paste the code?
-
From what I'm seeing those lines of code are printing lines of text onto the screen like "You'll need more than that". Looks like a taunt to me. Remember those canned taunts that you could send to an opponent. That is what it looks like to me.
What I find disturbing is that I have seen both 16 bit registers (AX, BX, CX, and DX) and extended registers (EAX, EBX, ECX, EDX, EBP, ESI, EDI, and ESP). Extended registers use double word or 32 bits in a register. For instance, ECX which is regularly used as a counter register (or variable) will have a low byte (CL) of 0 through 7, high byte (CH) of 8 through 15 and a extended portion (ECX) of 16 through 31. Just so we are on the same page, AX is usually used as a Accumulator register (or variable), BX is a Base register, CX is a Count register, and DX is a Data register.
Something else I'm seeing is that I'm seeing is that they defined some but not all of the keyboard keys (example: db 2Eh ; .). I would have done that once in the program and referred back to that part of the code as needed. Just so we are on the same page ASCII values in hexadecimal are as follows:
01 thru 1A = Control-A thru Control-Z.
1B: = ESC key
20: = Space key
30 thru 39 = Digits 0 thru 9
41 thru 5A = Upper case letters A thru Z
61 thru 7A = Lower case letters a thru z
The reason why I know this is that the programers were kind enough to put comments in the code for me to read. When you are looking through the program and see a semicolon, anything after that is a comment that the processor ignores.
For example: ; ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ S U B R O U T I N E ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦
Obviously that is not code and is meant to be read by programmers and not the processor. Things like that above are meant to keep things separated and make chunks of code easier to read. Once the processor finds a ; the processor stops reading anything to the right of that line and goes to the next line. One quick observation is that these guys sucked and commenting. I didn't see one INT (13h or 10h) in the code you quoted.
Something else I noticed is the line "mov eax, offset unknown_libname_1572". What this does is move (MOV) the first part of a line (OFFSET) located at unknown_libname_1572 into the EAX register. Why on earth would you name a variable something like that? Also noticed this: "Microsoft VisualC 2-8/net runtime". So they used two different types of programming languages for this, it's not unheard of but back then they didn't always play nice. But now that I think of it, I remember Erik Bethke stating that he "sold his soul to Microsoft". Maybe that is what he is talking about.
-
Some more random thoughts as I read through that code...
From my text books in Assembler, program data is defined or declared in a data segment. The data is introduced with the directive: .DATA
The following directives are used to define the different data types;
DB = A single byte integer or character.
DW = A two-byte (word) integer.
DD = A four-byte (double word) number, which can be either an integer or floating point (real) number.
DF = A 6-byte (far word) pointer.
DQ = An 8-byte (quadword) integer or floating point number.
DT = A 10-byte number. This is usually a floating point or packed decimal number.
For example:
.data:00857F90 db 2Eh ; .
This assigns the variable 00857F90 with the value of 2Eh (where h equals hex). Using ASCII code, 2Eh appears to equal a period.
I'm also seeing the commands PUSH and POP, these commands put data on (PUSH) and remove (POP) data to and from a stack. However I don't see where the stack is being defined. Example:
.STACK 100h ; Allocate 256-byte stack
Also it looks like .CODE has been replaced with .TEXT . I think what I'm going to do from here is start explaining each of the different instructions that I'm seeing here like the XOR instruction which means exclusive or. Maybe then some of you can get a handle on what was coded.
-
In explaining the different instructions, I think I'm going to start with the J command. To me this one is the most disturbing, a crude comparison would be the SOSUB or GOTO in BASIC programming. This is probably one of the biggest reasons most programmers don't want to touch this code with a 10 foot pole. I'm going to get some aspirin as this one is going to give me a serious head ache...
Anyway a J command is always followed by a condition such as JMP. Where in this case J is followed by MP, this tells the processor to jump unconditionally to another spot in the program. IIRC this program was built using a 16 bit operating system so JMP can only move the processor to a location that is -32,768 to +32,767 bytes from it's current location. Again, kind of like a GOTO in BASIC. So when I look at the code Adam provided above and I see a JMP $+5, I'm confused to say the least because I don't know where $+5 points to.
JNZ - Where we again have the J command and NZ is the condition. NZ means jump if not equal. Usually followed by a CMP (compare) or TEST command. Kind of like saying in BASIC: IF A <> B then GOTO 30. Crude comparison but you get the idea.
JZ - Where we again have the J command and Z is the condition. Z means jump if equal to. Or IF A = B then GOTO 30.
If anyone see's any other J commands that is not listed above then I'll provide the entire list but it's getting late so I'm going to stop here.
-
.data:00857F90 db 2Eh ; .
.data:00857F91 db 3Fh ; ?
.data:00857F92 db 41h ; A
.data:00857F93 db 56h ; V
.data:00857F94 db 74h ; t
.data:00857F95 db 46h ; F
.data:00857F96 db 78h ; x
.data:00857F97 db 5Fh ; _
.data:00857F98 db 50h ; P
.data:00857F99 db 68h ; h
.data:00857F9A db 61h ; a
.data:00857F9B db 73h ; s
.data:00857F9C db 65h ; e
.data:00857F9D db 72h ; r
.data:00857F9E db 40h ; @
.data:00857F9F db 40h ; @
.data:00857FA0 db 0
.data:00857FA1 db 0
In IDA, press the "a" key at data:00857F90. It will put all those characters onto one line that is easy to read: ".?AVtFx_Phaser@@",0
-
Yeah, I saw that after I posted. I still think it's clumsy.
-
As near as I can tell, but then again a lot of the subroutines that are called isn't listed on the example you provided. With those JMP commands I'm not totally sure those chunks of code are related. Again this is the first time I looked at Assembler code in 20 years.
-
That section of code you quoted frequently calls a subroutine "sub_5050E2". Have you looked at the section of code around line ".text:005050E2" and see if the code is related? My guess is that the programmer used the actual location part of the subroutine name.
-
There is something else we can try, look and compare both SFC II and SFC OP. Look for code that is not the same, that should help narrow it down a bit. Especially since we have the source code for SFC II. If you see duplicate code in both programs then it's probably not what you're looking for.
-
That section of code you quoted frequently calls a subroutine "sub_5050E2". Have you looked at the section of code around line ".text:005050E2" and see if the code is related? My guess is that the programmer used the actual location part of the subroutine name.
The interactive disassembler, IDA, provides these names simply for convenience. Taldren didn't create a function named "sub_5050E2" or a floating-point variable named "flt_9669A0". (Those are hexadecimal addresses after the underscore.) The programmers used Microsoft Visual C++ to write the high-level language code. They then compiled that into assembly code which must use GOTO statements because it is a low-level language -- it doesn't understand the concept of a conditional loop. I highly doubt anyone at Taldren looked at Starfleet.exe with a disassembler.
-
That convenience by IDA may still lead us to where that pointer leads to. Even in the 90''s we were told to stay away from JMP commands. I find it odd that Microsoft couldn't create a transitional library for a conditional loop that didn't have a JMP statement. Then again I've seen WinMe... but I degrees. Point is that appears to be a fault on Taldren's end. Why would Taldren announce the use of Microsoft Visual C in the middle of the program if it wasn't using two different programs? Anyway thanks Tar for clearing some of that up.
-
Maybe part of the game was written with Visual C++ 5.0 or earlier and newer stuff (v6.0) had to identify itself.
In other matters, I tried giving the PPD a hold cost of -8 by changing its value from 02 to F8. When the PPD was fully charged, it gave the ship 8 more power to use (although this bonus power isn't shown on the bottom of the screen). This could make an interesting unconventional mod...
If you give a ship a weapon (or weapon mode) that does no damage and has a max range of zero, and change its hold cost to a negative number, the "weapon" acts as a fragile power pack. If the weapon is destroyed, it produces no power. And obviously it first has to be fully charged. The UL PPD, Proximity Photon, or Plasma-G could have this power pack function. I don't know how to do it with Disruptors, otherwise the Disr-IV would be a good choice.
-
Not much going on with that Subroutine Adam. The FLD and the FMUL statement are as follows...
The FLD instruction loads a 32 bit, 64 bit, or 80 bit floating point value onto the stack. The instruction converts 32 and 64 bit operand to an 80 bit extended precision value before pushing the value onto the floating point stack. And the FMUL instructions multiply two floating point values.
So from the looks of it this subroutine is multiplying two numbers. I don't know what the variables mean so I can't tell you much more than that. Sorry Adam.
-
Just a quick question for everyone, has anyone tried Hex-Rays plugin for IDA. Supposedly this can make the code a little more readable or convert it into some type of C code. I just stumbled across this as I was looking into IDA, but don't know much about it so I thought I'd ask.
-
I GIVE UP :crazy2:
No different phasers other than what we already got. Moving along...
Ty for trying ;)
It's probably hard to find because I suspect that all phasers use the same subroutines. The only difference I can see is beam characteristics and damage charts and/or special damage to engines and such. I think if you found that chart(s) you will find how things work.
-
Photon range functions are modifiable. They'll go into the next patch.
Maximums for OL, Normal, Proximity, and Fighter
Minimums for Normal and Proximity
After doing a few battles, the minimum range for standard Photons (0 to 1.99) does not benefit the conventional game. You theoretically could discharge 1/2 of a battery to create a 9-point OL warhead and thereby gain that critical 100% base accuracy bracket. The two points of feedback in SFC are a significant penalty.
The AI, of course, doesn't benefit from a restriction.
But in an unconventional mod, a PPD-like blind zone or larger could spread out the combat. Range-zero alpha strikes are powerful but not particularly intriguing.
Isolated the Disruptor feedback range and damage variables. They'll go in, too.
-
Adam, the way things work with stuff that doesn't get referenced directly is as follows. Some location above the stuff in question gets referenced by a function and then the function starts counting from there. That's how the fx1 texture for phasers gets referenced.
I'll take a look at hex rays as soon as I have time.
Tar, you once said that the pi values are filler but I believe some of them handle the rotation of torpedoes (I found one near a value that determines the visual size of torpedoes).
-
.data:00C69F20 ; struct _OSVERSIONINFOA VersionInformation
.data:00C69F20 VersionInformation _OSVERSIONINFOA <?> ; DATA XREF: sub_6996E0+3w
.data:00C69F20 ; sub_6996E0+Do ...
.data:00C69FB4 ; int X
.data:00C69FB4 X dd ? ; DATA XREF: sub_6997C0+1E9w
.data:00C69FB4 ; sub_6997C0+21Fr ...
.data:00C69FB8 dword_C69FB8 dd ? ; DATA XREF: sub_6997C0+219w
.data:00C69FB8 ; sub_69A4C0+215w
.data:00C69FBC ; int nHeight
.data:00C69FBC nHeight dd ? ; DATA XREF: sub_6997C0+1DEw
.data:00C69FBC ; sub_6997C0+203r ...
.data:00C69FC0 dword_C69FC0 dd ? ; DATA XREF: sub_6997C0+164w
.data:00C69FC0 ; sub_6997C0+190r ...
.data:00C69FC4 ; HMENU hMenu
.data:00C69FC4 hMenu dd ? ; DATA XREF: sub_6997C0+1ACw
.data:00C69FC4 ; sub_6997C0+1FBr ...
.data:00C69FC8 dword_C69FC8 dd ? ; DATA XREF: sub_6997C0+170w
.data:00C69FC8 ; sub_6997C0+196r ...
.data:00C69FCC ; int nWidth
.data:00C69FCC nWidth dd ? ; DATA XREF: sub_6997C0+1D4w
.data:00C69FCC ; sub_6997C0+20Ar ...
.data:00C69FD0 dword_C69FD0 dd ? ; DATA XREF: sub_6997C0+2FCr
.data:00C69FD0 ; sub_699B30+29w ...
.data:00C69FD4 ; HWND dword_C69FD4
As a whole a lot of variables are being declared here but I still don't see a whole lot going on. A few things that did interest me in the section above, one of them is "struct _OSVERSIONINFOA VersionInformation". If my guess is correct this Procedure is checking to Operating System that the program is installed on. The next two things I noticed were "nHeight" and "nWidth". This may (??!?) be asking the screen size of the monitor (1024 x 768 etc). I could be way off but those two things I listed make me think I'm on the right track. One other thing I noticed was "hMenu". I'm racking my brain right now trying to figure out what that might stand for either in game or in the OS and I'm coming up blank. Anyone have any ideas here? Almost forgot, one last observation I have is that when I see INT on the screen it is always in the comment section and doesn't have a hex value after it. I'm having trouble with that one as well.
.data:00C69FE8 ; DWORD dwStyle
.data:00C69FE8 dwStyle dd ? ; DATA XREF: sub_6997C0+180w
.data:00C69FE8 ; sub_6997C0+1A6r ...
.data:00C69FEC ; HHOOK hhk
.data:00C69FEC hhk dd ? ; DATA XREF: fn+5Fr
HHOOK and hhk, why do I think Hydran here, probably totally unrelated. Defined as 4 byte variables...
[/quote]
.data:00C69FF9 db ? ;
.data:00C69FFA db ? ;
.data:00C69FFB db ? ;
.data:00C69FFC db ? ;
.data:00C69FFD db ? ;
.data:00C69FFE db ? ;
.data:00C69FFF db ? ;
.data:00C6A000 flt_C6A000 dd ? ; DATA XREF: .text:0069AEC2w
.data:00C6A004 flt_C6A004 dd ? ; DATA XREF: sub_507AEA+E2r
.data:00C6A004 ; sub_511643+197r ...
[/quote]
So someone wanted to define text with seven characters in it. Two other variables defined with four bytes each from the looks of things. One last thing I noticed a lot of extra characters in the code that was quoted, looks like boxes with little numbers in them. Is there extra code that we can't see.
-
Tar, you once said that the pi values are filler but I believe some of them handle the rotation of torpedoes (I found one near a value that determines the visual size of torpedoes).
I have found exactly two pi that are indeed linked to functions. The other 300 or so must be intentional filler, which has made the addition of new variables practical. As of yet, I've not noticed any side-effects from employing those bytes devoted to isolated 3.14's, nor do I expect to.
I too found a value that determines the size of Photon Torpedoes. If greatly increased, they look like space moths, fluttering their wings.
-
...one of them is "struct _OSVERSIONINFOA VersionInformation". If my guess is correct this Procedure is checking to Operating System that the program is installed on. The next two things I noticed were "nHeight" and "nWidth". This may (??!?) be asking the screen size of the monitor (1024 x 768 etc). I could be way off but those two things I listed make me think I'm on the right track. One other thing I noticed was "hMenu". I'm racking my brain right now trying to figure out what that might stand for either in game or in the OS and I'm coming up blank. Anyone have any ideas here? Almost forgot, one last observation I have is that when I see INT on the screen it is always in the comment section and doesn't have a hex value after it. I'm having trouble with that one as well.
IDA is guessing about the terms used by the higher-level language that originally composed starfleet.exe. When it analyzes a function in Orion Pirates, it suggests by way of comments, the types that were used as arguments passed to functions. For example:
C++
int getPhotonDamage(int range);
The first "int" determines what the function, getPhotonDamage(), gives you when it's finished -- an integer. The second "int" defines the type of argument it will accept. In this case, another integer. If we try to use a 1-byte character as an argument, the function will not work properly and it might cause StarfleetOP.exe to crash. If we use a 4-byte float, the function will not provide the expected information because 41 00 00 00 (8.0f) is not the same as 08 00 00 00 (plain old 8).
"struct" is a structure, more-or-less a way to efficiently associate several variables (properties) with one item. Such as box.width, box.height, box.length. Box is the item, while width, height, length are its properties.
"nWidth" is an example of a variable that stores a countable quantity n, in this case probably pixels.
"hMenu" Hmm, maybe it's a hook. I'm not familiar with hooks in software, but that term can be related to getting input from a device, like the keyboard.
-
What exactly are you proposing then for the next CE patch particular with the Photon/HBs?
You'll have the option to enforce a minimum range on the standard Photon, such that its range is 2.0 to 30.1. You'll have the option to adjust the range limits on Proximities and Overloads. Defaults will be 9.0 to 30.9 and 0 to 8.9, respectively.
The AI's performance might be improved if Proxies could be fired at range 5.0 to 8.9 and standard Photons couldn't be fired beyond 12.9. But those decisions aren't mine to make.
Hellbores won't be any different.
Warp Tacs will occur at a ship's speed of 3 (instead of 4) so that a WW won't be unintentionally voided in multiplayer. Since less energy is expended (3 instead of 4 for a CA), the turn rate will be reduced by 25%. I very much appreciate Warp Tacs when my ship is in a minefield.
-
What do I search for in orion pirates for the size of photons. And is it possible to make the PhoF micro torpedo size to reflect that they do in fact belong to shuttles and fighters.
Do you think the PhoF/Phot and PhoH all share the same size variable.
Tar, is it possible to find the phaser coding for the colors or do you think it's a dead end.
There is a 5.0f that determines the radius of all Photons Torpedoes. I don't know how to give the fighter a micro torpedo.
The code has a class, somewhere, called something like Photon. One of its properties is 3D size. If a fighter fires a PhoF, it inherits certain class variables, such as 3D size and sound effect. It does, as a subclass, use its own variables for range and damage. Changing the classes and subclasses via HexEdit is impossible with my current knowledge.
Adam, I applaud your effort to give Phasers custom colors. I suggest you let that idea rest for a little while. Perhaps while you're experimenting with other things, you'll come across some info that determines color associations.
-
Thanks Tar, I was so focused in the Assembler code that I didn't even think about it referring to declaring a integer in C. If I have time tomorrow I'll look up what I can about hooks.
-
Sounds great. Do you have the location in SFC2OP so that I may make adjustments to my photons and HBs ;D
No, but I do have this info from CE:
.rdata:00A61EA0 flt_A61EA0 dd 5.0 ; DATA XREF: sub_59E140+E5
.rdata:00A61EB0 aAssetsTextu_73 db 'assets/textures/photons-2.bmp',0
There should be a similar bitmap in OP. That 5.0f should determine the size.
-
Following the scanner's references led me to a cloak formula for effective range.
In 2.672, I'm thinking of changing the formula. It has been EffectiveRange = (TrueRange*2)+5 for more than 14 years. EAW's cloak has, at times, been called the croaking device.
The cloak in Orion Pirates, on the other hand, can be highly protective because it can reduce incoming direct-fire damage by 50% or 75%. The damage is based on effective range for hit-or-miss weapons, never true range, for another 40% benefit (except vs Photons, which don't degrade).
In OP, a Disruptor fired at a cloaked vessel from range 1.9 uses the range 5-8 bracket for accuracy and damage. OP's cloak chart establishes an equal chance of doing 3, 1, or 0 damage if it hits. The average damage is a terrifying 0.89. In EAW/CE the average is 2.
But it is essentiallly the Phaser-1 which makes the cloaking device a death trap in EAW/CE. Its average damage is 3.5 at a true range of up to 0.4. So a ship with, let's say, 6 Ph-1's can do about 20 damage to a cloaker on each high-speed pass. There's no great need to ram its own mines, although it can do that too for a flash bonus.
In OP, the Ph-1 does an average of 1.83, which is about half (52%) of the damage of its counterpart in EAW/CE. Some players have said that this feels just about right to them.
I think a change from (Range*2)+5 to (Range*2)+6 is an excellent way to improve the cloak in CE without any significant side effects.
The Ph-1 would use, at best, the range 6-8 bracket for an average damage of 2.17. I'm testing this now...
-
IDA is guessing about the terms used by the higher-level language that originally composed starfleet.exe. When it analyzes a function in Orion Pirates, it suggests by way of comments, the types that were used as arguments passed to functions. For example:
C++
int getPhotonDamage(int range);
The first "int" determines what the function, getPhotonDamage(), gives you when it's finished -- an integer. The second "int" defines the type of argument it will accept. In this case, another integer. If we try to use a 1-byte character as an argument, the function will not work properly and it might cause StarfleetOP.exe to crash. If we use a 4-byte float, the function will not provide the expected information because 41 00 00 00 (8.0f) is not the same as 08 00 00 00 (plain old 8).
"struct" is a structure, more-or-less a way to efficiently associate several variables (properties) with one item. Such as box.width, box.height, box.length. Box is the item, while width, height, length are its properties.
"nWidth" is an example of a variable that stores a countable quantity n, in this case probably pixels.
"hMenu" Hmm, maybe it's a hook. I'm not familiar with hooks in software, but that term can be related to getting input from a device, like the keyboard.
I researched "struct _OSVERSIONINFOA VersionInformation" the first thing that popped up was this:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms724834%28v=vs.85%29.aspx (https://msdn.microsoft.com/en-us/library/windows/desktop/ms724834%28v=vs.85%29.aspx)
"Contains operating system version information. The information includes major and minor version numbers, a build number, a platform identifier, and descriptive text about the operating system. This structure is used with the GetVersionEx function."
So I may have been on the right track after all. When I looked up hooks I found this as well from Wikipedia of all places:
http://en.wikipedia.org/wiki/Hooking (http://en.wikipedia.org/wiki/Hooking)
"In computer programming, the term hooking covers a range of techniques used to alter or augment the behavior of an operating system, of applications, or of other software components by intercepting function calls or messages or events passed between software components[disambiguation needed]. Code that handles such intercepted function calls, events or messages is called a "hook".
Hooking is used for many purposes, including debugging and extending functionality. Examples might include intercepting keyboard or mouse event messages before they reach an application, or intercepting operating system calls in order to monitor behavior or modify the function of an application or other component. It is also widely used in benchmarking programs, for example frame rate measuring in 3D games, where the output and input is done through hooking."
If this is the case with SFC.exe then why? Maybe this is a debug code that was no longer used and commented out but then we would have seen it commented. Is there anything like this in the source code in EAW?
-
OP's Cloak range formula function can be found at text:00438522 sub_438522
It has a switch with 5 cases: 50.0d, 40.0d, 30.0d, 20.0d, 10.0d
Those values are added to the cloaking vessel's effective range as the device deactivates (or activates) over approximately 5 seconds.
That function loads the maximum value, 50.0d, from rdata:0079A140 dbl_79A140.
But that 50.0d is shared with 3 other functions. So it needs to be isolated. One of those 3 other functions may be the maximum transporter range, in fact.
There's a free pi right below at rdata:0079A150 dq 3.141592653589793
Remember that these are 8-byte doubles, not common 4-byte floats. So you can fit one double variable in that double pi.
-
Another thing I'd like verified is the OP cloak seeking weapon damage reduction chart. Dave said it was "SFB specs", but I had to assume that. We would need the % damage reductions for tractored and non-tractored ships.
It'll look something like this and when found SFC-CE/EAW can be brought up to specs:
_Cloaked Ship Status_ _Chance of Normal Damage_ _Chance of 1/2 Damage_ _Chance of 1/4 Damage_
Non-Tractored 33.3% 33.3% 33.3%
Tractored 66.7% 33.3% 0%
Found the function in OP today. Hidden in plain sight. Its associated string is tCloakSystem::mDetermineCloakSeekingWeaponDamageModifier
d6 | Multiplier
-------------------
1 | 1.0
2 | 1.0
3 | 0.5
4 | 0.5
5 | 0.25
6 | 0.25
7 | 0.0 (I don't know if this value is ever used. It could be there to handle unexpected values.)
There is probably another function for ships that are tractored. I don't see a subtraction of 2 from the die roll in this one, but that -2 would do it, resulting in a 33% chance of half damage.
-
Good find. They may not have bothered with the tractor table, but keep looking.
-
EffectiveRange = (TrueRange*2)+5
That's the location of the example you previously gave?
Yes.
Here's the doubling of range: text:0043857A fadd st, st
The "fadd" means add the range stored in the "st" register to itself. In other words, multiply by two. This would be tricky to modify however. There's no room to put in a larger instruction, like fmul. The fadd only uses two bytes. OP's code is, unfortunately for us, tight.
The 50.0d in my previous example is added to the doubled or non-doubled range. If you increased it to 90.0d, a cloaked ship would be incredibly resistant to damage. You'd have to flash it with a mine to do substantial damage, except for Ph-4s and good-luck Photons.
-
Good find. They may not have bothered with the tractor table, but keep looking.
Easy to test in that almost forgotten thing called multiplayer. If a Range-1 Plasma-F ever does 5 damage, then your suggestion is correct.
-
All this wonderful stuff you peeps have unearthed has me intrigued, the fire vs cloaked ship table (in OP only) was hiding in plain sight.
With all this focus on the client, has anyone thought of applying the same kind of endeavor to the server kit?
Who knows what magic could be retro-fitted.
-
The Dynaverse-related stuff seems to be full of references that go nowhere other than to useless descriptions. If someone wants to dive into that aspect of the game, that would be great.
Today I tried for 3 hours to find the function that discriminates between Nuclear Space Mines and regular t-bombs, and assigns the appropriate damage. It should be an easy thing to find, but it hasn't been. There should be a function with a fork to a 10 or a 35 and a reference to the words "mine" or "transporter bomb". I did find the one that prints the NSM detonation message, but that has no link to damage.
Progress is made one byte at a time.
Edit: I found the t-bomb cursor limit. Once that is increased, another variable can be adjusted for a very long-range t-bomb attack. This doesn't affect hit & run raids, which is controlled separately. So you can have Range-3 Hit&Runs and Range-8 t-bomb attacks if you so choose or vice versa. You can also adjust the distance from the minelayer at which a mine/t-bomb becomes hot. Look for 2.672 tomorrow.
-
Code that handles such intercepted function calls, events or messages is called a "hook".
"h" could also be a prefix for "handle", which I noticed today in IDA. I don't know much about them either.
-
The pseudocode (F9) option of the Hex Rays plugin for IDA seems to be quite useful. With it a pile of mov and push commands becomes a readable if statement or loop. This should in theory make it much easier to find stuff from now on.
@Adam, I haven't given up on phaser coloring/texturing, in principle color hex codes should stand out much more clearly when you come across them if you are looking at pseudocode. Eliminating irrelevant references and functions to narrow down a search also becomes easier.
-
Another thing I'd like verified is the OP cloak seeking weapon damage reduction chart. Dave said it was "SFB specs", but I had to assume that. We would need the % damage reductions for tractored and non-tractored ships.
It'll look something like this and when found SFC-CE/EAW can be brought up to specs:
_Cloaked Ship Status_ _Chance of Normal Damage_ _Chance of 1/2 Damage_ _Chance of 1/4 Damage_
Non-Tractored 33.3% 33.3% 33.3%
Tractored 66.7% 33.3% 0%
Found the function in OP today. Hidden in plain sight. Its associated string is tCloakSystem::mDetermineCloakSeekingWeaponDamageModifier
d6 | Multiplier
-------------------
1 | 1.0
2 | 1.0
3 | 0.5
4 | 0.5
5 | 0.25
6 | 0.25
7 | 0.0 (I don't know if this value is ever used. It could be there to handle unexpected values.)
There is probably another function for ships that are tractored. I don't see a subtraction of 2 from the die roll in this one, but that -2 would do it, resulting in a 33% chance of half damage.
It's been a while, but at one point I seem to remember their being modifiers that were applied to this roll in SFB in some instances. Can't remember what they are now - natural ECM maybe?. Possibly even regular ECM...
That might be something that changed between edition updates in SFB, and I don't have a rulebook available at the moment, but it as I said this rings a bell...
-
There is reduced damage due to ECM in SFB (and presumably SFC). The cloak chart is supposed to supplant that chart.
-
There is reduced damage due to ECM in SFB (and presumably SFC). The cloak chart is supposed to supplant that chart.
I am aware of the reduced damage from ECM, although that's usually handled via to hit modifiers as I remember (and of course adders to the phaser chart roll, with results over six being carried to the next column(s) '6' result.
But I remember specifically the Cloak chart having the 7+ column entry, with some modifiers applying to it. Again, it's been decades since I played SFB last, so I'm working off of memory here. Our group had a discussion about this very thing, and as I said it may pertain to an earlier edition of SFB.
-
The chart is the Fire Vs Cloak table...from SFB, at least my copy of the ruleset.
Have zero idea what the 7 is on the table, perhaps to acct for "unexpected value"?
Basically, fire at cloak process was a 2 step affair
1) fire at cloak adjusted range = Real Range * 2 + 5 while cloaked, during fade in, it was Range + X , with X being the number of impulses of the fade in or out.
2) if a hit was scored, that hit was rolled on the fire vs cloak table to determine the true damage scored; the cloaked entity had to be fully cloaked, no fade in/out.
That concludes the stripped down version of the cloak rule in SFB.
-
He's right, that is the damage correction vs DF and seeking weapons, but the 7+ slot can only come into play using one of two systems that the player is supposed to choose from during Fade In/Fade Out combined with an optional rule that allows the tracking ship to gain experience in firing after a few successful shots in the dark. It's not clear yet if they used this optional rule (I doubt it though as it is waaaay more complicated than using system 2 in the above description), so it is unclear why that entry exists.
-
I have a vague memory of testing the fade cycle in OP - many moons ago - I think we validated the fade in / out expected results based on the SFB standards. But that was a long time ago.
I do recall some other weirdness w/ cloak, that might have been EAW and fixed in OP.
-
Adam, I've managed to make some of the Klingon disruptors in SFC3 to use the Romulan disruptor texture (we're in luck: the textures are assigned per individual weapon, not per weapon class). When you search the strings list for the appropriate texture of a weapon you can trace the functions all the way back to one giant function. This giant function is sub_41C726 in SFC3, I believe the equivalent function in SFC:OP is sub_41C271. In pseudocode view (F5) the giant function becomes a neat list of if statements which will for example go something like "if a5 >= 20 then call function 123, if a5 >= 30 then call function 456", here a5 is some numbering system for all the weapons (plus tractor beam and possibly some other effects) in the game and functions 123 and 456 (fictitious names of course) are functions that lead to other functions which lead to other functions, etc... and ultimately point to a texture. There is some numbering before functions like 123 and 456, possibly indicating pixel coordinates on the texture, but it's more likely that's done in one of the intermediary functions.
Updates will follow...
P.S. I can't believe this weapon texture thing is turning out to be less hard than getting the damn DD and BC ship symbols to show up on the map...
-
Another vague memory of days gone by; IIRC, all the wpn gfx were bound to the textures, there were some mods to all of them by modifying the texture directly, I messed w/ the Plasma and couple other folks did others, including a rather nice non continuous phaser, like a string of B B 's.
Could one clone the orig texture, rename, edit to the color/texture one desired, edit new weapon string to point to the new texture instead of the old (or the code equivalent) and still work?
If this is the case, new weapon textures could be used side by side with the stock ones.
-
Another vague memory of days gone by; IIRC, all the wpn gfx were bound to the textures, there were some mods to all of them by modifying the texture directly, I messed w/ the Plasma and couple other folks did others, including a rather nice non continuous phaser, like a string of B B 's.
Could one clone the orig texture, rename, edit to the color/texture one desired, edit new weapon string to point to the new texture instead of the old (or the code equivalent) and still work?
If this is the case, new weapon textures could be used side by side with the stock ones.
Sort of... Some weapons independently point to the same texture so the string "assets/textures/weapon" simply appears twice inside the .exe. The ion cannon and shield inversion beam in SFC3 do this and there it's trivial to decouple them from each other. Sub_41C271 in SFC3 points to chains of functions that ultimately lead to a texture, you can change these and for the Romulan and Klingon disruptors you could in theory do this for every individual weapon (eg. R-Disruptor IIIF), but the coordinates on the texture may be off, I think the Federation phasers might be an exception, their function chains point to the phaser1 texture but in the game the phasers only react to changes in the fx1 texture. Still working on this though.
-
Hmmm, when I set the link for fed phasers from the phaser1 to the tachyon texture it actually starts using that texture, even though previously it would not react to editing of the phaser1 texture. I suspect the fx1 texture is some kind of default for when a weapon texture is not accepted for some reason, or that the function chain for the fed phaser tells it to overwrite the phaser1 texture with its own orange color. Very strange, but I will keep investigating, if I can get the phasers to accept another texture I can get my polaron beams (by cannibalizing the slow phasers). If it turns out I have to redefine the sub_41C671 function somewhere else I might as well turn some (the slow) Romulan disruptors into Cardassian disruptors while I'm at it.
-
Ok, I now have proof the color of a beam weapon is determined (or referenced) somewhere in the function chain between the reference to the texture and the giant function (sub_41C726). I've been able to set some of the phasers to use the myotronic beam function chain, this works, but it also means they will use the beam color and short animation duration of the myotronic beam. However, it should be possible to create a new function chain in an empty spot and make it a copy of the normal phaser or Romulan disruptor chain and have it point to a different texture so that you can have a unique texture and have the beam properties of the phaser or R-disruptor (or decipher the beam duration length setting of the myotronic beam). One problem that remains is that the phasers are ranked from type IXS through type XIIIF, so by just changing the texture of the first 2 phasers both type IXS and type IXF will be affected, which means I can't separate the slow phaser from the fast phasers, of course I know I can change slow phasers into fast phasers (which I was going to do anyway), but I'm not sure how to create a long range starbase phaser with the alternative texture (I don't think I can just reverse the order of the range tables for phasers, but I hope I'm wrong). One extreme way to solve this would be to recreate sub_41C726 in an empty spot and try to change the if-statement list in it (very hard because it's a huge function and it's very hard to create new if-statements).
Long story short: all individual weapons can be given new textures, I've basically cracked the process, but it takes a lot of work.
-
Yes, you start by following the function chains. Find a weapon texture, go to the function that references it, then go to the function that references that function, this second function is usually (sometimes there is a third in the chain) the one that gets referenced in the giant function, sub_41C271 in SFC2:OP. For SFC3 I made a list of these functions, the weapon they belong to, and where in the giant function they're referenced. Now look at the giant function in pseudocode mode (F5) and you should see a list of "if some variable has some value then call a function", the variable is the number of the weapon. You can change which weapon calls which function chain. You can usually get around the hardcoded colors by editing the texture image in the assets/textures folder, sure the hardcoded color gets mixed in but you can compensate for that most of the time, otherwise just use the function chain of another weapon that has a hardcoded color that you can work with (for example if you want to turn a blue phaser into an orange phaser I don't think there's any color you can paint the texture that would mix with the hardcoded blue to produce orange, but if you use the function chain of a white phaser you can mix that with an orange painted texture).
Note: some weapons will be grouped together in the giant function (though I think this is much less common in the SFC2 games than in SFC3), to separate them you have to rewrite the giant function, which is very hard.
-
7 hours to find two new hotkeys. :buck2:
The Shuttle Conversion hotkey is something I've wanted for a while. (Still need to choose the shuttle type.)
Still looking for a hotkey to "Send Marines"... Found it. The Capture panel has to already be open for it to work.
It's above AVtState_HotKeys@@ in a map format. 4-byte "key" followed by a 4-byte "value". The keys increase sequentially and are associated with a slot in the HotKey selection menu. The values are haphazard.
Moderately useful values discovered by trial and error:
13 01 01 00 = Shuttle Conversion Panel
7A 00 01 00 = Send All Marines to capture
Edit: The "Select All Weapons" hotkey doesn't work as I thought it did. It's the same as Red Alert.
The first key-value pair description begins at "data:00B33EB0 dd offset aHkadjustspeedm"
Which is put into this map, starting here:
"data:00B33FE0 HK_Number dd 10004h" // the key for increase speed
"data:00B33FE4 HK_Value dd 1000Eh" // the value it reports (modifiable)
-
Worked on sprites today...
Fixed the Lyran Plasma Torpedoes. A good guess did the trick.
Bad data:
PlasF = [f..\f..]f..^f
PlasG = `f..af..bf..cf
PlasS = ef..ff..gf..hf
PlasR = jf..kf..lf..mf
It should be:
PlasF = jf..kf..lf..mf
PlasG = ef..ff..gf..hf
PlasS = `f..af..bf..cf
PlasR = [f..\f..]f..^f
Quicktips were inverted, too.
This fix, and the Klingon Defensive Plasma quicktip fix, will be included in 2.673.
-
Another thing I'd like verified is the OP cloak seeking weapon damage reduction chart. Dave said it was "SFB specs", but I had to assume that. We would need the % damage reductions for tractored and non-tractored ships.
It'll look something like this and when found SFC-CE/EAW can be brought up to specs:
_Cloaked Ship Status_ _Chance of Normal Damage_ _Chance of 1/2 Damage_ _Chance of 1/4 Damage_
Non-Tractored 33.3% 33.3% 33.3%
Tractored 66.7% 33.3% 0%
The "Tractored" row is not used for direct-fire weapons.
I fired 30 Photons into the hull of a cloaked & tractored Romulan DN at range 0.40. I had 6 ECCM. The DN showed zero ECM.
12 Photons did 2 points each (25% of standard yield). The rest did either 4 or 8 points each. There appears to be no active code in single-player mode to modify damage in a special manner if the target is tractored. Maybe multiplayer is different, but I have my doubts after a battle with Moog's R-WVL on Gameranger yesterday.
Fusion beams did even worse. Sometimes doing only 1 point of damage, which should be impossible. The minimum should be 4 points at that range (or 2 points if using the first row of Corbomite's chart).
-
Hmm, well then you're on your own in finding the whole system. Tractor beams spilll over into many other systems. It'll be interesting to see how they tied it all together, or not. Good information to know though.
-
More data indicates that the range remains effectively doubled even while the cloaked target is tractored.
30% (7/23) of my Fusion Beams did 1 point of damage at a true range of 0.9. None did more than 8. The effective range is assumed to be 1.8, resulting in a serious loss in damage potential compared to range zero. And a smart opponent will drop a WW for a +2 shift which also applies to weapons before they even reach the cloak chart. So trying to flash&blast a R-KE with OL Fusions just isn't going to cut the mustard, unless you have at least twice as many mines as the King Eagle has shuttles (or the Romulan captain falls asleep from boredom).
One would think that a tractor beam would negate range-doubling. At least the additive adjustment of +5 isn't in effect.
(This post applies only to SFC:OP.)
-
The cloak chart is supposed to trump any ECM from any source. That needs to be confirmed.
-
The cloak chart is supposed to trump any ECM from any source. That needs to be confirmed.
Just to be clear, ECM is supposed to be effective during Fade Out to try to keep the tracking unit from retaining a lock on, but once you are cloaked all damage goes through the cloak chart.
As far as the range thing, it seems they might have only read the part about Tractor Beams negating the 5 hex range penalty and forgot to read the beginning of that section which tells you what the effects of a voided cloak are and that apply to everything listed in that section.
-
Tar,
Have you located how the AI allocates power to shield.
I don't know how the AI does anything. The stuff I've tested applies to all players, and thus the AI has no choice but to follow the same rules.
I could look for the shield efficiency as an array of floats...
Number of shields that are reinforced : multiplier
1 : 1.0 ; 100% efficient, but only applies to one shield
2 : 0.9
3 : 0.8
4 : 0.7
5 : 0.6
6 : 0.5 ; only 50% efficient, but applies to every shield
Changing this wouldn't help the AI with energy management. One idea that might work is to write a mission script (let's call it MaulerFest.scr) that prohibits the AI from using shield reinforcement. The AI might be able to recharge its batteries, unless it flies around at 28 sniping with a few phasers. You also probably need a custom shiplist that exchanges warp power for impulse power on Mauler ships.
-
The cloak chart is supposed to trump any ECM from any source. That needs to be confirmed.
I suppose there could be a penalty for Erratic Maneuvers.
I am unable to easily test this in single-player mode. The AI seems programmed to not use ECM while cloaked...but I just fought a K7RB that used 2 ECM while cloaked -- so it's unpredictable.
I tried giving the Vulture a Stealth Bonus, but this didn't do anything vs direct-fire weapons. Range-1 Photons would always hit the tractored & cloaked Vulture despite its "stealth" of +2, +4, or +6.
I also gathered data on seeking-weapon damage in the same scenario. Out of 15 Plasma-F's, five of them did only 5 damage. What chart are they supposed to use, Corbomite?
Edit: I did some searching on this forum, and we already had this discussion 12 years ago. Dave Ferrell said all weapons are subject to the cloak chart. And "all" includes everything...except the ESG which is neither a direct-fire nor seeking weapon. He never said that an engaged tractor would grant any benefit other than the ability to launch seeking weapons.
We can modify OP's cloak chart. But the chart is working as Taldren intended. The problem, if there is one, is that the player who successfully anchors a cloaked ship is still highly penalized -- all weapons have a 33% chance of doing quarter damage and a 33% chance of doing half damage. Now if you anchor something with a D5D, all those Type-IV drones still hurt at 24, 12, or 6 points each, followed by a scatterpack threat. But if you anchor a King Eagle with a G-CC, your two Plasma-Gs might knock down a shield with good luck. With bad luck you do 10 points, which seems broken to me. Granted, the R-KE is a good ship and has a BPV advantage over the G-CC, but the CLF, CDD, and BC are not its counterparts. The closest would be the CA+, I suppose.
A protective cloak is good. It just seems too good a deal for a handful of ships in certain circumstances. But ordinary ships, like the R-BH, WE, and KR aren't dominating because of the latest cloak implementation in OP. Again, the usual suspects are oddballs like the KVL and maybe the WVL.
-
I also gathered data on seeking-weapon damage in the same scenario. Out of 15 Plasma-F's, five of them did only 5 damage. What chart are they supposed to use, Corbomite?
Edit: I did some searching on this forum, and we already had this discussion 12 years ago. Dave Ferrell said all weapons are subject to the cloak chart. And "all" includes everything...except the ESG which is neither a direct-fire nor seeking weapon. He never said that an engaged tractor would grant any benefit other than the ability to launch seeking weapons.
As it should be. All weapons use the same chart (except the ESG). ECM is the one where the charts are split. As I said, Tractor rules are complicated and intertwine with many systems. Dave was working alone and probably didn't have time or missed it. It'd be nice to get it in there, but that may be impractical with the tools you possess.
As far as the AI and batteries, you would need to raise (or place) them higher in the default power priorities to improve their performance; at least one higher than shields.
-
All weapons use the same chart (except the ESG). ECM is the one where the charts are split. As I said, Tractor rules are complicated and intertwine with many systems. Dave was working alone and probably didn't have time or missed it. It'd be nice to get it in there, but that may be impractical with the tools you possess.
In SFB, what is the effective range to a cloaked ship that is tractored? I'm sure that the doubling penalty is removed because you've obtained a lock-on -- that's what allows you to launch plasma, drones, and suicide shuttles. But is the +5 range adjustment still in effect for direct-fire weapons?
If a cloaked ship is flashed (but not tractored), is the +5 range adjustment temporarily suspended?
-
Fixed the Mirak Hit&Run Pause button tonight. All races can toggle theirs via a new hotkey. The hotkey only works if the marine panel is already active. The pause button will not visually change to an "!" unless you refresh the marine panel. But it works -- press the hotkey and the raid occurs.
Psuedo Plasma can be fired via a new hotkey. The specific torpedo or torpedo group must be selected first.
A regular hotkey must be sacrificed however for each of them. Perhaps "Yellow Alert" and "Turn All Weapons Offline :huh: ". These are not things I usually need to do in the heat of battle. The unexpected hotkeys aren't yet sticky though. They must be set each session, which isn't a big deal because its just a few keys. If you forget to do so, the game will load the default assignments for them, but it honors all your other key assignments.
-
Quick note:
In SFB, Erratic Maneuvering adds to a ship speed while it is cloaked, for lock-on purposes. Since it (normally) costs 4 or 6 points of movement for EM (it's been a while, thinking it's six), you'd add 6 to the ship's speed while EM'ing. Lock-on chances have two components: range and speed. Also, if you HET while cloaked, add 5 to your speed for lock on purposes.
Any time a ship changes it's speed or the range bracket changes in such a way to improve the chance of lock-on, a new lock on roll is made. And if I remember correctly, the doubling went away if you locked on.
Dunno how much of the above calculations went into SFC, but nonetheless I felt the need to share what I remembered about this.
-
You peeps may require me to unearth the ruleset...IIRC, all voids of cloak required a lock on check or any change in speed etc, if you locked you could fire etc at true range though all fire was parsed through the cloaked table even if tractor lock was established
-
All weapons use the same chart (except the ESG). ECM is the one where the charts are split. As I said, Tractor rules are complicated and intertwine with many systems. Dave was working alone and probably didn't have time or missed it. It'd be nice to get it in there, but that may be impractical with the tools you possess.
In SFB, what is the effective range to a cloaked ship that is tractored? I'm sure that the doubling penalty is removed because you've obtained a lock-on -- that's what allows you to launch plasma, drones, and suicide shuttles. But is the +5 range adjustment still in effect for direct-fire weapons?
A Tractor completely voids the cloak, including the +5 range adjustment. In this case the damage will be calculated on the normal/ECM charts. Cloaked ships can still generate ECM, even though it doesn't help while cloaked, so the voided cloak would be ignored in favor of any EW shift. Cloaked ships cannot generate ECCM as that would require Active Fire Control. Since all the cloak penalties are still in effect for the cloaked ship, it can't use it. It may, however, allocate points to ECCM in anticipation of decloaking during that turn and get the benefit of it after Fade In completes.
If a cloaked ship is flashed (but not tractored), is the +5 range adjustment temporarily suspended?
No, only the range doubling is suspended for that impulse.
Fixed the Mirak Hit&Run Pause button tonight. All races can toggle theirs via a new hotkey. The hotkey only works if the marine panel is already active. The pause button will not visually change to an "!" unless you refresh the marine panel. But it works -- press the hotkey and the raid occurs.
Psuedo Plasma can be fired via a new hotkey. The specific torpedo or torpedo group must be selected first.
A regular hotkey must be sacrificed however for each of them. Perhaps "Yellow Alert" and "Turn All Weapons Offline :huh: ". These are not things I usually need to do in the heat of battle. The unexpected hotkeys aren't yet sticky though. They must be set each session, which isn't a big deal because its just a few keys. If you forget to do so, the game will load the default assignments for them, but it honors all your other key assignments.
Yellow Alert yes, All Weapons Off, no. All Weapons Off is good for rope-a-doping and is better than Yellow Alert since it doesn't shut off your EW or Shield Reinforcement. I'd give up Orbit before I'd give up that one. Unfortunately, Green Alert is used in some campaign missions IIRC, so that's out. All the HET hotkeys except Random Angle and maybe 180° About could be used without much loss I think since they are on the MFD anyway.
Quick note:
In SFB, Erratic Maneuvering adds to a ship speed while it is cloaked, for lock-on purposes. Since it (normally) costs 4 or 6 points of movement for EM (it's been a while, thinking it's six), you'd add 6 to the ship's speed while EM'ing. Lock-on chances have two components: range and speed. Also, if you HET while cloaked, add 5 to your speed for lock on purposes.
Cloaked ships can't use EM. They may use it during Fade In/Fade Out. They must cease using it before the Fade Out is complete and before the roll to retain a Lock On is performed.
The formula to retain a Lock On is:
P = S - (EW adjustment) - RF + SF - 4
where:
P = Probability of retaining Lock On
S = Sensor ratring of the ship trying to Lock On
EW = Electronic warfare adjustment
RF = Range adjustment factor (different chart)
SF = Speed adjustment factor (different chart)
The formula to reaquire a Lock On, or gain a Lock On to a ship entering the senario cloaked is:
P = S - (EW) - RF + SF - 10
But only a scout or scout assisted ship that was very close to a fast moving cloaked ship even has a chance of making that roll.
-
You are likely correct as far as the more recent rules are concerned. There was a lot of addenda (errata was considered too strong a word) back in the early SFB days, and I remember swapping out pages on multiple occasions in my Commander's and Captain's Edition binders. The EM thing may have been one of those things that changed during the addenda days, possibly more than once...
Our focus r.e. the lock-on roll was using T-Bombs and such to 'expose' a cloaked ship, and then trying to retain the lock on, at which point things like speed and proximity became a very big deal. There are other ways to 'flash' a cloaked ship as well. I'd be curious as to what Taldren was able to bring across to SFC r.e. the anti-cloak tactics. It sounds like Tractors aren't a 100% translation. Taldren may have had their reasons for this, there are a few things that I think SFC did right when they diverged from the rules a bit. Hex/turn based games don't always translate well into real time with no hexes.
BTW, I've also played the miniature rules for SFC, and I actually prefered it over hexes. Other than the long-ass games of course, but those happened regardless of which version you played (hex vs. hex-less).
I jumped on board SFB when the first boxed edition was released. I missed out on the pocket edition, but I did buy the 'pocket format' expansions. Can't remember what the big change was between those editions and the Commander's edition, which I think involved the Hyrans or something... and if I remember right the Andros were throttled back a bit between the pocket expansions and the Commander's edition.
It's been a LOOOOONG time since I've stuck my nose in an SFB rulebook though. SFC cured that tendency... I don't think I've even looked inside an SFB rulebook since SFC1 came out. My rules are buried in storage elsewhere currently, and aren't readily accessable to me.
Federation and Empire is another story. I was following that on the ADB boards for a while, although I stopped following that game as well a couple of years back. There's a part of me that still prefers the Federation Space game, although F&E was an interesting game as well that our group played a few times (don't think we finished that game very often though, people would get busy or whatever) although I did play through quasi solitaire a few times to brush up on my tactics. World War I in space is the term I've often heard used in my circle about F&E...
-
A Tractor completely voids the cloak, including the +5 range adjustment. In this case the damage will be calculated on the normal/ECM charts. Cloaked ships can still generate ECM, even though it doesn't help while cloaked, so the voided cloak would be ignored in favor of any EW shift.
If a cloaked ship is flashed (but not tractored), is the +5 range adjustment temporarily suspended?
No, only the range doubling is suspended for that impulse.
Thanks. This is the information I needed.
All Weapons Off is good for rope-a-doping and is better than Yellow Alert since it doesn't shut off your EW or Shield Reinforcement. I'd give up Orbit before I'd give up that one. Unfortunately, Green Alert is used in some campaign missions IIRC, so that's out. All the HET hotkeys except Random Angle and maybe 180° About could be used without much loss I think since they are on the MFD anyway.
Orbit actually works around planets. I thought I'd surely crash into the planet, but it does a good job of maintaining a certain altitude of about 10, as Adam mentioned.
How about the hotkey for "Swap Displays"? I've never used that one. And do we truly need a hotkey for "Self-destruction"? It takes less time than Zero, Zero,Destruct...Zero.
-
Orbit works around anything. I've used it to orbit moving ships. I've also used the Self Destruct hotkey, though not often. If you are trying to time your explosion to happen on top of another unit, it comes in handy.
-
A Tractor completely voids the cloak, including the +5 range adjustment. In this case the damage will be calculated on the normal/ECM charts. Cloaked ships can still generate ECM, even though it doesn't help while cloaked, so the voided cloak would be ignored in favor of any EW shift.
This is in error. I reread the entire section and no matter what the status of the cloaked ship you are supposed to roll on the Fire Adjustment Chart for damage adjustment and ignore the ECM shift. A tractor lock on the cloaked ship gives the tractoring ship the true range for firing purposes, but damage still has a chance to be reduced. My earlier chart showing different damage values for different conditions is wrong. I can't even remember where I got that information.
For DF weapons, the effective range is used to determine the probability of a hit. This doesn't allow weapons to violate their myopic zones, however.
For phasers, fusion beams and TR beams you use the effective range to determine the damage by the weapon, then adjust on the Fire Adjustment Chart.
For disruptors, plasma bolts, hellbores, PPD's, armed probes and photons you use the true range to determine damage, then adjust on the Fire Adjustment Chart.
For maulers you use the true range only for all aspects and you don't use the Fire Adjustment Chart. Instead there is a 50% chance to do full damage and a 50% chance to miss entirely. This roll is adjusted up or down by the ECM shift. This is assuming the mauler has a Lock On.
Seeking weapons are adjusted by the Fire Adjustment Chart, assuming the weapon has retained its Lock On.
-
Corbomite, I appreciate your research...
I can see why SFB players refer to the Fire Adjustment Chart as the "Misery Chart". Gorn captains must get frustrated when each Plasma-S does a paltry 7 damage after getting punished by an EPT-R to successfully anchor an evasive Romulan ship. Whacking the target with 4 Suicide Shuttles could yield just 20 total damage with bad luck.
I'm checking out CE's cloak now. I like what I see. It isn't as strong as OP's cloak but it is useful. If a Plasma Torp strikes a cloaked ship it never does full damage.
Rough estimate until I find the code:
33% chance of half damage
33% chance of quarter damage (7 for Plas-S, 12 for Plas-R)
16% chance of approx 1/20 damage (1 point for Plas-S, 2 points for Plas-R)
16% chance of zero damage
I suspect the damage potential is being divided by two every time a Plasma Torpedo fails some unknown tracking test. (Edit: Nope. Never does 1/8 or 1/16.)
Missiles seem to be removed if they fail a single tracking test. Only fast missiles have a good chance of hitting a flashed cloaker. They never strike for full damage. Their damage distribution is similar to that of Plasma.
If you do flash & tractor a cloaker, the cloak offers no noticable protection. (It may deactivate automatically.)
-
Side note, I think I will try to locate the Plasmas shotgun variables, 2x, 3x and 5x.
Found them tonight in CE. Op should be similar.
Once you find the Plasma Warhead data array, there should be 4 external references...
.rdata:00A5FC0C aPlasWarhead db 32h ; DATA XREF: isPseudo+1Er
.rdata:00A5FC0C ; getPlasWarhd+11r ...
.rdata:00A5FC0C ; 50 Plasma-R
.rdata:00A5FC0D db 1Eh ; 30 Plasma-S
.rdata:00A5FC0E db 14h ; 20 Plasma-G
.rdata:00A5FC0F db 14h ; 20 Plasma-F
.rdata:00A5FC10 db 14h ; 20 Plasma-I
.rdata:00A5FC11 db 0Ah ; 10 Plasma-D
.rdata:00A5FC12 db 0 ; 0 PPT?
The fourth reference leads to a function that branches to a 5, 3, 2, and 1, which are modifiable immediate integers.
-
Fixed the Mirak Hit&Run Pause button tonight. All races can toggle theirs via a new hotkey. The hotkey only works if the marine panel is already active. The pause button will not visually change to an "!" unless you refresh the marine panel. But it works -- press the hotkey and the raid occurs.
Psuedo Plasma can be fired via a new hotkey. The specific torpedo or torpedo group must be selected first.
A regular hotkey must be sacrificed however for each of them. Perhaps "Yellow Alert" and "Turn All Weapons Offline :huh: ". These are not things I usually need to do in the heat of battle. The unexpected hotkeys aren't yet sticky though. They must be set each session, which isn't a big deal because its just a few keys. If you forget to do so, the game will load the default assignments for them, but it honors all your other key assignments.
The new hotkeys are now sticky. I needed to reassign the defaults.
Swap Display = Launch selected Pseudo Plasma
HET Left = Toggle for Hit & Run raids
HET Right = Shuttle Conversion Panel
I've updated aaStrings.txt to display the correct names on the Hot Key assignment menu. The ability to use these new keys is a pleasure.
-
Any idea what this chart is?
0, 0, 0, 0, 1, 1, 1, 1, 1, 1
0, 0, 1, 1, 1, 1, 1, 2, 2, 2
0, 1, 1, 1, 2, 2, 2, 2, 3, 3
0, 1, 1, 2, 2, 2, 3, 3, 4, 4
1, 1, 2, 2, 3, 3, 4, 4, 5, 5
1, 1, 2, 2, 3, 4, 4, 5, 5, 6
Is it for boarding party combat?
-
Is there any context at all?
-
Any idea what this chart is?
0, 0, 0, 0, 1, 1, 1, 1, 1, 1
0, 0, 1, 1, 1, 1, 1, 2, 2, 2
0, 1, 1, 1, 2, 2, 2, 2, 3, 3
0, 1, 1, 2, 2, 2, 3, 3, 4, 4
1, 1, 2, 2, 3, 3, 4, 4, 5, 5
1, 1, 2, 2, 3, 4, 4, 5, 5, 6
Is it for boarding party combat?
Yes. Did you want it explained?
-
What's the formula for losing marines when being damaged?
One Boarding Party for every 10 internals after ignoring the first forty internals.
-
Any idea what this chart is?
0, 0, 0, 0, 1, 1, 1, 1, 1, 1
0, 0, 1, 1, 1, 1, 1, 2, 2, 2
0, 1, 1, 1, 2, 2, 2, 2, 3, 3
0, 1, 1, 2, 2, 2, 3, 3, 4, 4
1, 1, 2, 2, 3, 3, 4, 4, 5, 5
1, 1, 2, 2, 3, 4, 4, 5, 5, 6
Is it for boarding party combat?
Yes. Did you want it explained?
I found this chart in the code today. It has no obvious connections to anything.
From long ago, I seem to remember that the invader rolls on the chart for every group of 10 marines and a fraction thereof. The defender can take casualties and/or abandon control spaces. I forget how the attacker suffers losses.
Tested some modifications to the chart. Capture can be prohibited in all missions. Some missions crash when a ship is recaptured. Sometimes a player will lose control of his ship and involuntarily disengage after an AI ship is captured.
-
Each side rolls a d6 and then they look on the chart for however many BP's they have in combat and then each side subtracts the number indicated from their troops. The chart goes up to 10 BP's. If you have more than 10 BP's you are supposed to divide your forces into groups of 10 or less and roll a d6 for each group to resolve combat.
-
Hi there,
Has been a while.
Yesterday while talking with Tar, i decided to built a tool for making hex modding more easier. I've worked during this morning on it and is pratically finished. Tar supplied me with the all the Hex he has on the moment
During the day, after checking if it is working like it should, i will release it.
Carlos
-
No, it will work with any version.
You just need to have a text file with the correct hex's offsets and types.
The editor will pick those values on the text file and build a graphical interface for you to edit it.
heres a picture of it:
(http://imagizer.imageshack.us/v2/xq90/537/5Rocsm.jpg) (https://imageshack.com/i/ex5Rocsmj)
-
Here it is.
Use it at your own risk.
http://1drv.ms/1zE7Dvr (http://1drv.ms/1zE7Dvr)
Without any arguments, the editor will try to open "Starfleet2CE.exe", but if you add an argument like in the examples below the editor will try to open and use it instead. Of course, all the addresses in the file "offsets.txt" must have be valid!
"SFC2CE_Editor x64.exe" my.exe
"SFC2CE_Editor x64.exe" "my new.exe"
(The "offsets.txt" file was created and is maintained by Tar Minyatur.)
Carlos Santos
-
Muchas Gracias, Carlos!
Here's an update of the offsets for the upcoming 2.673 (http://1drv.ms/1Bh5slU). It fixes a few of my mistakes.
It works with SFC 2.671, but the following variables are unsupported: PPD hold costs, OL PPD maximum range, Mine activation range, EM cost, T-bomb range, Hit&Run range, and the additive Cloak range adjustment.
It works very well with 2.672, except for the OL Plasma-S charge rate.
Please post any bugs that you find. I can probably fix the data.
Edit: I converted the hexadecimal numbers in the commentary to plain old numbers in offsets.txt. It should make more sense now. I've arranged the entries to alphabetical order more or less.
-
Wow, I am just utterly blown away by this thread. Amazing work!
I had to take the last 9 months off from Dynaverse forums because of starting a new job and had just started dipping my toes back in, and when i first saw this thread I put off reading it until I had time. Holy. Frak. I am still working my way from the beginning so I can follow along (hexadecimal + little endian = very slow for me to comprehend) but I can't hold back any longer.
WWAAAHHHHHOOOOOO!!!!!!!!!!!!!!!!!!!!!!!!!!
Krist on a kracker, this is some of the most exciting stuff I've seen for this game since the first time I learned how to mod the SFC spec file. I've been wanting to understand more of this process before throwing in my pov, adn with d4v1ks' tool I feel like I can catch up a little faster. I just wanted to share my jubilation that refelcts on what Capt Adam and Tar have posted, the child-like glee of the most awesome present from Santa ever.
No, seriously, remember when Calvin was asking Santa for a RPG launcher for Xmas and was always disappointed when he did get it???
Mmwwhhaahaaahaaaa!
-
Seriously, I want to buy you all a drink. Thanks for all the hard work everyone, and keeping this game alive and vital.
-
Here's an update of offsets for 2.673 (http://1drv.ms/1Bh5slU).
I've rearranged the data into a more logical order. It is a big improvement.
This file will work with 2.672, except for the OL Plasma-S charge rate. (I moved that data because it inhabited the least significant 4 bytes of INT MAX.)
2.673 will be released this week, featuring three new hotkeys and some other stuff. I may include an Orion Engine Doubling hotkey. I don't know how to restrict it Orions. Ideally, I'd put a "2" in the variant column of shiplist.txt to permit doubling.
Edit: Download this again. The old one had a couple mistakes that have been fixed. This should show the bugfix on line 1.
-
Hello all,
I've released a small update for the Editor.
Has some improvements.
Now it check the offset's range, size of data, values, and memory overlapping.
I think it is a little faster too.
Etc...
Use at you own risk.
http://1drv.ms/1zE7Dvr (http://1drv.ms/1zE7Dvr)
This update has no offsets.txt
Look for it somewhere under this topic. ::)
Carlos
-
Seriously, I want to buy you all a drink. Thanks for all the hard work everyone, and keeping this game alive and vital.
You are welcome, TAnimaL. If we meet on Romulus someday, you can buy a round of ale for the crew.
-
Today, i found 1 or 2 minor issues in the editor parser, that could make the editor crash while trying to read the «offsets.txt» file.
But already fixed it.
Meanwhile, to allow a more user friendly interface i relaxed a bit the accepted format, and added some new types.
Tomorow will release it.
-
I haven't had time to do more than dload but now, come to think of it, just how does one "add an argument" as you mention a few posts back? "cause I didn't follow your example. Not that it matters until someone releases offsets for OP, III, etc. (pretty please) I'm way behind the curve on everyone else here and won't have time til tazes are done ::)
-
TAnimaL, you could create a batch file and put it in your SFC:OP root folder.
For example, you can use notepad to write this:
"SFC_Editor x86.exe" StarfleetOP.exe
pause
Save this plain text file as OP_Edit.bat
When you open OP_Edit.bat it will load StarfleetOP.exe, the custom argument, instead of Starfleet2CE.exe. Of course, as you noted, it needs the correct offsets.txt too.
-
I found out a bit more about hardcoded weapon colors. Some weapons derive all their color from their textures (example the photon torpedo). In SFC3 the phasers and some other weapons and effects are colored by a set of RGB values, some of these are listed in sub_41C726. Basically you'll see (in pseudocode mode) stuf like "sub_41CFAA((int)&v22, COERCE_INT(0.93000001), COERCE_INT(0.75999999), COERCE_INT(0.1));" (the numbers are rounded 32bit floats, for example 0.1 is coded as CD CC CC 3D at 00(4)1C8E2). So what color does this result in? Let's see: 0.93000001 * 256, 0.75999999 * 256, 0.1 * 256 gives us approximately Red: 238, Green: 195, Blue: 26, this is a shade of dark orange, exactly like we expect of SFC3 phasers.
For SFC:OP the equivalent of sub_41C726 is sub_41C271. In it I found (in pseudocode mode) "sub_41C983(LODWORD(v29), LODWORD(v33), LODWORD(v34));" with the values of the variables listed next to it: "v34 = 1.0; v33 = 0.5; v29=v27 = 0.5;", so this would be Red: 128, Green: 128, Blue: 256 which is a shade of light blue. I have no working copy of SFC:OP test if this codes weapon colors (it seems to be connected to the function chain of the "heavy phaser" object), but I'm pretty sure it does.
-
Ok, the next version of the SFC Editor is available.
I am happy with its current state.
Unless someone finds something wrong with it, is likely to be the final version.
Now you can use it too with other offset files.
I left examples inside the .zip for you to know how to use the SFC Editor.
Have fun! 8)
http://1drv.ms/1zE7Dvr (http://1drv.ms/1zE7Dvr)
-
Thanks again, Carlos.
I like how the floating-point numbers are in purple and the integers are in black.
Good work.
-
I like how the floating-point numbers are in purple and the integers are in black.
Have you tried to change this offset, to see how it looks now?
65FA28: 7c // SFC2CE version // 2.6.7.3
-
Very nice. Red font for ascii characters and blue font for unsigned bytes. Those will be helpful, indeed.
Possible problem with new line. The unsigned bytes are not saved by the editor.
6902D: ub // Capture Enabled = 134 (0x86), Capture Disabled = 135 (0x87) // 134 (0x86)
The Editor writes a null byte to the memory address, not an 86 or 87.
Ideally, the 86 or 87 should always be represented as an 86 or 87. I changed an Intel opcode there, not a countable variable. Converting 0x86 to an unsigned byte 134 or to a signed byte -122 is just asking for trouble.
The following offset entry is what I'd like to see:
6902D: 1umb // Capture enabled = 86, Capture disabled = 87 // 86
The editor would display it as an unmodified byte.
-
Possible problem with new line. The unsigned bytes are not saved by the editor.
(...)
The Editor writes a null byte to the memory address, not an 86 or 87.
Yes, you are right.
Thank you for bringing that to my attention.
In fact the value was not being updated before saving to the executable.
I uploaded a new version (1.2.1) with the fix.
As i touched in that code again i also added big-endian support. So now the Editor should work with both processor architectures (little and big endian).
About, that new feature, i will add it soon.
-
The Marine Combat chart in Community Edition (and probably OP) has the data for the X-axis switched with the Y-axis.
The correct 2D array is 10x6 integers.
Marines
# |-------1d6--------|
1: 0, 0, 0, 0, 1, 1
2: 0, 0, 1, 1, 1, 1
3: 0, 1, 1, 1, 2, 2
4: 0, 1, 1, 2, 2, 2
5: 1, 1, 2, 2, 3, 3
6: 1, 1, 2, 2, 3, 4
7: 1, 1, 2, 3, 4, 4
8: 1, 2, 2, 3, 4, 5
9: 1, 2, 3, 4, 5, 5
10: 1, 2, 3, 4, 5, 6
The flawed chart, rearranged to 10x6, works this way:
Marines
# |------1d6-------|
1: 0, 0, 0, 0, 1, 1
2: 1, 1, 1, 1, 0, 0
3: 1, 1, 1, 1, 1, 2
4 2, 2, 0, 1, 1, 1
5: 2, 2, 2, 2, 3, 3 // 5 boarding parties benefit from this chart...
6: 0, 1, 1, 2, 2, 2 // ...while 6 boarding parties are relatively penalized
7: 3, 3, 4, 4, 1, 1
8: 2, 2, 3, 3, 4, 4
9: 5, 5, 1, 1, 2, 2
10: 3, 4, 4, 5, 5, 6
The average damage of both charts is similar, but the repaired chart removes some oddities. On the high end, a group of ten marines will cause 1, 2, 3, 4, 5 or 6 casualties instead of 3, 4, 4, 5, 5, or 6. Anyway, at least the chart will be working as intended in 2.674. The effects of capture, however, still need a lot more work.
-
Ideally, the 86 or 87 should always be represented as an 86 or 87. I changed an Intel opcode there, not a countable variable. Converting 0x86 to an unsigned byte 134 or to a signed byte -122 is just asking for trouble.
The following offset entry is what I'd like to see:
6902D: 1umb // Capture enabled = 86, Capture disabled = 87 // 86
The editor would display it as an unmodified byte.
Ok, so this morning i took a look into that feature.
It introduces a new type (opcode) and a number base (binary, octal, decimal and hexadecimal).
So if you wish to add an offset with a opcode, base 16, you should write something like:
1234 : 1 op // True (9A), False (BC) or 1234 : op // Opcodes: (78/9A)
(op type use base 16 by default, all the others default to base 10.)
In this case the UI will show the opcode in hexadecimal and only accept an value that exists on the description. The values must be declared there (it makes no diference how you do it), but must be enclosed between parentheses.
So, theres a lot of options right now.
If you people have time, maybe you can test this new version a little, to see if you can discover any bugs, loading and saving diferent types, number bases, rows and columns combinations. As it edits directly your *.exe, you will want to test it!
The format is:
Offset : [[Rows x ] Columns] Type [Base] [ // [Description] [ // [Tooltip]]]
[ ] = Optional arguments
Offset = hexadecimal memory address
Rows/Columns = Must be numbers above 1
Type = b (int8), ub (uint8), c (utf8 char), op (byte), s (int16), us (uint16), u (utf16 char), i (int32), ui (uint32), f (32bit float), l (int64), ul (uint64), d (64 bit float)
Base = 2 (binary), 8 (oct), 10 (decimal, default), 16 (hex)
(op requires a description with valid values, enclosed between parentheses, to work.)
In theory, it should work with little and big-endian machines...
:buck2:
-
Thanks for enabling the opcode type, Carlos.
I found a minor problem...
177EA7: op // Phaser-3 PD vs Non-Plasma, first bracket (0) or other bracket (4) // 0
The type-tester will allow a "3" because it happens to be in the description. I can change Phaser-3 to Phaser-III to avoid the arabic numeral.
Perhaps only values that are enclosed by parentheses should be valid for opcodes, such as (0A, 0B, 0C) or (0, 4).
-
177EA7: op // Phaser-3 PD vs Non-Plasma, first bracket (0) or other bracket (4) // 0
The type-tester will allow a "3" because it happens to be in the description. I can change Phaser-3 to Phaser-III to avoid the arabic numeral.
Perhaps only values that are enclosed by parentheses should be valid for opcodes, such as (0A, 0B, 0C) or (0, 4).
Its a good idea. Yesterday, i don't even had thought in this kind of problem.
So, i added your ideia and fixed it.
Thank you.
----------------------------------------------------------------------------------------------------------------------------
SFC Editor 1.3.3 http://1drv.ms/1zE7Dvr (http://1drv.ms/1zE7Dvr)
I think the program is stable by now.
A new option was added to the format:
Offset : [[Rows x ] Columns] Type [Base] [r] [ // [Description] [ // [Tooltip]]]
[ ] = Optional arguments
Offset = hexadecimal memory address
Rows/Columns = Must be numbers above 1
Type = b (int8), ub (uint8), c (utf8 char), op (byte), s (int16), us (uint16), u (utf16 char), i (int32), ui (uint32), f (32bit float), l (int64), ul (uint64), d (64 bit float)
Base = 2 (binary), 8 (oct), 10 (decimal, default), 16 (hex)
r = Restricted mode. The values are limited to the values enclosed by parentheses in the description.
For example, with this new format, the following 2 lines are equivalent:
1234 : 1 op // (A1, A2, A3, A4)
1234 : 1 ub 16 r // (A1 to A4)
Changes (v1.3.3):
- The way how the UI validates data at the moment is a little different. Values are only validated when you leave the text box (when it loses focus). The application will hold until you introduce a valid value in the box.
- When the UI loads the offsets in the file text, if it finds some problem it will still load, but it will disable that text box (will appear as a grey box). It can happen when you try to load a char (utf8 or utf16) that is not supported (charcodes <= 31), or when you try to load a restricted type with a value that is not declared in the description, or when you try to load an offset out of range.
-
I found a bug with the new version. The first parentheses must be followed by a space, otherwise that adjacent value will hang the application.
Bugged...
06902D: op // Capture Enabled (86) , Capture Disabled (87) // 86
But this is OK...
06902D: op // Capture Enabled ( 86) , Capture Disabled (87) // 86
-
Fixed ;)
ps: I also added 2 new notes to the end of my previous post.
-
Excellent. You've created a great utility, Carlos. Everything seems to be working properly.
P.S. I've updated the offsets.txt for 2.673 (http://1drv.ms/1ww4F09) to take advantage of the enhanced value-checking functions of the SFC Editor 1.3.2.
The file now includes descriptive tabs, such as "Missiles", instead of the number 12 or something.
-
Made a little cosmetic update to SFC Editor.
The purpose was to make offsets' descriptions, in restricted mode, be more readable.
For example, now instead of adding a line to "offsets.txt" like:
0 : ub r // Photon Range (0, 1, 2, 3, 4, 5, 6, 8, 9, 10, 11, 13)
You can just write:
0 : ub r // Photon Range (0 To 13)
And it will force the user to choose a value between those 2 numbers.
Happy modding. :)
-
Please test this Unofficial CE 2.674 Beta.
Attempts to capture fighters should result in this message: "Cannot beam to this target."
All units that have the "NT" special role in shiplist.txt should continue to be immune to transporters.
Try to capture or beam spare parts to and from planets, shuttles, probes, missiles, etc.
EDIT: 2.674 Beta crashes. The AI tries to capture fighters even though I have made it impossible to do so in one subroutine. Another capture function must be involved. I haven't found it.
-
JanB,
So I messed around with sub_41C983. Changing the 04, 08, and 12 to 00's. It made the heavy phasers appears like traditional phasers. But the Phasers colors remained the same. Only the appearance changed to that of regular phasers.
I think you have to edit sub_41C271, but to be honest I've had mixed success with this whole thing it in SFC3 (it doesn't work for all weapons: it worked splendidly on the shield inversion beam but when I tried it on the phaser I changed the shape of photon torpedoes instead), so it's not the whole story.
I solved the problem for my own purposes by exploiting the "BlueLight=1" trick (only exists in SFC3), and changing the coding in sub_41C726 (SFC3's equivalent of sub_41C271) to apply the effect to uneven numbered phasers and the normal phaser effects to the even numbered phasers, this got me 5 blue phasers and 5 orange ones, with both groups having one starbase weapon.
P.S. somestimes the values you have to change are referenced as flt_123456, so they are actually located outsode the function.
-
So, what, now you guys have a cool widget so no more updates?
Some of us were enjoying reading about what you were trying to change!
;D
-
EoJ,
Unfortunately, one gathers the low-hanging fruit quickly. Climbing a massive tree, while nearly blindfolded, to reach the laden branches does indeed take a while.
I am presently vexed by the AI's attempts to capture, which results in an unpredictable, but eventual, hung window. I'd prefer a crash to desktop -- it would be easier to fix!
-
I'm still trying to figure out how to get separate ship symbols on the map for destroyers and light cruisers (or heavy cruisers and battlecruisers) in SFC3, but I'm probably not going to solve that one...
I did figure out how to change slow phasers into fast phasers in SFC3. I found the function that sets the kind of medals each race gets during their campaigns (but you're limited to fed, kling, rom or borg medals). I looked for stuff that could make more than 4 races show up in the vessel library and have more than 4 races be able to buy ship systems and bid on ships during campaigns but I couldn't find those functions.
Oh and I found out how to run SFC3 on Windows 8.1 (you have to download d3d8.dll and place it in the game's main directory, if you then set windowed to 1 in the sfc.ini the game runs under Win 8.1).
I'm winding down my efforts on this, it's taking more and more time to find interesting stuff and I've accomplished most of the things I set out to do when I started hex editing the game (like I said, I probably won't be able to fix the ship symbol thing, and I knew from the beginning it would be next to impossible to add more players or raceslots to skirmish mode or to make fully functioning campaigns for more than 4 races and it turns out I was right).
-
The AI does indeed seem Boarding Party happy. The marines go out (even to fighters, monsters and other non H&R/Capture elegible targets), but I'll be damned if I know what they are doing. I can't remember losing one system to an AI H&R raid... ever. They aren't there to capture either as that would show up in the Security MFD.
-
I'z jus teasin' ya guys!
Keep up the good work!!!
;)
-
E8 = opcode to call another function
E4 24 0D 00 = relative starting address of that function (not including the 5 bytes for this instruction -- E8, E4, 24, 0D, 00)
D24E4 + 5 = D24E9 ; Total displacement
Look for a function starting at +D24E9 bytes (+861,417 bytes in decimal) from the address of the caller.
After that function is called and resolved, the next instruction to be executed will be the line that follows "call sub_4EE92F". I say "and resolved", because the function at +D24E9 bytes will probably call other functions, which call other functions, which call other functions...
-
Adam, I change function calls by copying the oine of the cursor call, then placing the cursor on that line and then edit->patch->program->assemble, copy paste into the window and change the function number, then click ok. This will automatically fill in the correct bytes.
Congrats on the weapon colors, but before you go copying functions, etc... (when you do copy a function you have to adjust most of the calls because the locations will be off) check for crosslinks: for example I got the fed phaser to use the rom disruptor beam shape, but with the phasers' texture and functions, so I could change the color of the fed phaser but then when I played against Romulan ships the moment a Romulan disruptor was fired all Federation phasers changed to the Romulan disruptor color. This was in SFC3 but similar stuff could happen in SFC:OP as well.
-
I noticed in Orion Pirates that a standard (or overloaded) Phaser-X cannot be manually fired at a Plasma torpedo. It isn't a very serious bug, but it is odd.
-
OL Phasers can't be used for PD, but they work on normal setting. I've never tried firing normals manually.
-
Tar, try cycling the PD hotkey between normal and OL after setting the phasers to OL. I've noticed that X-Phasers on normal won't initially fire as PD when set to OL and just turned off once.
-
Tar, try cycling the PD hotkey between normal and OL after setting the phasers to OL. I've noticed that X-Phasers on normal won't initially fire as PD when set to OL and just turned off once.
If a ship exclusively has Type-X phasers, the PD hotkey doesn't activate PD the 1st time. This explains why I got whacked by a few drones recently. The second hotkey press activates PD.
If the ship has a mixture of phaser types, the weapon officer's panel initially shows PD as active for Ph-3 and Ph-G. And the PD cycle therefore makes more sense. ON(except for Ph-X) -> OFF -> ON -> OFF...
I noticed today that the Ph-G2 (like the Ph-X) is unable to be manually fired at plasma torpedoes. These phasers could assist an ally being chased by a Plasma-R, if your ship is at a range of 2 to 8 to the torpedo.
-
Adam, the AI can be prohibited from using PD in OP. I'm sure the function is similar to CE.
-
Adam, I am looking for it now...
...and I repaired the Phaser-G2 damage estimator. The sixth row in the Ph-G2 chart was referenced to estimate the maximum damage instead of the first row. The actual damage hasn't been changed, just the HUD info.
HexEdit 0xE2816: A4 -> 7C
---
Found it.
IDA .text:004E2AAA. This function loads floats to set the maximum range for PD. I loaded a nearby float of zero instead.
Use HexEdit to replace these [values] in StarfleetOP.exe:
0xE2AC8: D9 05 [48 6B] 85 00 -> [CC 6B] to disable automatic PD for Ph-4
0xE2AD0: D9 05 [E0 6A] 85 00 -> [CC 6B] to disable automatic PD for Ph-3/G/G2 vs Plasma
0xE2AE9: D9 05 [E4 6A] 85 00 -> [CC 6B] to disable automatic PD for Ph-3/G/G2
0xE2AF1: D9 05 [9C 6A] 85 00 -> [CC 6B] to disable automatic PD for Ph-2
0xE2AF9: D9 05 [40 6A] 85 00 -> [CC 6B] to disable automatic PD for Ph-1
0xE5E83: D9 05 [A0 6F] 85 00 -> [CC 6B] to disable automatic PD for Ph-X
-
Adam, my heart is profoundly broken. Divorce hurts deeply.
I don't think I'll be tinkering with the game any time soon.
-
Adam, my heart is profoundly broken. Divorce hurts deeply.
I don't think I'll be tinkering with the game any time soon.
Been there (albiet a long while back), not fun...
Anything I say will sound cliche', but definitely keep us Dynaverse guys in mind if you need a spirit boost!
-
Adam, my heart is profoundly broken. Divorce hurts deeply.
I don't think I'll be tinkering with the game any time soon.
That's really tough, sorry to hear it. Like they said, if you need to vent, or blow off steam by blowing stuff up, we're here.
Tell you what, we'll do 5 vs you, you take the DN of your choice and we all fly G2s ;)
-
Adam, my heart is profoundly broken. Divorce hurts deeply.
I don't think I'll be tinkering with the game any time soon.
Been through this recently myself. I won't sugar coat it, it hurts. Don't waste time, hire a good attorney and protect yourself as best as you can. It's going to be a long road but life will get better.
-
Thanks for the support. I feel better after enduring a sleepless night of trembling rage.
-
( hope things are getting better for you Tar)
I have been slowly working my way through this thread and working on the OP side. Thanks to the great notes from CaptAdam (thanks again Adam) I have a partial list of offsets for OP if anyone is interested in them. Things like breaking the speed 31 barrier and changing weapons costs & damage have gotten easier for me, but I'm still a ways from understanding what I'm doing in IDA. I'll keep working on the offsets for OP until I'm closer to what exists for CE, but if anyone's interested to see what I have so far, just let me know.
One thing I was wondering was how we might go about sharing these modified .exes. Any thoughts?
-
Tar had some of his modifications up for download. There is a thread in this sub forum here. IMHO the most important thing right now is trying to get OP working with Win 8.
-
Bumping this because I may be working on this again soon. :)
-
(Tar, sorry I didn't see your note six months ago) I took off checking in here after getting laid off (ironically giving me more free time but the pressure was on and no time to goof off) but I have gotten OP running in Win8.1. Check out this thread
http://www.dynaverse.net/forum/index.php/topic,163393826.msg1123043655.html#msg1123043655 (http://www.dynaverse.net/forum/index.php/topic,163393826.msg1123043655.html#msg1123043655)
Also, I got pretty far along on the hex editing of the OP exe (thanks greatly to work done by CaptAdam). I was almost at a point to share it when I got hung up when I couldn't find everything in OP editing that had been found in CE editing, but I'm mostly ready to release what offsets I have. For example, I discovered that for some reason, the TR beam range brackets in OP are 0-2, 3-4, 5-7, et. al. instead of SFB's 0-3, 4-5, 6-8, et. al., and that special shuttle (WW, scatter, suicide) speeds in OP are controlled by one function, unlike separately as in the CE exe. Over the weekend I'll upload what I've got so far.
-
Bumping this because I may be working on this again soon. :)
Glad to see you active again on your hobbies. Its a sign that you are going well.
Still envy the patience you guys have to discover all the offsets and stuff.
If you ever need some improvement on the editor to make all those discovers more easy to share between all here, just drop a message.
Still love all these bits and bytes talks and the SFC universe.
Peace.
-
I was hoping to include in my "release" a modified OP exe that has the corrected TR Beam brackets, for those interested.
-
I got pretty far along on the hex editing of the OP exe...Over the weekend I'll upload what I've got so far.
Excellent!
-
I will try to incorporate changes into sfc4
-
changing the source i also have the ce source.
-
duplicate ut not copy t the best of my ability,
-
um, I'm not picking on you specifically Exeter, but there are a few people here who tend to respond in threads without, you know, nouns, verbs, proper English grammar, and that makes it hard to understand. Your answer to CaptAdam illustrates that :D
There are the same number of brackets (6) for the OP TR Beams as there are in SFB, so it's an easy fix to correct them.
Adam, you and I might have a conversation about coding the textures and whether it would be worth putting those sections of the exe into the offsets.txt for easy modding
-
i do not have sfb nor am i familiar with it, copyright deniability.
-
I started to giggle when I read your post Adam but realised you probably meant it in all seriousness. :)
There are no pics of TR beams in action because there are no pics in SFB really. There is artwork on the covers, and in the "magazine" Captain's Log there are occasional images but no one (I know) takes these too seriously. I mean, over the years the artwork has ranged from crude sktechs to primitive computer-generated to more sophisticated art, so they're mostly filler. In fact, if I know SFB players, I'll bet there has been more than a few rules arguments that started over something in an image - it doesn't take much to get a "rules lawyer" going.
I'm including a few pictures from covers with Andros, just to give you an idea what I'm talking about. I think your "TRs look like tractors" is as good as an approach as any. Whatever looks cool ;)
-
And usually, it was just counters on a map, unless you had some miniatures around. :laugh:
-
Damn Seeing those SFB pictures of the minis are bring back memories ;D
-
As promised/threatened, here are the offsets I have found for the OP exe. This is not complete but I'd rather not hold back posting this any longer. As I note in the readme, some things are handled differently in OP than they are in CE. For example, I couldn't find plasma-degradation values; you can assign ranges based on type however. And special shuttles (WW, scatterpacks, suicide, Assault) all use the same speed controller, unlike separately as in CE.
Here are CE elements I couldn't find in OP:
- Capture enabling (might not exist in OP?)
- Mines detonation, activation ranges (I haven't tested all of the possibilities yet)
- Max Range limiters on Phasers 1/2/3/4 (might not exist in OP?)
- Point Defense controls - beyond my limited abilities, might be handled differently in OP
- Photon holding as multiple of charge rate (I haven't tested all of the possibilities yet)
Here are CE elements I didn't look for yet in OP
- Fusion (std, OL,SOL) charge rate, total charge
- Hellbore charge rates
- Missile endurances
- PPD hold costs, OL max range limiter
- Tractor engagement range
I also found some interesting things about the TR Beams and the not-as-broken DroD & DroE but I'll maybe start another thread for that.
The attachment "OP_EXE_Offsets.ZIP" is just the offsets. The attachment "SFCOP_Exe_Editing.zip" contains the SFC_Editor1.3.3 program, the offsets and the .bat to load them, but you'll need to place a copy of the StarFleetOP.exe into that folder. Again, thanks to everyone else on this thread for getting it this far
EDIT: small issue found in the offsets, newer versions below
-
I also did a little tweaking to the stock OP exe and placed it in the Library, called "OP_exe_SFB_Normals"
ftp://www.dynaverse.net/sfc2_op/Uploads/OP_Exe_SFB_normals.ZIP (http://ftp://www.dynaverse.net/sfc2_op/Uploads/OP_Exe_SFB_normals.ZIP)
In this exe, I changed anything I found in the stock OP exe back to "SFB standards"
-TR beams used different range bracket values in stock OP than they do in SFB. Fixed to SFB brackets (0-3, 4-5, 6-8, 9-12, 12-18 19-26)
-Proximity Photons changed back to SFB charts to stop the complaining
-Plasma speeds changed back to 32 (except Plasma-X, still 40), same as missiles. You're welcome.
-All "light" weapons for fighter (Disruptors, photons, fusions, Hellbores) changed back to standard damage, not half
This is just meant as an experiment I wanted to play around with. Please please let's not start any sort of digression about "magic" anythings. ::)
-
Thanks for your efforts, TAnimaL.
Looks like there is an address error for the OL Fusion Beam table as viewed in the SFC_Editor. The quicktip info looks good, but the 6x6b chart isn't quite right. It has two columns full of zeroes. All the other charts look good.
I'd fix this myself, but I've forgotten how to do it. It may take me a few days to relearn this stuff.
-
Thanks for the catch Tar, I found that error and fixed it, attaching new versions.
Adam, I didn't see anything in your previous notes re: point defense enable/disable, maybe this is something easier to find in IDA? In HxD it would be impossible to discern one option point byte from another. There was one mention in your notes about P3 range lmitations but I didn't really get it, and I guess I don't really see range limitations as that important. Point defense would be nice tho.
(And if it was somewhere else in this thread, sorry, I must have missed it. Getting close to 33 pages now!)
-
TAnimaL,
From your OP offsets.txt: "397688: 1d // Cloak range x10, added to true range // 60.0"
I don't think this offset is correct. SFC:OP should have a 50.0d modifier. The 60.0d modifier in CE's offsets is used to strengthen Community Edition's weak cloak. I could be wrong, but OP's cloak does not need a +6 range adjustment, on top of the doubled-range effect, which then gets passed to the Misery Chart (which CE lacks).
I'm looking for a 50.0d (double-precision float) value...
I found it. .text:00438522 sub_438522
All seems ok. Cloak effect is range +1, +2, +3, +4, +5, and then range*2 +5.
Decloak is the reverse.
-
Tar
I know by reading a previous thread of mine circa 2003 you stated the Stealth (+ECM) in the shiplist didn't work on EAW, but does it work in OP?
Adam
No.
-
Adam, somewhere there may be a variable's value (0 or 1) that defines an empire as fighter-equipped or PF-equipped. There probably is no value (such as 2, an arbitrary enumeration) that would allow a race to carry both types of attrition units. But Taldren might possibly have coded this capability very early on, before the segregation took place. If so, it would be easy to hex-edit. But not so easy to locate.
Rod O'neal's manipulation of the shiplist may be the most practical way to get a pair of PFs on a Klingon D7C.
-
what is a pf?
-
fast,
turns sharp,
decent offense,
no defense.
a glass cannon
-
what is a pf?
Pseudo Fighter, Like a TNG/DS9 Runabout, Almost a mini, tiny, limited Frigate, Fast Patrol, Corvette like
Whereas a standard fighter is like the fighters seen in DS9, no shields
Hope that description helps
Adam
PF stands for Fast Patrol ship, not Pseudo Fighter. Pseudo Fighter is more of a nickname.
fast,
turns sharp,
decent offense,
no defense.
a glass cannon
Sure, one is, but you usually had twelve or more on the board in a decent sized battle involving them. And they were hard to knock off if used correctly.
-
Adam,
Remember that the donor ships for the Romulan carriers will not get a NSM. It's part of that hard coding I mentioned before.
-
With good reason. Only pirates get engine doubling. It would carry over to the transplant race for the same reason only Romulan ships originating in the Romulan part of the shiplist get a NSM.
-
NSM?
-
That reminds me; someone has to bump NSM back up to 50 pts where they belong. Whomever dropped them to 35 was just a hater :P.
-
No consistency on Taldren's part...
Suicide shuttles do 25, instead of a max of 18, but they consume a t-bomb.
NSMs do 50? Is that right? I never deployed one in SFB. NSMs should only be on old-school Romulan ships, like the BH, WE, and KE. It seems wrong for a K5R or a KRC to have one of these suckers for a huge self-destruction blast.
-
NSM did 50 in SFC1. I was just waxing nostalgic about how much more satisfying the "Nuclear Space Mine Detonated!" message was then. They do 35 in SFB and old Rom hulls get them for free and pretty much any Rom hull can get them as optional equipment, which Taldren just ignored in favor of all ships just getting one if you want it. With the weaker cloak and double internals I agree with that free option (and the 50 pts!).
-
You know, I just realized that we could have had minelayers with captor mines and TBomb/dropped small mines the whole time. ::)
-
Size, just like SFC.
-
Oh My Goodness! Wow! You guys are freaking unbelievable!
I've been gone from this sight for a while (I'd guess a bit more than a year), and I come back and it looks like you've cracked the code! Wow oh wow! It's Christmas in November!
Thanks guys! We still have 6 + computers using Windows XP loaded with our modified version of SFC2OP. We so LAN battles with our modified version (as work team building of course). I'm so excited I can't even think.
I need some help. When I try to run the editor, it keeps saying it can't find the file. TAnimal's notes seem to suggest that I copy 2 lines of text, but I can't figure out where to put the text. Any ideas what i'm doing wrong.
Thanks again guys. This is just SO UNREAL!
Kid Carrson
-
Still can't quite figure out how to get it to work. I'm guessing I'm putting the files in the wrong spot somehow.
KC
-
SFC2OP Standard Phaser Max Ranges
My apologies TAnimal, I found the phaser range limitations after I sent you my notes hence you didn't have them. My fault.
Ph4:
Using IDA Address: 4E3B12 (D8 1D 08 D5 79 00)
flt_79D508: dd 1.0e3 or 1000.0f represented as 00 00 7A 44 (Which is the Ph4 Max Range 100.0)
Using HexEdit Address: E3B12 (D8 1D 08 D5 79 00)
flt_79D508: Same as above but located at 39D508
Ph3/PhG:Using IDA Address: 4E3B1A (D8 1D 8C E2 79 00)
flt_79E28C: dd 1.5e2 or 150.0f represented as 00 00 16 43 (Which is the Ph3/G Max Range 15.0)
Using HexEdit Address: E3B1A (D8 1D 8C E2 79 00)
flt_79E28C: Same as above but located at 39E28C
Ph2/PhG2: Using IDA Address: 4E3B22 (D8 1D 84 7C 79 00)
flt_797C84: dd 5.0e2 or 500.0f represented as 00 00 FA 43 (Which is the Ph2/PhG2 Max Range 50.0)
Using HexEdit Address: E3B22 (D8 1D 84 7C 79 00)
flt_797C84: Same as above but located at 397C84
Ph1/X: Using IDA Address: 4E3B2A (D8 1D 18 82 7A 00)
flt_7A8218: dd 7.5e2 or 750.0f represented as 00 00 3B 44 (Which is the Ph1/PhX Max Range 75.0)
Using HexEdit Address: E3B2A (D8 1D 18 82 7A 00)
flt_7A8218: Same as above but located at 3A8218
Any Questions?
Adam
Unfortunately, these variables are shared with unrelated functions. To overcome this problem, I have isolated the Ph3 and Ph2 maximum ranges.
Just after the variable (150.0f) for the max range of Ph3 (and other stuff) is one of hundreds of 8-byte representations of pi. We can use this "pi filler" to create two new 4-byte floats. One for the max range of Ph3, the other for the max range of Ph2. Then we change the address in the function to read these new variables.
(In IDA, you will find the Phasers' Maximum Range function at .text:004E3ACD)
Using HexEdit, make these changes in brackets:
E3B1A: D8 1D [8C E2 79 00] -> [90 E2 79 00] to segregate Ph-3 max range ; .rdata:0079E290
E3B22: D8 1D [84 7C 79 00] -> [94 E2 79 00] to segregate Ph-2 max range ; .rdata:0079E294
39E290: 29.9f // New! Ph-3 max range; 29.9f = 41EF3333 = [33 33 EF 41]
39E294: 89.9f // New! Ph-2 max range; 89.9f = 42B3CCCD = [CD CC B3 42]
You can choose 160.0f and 510.0f, instead, to keep the SFB max ranges for these weapons. I modified the Ph3 and Ph2 brackets and long-range damage so the combat estimator will be accurate and ECM shifts will continue to be honored.
I've attached what I call "2.5.5.3". It also fixes the combat estimator's computation for the Phaser-G2's maximum damage. HexEdit E2813: 0F B6 80 [A4] 6B 85 00 -> [7C]
Fighters are lethal - they cannot waste Ph3/G shots. And forget about killing a H-DE with drones from far away -- which is something silly you can do in 2.5.5.2.
-
Damn it! I keep getting the Editor cannot find the file.
Well, I've waited nearly 15 years, I guess a little longer can't hurt.
Thanks for all of your work guys. This is incredible.
I'm so looking to tweaking weapons to make the game work cleaner and the AI work smarter.
Any help would be greatly appreciated. It feels like Christmas and Santa's sled just keeps circling the house. Maybe kinda like the Santa in Futurama.
Thanks for any help.
KC
-
Still can't quite figure out how to get it to work. I'm guessing I'm putting the files in the wrong spot somehow.
KC
The batch file may be blocked by your security. Right click the file called "SFC_Editor4OP.bat" and look at its "Properties" on the general tab. Unblock it. Unblock the "offsets.txt", too. These files must be in the same folder as your StarfleetOP.exe.
-
Tar,
Thanks so much. That worked. Woow who! It's Christmas in November.
Thanks and thanks to everyone whose worked on this thread over the past year.
KC
-
EEEEEH!!!! I'm so HAPPY !
Unbelievable! This is so AWESOME!
I can't even comprehend it!
Thanks SO MUCH!
KC
-
The SFC Hex Editing tool is awesome. Just excellent!
I did see one odd chart that it might be wise to have someone check: the default numbers for the Fusion Beam OL Damage chart for OP seems odd. Something just doesn't look quite right on that one damage chart, like maybe the numbers are reversed or something.
Please take a look and pass along any thoughts.
Thanks!
Also, is there a reference to the EGL Lance anywhere?
KC
-
Thanks Captain. My understanding is the ESG Lance currently does 16 points of damage, costing 4 points to charge, out to range 6.99 I believe. I just didn't see it in the editor for possible modification. I'd maybe like to change range and damage.
The Fusion Beam OL damage chart seems odd, like maybe some numbers are reversed.
Thanks
KC
-
Well, there you go. That makes sense.
Any thoughts on that Fusion OL damage chart?
-
Good deal. I'm still in utter awe of what you all have done with this task. The options available are just amazing.
Just incredible!
Thanks
KC
-
Remember that the editor is for SFC CE and not for OP. ESGL is an OP weapon and therefore would not be in the current editor.
Adam
Went away for a few days and there's a few things I want to respond to, but first and foremost, that is incorrect Adam. The offsets I released work with the SFC Editor 1.3.3 if you use the "SFC_Editor4OP.bat" I mention in the offset. Sorry if that wasn't clear. I have a zip that includes the whole shebang, editor, offset and bat, but it is bigger than can be attached to a post. I'll put somewhere to host and link it.
The Fusion charts are correct on my box, let me double check the version uploaded
-
Thanks for pointing out my OP cloak error Tar, I should have been more upfront in admitting I haven't tested all of those offsets and the cloaking formula was one such place. I did assume that OP used the same 60.0 that CE uses but hadn't tested. So the value you found at 438522is teh correct one? I will then update the offset file (as with any other additions/errors).
As Corbo points out, NSMs do 35 in SFB. Call me a purist but that feels right to me, but if that does live in the exe we can add that to the offset list.
Tar, you bring up something important but I believe you are in error about ship explosions. In SFB, there was a formula that one would use to find out how big an explosion a ship would make (based on warp, weapons including mines, etc), BUT, it was complicated (like many things in SFB) and it could be manipulated (add extra mines and tbombs, missiles). This became a HUGE argument (and when you say huge by SFB rule standards, it was an epic fight across bulletin boards and chat sites) and in the new edition of the rules, the formula was thrown out and every ship got an explosion value of x. There is a similar "Explosion Strength" number for each unit in the shiplist so I've assume that this is used "as-is," but can't remember the last time I would have tested that. I can't imagine that Taldren would have gone back to the "old SFB" way, unless of course someone among them was one of those involved in the fight, back in the day... Maybe I'll test that tonite.
For a bit more detail - Adam, in SFB there was an Annex that gave the cloak power cost that was used in SFC. Romulan ships always paid a point or two or three little less than other ships in that class.
I'm still a little confused about the P2/3 range limiting (and someone is going to have to walk me thru using IDA one day, still can't get a grasp on it). As I understand the above - the limitations values CaptAdam found can't be used with the offsets & Editor and exe 2.5.5.2 (because those variables are shared). Using IDA, Tar has made a exe 2.5.5.3 that can put a limitation entry in SFC_Editor; or, the 2.5.5.2 exe can be tweaked by altering the upper range brackets for those weapons. Am I correct?
I'm also confused by your mention of a PG2 computation - there is a separate table for the P-G2 than the P-3
Kid, I think Adam found the range limitations for the ESG Lance, maybe I'll try again to find more about the Lance. (So many things to play with!)
-
is there a chart that shows range/damage for weapons.
-
A weapons wiki thing was made for OP. You can download the .html from Dynaverse.net.
http://www.dynaverse.net/forum/index.php?action=dlattach;topic=163350834.0;attach=18573 (http://www.dynaverse.net/forum/index.php?action=dlattach;topic=163350834.0;attach=18573)
-
I'm still a little confused about the P2/3 range limiting...the values CaptAdam found can't be used with the offsets & Editor and exe 2.5.5.2 (because those variables are shared). Tar has made 2.5.5.3 that can put a limitation entry in SFC_Editor; or, the 2.5.5.2 exe can be tweaked by altering the upper range brackets for those weapons. Am I correct?
The offsets.txt for OP needs to be updated for the SFC_Editor to modify the new variables that I defined in 2.553.
<<Maximum Range
39E290: 1f // New in 2.553! Ph-3 & Ph-G max range x10 // 29.9
39E294: 1f // New in 2.553! Ph-2 & Ph-G2 max range x10// 89.9
Changing these values in 2.552 will do nothing useful. (It would modify data that the application never reads.)
I see no way to properly modify these phasers' maximum ranges in stock 2.552 without contaminating other functions that share the default values at default offsets. You can indeed adjust the Ph-3's range brackets to have a max range of 2.99k (30.0f) in the chart, but a player can still fire a Ph-3 at range 15.0k (150.0f), and never do any damage. The effect on the AI is unknown, but I assume it won't fire if the entire column is full of zeroes.
The charts don't affect the "z" key -- to manually fire a weapon. The max range variables, however, do. They essentially send a signal to the UI, to enable the fire button.
-
Adam, if you adjust the maximum range of a Ph-3, you are affecting a function that modifies planet "PL6" (as well as several other unknown aspects of the game!). There should be only one external reference to a customized variable, otherwise unintended side-effects will be generated.
Control-X in IDA will show all the functions that refer to a specific variable. If there is more than one x-ref, the variable must be left alone. The function should look for a newly created variable instead.
Look at this float:
Ph3/PhG:Using IDA Address: 4E3B1A (D8 1D 8C E2 79 00)
flt_79E28C: dd 1.5e2 or 150.0f represented as 00 00 16 43 (Which is the Ph3/G Max Range 15.0)
It is shared across many subroutines. Only one of them has anything to do with max range. But if you create a new one at .rdata:0079E290, and modify the function to look there, you'll be ok.
HexEdit E3B1A: D8 1D [8C E2 79 00] -> [90 E2 79 00] to segregate Ph-3 max range ; .rdata:0079E290
It used to read IDA 79E28C (the address of the variable that has a value of 150.0f). Now it reads 4 bytes after.
I've attached an image of the shared 1000.0f variable. Many functions read this data. We want to modify only one of them that determines the limit for Phaser-4's. We need to create a new float. Then change the place the Maximum Phaser Range function looks so it can find our new float, of say, 1500.0f, for a new max range of 150k.
I'll post more pictures of the isolation process. I've got to quit tonight though...
-
So, I was correct then Tar, right? :D
If we want to have a) an EXE that can be edited by b) players using SFC_Editor that includes c)phaser 2/3 range limitations for AI, we have to use 2.5.5.3
I did a short test - explosion strength in game uses the value found in the shiplist. For NSM - There is only one float of 350.0 (35x10) and it is not the variable for a NSM. There are 4 floats of 35.0 that I have to test
-
So, I was correct then Tar, right? :D
If we want to have a) an EXE that can be edited by b) players using SFC_Editor that includes c)phaser 2/3 range limitations for AI, we have to use 2.5.5.3
I did a short test - explosion strength in game uses the value found in the shiplist. For NSM - There is only one float of 350.0 (35x10) and it is not the variable for a NSM. There are 4 floats of 35.0 that I have to test
You may use my 2.5.5.3 or create your own 2.5.5.X. I think we need to create a vanilla StarfleetOP.exe with bug fixes, and then we can customize it as we see fit. I've already done this for Community Edition, but it has been largely ignored.
Thanks for the test on explosion strength. My self-destruction comment was about a Romulan that runs into his own NSM and thence pops, adding 35 to the damage caused to any nearby ships.
-
I like the idea of a vanilla OP exe update (2553 works as a name well enough). Perhaps a discussion for that is worth a thread of it's own. It should probably kept to the minimum bug fixes (especially since players can now mod it on their own), like the range limitations for phasers and maybe the "corrected" TR beams range brackets.
This weekend I hope to look for the NSM value and anything I can find on ESG Lances.
-
Have you guys found anything in there that points to how the AI accesses things vs how things are accessed by human input?
-
Have you guys found anything in there that points to how the AI accesses things vs how things are accessed by human input?
Hex Editing the AI's behavior (trajectories, fire-decisions, target selection, energy management, etc. ) is almost impossible. I would need C++ code to attempt to do it sanely. Strat said (after studying the CE source code) that the AI is a crazy mess.
I can, however, alter the AI by changing the rules for all units. If a Ph3/G (a defensive weapon) is limited to range 2.99, the AI's performance is highly improved. If I swap some warp power for impulse power in the shiplist, the AI is better at energy management. It can't frantically zoom around at speed 31, never charging a heavy weapon. Instead, it might max out at speed 22ish and still charge photons/dizzies/etc.
-
The code for ce is owned by dyna, not to be released without frey's ok.
now take eaw, source, eliminate q3, update dx8 and the multiplayer, modify anything we want, it becomes sfc4. sorry so long, but 1 person takes a long time.
-
I can, however, alter the AI by changing the rules for all units.
This is where I have the problem. I was hoping that the firing issues with the AI could be solved independently of human use. We could fix a lot of bad firing decisions that the AI has by limiting their ability to use certain weapons until a better firing solution is presented, but all of that ruins human override capability. If the AI calls could be sent to a unique set of charts though...
-
ai needs more choices, only certainty is weak spot full spread.
-
I can, however, alter the AI by changing the rules for all units.
This is where I have the problem. I was hoping that the firing issues with the AI could be solved independently of human use. We could fix a lot of bad firing decisions that the AI has by limiting their ability to use certain weapons until a better firing solution is presented, but all of that ruins human override capability. If the AI calls could be sent to a unique set of charts though...
I wish ADB had defined the Ph-3 as a range-2 weapon back in 1977. I don't understand how the loss of 0.33 average damage at range 4-8 and 0.16 average damage at range 9-15 is unacceptable.
-
yes, and asking questions like "Why did ADB do that ?" is a quick route to madness, let me tell you. Suffice to say, it's a different type of game, being a boardgame with no "AI" to speak of.
-
A little note that might interest someone: while trying to find the value in OP for NSM (35), I changed the "35" that is part of the chain for "game turns" (...90, 60, 40, 35, 30, 25...). When I changed that "35," which is the time in seconds for speed 7 turns, the game would not speed up past 7. I could toggle back down as far as 1, but it wouldn't go higher than 7. interesting,
BTW, none of the four floats of 35 or the lone float for 350 are the NSM explosion. bummer
-
Well d4v1ks, we do have robot ships already.... ;)
There's also monster rules too but that doesn't really address the issue. In SFB a player can decide to waste firing a P3 at range 9, and there's not that many monsters/robot ships in SFB to worry about. And the rules you mention have a robot ship firing at range 4 or at best distance per turn. our AI is smarter than that, at least
-
A little note that might interest someone: while trying to find the value in OP for NSM (35), I changed the "35" that is part of the chain for "game turns" (...90, 60, 40, 35, 30, 25...). When I changed that "35," which is the time in seconds for speed 7 turns, the game would not speed up past 7. I could toggle back down as far as 1, but it wouldn't go higher than 7. interesting,
BTW, none of the four floats of 35 or the lone float for 350 are the NSM explosion. bummer
The game could store the arabic number 35 as an integer using various byte forms. It can be written as two groups of 16 and then a 3 in hexadecimal form:
1-byte = 23 (say "two three" not twenty-three!)
2-byte = 23 00
4-byte = 23 00 00 00
Hopefully it isn't stored as 23 because there could be thousands of them in the assembly code. "23 00 00 00" can be searched for. There won't be many of these 4-byte (32-bit) integers.
-
I gave up counting the 1-byte "23s" after two dozen, figuring there would be too many; I didn't try (or know to try) 2-byte and 4-byte versions. Most values for damage and speeds seem to be in 32 floats or sometimes 64 floats, do you think one of those others might be it? Hmmm
Edit: I did a search on "23 00 00 00" - there were about 77 of them. :( My understanding of bits/endian/hexadecimal stuff being minimal, should that be reversed in the exe as "00 00 00 23"? Did a search on that too but there were easily 4x as many.
-
As a non-coder, I would say this is why we need to proceed carefully. There are values that can be easily changed thru SFC_Editor, like weapons damage & range charts; this is where most modding will likely happen. There are values that would be useful to change, like the phaser limiters being discussed, but the choices for changing calls or rdirects seem dangerous, so maybe should be kept out of the UI for SFC_Editor?? So if something like Adam's idea for a OP vanilla 2553 exe is created, then there's a version of offsets that would look at the correct places for a value in 2553 that's not in the stock 2552, maybe.
Adam, what effect on weapons did you notice when you changed the top speed? I was playtesting in a exe with a top speed of 50 and didn't notice any, but I wasn't looking for weapon changes either.
-
Tar, when you modify a function to look for an argument in another location you literally append, for example 4 bytes to the EXE itself, and then redirect the pointer to there, right?
For example, if the exe is 1000 bytes long you make it 1004, and then you redirect the offset to that place?
Cause, i don't understand how redirecting something to other address' inside the exe could be safe. How you know that particular offset is not part of something important?
(I'm talking about the perspective of people editing that value in the SFC editor).
I have no idea why Starfleet executables have redundant data for the double-precision float value of PI so frequently! All these data are ignored -- according to the Interactive Disassembler and playtesting. No functions ever read them. Some functions, however, read the single-precision floats for PI to draw circles, calculate circumference, define arcs, etc. If the .exe didn't have any free space, I wouldn't be able to isolate shared variables. Any change to the energy cost of a Plasma-S, for example, would always affect 5 other systems. It would be a hopeless situation. I cannot successfully change the size of the .exe, Carlos. If I did, every pointer would point to the wrong data.
My guess is that the compiler, by design, uses 64-bit PI as easily identifiable "filler" to allow a programmer to modify a program at the Assembly level if the higher level language (C++) just doesn't work as desired. So each 8-byte PI filler gives me a place for two new floats. Then I update specific references to find this new data. Any unknown function will still read the default data and the game will run fine. My method is as safe as possible with the tools I have -- as reliable as modifying C++ code directly. I can make precise changes, but they are always unsophisticated. Essentially, I tell the CPU to read this singly-referenced number instead of that overloaded value. There is no good reason for Photons and Plasmas to share a variable, except to reduce the size of the file, I suppose.
-
I didn't notice any shield=non-existence issues with high speed but I'll run some tests soon. I changed both the "top speed" and "speed gauge bar" to 50, with some modified non-Xships capable of doing that wiht no problem. Some of us, and I think you included, like the "no turns above 31" side effect, although HETs are still possible, as is fighter launching (something not possible in SFB. Well, it is, but the fighters blow up :D ).
Lances - I hoped for something like a mini-chart of "16 16 16 16 16 16" for a damage table, no such luck.
-
Found the logic that controls the Phaser-G2's maximum range. By default, it uses the Ph-2's max range limit. I added an offset to allow the SFC_Editor to assign another phaser's limit to the Ph-G2.
StarfleetOP.exe offsets.txt
E3B0D: op // [2.554] Ph-G2 uses max range of Ph-1 (1C), Ph-2 (14), Ph-3 (0C), or Ph-4 (05) // 14
-
Great job Tar! So, this will be another thing for the "updated" OP exe, since, as I understand it, the E3B0D op you list doesn't exist in the 2552 OP, jes? Cool tho to have that oprion now
(Wow, I really got learn IDA)
Adam, my wingmen and/or AI opponents all stayed @ 31 or below. If my ship A is at speed 45, and I switch control to ship B, ship A slows down to 31 or less. Bit of a bummer but you can create some different tactical situations tho.
-
TAnimaL, this should work for 2.552. I didn't create a new float here. I made the distance of the Ph-G2 jump modifiable, so it can land at Ph-1, instead of Ph-2, for example, and read the default value of 750.0f instead of 500.0f.
But with 2.554 you can customize the max range limits for Ph-1, Ph-2, Ph-3, and Ph-4 and then pick which one you want to share with the Ph-G2. Unfortunately, there is no room in the code to give the Ph-G2 its own independent value.
-
Adam, the logic jump for the Ph-G2 is within a phaser-specific function. It uses a signed 1-byte displacement value, (00 through FF), which means it can be modified to hop a maximum of 127 bytes forward or 128 bytes backward. I don't think it can leave this particular function and enter another, such as an adjacent Disruptor function. There'd be no problem if the jumps were "far" -- 4-byte absolute addresses like 0x001234AB which can reach anywhere in the program.
I like your idea. There could possibly be a way to do it...
-
Lances - I hoped for something like a mini-chart of "16 16 16 16 16 16" for a damage table, no such luck.
I've been looking for it too. Found some curious data in a logical location.
offsets.txt
456410: 1f // ESG Lance bracket, range x10 // 70.0
But I don't know where the range limiter is yet. It should be 69.9f or 69.99f or 69.99d, but it could be 69.98987f or another odd value.
Adam, have you been able to fire the ESG Lance at ranges greater than 6.99k?
-
I'm trying to be a good boy and get some work done today but if I get a chance after lunch I'll try it
-
I have been following this thread an should have the range damage tables from the weapons this week.
-
I'm not sure I follow you Exeter; the range and damage tables we're discussing are the stock ones found in the game, and how to change them. Do you mean you'll have theses tables for your SFC4 project?
-
tables, yes, but not sure what version as the correlation between sfc and sfb
-
Sorry Exeter, but I feel like you're still not being very clear. Would you like the charts? Because the charts used in CE & OP are pretty much the same as each other and usually identical to their SFB counterparts. After all, that's where they came from. Or are you talking about new charts/tweaks that are being discussed? Because most of those are still in flux.
-
not sure where these charts are from, trying to follow to put in the new information
-
Fixed the Suicide Overloaded Fusions in Orion Pirates. They didn't obey the typical range 8.99k limit for overloaded weaponry. They used range 24.99k, like standard Fusions. Now you can set the OL limit at range 0.99k (or 1.99k), and watch AI Hydrans inflict enormous damage with these combat-effective Fusion Beams. The AI seems to love Suicide Overloads...it can actually make them worthwhile with this bugfix.
OP offsets.txt
3A7530: 1f // OL Fusion maximum range x10 // 89.9
DF230: op // Suicide OL range limit: broken (75), same as OL (78) // 75
-
Great find. Fusions are supposed to be scary. Now, really, SOL fusions shouldn't be the go-to for the AI, hence the name "suicide", but still, anything to make the AI more effective.
-
If the Ph-3/G is limited to tractor range, then an AI Hydran will still do decent damage with its Ph-G's until it repels the tractor. Then it will unleash some scary Fusions up close. "Don't overrun a Hydran" is good advice for SFB, but it has been an effective tactic in SFC (vs AI). Going to playtest it now...
Yep, Hydrans are somewhat challenging to defeat. Set the max range of all Fusion Beams to 1.99k and Ph-3/G's to 2.99k. Tried a L-CA+ vs a H-HR+ with 6 Hornet-II's. Lost a few, won a few. Excellent T-bombing is required on the Lyran's part. Disruptors are turned off after one R-15 strike so the ESG can charge. My L-CA+ is toast if I ever let the fighters get closer than 3.0k.
-
Back in the day in SFB, Hydran Command would drop these leaflets on Klingon worlds to discourage thier captains...
-
Let me state something in the hopes of understanding the exe better:
Since the ESG Lance has only one bracket (range 0 - 6), the range limiter is the same value (70.0 which equals range 6). If I changed just the range bracket to less , say 5, it would fire only at range 5 or less. If I changed just the limiter to, let's say 3, the range is still 6 but the AI will only fire at 3 or less. If I then changed the range bracket higher, trying 10, I can fire the weapon out to range 10 but the limiter still stops the AI from firing it above range 3. Do I have that right, or does the limiter prevent the Lance from firing past 3, even if the range has been extended?
Just trying ot make sense of all this, thnx
-
I use the Lance for the Monster Close In Defense System. It makes fighting the Doomsday Machine... interesting.
-
Yes. That will work.
Or you can copy and paste that line into your offsets.txt and thereafter use the SFC_Editor to choose 75 or 78.
-
Okay, Im home, just checked my notes, in HexEdit the address for the ESGL range limitation is DDF32 (D8 1D 1C 09 7A), 7A091C or 3A091C(HexEdit) is a value of 00 00 8C 42 = 70.0, redirect D8 1D XX XX XX, thats all
Adam
Thanks. I've isolated the range limiter. Six functions shared that 70.0f.
You may add this line to your Orion Pirates offsets.txt:
3A0958: 1f // [2.554] ESG maximum range x10 // 69.9
...then...
HexEdit DDF32: D8 1D [1C 09 7A 00] -> [58 09 7A 00] to redirect the function to find that 69.9f
The Lance's brackets, 40.0f and 70.0f, seem to only affect the HUD's damage estimator. The ESGL range limiter enables the Fire button. If the range limit is greater than the bracket, the ESGL ignores the bracket's implied maximum range.
-
do you think stacking is in the exe? Again, I'm no expert, but I sorta thought that would be handled by something else that the exe launches. Like the music - the exe is not a music player, the exe starts software that plays the wav files. Stacking in the ini is part of the "3D section," has anyone seen any references to lowres/windowed/lighting, etc., in the exe? Or could your ghosting problem be a problem with the models you're using, since they're not stock models?
Edit: Adam, You got me staring at the sfc.ini and there were a few lines I forgot or never knew, so I did a forum search for any threads that might fill in the gaps, and, lmao, I found a thread from 2003 with that same question from you Adam. ;)
http://www.dynaverse.net/forum/index.php/topic,163143841.msg1122375834.html#msg1122375834 (http://www.dynaverse.net/forum/index.php/topic,163143841.msg1122375834.html#msg1122375834)
-
I get what you meant by ghosting and what you were asking, I just think it would be someplace else other than the exe, but idk, maybe it's in there someplace. Maybe tho there's a upper end to how big the models are expected to be. When you say you scale them higher, are you enlarging the actual .mod, or are you changing the model.siz file? I've had good luck altering that file; I wonder if you could scale down the stock models to make yout TNG models work better? The FCA is 8.47 in the model.siz - you could halve that to 4.23 and see how it looks, esp in regard to the stacking.
-
Going to try to fix another bug with the Fusion Beam. It cannot do any damage at range 8.01 to 8.99 when overloaded (including Suicide OL). I was able to fix this in SFC: Community Edition...
Fixed. The maximum range is determined by three floats! I've disabled the effect of two of them, which were redundant and incorrect (8.0k instead of 8.99k).
HexEdit StarfleetOP.exe
DF230: [75] -> [78] // Enforces an overloaded range limit on Suicide Fusions
DF321: [77 C9] -> [90 90] // Bypasses redundant range limit for OL Fusion
DF343: [77 A7] -> [90 90] // Bypasses redundant range limit for Suicide Fusion
The float at HexEdit 3A7530 will determine the max range for both overloaded modes.
-
Humm... i was looking the backups i have here, to organize things a bit, and i noticed i have so many things...
Currently [SFC CE + v2673 + repaired_campaigns.mct.zip + Ancient mod] its the recomended version right? I have a v2674 but don't know if its ok to use. Would be great to have a pack to install on top of CE iso. Like a major update. Everything togheter. I've got some mods here for EAW, with sounds and textures. CE iso has some zip files like fonts.zip or the ones inside assets/sounds (dunno if they are to unzip), etc. i'm trying to install everything right on a fresh virtual machine running xp. Win10 gives me problems with everything. I'm a bit lost.
Would be so great if we could pack the good things that were released into a zip (sounds, textures, models, fixes, etc) and put it on front page.
About orion pirates, are you close to that version you have been talking about?
You've all been posting a lot of updates recently. :)
-
Don't look at me man, I just work here :D
Seriously, I'm not sure who is lead on this OP 2553 and how close we might be; if we agree that it's the vanilla update, it could maybe happen in the next month. I like the idea you have dv for something on the "front page," and this OP 2553 would just be the exe and maybe a readme (unless someone can come up with an installer?).
In regards to the Fusion Tar, as usual great work and as usl I'm a little confused. The disabling you did is in your modded exe, right? So I can't include those into my offset.txt for SFC_Edit yet? Seeing the OL fusions stopping at 8.0 makes me think that there was some error copying things over from SFB, like not taking into account the extra 99/100ths (SFB OL Fusion beams stop "at" 8).
I'm attaching the latest offset.txt for SFC_Editor below (and deleting the prior one) but I ran into a problem with a offset you shared a few post back Tar for "ESG maximum range" (at 3A0958 in HxD). The floats there are not "69.9". Was this for the updated version only? This new offset file does include the proper cloak adjustment, fusion OL max range and the option points for Suicide OL Fusions and P-G2 range limiters.
-
Carlos,
In 2.674, I tried to fix the problems associated with capture. I made progress! But capture involves other functions that I couldn't identify. 2.674 will crash when the AI attempts to capture a fighter. If a player attempts to capture a fighter, the battle continues normally. 2.674 can be retired.
2.675 will be the next unofficial patch for CE. At the moment, I'm looking at Orion Pirates. Finding stuff in OP can help me locate stuff in CE, and vice versa.
TAnimal,
Yeah, maybe we should start a new thread for the vanilla OP patch. It can be confusing with bugfixes and enhancements being developed independently.
3A0958: 1f // [2.554] ESG Lance maximum range x10 // 69.9
This offset requires 2.554.
-
3A0958: 1f // [2.554] ESG Lance maximum range x10 // 69.9
This offset requires 2.554.
Thanks Tar, I thought that was the case with the [2.554] in the line, but you had that in the offset you gave me for th PG2 op and that works in 2552. I should have asked
-
Well, has been some months since i last touched in my SFC_Editor source code.
Tonight i took a look to remember how i did it to found if i could improve some little things:
- Fixed a little "comestic bug" where lowercase's chars would be saved into the exe as uppercase chars if they were declared in a offset as such.
- Added a stronger input check into the UI interface, so people can we warned faster if they write a mistake.
- Improved i hope, the redraw time of the controls...
- Implemented a new parser option into the offsets.txt. Now you can write anywhere something like:
// Starfleet2CE.exe MD5 Checksum
// If the number appears green in your sfc editor, then you have the right version to start editing!
// The number is updated only when you read the EXE or save changes into it.
md5 38B133B44A8AB61C6C8FFE1FFEC029B3
(http://i.imgur.com/nb0YYTM.jpg)
I will post the updated version as soon i have tested it. Will be open to sugestions on how to improve it to make a stable version to distribute with the offsets files.
-
Sounds great!
Errr, at least the parts my poor brain understands
-
Sounds great!
Thank you.
-
In CE, I found a primitive Engine Doubling hotkey. It doubles warp power, but not impulse power. I don't know how to restrict it to Orion (or any particular empire's) ships. A ship suffers the loss of two engine points every two turns (60 seconds at game speed 8). There is no penalty for undoubling, as in OP.
I also found a developer's hotkey called "Revive Ship". Clearly this is not meant for actual battles. It repairs all damage but doesn't reset the HET success rate. It could be useful as a tool for gathering internal damage data. Or a magic hotkey for a very inexperienced player fighting the AI.
-
Exeter did say that there were a lot of "dead ends" where it appeared they began a system development and then abandoned it. It was part of the reason reading the code was so daunting.
-
and so much was not stock sfb
-
Interesting. I hope you find out more about these two particular finds. Quite interesting.
;-)
It might be cool to design an Orion Light Cruiser with, let's say, only 15 warp and a couple Impulse engines. It would probably need to double its engines to fight, but it would be on a serious time limit. I might find the variable that determines the resulting damage to engines. Anyone remember how SFB handled warp damage from doubling? Was there a die roll involved?
I also looked at a hotkey labeled "Destroy Target" which could be The Hand of Bethke, maybe. It doesn't seem to work in CE.
I was really hoping that the Fleet "GOTO" hotkey would work, like a comparable button did in SFC1. But it is not effective in CE.
-
In SFB, in rule G15.2, there is no special procedure for allocating the damage done from doubling. You actually double the individual warp engines, so you take 1 hit per engine, obviously in SFC both engines are doubled hence 2 damage points. And back in the early days of SFB, that's exactly how Orion ships were, they had to double their engines to be effective and were on a running clock. Later "General War" upgrades and expansions gave them (along with all the other races) lots of ship varieties.
-
Thanks, TAnimaL!
It seems that OP is more severe on the damage from doubling than SFB. Feels like a good chunk is destroyed each time the engines are undoubled.
What happens to doubled APR or Impulse engines in SFB?
So in SFB, each warp engine suffers the loss of one point of power at the end of each turn? CE is half that: 1 point for every two turns. But maybe this accounts for SFC's doubled internals. The first allocation stuns, the second allocation destroys.
I wonder if a ship with Center Warp in CE takes damage too, such that the ship suffers the loss of 3 power every two turns...
Did some testing in CE...
The damage is 1 point for left warp, 1 point for right warp, and 1 point for center warp each turn. SFC's doubled internals results in damaged engines on turn# 1, 3, 5, etc. and a visible loss of power on turn# 2, 4, 6, etc. An Orion ship with only Center Warp would be less affected by "overloading" the warp engine than one with L/R warp or L/R/C Warp. Interesting.
-
I don't fly Orions much in OP (or SFB), are you saying it damages more than 2 hits per turn? Overall, the effect should be pretty harshl of course in SFB you can micromanage so many settings you can track it
easier (ok, that's a sentence I never tought I'd say about SFB). You can double warp and impulse but not APRs, because there's no place to vent the excess heat.
Because I'm a geek and think you'd get a laugh out of it, for your consideration:
-
The damage is 1 point for left warp, 1 point for right warp, and 1 point for center warp each turn. SFC's doubled internals results in damaged engines on turn# 1, 3, 5, etc. and a visible loss of power on turn# 2, 4, 6, etc. An Orion ship with only Center Warp would be less affected by "overloading" the warp engine than one with L/R warp or L/R/C Warp. Interesting.
Sounds to me like a center warp only ship gets the same damage at the same rate
-
Hmm...
Let's consider two Orion ships, identical in all aspects except for warp engine assignments of 24 warp.
If the ship with 3 warp engines (8 Left, 8 Center, 8 Right) doubles all of them, the cumulative penalty is 3 damage per turn.
If the ship with 1 warp engine (24 Center) doubles it, the cumulative penalty is 1 damage per turn.
The "clock" is running much faster for the ship in the first example.
-
Ah, I see where you were going, I thought you meant as compared to other Orion ships., didn't see the "only center warp." This is probably why there are no Orion ships with only center warp, only 2 & 3 engine units
-
Now to find a way to make the starting on the guage a little ahead of the starting point to be able to go in reverse, if its even possible.
Wow.
I gave up modding this game a long time ago, basically got what I wanted then posted it.
Took a bit of time to figure out how to do this, but after replacing all the 31 floating bits with 62 ones (310.0 in floating point mode to 620.0 in the same). I can confirm this is indeed working with no ability to change direction, however HETs and weapon fire / shields do work! (just like just before entering warp as well). I am very very impressed guys. Thanks for taking the time to rift through hexadecimals. Very hard sometimes to find that needle in the haystack.
Any ideas regarding cloaking by chance? Like a distance where a target would not appear when cloaked? Or is that hard coded the same as distance to seeing target regardless of cloak?
Hard to imagine the game I grew up on as a kid still has secrets to bestow.
-
Took a bit of time to figure out how to do this, but after replacing all the 31 floating bits with 62 ones (310.0 in floating point mode to 620.0 in the same). I can confirm this is indeed working with no ability to change direction, however HETs and weapon fire / shields do work! (just like just before entering warp as well).
Not all of the 310.0f are associated with speed. Please check the combat estimator, shown as: min - max (average), for weapons that use 310.0f to define a range bracket (nn.00k to 30.99k). Several weapons (Phaser-2, PPD, Disruptor 3 & 4, Photon) use this value. The Disruptor-3, for example, may show that it can fire at range 61.99k. Try firing disruptors at a far away planet with a Klingon D6B. If you can fire beyond 30.99k, you've found an unintended consequence.
Any ideas regarding cloaking by chance? Like a distance where a target would not appear when cloaked? Or is that hard coded the same as distance to seeing target regardless of cloak?
I haven't discovered the "tactical intelligence" variables. I suppose all ships could be made to disappear at range 41.0k instead of 90ish. Cloaked ships might disappear at range 36.0k. I don't know yet. I haven't tested this. Cool to think about though!
Glad you're interested in this stuff.
-
Adjusting the "tactical intel" settings a little tighter, might be interesting thing to try out with min values, for example range 30 or less to even appear.
I think the gameplay would change dramatically if such a modification could be introduced.
-
its a very cool option to play stealthed. ;D
-
Keep up the good work guys! Still following your efforts - it makes for interesting reading.
;D
-
Adjusting the "tactical intel" settings a little tighter, might be interesting thing to try out with min values, for example range 30 or less to even appear.
I think the gameplay would change dramatically if such a modification could be introduced.
Indeed. The Wrath of Khan battle in the nebula was intriguing because of spotty tactical intel.
I think I can find the float that controls the appearance/disappearance of the 3D model (unrelated to cloak). If it consistently reveals a faraway Heavy Cruiser at 95.9k then there may be a 960.0f bracket for intel.
Using Deep Scan could be crucial in battle, since it adds 30.0k(?) to the range of the ship's sensors basically.
-
actually, SFB has an optional rules for hidden movement which is exactly like that, and my playgroup always used this option. You had almost no idea where the cloaked ship was; twice a turn (at fixed intervals) you could ask which shield of A ship was facing the cloaked ship, and maybe you could triangulate roughly where it was, and sometimes you knew what speed it as going, at least when it cloaked. Could be a tense few turns, let me tell you.
-
Another of the optional cloak rules allowed the cloaked player to shift the location of their counter a number of hexes away from it's actual position.
And I don't have my rules handy now, but I seem to remember an option that allowed the cloaked ship counter to be removed if the lockon roll failed by a certain amount. Accomplishing this using the tacintel rules (as previously suggested applying a divisor to the detection ranges while cloaked) would be nice. Not sure if that's within our reach here though, but if someone figures something out that'd be cool.
This would add a new dynamic for probes. Similar to firing probes off to detect a ship/fleet that is say over 100 hexes away, players might want to fire off probes to find traces of that cloaked ship that might be only 20 'hexes' away...
-
In default CE, the effective range to a cloaked ship is (true range * 2) + 5. I don't know if tactical intelligence uses the true range or the effective range. I have a hunch it might use the effective range, which would properly account for sensor and scanner damage.
Let's say a Fed-CA is fighting an invisible War Eagle at a true range of 15.0k. The F-CA will have an effective targeting range of no less than 35.0k to the Romulan ship. (It could be 44.0k with severe scanner damage.) If the 3-D model (and the off-screen tag?) can be made to disappear at 35.0k then the War Eagle could wait for an opportunity to uncloak at range 20.0k, dump an overloaded Plasma-R, and recloak forever against plasmaphobes. The Fed-CA can, however, choose to be struck by this torpedo (suffering minor damage, if any) and then efficiently pound the War Eagle with Phaser-1's and T-bombs the next few turns...
In Orion Pirates, invisibility would be another perk for an already extra-effective cloak (via the misery chart which is applied to attenuated damage). Fighting against Romulans might be no fun, unless there is a BPV adjustment.
All worth testing, if the tactical intel brackets are found, isolated, and customized in the executable.
Did a few tests... The most serious problem is that the camera (F5) has a flawless memory. If a ship that you've locked the camera onto goes out of sensor range, you can still see its location (of course without a 3D model). So it appears access to the source code is needed to make the camera forgetful. Learned that shuttles count as ships as far as tactical intel.
The standard brackets for tactical intel are:
Ship's name ("Enterprise") level = 0.0k to 4.0k
Ship's designation (F-CA) level = 4.1k to 30.0k
Ship's hull (Heavy Cruiser) level = 30.1k to 100.0k
No information level = 100.1k+
As Corbomite pointed out a couple years ago, the Fleet Control Overlay removes all surprises, unfortunately.
-
As Corbomite pointed out a couple years ago, the Fleet Control Overlay removes all surprises, unfortunately.
So do the screen edge tags, mostly.
I still think the cloak should work the way I outlined awhile back. I'll see if I can find the post.
It was easier than I thought:
Cloak Improved: I feel the Cloak is excellent as it is right now (OP cloak)... with a few small tweaks needed. If you press F9, all screen information indicators disappear, including the shield graphics. If you do this while targeting a cloaked ship, they turn nearly invisible to the naked eye (you can barely see them if one of the space backgrounds is behind them). They can still be seen on the Tactical MFD as a moving ship icon. This is very close to a SFB cloak and practically mimics the TOS episode Balance of Terror. You know the general direction and distance and that's about it. I would like to see those effects incorporated so the cloak works like this: When the ship cloaks the Targeting Reticle and shield graphics disappear for all units to the cloaking unit. The ship is still "targeted" by the motion sensors so the screen should still follow the ship like it was tracking normally, just with no Targeting Reticle and, of course, no lock on. The follow command, orbit command and ID Tag must be disabled so a tracking ship just can't simply follow them around. You get the general direction from the viewer telling you something is there, but you have to follow it manually using the Tactical MFD and your hunch as to just how fast they are going. I would also add that if a cloaked ship stops dead all tracking systems, including the icon on the Tactical MFD, be disabled. It disappears until it moves again or is voided in some other way (mine, black hole movement, shuttle launch). I know the cloak got better over time to be basically undetectable, but trust me, sub hunter is much more fun! ;)
There was a ton of other good stuff in that post.
-
I believe what Adam was asking about and what i was referring to with hidden movement cloak is the complete vanishing of the cloaker, not just resorting to F9 toggling and a barely visible 3D model, and from the sounds of it, this is not possible, especially with the Tactical Map.
Tar, just for clarity here, when you mention the "misery chart," do you mean how damage against a cloaked is penalized when it does hit (100%, 50%, 25%, 0% effectively)? This is standard in SFB; is it not in EAW/CE? Are there TacIntel range brackets in the exe that can be edited via hex edt? That could be an interesting variant to play around with too.
-
That's not what the post is saying. I was giving people a way of seeing what it might be like with hidden movement. If you actually read the post I spell out just what needs to be done to make it work pretty much like it did originally in TOS, which I think is better for a game. A TNG cloak would be boring/frustrating for the hunting party.
And no, EAW/CE does not have the reduced damage chart in effect for the cloak, but OP does.
-
Gee, Corb, maybe you should lay off the caffeine late in the day. I read what your post said but what Adam said was, and I quote, "you could have a sporadic blip on the tactical map but on screen in front of you it should be completely gone," which is what I said Hidden Movement is in SFB, and since this is a thread on hex editing, maybe we were just hoping to talk about if that's possible. For me, toggling F9, which affects HUD for EVERY ship, doesn't cut it, especially when pressing "y" for "target enemy ships" will find the cloaker. Whatever you outlined is not an actually in the game, you do realize that, right? That's what we're talking about, what could be done to make it that way, not just turing off screen info.
I also think you need a remedial viewing of "Balance of Terror." The Warbird disappears completely, no "visible distortion" like you see in ST movies, or the shadow model we get in SFC. And in the other TOS appearances of cloaked ships, there wasn't even a hint of the motion blip as in BoT.
-
I don't drink caffeine and you are completely misunderstanding what I was getting at, but no matter, sorry I brought it up.
-
Tar, just for clarity here, when you mention the "misery chart," do you mean how damage against a cloaked is penalized when it does hit (100%, 50%, 25%, 0% effectively)? This is standard in SFB; is it not in EAW/CE? Are there TacIntel range brackets in the exe that can be edited via hex edt? That could be an interesting variant to play around with too.
Let's say a K-D6 is hunting an O-DBR that is fully cloaked.
A Disruptor fired at a true range of 0.0k has an effective range of: 0*2 + 5 = 5. It properly uses the effective range for accuracy (67%).
Let's say it hits the O-DBR. The damage, however, is incorrectly based on effective range, not true range because Disruptors, Hellbores, Particle Cannons, Web Fists, Plasma Bolts, and Photons* are supposed to use the true range for damage calculations. {*Photons are weird in that they don't degrade.} So that K-D6's Disruptor does 3 points max instead of 5 max. But EAW and CE do not have OP's "misery chart". So the effective range "penalty" in EAW/CE actually approximates SFB's misery chart!
SFB
33% do 5
33% do 2.5 -> 2
33% do 1.25 -> 1
Avg Dam through chart = 2.67
Avg Dam per Disruptor attack = 1.78
EAW/CE
100% do 3
Avg Dam per Disruptor attack = 2
OP
33% do 3
33% do 1.5 -> 1
33% do 0.75 -> 0
Avg Dam through chart = 1.33
Avg Dam per Disruptor attack = 0.89
Haven't yet found the intel brackets. But they should be easy to find if they are typical "range x10" floats. I did look for a 1001.0f, but didn't find any. Could be one of the 1000.0f variables instead.
The follow command, orbit command and ID Tag must be disabled so a tracking ship just can't simply follow them around. You get the general direction from the viewer telling you something is there, but you have to follow it manually using the Tactical MFD and your hunch as to just how fast they are going.
Sounds good. However, the camera needs to erase its memory of hotkey-assigned (5,6,7,8) targets and the current target if any of them cloaks. Because the camera doesn't forget, you will always know, within a few degrees, which way to go to always find the cloaker. In SFB, you would know a 60 degree arc. (With two ships you could narrow that down considerably.) We need source code to do invisible cloak properly. I see no way to accomplish this with HexEdit because of the complexity of targeting.
-
The follow command, orbit command and ID Tag must be disabled so a tracking ship just can't simply follow them around. You get the general direction from the viewer telling you something is there, but you have to follow it manually using the Tactical MFD and your hunch as to just how fast they are going.
Sounds good. However, the camera needs to erase its memory of hotkey-assigned (5,6,7,8) targets and the current target if any of them cloaks. Because the camera doesn't forget, you will always know, within a few degrees, which way to go to always find the cloaker. In SFB, you would know a 60 degree arc. (With two ships you could narrow that down considerably.) We need source code to do invisible cloak properly. I see no way to accomplish this with HexEdit because of the complexity of targeting.
Well, if you don't want the viewer to show direction at all then you would need to have the game automatically use Deselect Target when a ship cloaks (probably not too hard to do) as well as having the equivalent of F5 view toggle in, but only for the cloaked unit. That could get problematic with several units onscreen at once.
-
Deselecting a target does not fool the camera, unfortunately. It will still follow the previously targeted unit. The camera needs to be "tricked". One way to do this is to have ships automatically target themselves when their current target cloaks. Any hotkey-assigned targets would then only work if isTargetCloaked() == false.
-
Could the camera target lock function be removed entirely?
If it isnt there, it does not need to forget.
-
I believe target lock (F5) can be disabled via HexEdit. However, this would be a serious sacrifice. I greatly prefer the smoothness of F5-enabled views over the jerkiness of those without it.
if (isTargetCloaked) {
setTargetLock(off);
setHUD_InfoLevel(F9);
setFollowStatus(off);
setOrbitStatus(off);
}
Not so easy to do with a HexEditor. Might be able to do this in a minute with C++ source code.
Edit: The above logic is insufficient. Nearly invisible ships would need to have their mini-map icon, shield graphics, HUD speed, and HUD range removed from the perspective of all non-allied units. Otherwise, if I target a Romulan War Eagle's ally, a Klingon D7 for example, I'll see the R-WE whether it cloaks or not.
-
Tar, thank you for the overly-explicit example but you didn't really answer my question - what is the the OP misery chart? Is it just the SFB G13.37 Adjustment chart (being applied without correcting for true range instead of effective), that is, a 1/3 chance of 100% damage, 1/3 chance of 50%, a 1/3 chance of 25%? And more importantly, is it in the exe somewhere? I think I remember in my notes a string I found of 1.0, .75, .5, .25 but I suppose that could be anything.
-
Yeah, TAnimaL, the "misery chart" in OP is the SFB cloak's effect on damage chart. Such that a Photon Torpedo, for example, that strikes a cloaked ship has a 33% chance of doing 8 points, a 33% chance of doing 4 points, and a 33% chance of doing 2 points.
This is located in the StarfleetOP.exe. And it is adjustable via HexEdit. I don't have my computer with me right now.
Here's what I wrote a while ago: "Found the function in OP today. Hidden in plain sight. Its associated string is tCloakSystem::mDetermineCloakSeekingWeaponDamageModifier"
So we could do 1.0, 0.5, 0.4 to weaken the cloak in OP slightly, for example. A Phaser-1 that hits for 5 would have equal probabilities of doing 5, 2, or 2 accounting for rounding (instead of the defaults of 5, 2, or 1 point).
-
When you find your notes, what's the offset for that? (I'm still not up to speed on Ida) I could run a few tests.
-
Unfortunately, the variables that modify the damage are shared. The 0.25f (1/4 damage) is used by 169 operations. You cannot safely modify it. The 0.5f modifier is used by 268 operations. Only one is the right operation. You can, however, create and link a new variable that only affects the cloak's misery chart.
IDA is essential to precisely hack the non-immediate values in the StarfleetOP.exe.
Here's a screenshot of the relevant function. I've renamed the variables to make them easily readable. The float in the red box is for 1/4 damage vs cloak.
-
I found the floats (aka decimal numbers) that define weapon arcs in Starfleet2CE.exe. Each arc descriptor (FA, FH, FX, etc.) is associated with 3 (or 4) floats. The first float determines the beginning of the arc in positive degrees from the ship's centerline. So "FA" begins at 60.0f. The 2nd float determines the end of the arc measured counter-clockwise. So "FA" ends at 300.0f. The 3rd float is mysterious if it's not followed by a fourth float. It doesn't seem to be meaningful unless the 4th float is present. Arcs like KFX, FARA, RW, LW, etc. have two sets of floats because these arcs are complex and non-continuous. So the bulk of "KFX" starts at 120.0f and ends at 240.0f, then the narrow aft arc begins at 190.0f and ends at 170.0f.
I fixed the SFBR, SFBL, RRP, and RLP arcs that were borrowed from Orion Pirates. The programmers probably measured clockwise instead of counter-clockwise, which is understandable and natural. CE's sprites.q3 doesn't accurately draw OP's additional arcs, but it draws something anyway, which we might be able to adjust with the Sprites_Editor.
Customizing these arcs is possible, but almost every referenced variable is shared with other functions. Free space for segregation is abundant, but it is a tedious process. If arcs desperately needed modification, I'd add the new variables. But SFC already has lots of arcs that seem to do the job quite well.
I searched StarfleetOP.exe for 4 hours. It does not use a similar arc definition. I thought 355.0f (the beginning of the "MLR" arc) would lead me to the right function. Nope.
-
That is very cool Tar.
Thanks for fixing that weapon arcs, and redirecting that dead gamespy link to evolve.
-
(removed)
-
(removed)
-
Pretty interesting. Even if the displays on the side were made bigger (assuming you couldn't figure out how to display say the tractors and weapons window at the same time), it'd be an improvement.
My two 'pet suggestions' I think are still beyond our reach though. Don't think I've shared these before, but I'm constantly reminding myself about these whenever I am playing...
1) Assigning fractional points otherwise assigned to shield reinforcement, also to ECM/ECCM, to battery recharge automatically. 5.3 points of shield reinforcement, or 5.3 points of ECM is kind of silly... This would make batteries a little more useful I think. Manipulating sliders at the fractional level is kludgy at best, and the game should just not assign fractional points to ECM or Shield Reinforcement (no benefit to shields, only in rare cases does a 3.1 ECM matter, if say your opponent somehow ends up with say 2.1 in ECCM). Movement and Weapons recharge rates can put fractional points to use, so fractions are fine for those. Tractors I think automatically assign 'whole numbers' based on the power level, so they aren't an issue to begin with...
A slider for battery recharge would also be nice (assuming it was assigned a priority level), but that's well beyond us I think. Batteries in general are poorly implemented, but could be more useful for weapons recharge and such. While I'm on the subject, it'd be nice to have a 'battery window display' that had 'checkboxes' which designate where battery power should be used (weapons, movement, etc.). Again, it's a wishlist thing, but Exeter might want to take note of these ideas for his new game...
2) Adding shield strength, as a numerical representation, on top of the shield bars on the ship systems/weapons display. That way you'd know if that rear shield had only 1 point of shielding, or 5 or whatever it current strength is, as the shields sustain damage, and also as they are repairing.
-
Even if the displays on the side were made bigger (assuming you couldn't figure out how to display say the tractors and weapons window at the same time), it'd be an improvement.
Agreed. When I started playing this game at the age of 25, I could see the elements of the UI clearly. Now that I'm almost 42, I would love to have 25% larger buttons, panels, sliders, etc. when using today's typical monitors that have many pixels per inch.
-
sfc.ini contains the variable "lowres" that the .exe reads to determine resolution.
We can update these values.
0= (800,600) ; 1366x768
1= (640,480) ; 1280x800
2= (960,720) ; 1440x900
3= (1024,768) ; ok
4= (1152,864) ; 1920x1080
5=(1280,1024) ; ok
6= (1600,1200) ; 1920x1200
Or allow any resolution to be chosen for, let's say, the lowres setting of 2.
-
In collaboration with Tar i bring you the first demo of the next patch 2676, featuring full HD support !! :rockinband:
1366x768
1920x1080
etc...
... that you can set in your own SFC.ini!
It is wonderful what the change of 4 numbers in the exe and add some stuff into sprites.q3 can do in a few hours of work, right? ::)
Sorry for the shaking as i was holding the camera while doing stuff. Anyway who cares? It works !! 8)
https://onedrive.live.com/redir?resid=5BEA448F9325A62B!45376&authkey=!AD9AF4S0TqaiGBg&ithint=video%2cmp4 (https://onedrive.live.com/redir?resid=5BEA448F9325A62B!45376&authkey=!AD9AF4S0TqaiGBg&ithint=video%2cmp4)
-
That's amazing, good work!
-
(removed)
-
Awesome. I've been dying to play 1920x1200 on my monitor. Do you think you can include it with the Sprite Editor since that has to change when changing the resolution. Instead of having two programs we can just have one. Maybe a seperate tab or sub menu.
You are the best ;)
Dunno yet. As it have to patch 3 files...
-
This is awesome, I'd love to see SFC OP HD resolution support.
If you can tell me an address or what to look for I can make the file myself to upload in HxD.
-
The Romulan Photon and the Mirak Disruptor were lacking quicktips. I was surprised that I could paste quicktip data into the sprites.q3, modify the preceding integer for an index, and not cause obvious problems. The file size has increased by a hundred bytes or so, which could cause everything to crash and burn. But it hasn't. I guess the position of the data in this part of the file isn't critical. Of course, I'm placing information exactly where it should have been...so that's why it works.
-
(removed)
-
This is awesome, I'd love to see SFC OP HD resolution support.
If you can tell me an address or what to look for I can make the file myself to upload in HxD.
Such thing don't exist yet.
It is being developed by me and TarMinyatur atm.
-
If you can provide me details on exactly what you did to the Romulan Photons and Mirak Disruptors I would really appreciate it. I would like to fix this for sfc2op. I believe you mentioned these two fixes which involving hex editing the sprites and the third you mentioned previous was fixing a Klingon arc but I believe that's simply replacing a Sprite photo to display proper arc placement.
Besides these three, are there any other fixes I should be aware of involving improper commands in a race UI?
Romulan Photons had PPDStatus as an associated function. Of course they didn't work. Mirak Disruptors were simply missing the quicktip data. (Don't focus on the hex addresses in these images.) The point is to show the arrangement of the quicktip, button_type, aaString, and Starfleet.function. Normal, overload, and proximity modes must be edited too.
Seems that quicktips (tooltips) don't need the racial affix. A6_DISRUPTOR_OFFLINE produces the same output as Z#A6_DISRUPTOR_OFFLINE. Maybe Taldren was going to use different fonts for quicktips by reading the first character.
-
Very cool work Tar,
Now we can clearly give a name and meaning to those tooltip strings.
Thanks.
I think we can even improve the fix, so we dont overwrite something there, by mistake.
-
There it is!
For all the SFC OP fans..
A demonstration of the game running at 1920x1080. 8)
Just finished the basic to make it work, so i didn't edited any image yet.
https://onedrive.live.com/redir?resid=5BEA448F9325A62B!45794&authkey=!AGUIVNUMf_VhcIQ&ithint=video%2cmp4
-
Nice! I can't wait for the OP patch!
Thank you guys for continuing to work on this.
-
Wow! One more OP patch, and its a biggie!
Who would have believed it?
-
Some questions...
The Doomsday Machine anti-proton beam has been simulated using the ISC PPD and Mauler. Is there any way to give it more punch without making it the new death star? Nothimg short of a CL in size should be allowed to take down a planet killer. I'd love to tractor a freighter or an enemy CL and ram it into the maw of the DDM. It's anti climatic when a mere fighter or shuttle group runs through it and kills it!
Tholians web - Klingon Academy modified the T web into a sphere that surrounds an enemy ship. Is there a way to repurpose the Lyran ESG to make its duration last longer and say give it the properties of the Plasma E? iIRC the Plasma E was as close to an energy damping weapon the Galaxies at war mod team could come up with for a T web.
Also does all this hex editing allow for Firesoul's ESG loop fix to be incorporated or is that something not related to this topic?
Are asteroids hex editable? Is it possible to make it so standard. Asteroids can be track red without having to be a c## programmer?
There has been amazing progress in this area keep up the great work!
-
There has been amazing progress in this area keep up the great work!
Thanks Klingon,
About your questions, those are in fact good ideas.
I'm sure they would be possible if anyone was actively working on the game code itself. But SFC is not really a community project, or even open source code, where anyone can contribute. Is as close as it can be.
From my point of view, all this hex editing is very time-consuming and not fun to work with. To tell the truth i just hate hex editing. Barely touched in it. All was done by Tar and others.
I just made the SFC_Editor and Q3_Editor, and will contribute to these patches as they require a bit of both.
It is not likely that i will continue to work on these kind of things anymore.
I just want to play SFC in HD, with a good shiplist, and a good model pack.
Just want to adjust one or other detail with the Sfc_Editor and Q3_Editor.
Play some games.
I really love the concept of Dynaverse and SFC CE...
But in pratice, from my user perspective, i barely notice any difference between SFC EAW and SFC CE...
They both run as well in my Win10 machine...
And OP really looks as it offers much more...
Wich is sad... rigth? After the code being released 8 (?) years ago...
Just notice this example...
Without any experience or knowledge on the game code and sprites.q3.
It only toke one afternoon talk, and 2 days, to realize that it was possible to make an HD patch for CE and OP.
Yes i did the Q3_Editor, but i also didnt even knew what it was 2 month ago.
There is other examples... but nevermind... it has not been a good experience at all.
And for what i read in the forums, that people have been posting all these years...
-
Some questions...
The Doomsday Machine anti-proton beam has been simulated using the ISC PPD and Mauler. Is there any way to give it more punch without making it the new death star? Nothimg short of a CL in size should be allowed to take down a planet killer. I'd love to tractor a freighter or an enemy CL and ram it into the maw of the DDM. It's anti climatic when a mere fighter or shuttle group runs through it and kills it!
You can do this by giving the DDM more batteries to power the Mauler. I have no idea how to select unit types that can kill the DDM by flying into its maw.
Tholians web - Klingon Academy modified the T web into a sphere that surrounds an enemy ship. Is there a way to repurpose the Lyran ESG to make its duration last longer and say give it the properties of the Plasma E? iIRC the Plasma E was as close to an energy damping weapon the Galaxies at war mod team could come up with for a T web.
No. This cannot be done with a hex editor. Creating an ESG Snare is impossible with the tools I have.
Also does all this hex editing allow for Firesoul's ESG loop fix to be incorporated or is that something not related to this topic?
The ESG loop (or any other audio) can be disabled in sounds.txt with a plain old text editor (notepad). Just put a tab before any annoying audio entry and it won't be played.
Are asteroids hex editable? Is it possible to make it so standard. Asteroids can be tractored without having to be a c## programmer?
The OP missions can be edited to allow asteroids to be tractored. But this does require old C++ development software and the OP API. Bypassing this might be possible with a hex editor and the help of a disassembler.
There has been amazing progress in this area keep up the great work!
Thanks. But 2.561 will be the last OP patch that I work on. CE 2.676/2.680 are almost done too. Little can be reasonably accomplished thereafter in SFC without access to source code. The Q3_Editor, SFC_Editor, and the research recorded here are the tools available to ambitious modders.
-
Great work all round. How difficult would it be to update the Taldren Mod viewer to a larger aspect ratio. ?
-
Starfleet2CE.exe
Found the missile hitpoint variables (ints) for Type-I, DroI, DroVI, Type-4...
Who would ever guess that they are stored as 256, 128, 128, 384...? So somewhere they get divided by 64. If you want to create "slug" or armored missiles, you'll be able to do that.
Thought I solved the problem of disappearing Disruptors, but giving them a 10,000-turn endurance didn't help. Photons and Hellbores (that miss) use that enormous value. Disruptors, however, have just one turn of endurance, travelling 1250k, which seems reasonable. So why did the programmers give errant Photons a graphical range of 5,000,000k? The biggest maps are, what, 500k across?
Found the t-bomb/mine lifespan variables (doubles). Is ten turns too short or too long? You'll decide. (Haven't found the damage variables yet -- 10 for standard and 35 for NSM.)
Fixed the SFBMode's effect on Proximity Photons. The CE programmers had it backwards and incomplete. I edited the function such that "magic" Proxies have +1 bonuses at R9-12 (83%) and R13-30 (67%), but I could not enable R31-55 torpedoes due to lack of space. All this will be customizable with the SFC_Editor.
Range
9-12 13-30 31-55
67% 50% 0% <----- SFBMode Off (bugged)
67% 67% 33% <----- SFBMode On (bugged)
------------------------------------------------------------
Range
9-12 13-30 31-55
83% 67% 0% <-----SFBMode Off (modified)
67% 50% 0% <-----SFBMode On (fixed)
Found the instruction for "single internals". SFBMode simply doubles any damage that penetrates a shield. This is why damage allocation still works as usual -- a large volley often stuns just one phaser and one torpedo. The multiplier can be modified with the SFC_Editor and an updated .exe, so you can enable 1x, 2x, 3x, 4x, etc. damage. It is hilarious to use a value such as x10 so that the first hull hit is highly destructive -- it's a radically different, lethal, game. Weapon damage vs shields is, by the way, not increased. It is possible to alter the instruction to divide internal damage. But nobody ever requested triple hitpoints. :)
Figured out the problems with shield regeneration. The CE programmers used EAW's value of 0.3 points/turn. One of a few mistakes in this function, because this value is doubled later. The formula should be 0.15 + 0.05*Labs, not 0.18 + 0.045*Labs. The formula for SFBModeOn should be 0.1 + 0.033*Labs, not 0.3 + 0.013*Labs.
F-NCL+ (Intended for SFBMode On, but was applied to SFBMode Off :D )
Base = 0.18 // Too high -- should be 0.1
+Labs = 0.013*4 = 0.052 // Too low -- should be 0.033*4 = 0.13
Total = 0.23 // 0.23
Effective rate = Total*2 = 0.46 // 0.46 (Amazing coincidence??? ;) 0.46 is 66% of EAW's 0.7, the desired rate!)
F-NCL+ (Intended for SFBMode Off, but applied to SFBMode On)
Base = 0.305 // Too high -- should be 0.15
Labs = 0.045*4 = 0.18 // Close enough -- 0.05*4 = 0.2
Total = 0.485 // Too high -- should be 0.35
Effective rate = Total*2 = 0.97 // 0.7
Experimental data...
0:56 to 11:19 --- regenerated 30 shield points @ game speed 10
Elapsed Time = 10:23 = ~31 turns
30 points / 31 turns = 0.97 points/turn
EAW v2.036 effective rate for F-NCL+ = 0.3 + 0.1*4 = 0.7 points/turn
Anyway, I've fixed this troubled function, and the SFC_Editor can customize it.
-
Great work all round. How difficult would it be to update the Taldren Mod viewer to a larger aspect ratio. ?
I think i can waste 20 minutes on that... ;D
http://www.dynaverse.net/forum/index.php/topic,163394470.0.html (http://www.dynaverse.net/forum/index.php/topic,163394470.0.html)
-
Well here's hoping Exeter after his current project is done will be willing to share some insight in the particulars of SFC2. At least guide us in the right direction so we can dabble in it.
I am willing to share what I can, but hard to change compared to exe, and may be difficult to find.
-
I remember Tar saying something about fixing the photon ranges for real, but I can't remember a couple of things, so if someone could tell me so I don't have to wade through several pages:
Did the photon range fix include OP or just EAW:CE?
and
Did you guys ever find the fighter hellbore ranges in OP as well? (I'd like to get them shortened to range 4 like all the other fighter HW.)
Thanks!
-
Corbomite,
Add this line to OP's offsets.txt:
E1087: op // Light Hellbore maximum range bracket, near to far: (90, 94, 98, 9C, A0, A4, A8) // 9C (4th)
If you want Fighter Hellbores to be limited to 4.99k, choose "98" with the SFC_Editor.
The Proximity Photon Torpedo damage chart can be modified by the SFC_Editor. If you don't want magic super Proxies, change four of those 4's to zeroes.
Adam,
Good idea. I don't know. Open a script with IDA as a "PE" file. It will show a lot of readable data. Somewhere there may be a list of backgrounds. If they are randomly assigned, perhaps renaming all of the extensions (except one) to .mox will work. The spacexx.mod file might then be the only valid background. But you could still get empty backgrounds...
-
Thanks Tar, but you assume I understand how to do that! Oh well, thanks anyway.
-
The SFC_Editor is not terribly hard to use. There's a download for OP around here somewhere.
Hmm, I can simply send you a StarfleetOP.exe that limits Fighter Hellbores to Range 4.99 and sets Proxies to SFB standards. Interested?
-
The SFC_Editor is not terribly hard to use. There's a download for OP around here somewhere.
Hmm, I can simply send you a StarfleetOP.exe that limits Fighter Hellbores to Range 4.99 and sets Proxies to SFB standards. Interested?
Well, that would certainly make my life easier, so yes, thank you. Before you go through he trouble though, make sure that they match the PhoF range, i.e. be sure it's really not 3.99 etc. Thanks Tar, you have made me want to play a lot again with this stuff. I was only firing things up about once a month or two before this. Now I'm working on a whole new version of my shiplist. Right now I'm trying to see if when I put the Commando ships in the Freighter section if they will show up in convoys as Troop Transports.
-
You're welcome. Here is your executable (http://1drv.ms/1SvEaQu).
You might need to unblock this file. Right click the .zip file. Select "Properties". Unblock and apply changes if neccessary.
-
Wow, that was quick! Thanks! To be clear, this will only change what you hard coded in the game right? All other outside configuration files (resolution, campaign file tweaks, etc) are all unaffected and the .exe just replaces my stock one? Also just to be sure, these are the only changes from stock in this version?
-
The executable is built on 2.561, which repairs Fusion Beams (so they obey the overload range limit of 8.99k). Everything is set to default status except for Fighter Hellbore range (4.99k) and SFB-based Proximity accuracy and range. I made no changes to resolution.
This .exe does not depend on any modified assets. And, yes, it is a simple substitute for your regular StarfleetOP.exe.
I recommend an update for sprites.q3 (Mirak hit and run pause enabled, UI fixes for Romulan Photons, Lyran Fusion Beams, Hydran Plasma Torps, etc.). But then you would need an updated aaStrings.txt and quicktips.txt for everything to be flawless. You mods might not modify these 3 files.
-
The executable is built on 2.651, which repairs Fusion Beams (so they obey the overload range limit of 8.99k). Everything is set to default status except for Fighter Hellbore range (4.99k) and SFB-based Proximity accuracy and range. I made no changes to resolution.
Oh, cool. Now if we can just get them to hold their regular fire until they are closer like the fighters. That and getting fighters to not fire their PhoF at stationary targets at over range 4 (guaranteeing an auto-miss) when set to Attack.
I recommend an update for sprites.q3 (Mirak hit and run pause enabled, UI fixes for Romulan Photons, Lyran Fusion Beams, Hydran Plasma Torps, etc.). But then you would need an updated aaStrings.txt and quicktips.txt for everything to be flawless. You mods might not modify these 3 files.
Quicktips I don't care about since they are switched off and my regular strings file is unique at this point. Can't remember about aaStrings though. Those fixes are done in Sprites and not the .exe? Interesting. I thought you and Carlos were releasing a UI patch though? Those fixes will be included?
-
I did a battery of tests and all seems to work as planned. The fighter hellbores fire at the new range and don't seem to glitch or "cheat" in any way on any setting. It actually makes them more formidable since HB get stronger at closer ranges, while giving the opposition at least a chance at a response.
The Phots also work as intended, but as you noticed before the function that doesn't allow you to fire over range doesn't apply, so I suppose the AI will waste a few shots here and there. Humans rarely, if ever, fire at 31-55, so it is a livable compromise. I hope that one day you guys can find that limiter function and apply it.
Thanks again! :thumbsup:
-
The Phots also work as intended, but as you noticed before the function that doesn't allow you to fire over range doesn't apply, so I suppose the AI will waste a few shots here and there. Humans rarely, if ever, fire at 31-55, so it is a livable compromise. I hope that one day you guys can find that limiter function and apply it.
Thanks again! :thumbsup:
The maximum range bracket for Proximity Photons can be set to any bracket (0-1, 2, 3-4, 5-8, 9-12, 13-30, 31-55). But I have a strong feeling that the AI will not fire if any chart's column is full of zeroes. Hmm, should be easy to test by tractoring an enemy equipped with modified Phaser-1's that have a hopeless Range-2 column...
The minimum Proximity bracket can also be changed. A conjectural 83% accurate Proximity Photon at range 5 to 8 would be useful against a +2 shift.
-
For you guys who have been poking around in there - Do you think changing the offsets to those in red would get the phots to be limited to 30.99?
457108: 7f // Photon brackets, range x10 // 20.0, 30.0, 50.0, 90.0, 130.0, 300.0, 310.0
EDIT: What the heck I gave it a shot and............ it works! It won't fire past 30.99 anymore and the only anomaly I saw was that when set to normal the damage estimate was off by -2 at 17% and by -1 at 33% (using 6 Phots to make the math easy).
So, if you want SFB Photons all you need to do is set the last two range brackets to 300.0 and 310.0 respectively, then on the damage charts you need to add an 8 into the first position of the seventh column (matching the one in the sixth) in the regular damage chart and then you need to zero the last 4 in both the fifth and sixth columns and then match the 4's in the sixth column into the seventh column in the proximity damage chart. That way that last tiny bracket of 0.99 has the same effect as the previous range bracket.
-
I did a test. An AI ship will not fire if a column is full of zeroes. But a player can do so.
Corbomite, you can make the 7th photon bracket even smaller by setting the 6th to 309.9.
Then only a miniscule bracket of 30.990k to 30.999k would apply to the last column, which you could fill with zeroes.
-
I did a test. An AI ship will not fire if a column is full of zeroes. But a player can do so.
Corbomite, you can make the 7th photon bracket even smaller by setting the 6th to 309.9.
Then only a miniscule bracket of 30.990k to 30.999k would apply to the last column, which you could fill with zeroes.
That's what I'm getting at here. No one can fire past range if you do the mod I did. You get the warning beeps if you try. It also makes the green/red color firing indicator in the lower left function (mostly) properly (no all red, but reading 0 damage potential in the display). I was trying to avoid accidental firing that would result in a sure miss and waste two turns.
-
I just experimented with a modified range 5.99 PH3/G that beefed up the last three damage columns a bit to give them a better chance to hit and a little more damage in certain slots.
I flew a drone cruiser with 6 racks and a full load of small fast drones against an MKE (6 PHG) with no fighters, no shuttles and 20 screws for repair. I used no other weapons except the drones. I did manage a good many hits when I managed to coax fire at close range and then overwhelm with a SP, but out of 160 drones only about 8-10 hit, some only weakening a shield, others doing about 60+ points of internals total. I ran out of drones and SP before it was even close to being crippled even if it had had only a few screws.
Seems like a decent compromise. I felt that PD phasers should at least be able to shoot at a downed shield during a boarding action. They definitely aren't SFB spec though.
-
Nothing really it was just an experiment. AI PD is definitely better with it and fighters do better as well. They don't fire PD at long ranges and actually seem to hold their fire most of the time to match the range 4 HW. I was using modified ISC fighters with PhG, HB and Phot.
If people are interested in trying it out I can give you the specs I used.
-
Well here, give it a shot and see what you think.
Set your PH3 chart to this:
Range:_ _10____20____30____40__ __50_____60
Max:__ __4_____4_____4_____3__ ___2______1
____ ____4_____4_____4_____2_____ 1______1
___ _____4_____4_____4_____1____ _1______1
___ _____4_____4_____3_____1___ __0______0
___ _____4_____3_____2_____0____ _0______0
Min:_____3_____3_____1_____0___ __0______0
Only the last two range columns and last three damage columns are modified, assuming you are starting from a stock config and not the the patch config. Then set the Phaser Max Range Tab at 59.9 for PH3.
-
Nice chart, Corbomite.
Interesting.
I like the ability to retaliate modestly with Ph3/G if you get Hit&Run...
-
Found the variables in Starfleet2CE.exe that determine the strength of shields in a Nebula. Default is 10 points for all 6 shields. I've updated the offsets.txt to allow any reasonable value to be chosen. The data is unusual because it divides the entry by 64. So 640.0f yields 10.0f. I needed to alter the .exe to point to segregated data, so this will be available for 2.680.
Found variables for the hitpoints of WW, SS, GAS, and Scatterpack shuttles. It's odd that they don't use the entry in ftrlist.txt for X-SH, but that's understandable because they are treated as seeking weapons. Still looking for the variable for the Suicide Shuttle's warhead (19h)...
Found the variables for T-bomb and NSM explosive strength. 100-point NSM's are brutal, but I haven't figured out how to restrict NSM's to old-school Rommies.
-
...That and getting fighters to not fire their PhoF at stationary targets at over range 4 (guaranteeing an auto-miss) when set to Attack.
That sounds like a bug. Try a speed-zero fighter with PhoF and no phasers. Deploy it at range 5.5k. Does it fire at a base station when set to "attack"? Then add a Ph-3 to the fighter. Same results?
-
I can add customizable speeds for each Plasma Torpedo in CE. Maybe we can do better than SFB's high-speed plasma "sabot" thing or OP's Fast Plasma. I don't particularly like SFB's direct-fire "bolt" option, either.
Plas-R, S, F/I, D: Speed 36, as usual. No need to reinvent the wheel.
Plas-G: Speed 34 with extended range. Max damage of, let's say, 10. But it has great endurance such that a fleeing target could fire Phasers twice at it. If you want to crunch your opponent, you switch to Plas-F for the 20-point warhead. I'll do some testing to come up with some reasonable numbers.
So what's the point? Plasma is already too strong or too weak, depending on the player's experience. Tar, why are you screwing around with the venerable time-tested Plas-G? Well, it's an experiment to overcome the lack of Plasma Bolts in the game. The BPV of a Plasma Launcher includes the bolt option, which Plasma chuckers can't access. It's sort of like the proximity option for Photon Torpedoes...what would you say if that mode wasn't available?
Anyway, it'll be an opt-in feature, through the SFC_Editor.
-
They may not have a bolt, but they have endless pseudos as you lamented. Give and take. Seems fair now.
-
Corbomite, endless Pseudos can be addressed. I think they should recharge slowly. Maybe 15 turns instead of 8 or 9. Once found, it'll be another variable for the SFC_Editor. (I don't remember lamenting over PPTs, but I guess I did.)
I tested a Speed-34 extended-range PlaG mod tonight. I like it. It feels like a Gorn-style weapon, although I can't yet restrict it to the flying staplers. So the Roms and Frogs get them too.
----------------Range------------------
0-33 34-48 49-57 58-60 61-63 64
10 7 5 2 1 0 <--- regular damage on one shield
20 15 10 5 1 0 <--- total enveloping damage (applies fully to unshielded units)
3 2 1 1 0 0 <--- damage per shield vs ships
Insane? Maybe. But a bolted PlaG does 10 damage out to range 10, if it manages to hit at 67% accuracy. So the average damage is 7 points. In this experiment, the target can run for 1.5 turns or choose to get whacked for 10 points on a strong shield. Enveloping mode looks very impressive until you divide the damage by 6 shields. The target can fire Phasers into the PlaG at range 5-8 initially and at range 0.9 a turn later if needed.
{Note to self: I need to make sure the torpedo has 40 hitpoints vs phasers (or 10 hitpoints vs 25% efficient phasers). ---> Confirmed.}
An unintended side effect: Starbases are toast, but they were already getting crunched (10 damage) from range 18 with normal Plasma-G's, where incoming Ph-4's do 4,3,2,1,0,0 at best. But bases could be given Plas-G...
-
Sorry, my mistake. It was recharging HETs you were feeling gave an edge over you in your battle with Tobin.
Talk to Tobin about how I trained the FPF to hit with plasma S by using plasma G to hone tactics. Not one G hit it's mark, and this was training people who never flew plasma before and didn't really know how to avoid it either. That's how easy they are to avoid. S & R (and X) are the only real threat unless you are close and unprepared.
-
I think I have mentioned the following reminder a few times over the years. The biggest killer of the player base was not being able to play dynaverse on post XP operating systems. Fixing bugs etc. is great. Changing things to suit a person or 2 while still hoping to grow back the player base is dangerous. People were generally accepting of non-sfb issues and thankful to have a closely resembling computer game. Leaving XP behind was the last nail in the coffin.
I'll now move into an area where I can get slapped more for my thoughts. I used too many HETs in a victory, so after 14 years (sfc2) we should nerf HETs? (my opponent used 3 HETs that I recall to my 12 in 2 hours and 9 minutes) In other games last week with someone else, I was told that I couldn't have won if my ship didn't have plasma D. So what now? We nerf or remove plasma D from ships? ( I let the other player set terms so c'mon ) Also told that another victory of mine was because person was tired. I didn't bother to say that I had been up 18 straight hours and was tired myself.
Let's just fix the game if it can be done to run clean on modern operating systems and not advocate changes because player A used a ship that's always been available to defeat player Bs' choice.
-
War is all about who has the better weapons, tanks, airplanes or ships at a given time. Sometimes just a release of a new thing would create an advantage.
All multiplayer games have to deal with this.
If a game was only A against B, and A > B, we would just need to nerf A or buff B.
But imagine that in a 3-player game, B > C, but even so C > A, how would we fix this?
If we boost A, cause it looses to C, then B would just get destroyed when playing A, etc.
Sometimes A, B and C are just diferent, and will never get perfectly balanced.
Game balance issues are the most common theme in a multiplayer game.
Some of the funniest videos are about it... for example
world of warcraft... https://www.youtube.com/watch?v=tRGDcwOxBzY (https://www.youtube.com/watch?v=tRGDcwOxBzY)
hearthstone... https://www.youtube.com/watch?v=dWA71iBD0-A (https://www.youtube.com/watch?v=dWA71iBD0-A)
league of legends... https://www.youtube.com/watch?v=Lnowbp88lwI (https://www.youtube.com/watch?v=Lnowbp88lwI)
So tournaments create some workarounds...
Like forcing a player to choose 3 ships, and when it wins with A, then it can only play with B or C next.
Or if a player won, then in next game he is the first player to choose a ship, so the other can counter it with a better choice.
Or like in chess, white has an advantage, so they switch sides each game.
People add clocks, restrictions, so the game can end in a draw, etc...
-
I think I have mentioned the following reminder a few times over the years. The biggest killer of the player base was not being able to play dynaverse on post XP operating systems. Fixing bugs etc. is great. Changing things to suit a person or 2 while still hoping to grow back the player base is dangerous. People were generally accepting of non-sfb issues and thankful to have a closely resembling computer game. Leaving XP behind was the last nail in the coffin.
I'll now move into an area where I can get slapped more for my thoughts. I used too many HETs in a victory, so after 14 years (sfc2) we should nerf HETs? (my opponent used 3 HETs that I recall to my 12 in 2 hours and 9 minutes) In other games last week with someone else, I was told that I couldn't have won if my ship didn't have plasma D. So what now? We nerf or remove plasma D from ships? ( I let the other player set terms so c'mon ) Also told that another victory of mine was because person was tired. I didn't bother to say that I had been up 18 straight hours and was tired myself.
Let's just fix the game if it can be done to run clean on modern operating systems and not advocate changes because player A used a ship that's always been available to defeat player Bs' choice.
:goodpost: I couldn't have said it better.
-
I'll now move into an area where I can get slapped more for my thoughts. I used too many HETs in a victory, so after 14 years we should nerf HETs?
No, we shouldn't nerf anything, like HETs. In SFB, we would often have post-battle discussions. I suppose I sounded like I was complaining, Tobin. But it was combat analysis from a frustrated loser (me in my R-KE). HETs should be risky, in my opinion, certainly after the first one. Wouldn't that result in more interesting battles and reward a player for attaining an advantageous position? Maybe it wouldn't matter. So an HET regeneration option for the SFC_Editor is harmless for those who want to experiment.
I was told that I couldn't have won if my ship didn't have plasma D. So what now? We nerf or remove plasma D from ships? ( I let the other player set terms so c'mon ) Also told that another victory of mine was because person was tired. I didn't bother to say that I had been up 18 straight hours and was tired myself.
I know players get annoyed when they lose, myself included, and come up with excuses -- mechanical or personal -- for their defeat. We may be rusty in our sportsmanship. It will get better. "GG. Let's play again." will be the norm or we are doomed.
Let's just fix the game if it can be done to run clean on modern operating systems and not advocate changes because player A used a ship that's always been available to defeat player Bs' choice.
Indeed. But I can't do that without (or perhaps even with) source code. In the meantime, I'll add more options for the SFC_Editor. Nobody ever has to use the thing. This Starlance cycle actually prohibits it (no hex edits). I'm advocating a sort of Omega Sector capability for SFC.
Thanks for your input, Tobin. I value everyone's comments.
-
Additional thoughts on HETs. You won't usually see any body use 12 HETS in a game, because you usually won't have a 2 hour plus battle. I might have used 1 in our 100 late asteroids match which was a more normal length. Also, since not all ships can HET, I am wondering if there are other variables like how fast the recharge rate happens depending on class of ship or just ship to ship, or some other factors? Most dreds can't HET. (66% chance?) The fed CLC light cruiser can't (83% chance) I never liked the FED-CLC for PvP because of that rare lack of a HET in the light cruiser class.
-
True, TobinDax. A few non-Dreads do have a chance of failure even with the 33% bonus. All the Federation New Light Cruisers and the Battle Frigate top out at 83%. Same with the Gorn Old Light Cruisers and Old Destroyers, and, surprisingly, the Lyran Battlecruisers. This weakness gives them character. But this seems like such an exclusive club.
SFC might be better if an HET is truly a desperation maneuver rather than an ordinary (yawn) pivot for the vast majority of non-Dreads. If a Dread or Battleship suffers a breakdown, they're almost certainly dead -- that's the way it should be for these oversized, overgunned monsters.
What regenerates in SFC? Shields (limited by labs), fighters (limited by deck crews), Pseudo Torps, Warp/Apr/Impulse, and HETs. The last three have no limits... :coolsmiley:
The rate of HET regeneration is 2.5% per turn for every ship. So the HET bonus is restored in 13.5 turns, roughly the length of an SFB tournament ship duel. Is a guaranteed HET every 7 minutes too frequent? :huh:
-
You can control HET % and bonuses manually through the shiplist.
On another completely different topic:
Is it possible to hex edit a mission?
-
Is a guaranteed HET every 7 minutes too frequent? :huh:
In 16 years of SFC I've never seen anyone fret about HETs except for this conversation.
Fights are just longer in SFC, regenerating HETs has never been an issue because of this.
-
Is a guaranteed HET every 7 minutes too frequent? :huh:
In 16 years of SFC I've never seen anyone fret about HETs except for this conversation.
Fights are just longer in SFC, regenerating HETs has never been an issue because of this.
How about we limit the number of times a Rom can cloak? Or maybe put a recharge rate on it so he can't just fire an R torp and cloak and then rinse and repeat? Leave the game alone.
-
How about we limit the number of times a Rom can cloak? Or maybe put a recharge rate on it so he can't just fire an R torp and cloak and then rinse and repeat? Leave the game alone.
Cloak has no SFB/SFC limit per scenario, of which we are all aware. Fighters had infinite regeneration, which we thought wasn't ideal, so that was patched by Magnum long ago, he didn't leave it alone.
The game was left alone for about 10 years. And how was SFC doing a year ago? Here we are in a thread with 20,000 views about hex editing. I think there is interest in enabling "house rules" and wild mods. If someone wants an option to limit Cloak in some way, that's great. I don't have to enable that option.
Again. Nobody is required to use the SFC_Editor, or anything that Adam, d4v1ks, TAnimaL or I have labored many, many hours upon. I'm getting tired of repeating myself. I am not imposing anything on anyone.
EAW 2.036, CE 2.670, and OP 2.552 are all available if someone thinks they are superior mothballed products.
I'll get back to work on the Sprites.q3 to enable an extra heavy weapon hardpoint on a model...
-
You can control HET % and bonuses manually through the shiplist.
On another completely different topic:
Is it possible to hex edit a mission?
The HET% is bugged when set low. It actually goes up after a ship suffers a breakdown. The HET+2 bonus always regenerates, which is precicely the feature that is being discussed. Is a one-time bonus considered too radical for this game? Anyway, I don't know the offsets that control HET behavior other than rotational velocity and movement cost, so I'll not comment further on a hypothetical issue.
EDIT: If a ship has two HET bonuses (e.g. K-F5), the first bonus does not regenerate. The second bonus does regenerate. I wonder why. Interesting.
Missions can be hex edited. Although with the mission API and Visual Studio you can edit them properly in a higher level language. No need to hack them with a crude Hex Editor...but if you don't know C++, go for it.
-
Well, all I want is to make more maps for the Ion Storm skirmish. I was always peeved that they only gave us that tiny map. Barring placing more maps, I'd like to make the one map a medium map.
If you could make an editor that can do simple stuff like change terrain and maps that would go a long way. There are a lot of missions out there that could be spruced up a bit without heavy lifting.
-
You can control HET % and bonuses manually through the shiplist.
On another completely different topic:
Is it possible to hex edit a mission?
The HET% is bugged when set low. It actually goes up after a ship suffers a breakdown.
23rd century duct tape is just that awesome! :D
Perhaps you could try an experiment where all ships are set at 83% with the recharging HET bonus and at 100% with the two bonus that doesn't. Then HETs become valuable, but riskier after time. Plasma would get a boost out of that (especially on a small map; D2 IDK) and then your slower plasma idea might have more merit to my mind.
And Tar, please don't feel like we are arguing with you or being dismissive about your proposals, but they must be able to stand up to spirited debate or what's the point of posting them?. Some theories need to be well play tested before they can be called good. One person can rarely think of everything when a change is implemented.
Also, since you guys are putting out patches and other tools, sometimes it is hard to discern right away whether you are tinkering or "fixing" for release. Perhaps preface some of your ideas that fit with "This is just an experiment. Try it out".
-
Perhaps you could try an experiment where all ships are set at 83% with the recharging HET bonus and at 100% with the two bonus that doesn't. Then HETs become valuable, but riskier after time. Plasma would get a boost out of that (especially on a small map; D2 IDK) and then your slower plasma idea might have more merit to my mind.
That is a good experiment. Wouldn't the values be 83% (regenerative) and 116% (one-time bonus)? Not that it makes a difference, except that your 1st HET can be done at 100% with the 16% Erratic Maneuver penalty in CE.
Then the ship regenerates from 50% to 83% in about 7 turns. HETs would be risky, indeed.
Also, since you guys are putting out patches and other tools, sometimes it is hard to discern right away whether you are tinkering or "fixing" for release. Perhaps preface some of your ideas that fit with "This is just an experiment. Try it out".
Right, this thread started as hacking, but it developed into the unofficial patches. So I can see how experimental Omega Sector stuff could be mistaken for upcoming material for the regular game. But I'm not going to start a new thread specifically for Hex Editing of vanilla SFC. This topic is about adding options so that players can customize their games conservatively or radically. That will continue.
Look for the 2.678 Patch topic someday.
-
Well, all I want is to make more maps for the Ion Storm skirmish. I was always peeved that they only gave us that tiny map. Barring placing more maps, I'd like to make the one map a medium map.
If you could make an editor that can do simple stuff like change terrain and maps that would go a long way. There are a lot of missions out there that could be spruced up a bit without heavy lifting.
Mission maps are, for lack of a better word, compressed. This makes hex-editing them a pain. You can add nebulae reliably (it's one character), or rocks but the results are not always what you expect. I think you can add ion storms to a larger map. I don't remember the character for ion storms...but it'll be in the tiny map.
-
Ion storms are weird. Apparently you can lay down one, a few or a ton like in the stock script. There are smaller ones in the Coop Ace script and Karnak used a few placed ones in some of his scripts. I don't know how they get them to clump. Perhaps each ion storm overlaps it's neighbor just a bit.
-
And your tinkering got me thinking and I might try going the other direction an make plasma speed based on size with sort of a drone feel.
R = Speed 32 - Extra large warhead, slow speed and excellent duration.
S = Speed 36 - Large warhead, medium speed and good duration.
G = Speed 38 - Medium warhead, fast speed and moderate duration.
F/I = Speed 40 - Small warhead, very fast speed and low duration.
X = Same as stock and I say it's just an up-jumped F Torp which explains it's speed, lack of special settings and early decay rate.
D = 45(ish, maybe faster, I'll have to play around) - These suckers are useless against fighters right now if they are flying away from the torp, which is a lot. Drones will die a bit faster, but since they fire too many anyway and the drone is obliviously flying to it's doom, it doesn't really affect that much on that front.
EDIT: I knew something didn't sound right. F and G torps are speed tied. I'll have to think some more.
-
Corb, if you reduce the speed of a Plasma torp, you have to increase its endurance. I don't think that data has been found in OP yet. Or maybe it does so automatically? I forget.
If I make a speed-18 PlaS in Community Edition, it will burn out at range 13. So I need to increase the endurance from 26/36 to 26/18. That 26 in the numerator is the SFB range in hexes (25) plus 1 to account for SFC's 0.99 typical range extension. That 18 in the denominator is the custom speed. Then you literally get a half-speed PlaS. Stationary targets just have more time to sweat.
The variables to find will be:
X = ~24.1/40 = ~0.6025
R = 31/36 = 0.8611
S/E = 26/36 = 0.7222
G = 21/36 = 0.5833
F/I = 16/36 = 0.4444
D = 16/36 = 0.4444
-
The plasma ranges are in the OP Editor, but the 3rd and 4th brackets say they are they same (both 15.9). Is that right? Why would you need two inputs for the same range value?
-
If you don't have these entries in your OP offsets.txt, here you go:
397A50: 1d // Plasma-R endurance {range/speed} // 0.8611
397A48: 1d // Plasma-G endurance {range/speed} // 0.5833
397A40: 1d // Plasma-F/I/D and Dro-D endurance {range/speed} // 0.4444
397A38: 1d // Plasma-X endurance {range/speed} // 0.6200
397A30: 1d // Plasma-S/E endurance {range/speed} // 0.7222
Lots of shared stuff. The 16 hexes (for 15.99k) would apply to Plasma F, I, D and the bugged Dro-D.
So if I want a true SFB Plasma-R, I would decrease the speed to 32 (320.0) and increase the endurance to 31/32, which is ~0.9688. If I don't do this, the PlaR will run out of gas at about 27.5k instead of 30.9k.
-
No, I mean in the editor the description says if you want 15.9 to use a 3 in the field. Then it says if you want 15.9 to use a 4. Why does it need two integers that do the same thing. Why not just use the 3 all the time?
-
The Plasma types each have a magical internal ID.
R = 0
S = 1
G = 2
F = 3
I = 4
D = 5
X = 6
E = 7
Dro-D = 40
Then they are assigned incrementally to a range via a table.
.text:0041E5F2 db 0 ; R ; +0 bytes
.text:0041E5F3 db 1 ; S ; +4 bytes
.text:0041E5F4 db 2 ; G ; +8 bytes
.text:0041E5F5 db 3 ; F ; +12 bytes
.text:0041E5F6 db 3 ; I ; +12 bytes
.text:0041E5F7 db 4 ; D ; +16 bytes
.text:0041E5F8 db 5 ; X ; +20 bytes
.text:0041E5F9 db 1 ; E ; +4 bytes
These numbers on the left are used to find the correct offset. They are multiplied by 4 to calculate the displacement for each Plasma type in a "jump table". Each offset is 4 bytes apart. So PlaR jumps to the first offset (+0 bytes). PlaS jumps to the second offset (+4 bytes), the same as PlaE. PlaF and PlaI jump to the same offset at +12 bytes. Etc.
It is highly confusing. These calculated offsets are links to locations within the function.
.text:0041E5B6 dd offset loc_41E164 ; +0 bytes, jumptable 0041E15D case 0 ; PlaR
.text:0041E5BA dd offset loc_41E26E ; +4 bytes, jumptable 0041E15D cases 1,7 ; PlaS,PlaE
.text:0041E5BE dd offset loc_41E1B8 ; +8 bytes, jumptable 0041E15D case 2 ; PlaG
.text:0041E5C2 dd offset loc_41E1F9 ; +12 bytes, jumptable 0041E15D cases 3,4 ; PlaF, PlaI
.text:0041E5C6 dd offset loc_41E201 ; +16 bytes, jumptable 0041E15D cases 5,40 ; PlaD , DroD
.text:0041E5CA dd offset loc_41E243 ; +20 bytes, jumptable 0041E15D case 6 ; PlaX
-
And your tinkering got me thinking and I might try going the other direction an make plasma speed based on size with sort of a drone feel.
D = 45(ish, maybe faster, I'll have to play around) - These suckers are useless against fighters right now if they are flying away from the torp, which is a lot. Drones will die a bit faster, but since they fire too many anyway and the drone is obliviously flying to it's doom, it doesn't really affect that much on that front.
I isolated and implemented speed-64 PlaD tonight. This feels proper. SFB be damned. ;)
PlaF and PlaI still use speed 36. There's no technical reason PlaD can't go faster (or slower) for a mod.
If you want to try it out, put these lines in your OP offsets.txt, Corbomite:
397F30: 1d // New! Plasma-D and Dro-D endurance {range/speed} // 0.4444
1E203: 2op // New! Plasma-D and Dro-D pointer; old (40 7A); new (30 7F) // 30 7F
You'll need to overwrite the pi filler for the initial endurance value. Then adjust the pointer to find it downstream.
I assume you'll check it for default behavior as I did. After that, set the PlaD speed to 72.0 and the PlaD endurance to 0.2222 and you've got double speed, but regular range and damage. Or you could do speed 45.0 and 0.3555 endurance. Or any speed entry, such as 64, that has endurance of 16/speed, which is 0.25 in this case.
-
Once I figure out what all that means I will try it.
-
StarfleetOP.exe
I found a possible conflict in the OP offsets.txt.
39E5D4: 1f // Transporter range x10 for Raiding, Capturing, and beaming items // 59.999
Two functions read this data. Only the first one is related to transporter range.
Add these lines to OP's offsets.txt:
39E5E8: 1f // Data isolation from transporter range. Change to 59.999. // 59.999
11BD59: 1op // New pointer for isolation. Change (D4) to (E8) // E8
These have been added to the revision of StarFleetOP.txt. Found in the SFC:OP HD stickied post.
This will alllow you to create a 59.999 for that second function -- which appears to be unrelated to transporters. This function might be for the AI's Phaser-1, such that it prefers 5.99k. Just a wild guess, at this point.
-
You should really just collect these and release a new offsets.txt.
-
Tar, do you have a copy of the OP offsets and if you do have you been systematically updating it as new things develop.
I have decided to primarily work on Community Edition. Unless someone has a specific question about OP, I'll rarely be looking at a game for which the source code has been forever lost. CE has the potential to incorporate the best of OP...and it's burdensome to duplicate my efforts on OP (or triplicate them with SFC3). Perhaps it is selfish, but I don't have unlimited time to devote to EAW/OP/SFC3 -- which I don't play.
I'll add the new offsets for an updated OP offsets.txt. It won't be part of an executable/graphics patch. Offsets.txt has the potential to be updated at a much greater frequency than .exe patches as TAnimaL and others find associations between data and game mechanics.
-
You should really just collect these and release a new offsets.txt.
Done.
https://onedrive.live.com/redir?resid=AA9122667945A037!334&authkey=!AMRavJ5zzUlJtNE&ithint=file%2ctxt (https://onedrive.live.com/redir?resid=AA9122667945A037!334&authkey=!AMRavJ5zzUlJtNE&ithint=file%2ctxt)
With the latest patch, Carlos has cleaned up the installation. So now there is a new folder for tool assets called SFC_Editor in the root folder. The generic "offsets.txt" has been given a more descriptive name, "StarFleetOP.txt".
The path will be something like C:Games\Orion_Pirates\SFC_Editor\StarFleetOP.txt
-
Fear not, i still got some energies for SFC OP.
Today i went a little beyond the common hex-editing and wrote an entire function for OP that enables it to choose randomly a "skybgnd-mono" texture from a path.
I limited it to 15 atm, but it can be any number you wish.
The path will be: ".\Assets\Textures\skybgnd-mono\"
And the they will be named: "0.bmp", "1.bmp", etc
To get space for that function i had to remove something from OP.
So i decided to remove the 2 little functions that write a log into "WeaponDamage.txt".
As it seems, each time you fired something, the program would open that file, append something and then save. That could cause some lag, so i traded this feature for that one.
(http://i.imgur.com/xJu9QP4.jpg)
-
Wow!! :o
So this does this in game each time you go into a nebula?
I believe that WeaponDamage.txt is probably a leftover dev tool like vollyinfo. I have never understood why we needed that file. Play will tell however.
-
So this does this in game each time you go into a nebula?
Yes, it is random.
Edit:
The function generates a random number and then loads the exact texture, by name, when you start the game.
It looks like it continues to use the same texture while you play a campaign...
(http://i.imgur.com/zwjZMVP.png)
-
It looks like that there is a connection between the mission scripts and the old "skybgnd-mono.bmp".
So a copy still has to be present in the standartd "textures" folder, when the scripts check it.
I figured it out when testing the client against the server. The game refused to join a campaign without the old texture in that place.
Have to take a better look in this.
-
It looks like that there is a connection between the mission scripts and the old "skybgnd-mono.bmp".
So a copy still has to be present in the standartd "textures" folder, when the scripts check it.
I figured it out when testing the client against the server. The game refused to join a campaign without the old texture in that place.
Have to take a better look in this.
Not surprising. It also checks for model size files being compatible. Ion storms cause damage, so even I put a suggested sameness of textures in my Read Me when playing in multi with others to prevent any tactical difference, even if it only visual. We are finding that skybgnd-mono is used for quite a few things here and there. The weird part is that they have four textures that are basically the same thing, but only seem to use two that I can find. The others must be called somewhere, but I can't place where.
-
I believe that WeaponDamage.txt is probably a leftover dev tool like vollyinfo. I have never understood why we needed that file. Play will tell however.
Wouldn't that be used at the end of a match to determine prestige points or battle stats?
-
I believe that WeaponDamage.txt is probably a leftover dev tool like vollyinfo. I have never understood why we needed that file. Play will tell however.
Wouldn't that be used at the end of a match to determine prestige points or battle stats?
True, that might be where the debriefing screen gets it's info, but I don't know why it would need to know that some obscure missile ran out of gas and disappeared. I'll check if this goes forward. There are already a few glitches.
d4v1ks - Most times all CRC listed files have to match for the server and all players wishing to join. If the server and everyone on it have the mod it should be ok as long as it always gives the same random neb/ion storm to players in a unique mission together. This may not be possible, but choosing one of each for the server and having everyone pick it would again line things up.
-
Yes... in singleplayer it works fine, but in multiplayer it refuses to work sometimes...
Well, the random nebula function is 45 bytes long. So i just need to find another place to insert it if is that the case...
Or maybe is the memory buffer where i allocated the result. Had to overwrite something...
Resources are limited.
-
I believe that WeaponDamage.txt is probably a leftover dev tool like vollyinfo. I have never understood why we needed that file. Play will tell however.
SFC Community Edition does not write to WeaponDamage.txt. I don't see how this text file is crucial to Dynaverse campaigns for EAW or OP. It would cause noticable lag as this file is opened, written to the harddrive, and closed 8 times on each player's machine as two Dreads exchange close-range missile fire.
Wouldn't that be used at the end of a match to determine prestige points or battle stats?
Unlikely. It was probably used in debugging Seeking Weapon shifts. Taldren disabled these shifts for multiplayer.
-
Good news...
I was able to isolate the place where the nebula is loaded (skybgnd-mono.bmp).
There are other 3 references to the same texture in the game.
If you know where they are used maybe we can give it their own texture.
Writing a function in assembler was is probably the most painfull thing i did these last times...
The exe is a static object! Can't expand it or edit it easily.
Had to highjack a "push offset" (5 bytes) and turn it into a call to a fake function with 1 argument. Luckly the "call offset" is also 5 bytes length.
Now keeping the stack pointers, registers and flags all in place and healthy, saving, loading arguments and executing calls to c++ rand and sprintf was a nightmare.
The program i used to do it is not an editor per se, and didnt wanted to save/update the changes sometimes.
In the end, i still removed the 2 functions that write a log into the WeaponsDamage.
Till now, i didn't had any issues while playing missions in multiplayer or when the missions ended.
All seems ok.
Resuming...
the textures will be saved in ".\Assets\Textures\SkyBgnds\"
and named "0.bmp", "1.bmp", etc
The funny part is that this function, in c++ code, would take 5-10 minuts to write and test...
So i dunno if i will have courage to do something like this soon.
(http://i.imgur.com/GO6G5GM.jpg)
(http://i.imgur.com/UgiysUV.jpg)
-
Good news...
I was able to isolate the place where the nebula is loaded (skybgnd-mono.bmp).
There are other 3 references to the same texture in the game.
If you know where they are used maybe we can give it their own texture.
That is good news. We know what two of the calls are, I told you those. Sometimes they use them so subtly that it's hard to tell what they go to.
-
bitmap should be 6 files
-
Found another use for the "skybgnd-mono.bmp" texture...
Maybe it is better to split them rigth now. Make an entry for the shields, other for the black holes, and let the last reference as it is...
This will cover all the texture references in the executable...
I will do it in a sec...
(http://i.imgur.com/V8UIAwi.png)
-
Oh good find! Now I know why those suckers are square! I can fix that. If you can isolate Black Holes and Shields man o' man can we make improvements!
-
Starfleet2CE.exe
I found the variable that determines Phaser Efficiency vs Plasma. It is initially set to 0.25d. Doublechecked everything and the customizable variable works. Plasma is easily thwarted in normal SFC with 50%+ efficient Phasers vs Plasma Torps. You can starcastle if you can't phaserboat. 20% to 30% is reasonable.
I also found those peculiar Plasma Damage Brackets. You'll be able to adjust the decay rate for all the plasma types. Unfortunately many of the damage multipliers are shared with unrelated functions, so it will take time to isolate them. But the brackets for Plas-R, S, and G are easy to edit.
Modded Plasma-"R" (Plasma-R2?)
Damage after traveling nominal hexes
0-10 = 50
11-15 = 45
16-20 = 40
21-25 = 35
26-28 = 20
29-30 = 10
31 = 1
or
Modded Plasma-"R" wave (Plasma-W?)
Damage after traveling nominal hexes
0-10 = 5
11-15 = 10
16-20 = 25
21-25 = 50 :knuppel2:
26-28 = 25
29-30 = 10
31 = 5
endless mods...
Add to CE offsets.txt
63B990: 1f // Plasma-R 1st range bracket // 0.3548 ; 11/31
63B99C: 1f // Plasma-R 2nd range bracket // 0.5161 ; 16/31
63B9B0: 1f // Plasma-R 3rd range bracket // 0.6774 ; 21/31
63B9C8: 1f // Plasma-R 4th range bracket // 0.8387 ; 26/31
63B9D4: 1f // Plasma-R 5th range bracket // 0.9355 ; 29/31
63B9E4: 1f // Plasma-R 6th range bracket // 0.9677 ; 30/31
63B998: 1f // Plasma-S 1st range bracket // 0.4231 ; 11/26
63B9A8: 1f // Plasma-S 2nd range bracket // 0.6154 ; 16/26
63B9C0: 1f // Plasma-S 3rd range bracket // 0.8077 ; 21/26
63B9D0: 1f // Plasma-S 4th range bracket // 0.9231 ; 24/26
63B9E0: 1f // Plasma-S 5th range bracket // 0.9615 ; 25/26
63B9A0: 1f // Plasma-G 1st range bracket // 0.5238 ; 11/21
63B9BC: 1f // Plasma-G 2nd range bracket // 0.7619 ; 16/21
63B9CC: 1f // Plasma-G 3rd range bracket // 0.9048 ; 19/21
63B9DC: 1f // Plasma-G 4th range bracket // 0.9524 ; 20/21
The values for the brackets should increase from one to the next. Giving a 4th bracket a value less than the 3rd bracket is not going to crash the game. It is just difficult for a person to follow the flow. You can give the first bracket a value of 1.0, and the torpedo will not degrade as it travels -- same as a missile.
-
Starfleet2CE.exe
I noticed a redundant 360 degree arc in the code. So I renamed it "RMLR" for Rear-firing Mauler to do a test. Then I altered the starting position to 190 degrees and the ending position to 170 degrees (measuring counter-clockwise). After that I updated the bitmap with Paint, Gimp, and dropped it into Sprites.q3 with the Q3_Editor. It works.
-
Starfleet2CE.exe
I noticed a redundant 360 degree arc in the code. So I renamed it "RMLR" for Rear-firing Mauler to do a test. Then I altered the starting position to 190 degrees and the ending position to 170 degrees (measuring counter-clockwise). After that I updated the bitmap with Paint, Gimp, and dropped it into Sprites.q3 with the Q3_Editor. It works.
You have a good eye for those little details.
Good work.
-
Starfleet2CE.exe
I noticed a redundant 360 degree arc in the code. So I renamed it "RMLR" for Rear-firing Mauler to do a test. Then I altered the starting position to 190 degrees and the ending position to 170 degrees (measuring counter-clockwise). After that I updated the bitmap with Paint, Gimp, and dropped it into Sprites.q3 with the Q3_Editor. It works.
OP has a bunch of extra arcs coded, but they have the wrong pie slice on the display when showing the arc. Maybe I should look into doing them right.
-
I figured out the mysterious third float in the arc function. It is the midpoint of the arc. I guess this is for AI purposes because a player doesn't care about the midpoint of an arc with such precision.
I noticed errors in the midpoints for RW, FLL, RRP, SFBR, and SFBL. Perhaps the AI will do better with accurate information.
Here's an attached picture of the common "FA" arc. Orion Pirates may use the number 8192 to indicate 360 degrees. OP does not directly use degrees.
-
Starfleet2CE.exe
Why not make the neglected arc "120" fully customizable for your favorite mod?
For example, the "MLRX". Start 10, End 350, Midpoint 0. This gives a Mauler-ish weapon a 20-degree arc instead of a 10-degree arc (the default for the conjectural MLR). The FRRX, FLLX, and KFX's rear-firing sectors get 20 degree coverage. LS an RS are actually 200-degree arcs, not 180 as you would expect. (Orion Pirates uses a 20-degree arc for the Mauler and a narrow 10-degree arc for the ESG Lance.)
So here's a look at the SFC_Editor in action...
-
I figured out the mysterious third float in the arc function. It is the midpoint of the arc. I guess this is for AI purposes because a player doesn't care about the midpoint of an arc with such precision.
There is one weapon where that is important - the Attack Probe.
-
I figured out the mysterious third float in the arc function. It is the midpoint of the arc. I guess this is for AI purposes because a player doesn't care about the midpoint of an arc with such precision.
There is one weapon where that is important - the Attack Probe.
Attack Probes are 360 degree weapons in SFC. Always have been, right?
-
I really wanted my SFBL and SFBR to be a little wider. Same degrees as FA/RA.
This is a neat find. Ty. If I feel a little better today I will try to find in via Hex in OP.
And btw. I love the RMLR. Only bc in my TNG shiplist; I have always believed the Cardassian had a purposes for that funny pitch fork butt on all their ships. Would make an excellent arc for a special weapon if they are being chased. Thanks for the find/creation of the RMLR.
I think I'll set the defaults for the custom arc to MLRX, because the MLR doesn't have a bitmap pie in CE -- an incorrect bitmap gets drawn. I have already updated the sprites to provide the MLRX with accurate bitmaps.
I bet OP has these redundant but functional arcs too: "180", "120". No shiplist or ftrlist has these as entries.
---
This is what you're looking for, Adam?
-
I figured out the mysterious third float in the arc function. It is the midpoint of the arc. I guess this is for AI purposes because a player doesn't care about the midpoint of an arc with such precision.
There is one weapon where that is important - the Attack Probe.
Attack Probes are 360 degree weapons in SFC. Always have been, right?
Unless I'm mistaken though they can be fired any direction they can only hit dead ahead.
-
I did not notice that correlation, Nemesis. In my recent battle with Tus, my flashed-and-tractored Battlehawk decloaked just in time to fire my probe at his scatterpack, destroying it before it bloomed. It was 30 degrees off my centerline.
I had an ounce of energy for Orion Pirates today so here's a look at the weapon arcs in StarfleetOP.exe. They work the same way as in CE. Draw the arc counter-clockwise. Nobody would ever have guessed that the values are integers as hexadecimal representations of 22.75555556 * n degrees. But there was a clue in CE.
OP Weapon Arc degrees in hex * 22.75555555
360 = 0x2000
355 = 0x1F8E
350 = 0x1F1C
345 = 0x1EAA
330 = 0x1D55
300 = 0x1AAA
270 = 0x1800
240 = 0x1555
210 = 0x12AA
190 = 0x10E3
180 = 0x1000
170 = 0xF1C
150 = 0xD55
120 = 0xAAA
90 = 0x800
60 = 0x555
30 = 0x2AA
15 = 0x155
10 = 0xE3
5 = 0x71
0 = 0x0
-
Here you go Adam. Add these 5 lines to your StarFleetOP.txt file.
Tab Arcs
D7E73: 1i // SFBL start // 6826 (300 degrees)
D7E78: 1i // SFBL end // 5461 (240 degrees)
D7E92: 1i // SFBR start // 2730 (120 degrees)
D7E97: 1i // SFBR end // 1365 (60 degrees)
If you want wider arcs, use:
7509 for SFBL start (330 degrees)
4778 for SFBL end (210 degrees)
3431 for SFBR start (150 degrees)
682 for SFBR end (30 degrees)
-
I figured out the mysterious third float in the arc function. It is the midpoint of the arc. I guess this is for AI purposes because a player doesn't care about the midpoint of an arc with such precision.
There is one weapon where that is important - the Attack Probe.
Attack Probes are 360 degree weapons in SFC. Always have been, right?
Maybe I'm confusing it with SFB rules. How about the mauler arc?
-
The Mauler arc in OP is 20 degrees. It has a midpoint of straight ahead, 0 degrees. How this represents the SFB arc isn't clear. I think they are close. The SFB Mauler could attack ships that were a couple hexes off the direct column of hexes at range 9 or 10.
EDIT: My contributions to this topic will continue here (http://www.hotandspicyforums.com/hex-editing-of-sfc-t18867.html).
-
I have decided to offer my SFC 2.679 disassembly database to everyone.
https://1drv.ms/u/s!AjegRXlmIpGqglXJnFCyTRNgHi6d (https://1drv.ms/u/s!AjegRXlmIpGqglXJnFCyTRNgHi6d)
I request that any executables that you create should use a splash screen version number, starting at 2.700 or greater. My work will be defined as versions 2.671 through 2.699.
I hope that someone will find this database to be useful.
Thank you.
-
I am sure this is another known issue, but I think since you guys are making so much progress on the .exe, I thought I would bring it up.
There is ERA start dates hard coded into the EXE. I have tested and tried this out numerous times with great frustration.
Firstly the mod I am working on starts in TOS currently at 2248-2263, 2263-2278, 2278-2293, 2293+.(15 years per ERA)
So editing the Time file is only a superficial way of showing years progression. The inner working of the game (EXE) seems to be set in stone for 2263,+10+20,+30. This affects ships being released at the correct times, drones, and fighters..etc etc.
The Dynaverse engine doesn't like using negative numbers or years, it only works correctly when you start at zero, and that is only part of the issue with starting in my TOS ERA. Ships cannot get released in the proper year because the EXE thinks it has already released them. The EXE is running from 2263 onwards as time progresses..so it is always running 15 years ahead. When I run 2263 middle era everything is fine from there on. However, If I run late ERA, ships are 5 years behind, and Xgen is 10 years behind. I logically used 15 years in an ERA's so that X-Gen would work out on the proper years. McCoy pipes in "Damn your logic Spock!!!"
So basically what is happening in my mod is any era that is not set with the original timing of the hard code or original time file, gets out of sync. Ships will be released years ahead of their time in the early era, or not released until much later in late eras. Of course, fighters and missiles also get all screwed up because of this. This is affected by any era you pick, other than the middle ERA (2263). It is crystal clear to me now that each era must have its own start date hard coded! :banghead:
The only options I really have at this point for the campaign to "appear" to work correctly change all my early ERA ships list dates starting at 0 then add +10 to all others plus use the original 10-year eras. Basically having a "fudge factor" starting the year at 2253 in the time file. Then, of course, my X-Era will not start when it should, 2283 instead of 2293... It really bothers me to be locked you into a certain time frame! It greatly limits our flexibility and creativity.
If these could be found and if we could change these in the EXE, then mods could work correctly no matter when a mod is supposed to take place. I do feel this is an important issue to work on if it can be done, otherwise, I feel that the work I am doing on my mod will end up another vanilla style mod and will never be released.
Thank you for your time and thoughts
Xeryx
-
Which version of the game do you want to use for your mod? SFC2 Orion Pirates 2.563?
-
I am currently using 2.5.6.3.
The other issue that is a real pain in the rear is the shield reinforcement slider, is there any way to either disable it completely or change the formula? So that it does not dramatically affect the rate at which shields are reinforced. So instead of being able to apply 100% of total energy of the ship available into the shields, maybe it could only do say 20% or 10%? I know this issue has existed since the game was released, just wondering if it is even remotely possible?
Thank You Tar
-
Xeryx, I don't understand the issue with shield reinforcement. If I set my energy priorities with shields at least important ("5"), then the shields will never draw much power. Only after movement, weapons, and sensors are satisfied will the shields get any juice.
I guess you're talking about the AI? Or just automating shield reinforcement to reduce micromanagement -- so the slider is disabled. I don't know where to find this function in the exe. I have no idea how the AI does anything.
Shift + Scroll Lock will save your preferences for each ship in Assets\WeaponGroups\wqsb.ini. So you don't have to adjust the reinforcement slider ever again. On red alert the preferences are loaded (takes about 5 seconds sometimes)!
[F-CA]
RedAlertOverride=1
RedAlertEnginePriority=4
RedAlertWeaponPriority=4
RedAlertShieldPriority=5
RedAlertTractorPriority=5
RedAlertEWPriority=1
RedAlertShieldReinforcement=14
RedAlertShield1=0
RedAlertShield2=0
RedAlertShield3=0
RedAlertShield4=1
RedAlertShield5=0
RedAlertShield6=0
RedAlertECM=1
RedAlertECCM=2
RedAlertSpeed=14
RedAlertWeapon1=N
RedAlertProjectileType1=
RedAlertWeapon2=N
RedAlertProjectileType2=
RedAlertPhaserCap=49
-
An issue with time is missile speed. If I recall correctly, medium-speed missiles arrive at year zero +5. This can likely be modified to year zero +15 or whatever. The game uses 163 (for Y163) and 2263 as hard-coded starting dates in functions. As you know, the first year of a campaign can be set at 0 or 1984 or 2010 or whatever. This is unfortunately a cosmetic number with no SFB-based meaning.
time.gf
[Clock/StartingDate]
BaseYear = 2263
0 = 0
1 = 10
2 = 20
3 = 40
I asssume these values for 0,1,2,3 are ignored?
I found the variable that is added to the shiplist's Year First Available. This is called the "Date Introduced" in the vessel library. I tried a value of zero, instead of the default 2263. The vessel library can handle negative numbers. So the Fed CA shows as "-33" in that case for its YFA.
Add these lines to your StarFleetOP.txt in the SFC_Editor folder...
Tab Year
CDA68: 1i // Vessel Library's "Date Introduced" (Shiplist YFA is added to this value) // 2263
All seems cosmetic. I don't know how the dynaverse campaign time works yet. Somewhere "BaseYear" gets +10. So it would be something like the following in IDA:
mov eax, BaseYear
add eax, 0Ah
-
Tar,
Thank you!!
I will add this soon and see how the TOS section works.
Think of it as 2 clocks. One in the EXE and one from the Time file. We can change the Time file, but if the EXE time is not matched to the same a the eras in the Time file then the two will become out of sync. Because the game uses the EXE game clock for almost everything.
The easiest way to test this is to watch for ships to be introduced in the campaign, I spent a lot of time doing this trying to figure out this issue. Initially, I was focused about my TOS scratching my head about how ships that should not be available to buy at the auction kept showing up. I kept playing with the dates of the ships and then I decided to try the other eras. Middle worked exactly as it was supposed to, ships released on their commissioning dates. The rest is explained above.
If you watch the news in the campaign, it will tell you when a ship is commissioned. To properly get your ships commissioned through the eras, your time needs to start at a zero date. For example, when I run my TOS era..every ship is already commissioned in TOS, because the EXE Zero date is 2263, It isn't using the Time file for those things. It is using a time clock in the EXE for missiles, fighters, and ships. The Time file is used for what YOU see and giving YOU a superficial way of changing the start dates of eras and stuff.
If you deviate from the 10-year eras in the TIME file then that is where the problems start.
In a nutshell; Any and all (-) service dates are seen by the game as already commissioned (again watch the Auction you should see those ships available in the auction in and in the News you will never see them). They are not released year by year, I repeat they are not released the year of their in-service date, they are all released at one time. You would use these (-) in-service dates to supplement your early auction with ships for the first year, until more ships get commissioned.
The start date is 2263 in EXE and 0 in the ships and fighter lists, in a stock campaign starting in the Early era which is 2263 all ships before zero are already commissioned. Then you will see new ships appear with a start date after zero get commissioned on a yearly basis when available. Like you said about missiles, it is set to like a +10, 20, or whatever and that is how it know when to release them. But it uses the start date in the EXE to do this, not the TIME file. The TIME file is only a cosmetic change for the years to appear on the screen as you want them. The Real-Game Clock is based in the EXE at 2263, This RGC is what the ships list and fighter list use to release the ships (watch the news feed in the campaign). That is why it is always based on 2263 in the ships list.
In my mod; if I change this Start year in the EXE 2263 to 2248 then all ships must have +15 added to them for the service dates. Then I should see the TOS ships, and all ships thereafter, commissioned in the proper years after 2248.
So until the other ERA start numbers can be found then we will only have 10-year eras to use, and your Time file must match or ships will not commission in the proper years when starting in different ERAS.
I realise that BPV Matching is the most important for Battles but the game also uses ships from the era, so it is important not to have the AI pulling from a more advanced ERA, because it thinks that that ship is already commissioned. For example; In my mod I was seeing TMP era ships in battle against me in the TOS era, because to the game time started at 2263, not my start time of 2248. This was using a fully stocked shipslist, the only faction modded was the feds, with plenty of ships for BPV availability and matching. So it was not a BPV issue but a time issue.
time.gf
[Clock/StartingDate]
BaseYear = 2263
0 = 0
1 = 10
2 = 20
3 = 40
I asssume these values for 0,1,2,3 are ignored?
The RGC (real game clock) ignores these, however like you said they coincide with the ERA's that are hard coded in the EXE. If you change them you will see your campaign era start when you think it should start. Meanwhile, the RGC is always starting at 2263. That is why missiles will not be commissioned correctly because you cannot change the service dates like you can fighters.
You can easily prove what I have said.
Change your TIME file start date to 2258 then find a couple of ships or fighters and change their service date to 1,2, and 3. Then start the campaign in the early era. Even though you will see the year as 2258 when one year passes (2259) ship/ftr 1 should be available and show in the news feed and so on and so on.
So just to reiterate, the 0 year in ships list and fighter list are directly linked to the start year in the EXE, not the TIME file. So when you change the start year in the EXE to 2248 in my case. A ship with an in-service date of 2 will show up in 2250. Not 2265 as intended by the original numbers in the ships list. You would have to change all of the in-service dates to compensate for this change, but ships will commission properly on the date they are supposed to.
Another example, let us say I wanted to do a TNG mod with a start year of 2363 for sake of easy numbers. Let's assume I am starting from scratch with all new ships. Using the stock game file, and using the fictional in service dates, I would have to add 100 to all my ships, for them to come out on actual start date...but guess what! Since the RGC is still starting at 2263. I would have to wait for 100 years to pass in the game for those ships to show up at the auction and be commissioned and show up in the news feed. To make that work, you would have to do some fancy trickery and not use actual in-service dates of the ships, they would all be based on 2263 and 10 year eras. While changing the TIME file to give you the proper visual of the proper year passage.
What if someone wanted to do a real multi-era mod from Pre-TOS to TNG? Naturally, they are limited to 4 ERAS because of the game, so they have to compensate by stretching out each ERA. Do you see where I am going with this? If we can find those additional dates of the +10, +20, and +30 in the EXE, then we can make much better mods where time flows correctly and then we are not locked into a 10 year ERA because of the EXE.
-
Yep, the time stuff is annoying. The +10, +20, and +40 modifiers are in the .exe somewhere. 2273, 2283, and 2303 are not used (at least as integers) in the code as immediate values. So we're looking for these bytes: 0A 14 28
Are you sure the campaign's advanced era begins at +30? I'll look for both +30 and +40...
It could also be determined by date = 2263 + n*10, where n is 0, 1, 2, 3. The 0Ah is the clue. Perhaps the value of "early" is zero, "mid" is one, "late" is two, and "advanced" is three.
Some people have used trickery to make early era feel longer. The first year has 3650 days instead of 365. So ten years of gameplay occurs before the game clock increments to year +1. The server admin adjusts the cycles per year thereafter. Everyone playing sees the year as 2263.1825 by midyear. But 2264.183 would be the next midyear. Not ideal, but you do what you can with the tools we have.
Edit: I found the variables for the eras in Skirmish mode. I don't think they apply to Campaign mode.
Tab Year
CDA68: 1i // Vessel Library's "Date Introduced" (Shiplist YFA is added to this value) // 2263
47BFE4: 4i // Final inclusive year of Era in terms of YFA for Skirmish Mode (Early, Mid, Late, Advanced) // 0, 7, 35, 100
-
Tar,
I did some testing.
The year change works completely for ships in the early era!!! WOOT WOOT
All of my ships show up correctly, all of the ships after 0 show the in-service date 10 years sooner in early era (I changed my start date to 2253). They also show up when supposed to in the campaign, in both the news and the Auction. I still have other eras to test, after my shipslist is complete, but initial testing looks promising.
The fighters however, may be tied to another number. I got strange results but I need to do more testing to ensure my numbers are good.
Here is what I did, I have 4 hawks, I took hawk one, made the ISD (in service date) -15 to 11, Hawk 2 11-21, Hawk 3 21-31, and Hawk 4 31-999.
When I went into skirmish mode and loaded up a CVA, in the early era. Then I went into the supply hanger and when I cycles the fighters, I received a ship not found error! This usually happens when dates don't overlap properly. When in middle era the Hawk 1 shows up, but in Late era, all of them show up. That is very strange, to say the least.
In the campaign, my fighters did not show up when they were supposed too. Maybe you can see if you can replicate this, I will try with a different fighterlist tomorrow, just in case mine has an error.
I wonder if they use this that you mentioned. The game uses 163 (for Y163)
I guess all we can do is "Hope" that they used the same dates as the Time.gf file.
Well good job TAR! just finding the start year was a huge help. Thank you very much.
I still have to go through my ships list and change dates for testing. Maybe tomorrow, not sure as I have to study. I will post more as soon as I can test further.
Unfortunately, I am not a coder by any stretch of the imagination. I wish I could help you find them, though.
I guess baby steps are in order for this.
-
Glad to help, Xeryx. Upon second thought, the Y163 reference is only found in SFC2 Community Edition. I guess Firesoul and Bonk had some input back in 2012 to get SFB-style dates in the game somehow.
The SFC_Editor can modify missile speeds if the campaign is not working as you hope. Let's say medium-speed missiles arrive too early. Just change the speed variable to slow (8, 12, 16 or whatever) for all ship-based missiles (Type-1 and Type-4).
Let me know what's going on with fighters when you figure it out. If a fighter with a YFA of 2268 arrives in 2263, that's a pain. I don't know how to fix that. Hopefully fighters and ships will obey their in-service and retired-from-service dates. There are reports of units not obeying these limits in campaigns. Perhaps there is a % chance for obsolete units to remain in service... Or perhaps there's a % chance for early entry -- prototypes. Just guessing.
-
Hmmm, you mean Kirk is refusing to decommission the Enterprise when he's suppose to, it's plausible.
Sidebar: Tar, I just put the Saratoga Mega Phasers on an Excelsior pylons, LMAO, looks like a BEAST!
(http://i821.photobucket.com/albums/zz139/Nxreliant1864/Image1.jpg)
-
Tar, I just put the Saratoga Mega Phasers on an Excelsior pylons, LMAO, looks like a BEAST!
([url]http://i821.photobucket.com/albums/zz139/Nxreliant1864/Image1.jpg[/url])
:o you are not trying to tease up people with a model pack of some sort, are you?
-
If I didn't have to work 9+ hours and have this terrible NYC commute each day I would but you know how time and fatigue affect modding. Sorry.
I will work harder on it. :P
-
I have been able to do some testing this afternoon, and I am very pleased to say that I have great news.
The new values that TAR provided for the Skirmish helped a lot.
Initially, I used fighters as my testing tool. I spaced out all fighters 2 years apart. So I could determine the effects of the numbers in the era's. Then I could see what fighters showed up and when. When I reached the end of a fighter in the list, It gave me the year. Which corresponded somewhat with the numbers below.
The original values are
0= early,7= middle, 35=late, 100=advanced
Thankfully the numbers were actually very straight forward.
The original year (2263) value is the zero year in the fighter list as well! Mine is set to 2253
In the EXE, I set my year tab numbers to these in the Skirmish mode 9,19,29,100. I kept the hundred years out so that all ships could be included. Then I set up my fighters were also set for ISD's of -50-11, 11-21,21-31,31-999 Great news! All fighters showed up correctly for each era.
Testing revealed that the numbers should be used for the ending date of the ERA. We are now one step closer.
Once I have my ships list complete I will verify with it as well, but I am pretty sure it works just fine.
I am unsure if those numbers above affected the campaign at all, but my fighters worked in exactly as they were supposed to in the campaign as well.
Right now I am just glad things work correctly.
Need to test this; To see if these numbers affect the ERA's in the Campaign, if not then there is another set of numbers that do. Maybe they are similar to the ones Tar already found? Also, the missile ISD's which I will find the exact dates for and report them here. They will be like these numbers were, additive because they acted the same after changing my start date.
I will test my campaign after I make my years of in-service edits, so that should be this weekend sometime.
Great JOB! TAR!
BTW I need my account activated or an activation email sent to me on Hot and Spicy, but no one has answered my multiple emails to them. So that is why I am posting here.
Great Scotts what a great looking ship you have there.
-
I tested missile speed availability tonight. The game treats this differently in campaign mode.
In skirmish mode the era acts as an incremental counter (0 to 3).
Early (0) does not activate the right arrow next to missile speed, so you're stuck with slow.
Mid (1) activates the right arrow, allowing you to choose medium speed missiles. The right arrow is dark.
Late (2) activates the right arrow when you choose medium speed, allowing fast missiles. The right arrow is dark.
Advanced (3) activates the right arrow when you choose fast speed, but nothing is better than fast. The right arrow is bright but useless.
The Skirmish Eras for the SFC_Editor are ignored in Skirmish mode for missile speed. All that matters is the Era choice via the Era button.
Customized Eras do indeed affect ship and fighter selection. If I set the values to 0, 1, 2, 3 then only ships with YFA of 3 or less (Year 2266 by default) will appear in the Advanced-era vessel library. Only fighters with a YFA of 3 or less will appear in spacedock.
In campaign mode, missile speed upgrades are determined by the time.gf modifier.
[Clock/StartingDate]
BaseYear = 0 // 2263 is just for show
0 = 0 // (Negative numbers or letters are converted to zero).
1 = 0 // Medium speed drones arrive in 4th year.
2 = 2 // Medium speed drones arrive in 2nd year.
3 = 10 // Medium instantly available. Fast drones arrive in 7th year.
So obviously the game has hardcoded the values 4 and 17 for missile speed upgrades.
04 00 00 00 11 00 00 00 are the 8 consecutive bytes to search for in the .exe.
Fighters seem to be delayed in appearing in the dynaverse spacedock. A fighter with a YFA of 7 wasn't available until 3 years later than expected. Could simply be some lag in updating the ftrlist. My game turns were quicker than typical, just 90 seconds/turn instead of 10 minutes or whatever for a real campaign.
-
The dates for missile speed upgrades can be customized for your campaigns. It doesn't have to be +4 and +17.
Good thing Taldren picked a number like 17 for the year of fast missile arrival (2280-2263=17). Searching for 16's would have been brutal! IDA found a small number of cmp eax,17h. I actually found the button elements first. Lots of verification going on in the UI.
StarFleetOP.txt:
Tab Year
CDA68: 1i // Vessel Library's "Date Introduced" (Shiplist YFA is added to this value) // 2263
47BFE4: 4i // Final inclusive year of Era, in terms of YFA, for Skirmish Mode (Early, Mid, Late, Advanced) // 0, 7, 35, 100
8689F: 1b // YFA Medium-speed Missiles (button highlighter) // 4
86B4F: 1b // YFA Medium-speed Missiles (button click) // 4
DB0FB: 1b // YFA Medium-speed Missiles (verifier) // 4
868B7: 1b // YFA Fast-speed Missiles (button highlighter) // 17
86B63: 1b // YFA Fast-speed Missiles (button click) // 17
DB100: 1b // YFA Fast-speed Missiles (verifier) // 17
-
Tar you are Nailing these Numbers man!
Those Missile numbers affect the campaign too!!
I set my medium missile numbers to 11 and fast 21, and they showed up on the correct years in the campaign, so they affect both!! As far as the Fighters, you need to move to another starbase for them to become active for some reason, but they do show up in the proper year. Missiles do also, you just exit out of the equip screen and go back in. Maybe they have some verifiers and button clicks too that were missed the first time.
I am glad they used a 17 as well to make it easy to find!
Now I can match my missiles to my eras!!! WOOT WOOT!! This is friggin AWSOME!!
I will test the ERA's numbers today for campaign effects.
I think the Bases are loaded and you are about to hit a grand slam!
EDIT: After further Testing, because I could not wait.
I am going to break this down, I hope that I can make this simple without wordiness bear with me.
The TIME.GF file controls the START date of an Era for a campaign.
The Time 1 Tab in the EXE controls the END of an era in the Skirmish mode only and also
your Base Year. Both Base year numbers in the EXE and Time .GF need to be the same in order for your years to be in sync with each other.
Here is what I did in my mod.
I start my time at 2253,
Early ERA = +10yrs (2263)
Middle ERA = +15Yrs (2278)
Late Era =+15yrs (2293)
Ok so this is how you set up the TIME.GF file for those eras.
[Clock/StartingDate]
BaseYear = 2253
0 = 0 //Start of EARLY Era (This should always be 0)
1 = 10 //Start of MIDDLE Era
2 = 25 //Start of LATE Era
3 = 40 //Start of ADV Era
In my EXE I edit the time tab for the ending of the ERA's like this
Because I want my skirmish eras to coincide with my campaign for testing of ships and balance.
10, 25, 40, and 100
10= End of EARLY
25= End of Middle
40= End of Late
100= End of Advanced
I would appreciate if someone else could double check in their game.
Outstanding work TAR you MADE my friggen month. As far as I am concerned this is probably one of the BEST edits available because it really opens up possibilities for many mods. In case you don't realize it you just closed a subspace tear in the Time space continuum. (and fixed an error with the game that even the developers never caught)
The slipstream is now fluid and can pass through time with ease.
I dub thee
Tar The Time Lord.
-
Glad to help.
I understand why 14 Degrees East and Taldren used the 7th year (2270) as a limit for Mid Era Skirmishes. If you include ships with in-service dates of 2271+, they become more powerful each year. The year 2270 includes a few fantastic ships (L-BCP+, L-CWLP, I-CAY) but typically gives the first decent upgrade for most races (F-NCL, G-CA+, H-DG+, H-CAV, I-CLY, K-D5C, Z-CM, R-K7RB). Changing Mid Era to the 6th year would be rough for the Gorn and Feds and Hydrans -- they need the 2270 arrivals to compete in free-for-alls against experienced captains. (The Lyrans arguably rule Mid Era that closes on the 7th year. Check out the Nexus Traveler's Ship Guide.)
Whenever you end an era, it is arbitrary. 2270 seems fine for Mid. Changing it to 2269 or 2271 would benefit some empires more than others and ignite arguments. But in singleplayer, you don't have to compromise. :-)
I guess the programmers used SFB's 2267 and 2280 for the introduction of medium-speed and fast-speed missiles respectively. Using 2274 (+11) and 2284 (+21) would not comply with the board game's history. Some people care about this SFB stuff more than others. But with the SFC_Editor you can customize as you see fit.
It can be argued that Early Era soon ended when the Romulan shipyards produced warp-capable cruisers, such as the War Eagle (R-WE) in 2262. They had purchased some Klingon D6's for conversion to the R-KR a bit earlier (as shown in TOS). Again, it's arbitrary. 16 years ago, Overon and I requested that Taldren's programmers (Dave Ferrell) change the blocky era function to an incremental function -- you set the precise year per scenario. Dave liked the idea, but it never happened...I'm sure it would have been good and bad for multiplayer. What Klingon wouldn't ask for 2277 in a Starlance match, which just happens to exclude the F-BCF (2278) by one year? Actually I take that back, the Klinks I knew had a sense of fairness. Most of us were not terms campers regardless of empire.
-
Hmmm, you mean Kirk is refusing to decommission the Enterprise when he's suppose to, it's plausible.
Sidebar: Tar, I just put the Saratoga Mega Phasers on an Excelsior pylons, LMAO, looks like a BEAST!
That is a beast, Adam. Phaser-4's for Mega Phasers?
-
I made this kitbash for Xeryx, he was thinking PhA/B but I was thinking if you use Ph4, just 1x each side and place it on Heavy Hardpoints, they'll be a delay in firing once the standard compliment of phasers is exhausted within the capacitor. That minor delay would work well. The ship could be used for Base/Planetary Assaults. I'm thinking a Federation experiment with placing Ph4 on a mobile platform. Make the ship slow, poor maneuverability and underpowered.
But I do like the Saratoga megaphasers on it. Looks great.
-
Tar you should probably include these numbers in your next update so games will work right.(10,20,30, 100)
...I would also remove the references to the "Skirmish mode" in the time tab as that may confuse people, if possible.
Hmm...I don't see how the .exe edits for the end of each era affects a campaign. You can run a campaign with these numbers: 0, 1, 2, 3 in the Year tab. Try it. I don't think the Dynaverse cares, right? These numbers only restrict ship selection in singleplayer and multiplayer skirmish modes, as far as I can tell. I could very well be mistaken though. Time.gf, on the other hand, is the controller in a campaign. It acts as a fast-forward button.
I found an oddity, however, tonight. In a multiplayer Free-for-all, selecting "Advanced" era allows all ships to be browsed through, including tournament ships (with YFA of +999) even if Advanced era is customized to end at year +3 (2266)! So there is an override that I haven't discovered yet. The tournament stuff must ignore the hardcoded era limit of +100 (default for Adv), otherwise these important ships (F-TCA, K-D7CT, R-TKE, etc.) would never be available.
-
Just when we thought we had it all figured out bam! Another curve ball. Ehh
-
Xeryx, I will look for the game going out of sync. It would be good to have this time thing straight in my head. It is complicated. :o I actually think the best solution may be to modify the processing of the time.gf file to read negative numbers. Then we don't have to mess with the shiplist in-service dates.
[Clock/StartingDate]
BaseYear=2263
0=-15
1=0
2=15
3=30
But that's not going to be easy to implement.
Anyway, I tested these values in a campaign:
Year Tab = 2263, 0, 1, 2, 3
[Clock/StartingDate]
BaseYear = 2263 // Should equal value in Year Tab in SFC_Editor
0 = 0 // Negative numbers not allowed yet
1 = 4 // Medium-speed missiles arrive in 2267
2 = 17 // Fast-speed missiles arrive in 2280
3 = 100 // TNG stuff
I tried "Late" era, shown in red. This ought to be out of sync, right? Well, I created a bunch of Romulan War Eagles named WE2, WE4, WE6, ..., WE24, etc. with the YFA in the designation to do easy math in my head. Each ship had a service period of two years (e.g. YFA2 -> YLA4).
The game began in 2280 as expected (2263+17). The annual economy ran in 2281 and a few WE16 (YFA 2279) and WE18 (YFA 2281) appeared in the shipyard for purchase. Seems good. In 2282, all WE16 (YFA 2279) were properly removed from the shipyards. In 2283, a WE20 showed up in the shipyard. The news properly displayed the new available ships and fighters every year. This continued for 4 more years. Nothing unusual happened. Apparently the Year Tab can be set to 2 (instead of 35) for the end of Late Era without causing a problem.
Perhaps a problem occurs if the BaseYear is not equal to 2263. I'll try a BaseYear of zero...
...from economy.gf:
[General]
// This is how often the economy gets run. 10 = every 10th turn
TurnFrequency = 1
[Auction/Ship]
// This is the number of turns a ship will stay in the auction que before being removed
MaximumAge= 1
...from time.gf:
[Clock]
TurnsPerYear = 1
MilliSecondsPerTurn = 90000 // (60000)
DelayBeforeFirstTurn = 10000
TimeStopWhenInTactical = 1 // (0) ALWAYS 0 for Server!
-
It is a lot to get your head around and of course I am still learning as well, and why I am a pest! I will process your results and see why you came up with something different. It is always possible to misinterpret data, and that is why I wanted you to test as well.
So basically you are saying, that the Skirmish numbers have zero effect on campaign and the original numbers that are in the skirmish mode, are setup that way because of developments in the SFB universe? Correct? Not to correlate with the campaign timing in the campaign ERAs right?
Change the base years to be different in the files and see what the effects are please. I will have some time to do more testing tomorrow. I definitely did have an out of sync condition with different era's.
Ok here are the original years in the campaign right?
[Clock/StartingDate]
BaseYear = 2263
0 = 0
1 = 10
2 = 20
3 = 40
-
Xeryx, you're not a pest. Heh.
I tried these settings:
Year Tab:0; 0, 1, 2, 3
time.gf:
[Clock/StartingDate]
BaseYear=0
0=0
1=4
2=17
3=100
Started a campaign in Mid Era (4). WE6 appeared in year 6 as expected. WE8 appeared in year 8. WE10 appeared (and WE6 was removed) in year 10. I don't see an out-of-sync situation here.
Yeah, I think the default settings are these in time.gf:
[Clock/StartingDate]
BaseYear=2263 // this value is increased by the following choices to define the first year
0=0 // start of "Early"
1=10 // start of "Mid"
2=20 // start of "Late"
3=40 // start of "Advanced"
Trial #2:
I tried these settings:
Year Tab:0; 0, 100, 200, 300
time.gf:
[Clock/StartingDate]
BaseYear=0
0=0
1=4
2=17
3=100
I chose Late Era. Game began in Year 17 (0000+17). My War Eagles, the WE16's, were soon available. Year 18 arrived...a WE18 quickly appeared in shipyard. Year 19 arrived...a WE16 stayed in auction as obsolete. Year 20 arrived...WE20 and WE18 were available and the WE16 was retired. Nothing strange here as far as I can tell.
Trial #3:
Year Tab:100; 0, 4, 17, 100
time.gf:
[Clock/StartingDate]
BaseYear=0
0=0
1=4
2=17
3=100
Started in Mid Era (4). Nothing unusual. WE4's available right away. WE6's available after two years (year 6). WE4's mothballed in year 8 as WE8's were deployed.
YLA's are inclusive. So any ship with a YFA of 4 and YLA of 6 can be built in year 4 or 5 or 6. It can also linger in the auction for a number of turns (set in economy.gf as "Maximum Age"). In my case, I allowed a ship to remain in the auction for one turn. Since my turns/year is set to the minimum of 1, a ship gets a whole year to gather dust -- year 7 in the example above. In year 8, it gets kicked out of service.
-
Thanks Tar the Time Lord for your testing and input! 8)
I also did some more testing today while just changing the skirmish years. As you said Tar "They do not affect the campaign". Only having different base years in the EXE and Time.gf seems to have the effect of time warpage.
The only thing I can think that caused my out of sync condition when I first tested is that I forgot to save the change in the exe while seeing it was the same on the screen.
I will go fix my previous post so no one gets the wrong idea about the time space continuum.
On to the next challenge.
I do have a question though..are there any Campaign debugging commands?
Xeryx
-
Another complexity is that game uses two shiplists (and ftrlists). The campaign uses the shiplist.txt in the MetaAssets folder by default. Skirmish Mode uses the shiplist.txt in Assets\specs. Testing eras via a skirmish won't provide any useful information about the campaign shiplist.
Taldren specifically did this to allow players to simultaneously have different specification environments. One for mPlayer Arcade (later Gamespy and Gameranger and Evolve) and a second for Dynaverse campaigns. You could play on a TNG Dynaverse server for a while and then jump into the arcade version for a free-for-all without having to overwrite your shiplist and ftrlist.
If you want to automatically use your skirmish specs for your singleplayer Dyna campaign, change the assets.txt in MetaAssets\ServerProfiles\Singleplayer.
[Files]
ShipSpecs = ".\Assets\Specs\shiplist.txt"
FighterSpecs = ".\Assets\Specs\ftrlist.txt"
A multiplayer Dynaverse server will validate spec files in MetaAssets, never in Assets\Specs, however.
-
I am aware of the two sets of lists, and usually change both when I make changes.
I did not think to change those values in the assets.txt file to keep them the same.
That will be helpful.
Not sure if you saw my question because I was editing my previous response.
Are there any campaign debugging tools? I would like to see more of what is going on under the hood.
Also can you tell me what the final verdict on cloaking ended up being. I read through the posts, but there was a lot of indecision about it at the time.
-
Campaigns can be run in a debug mode, but I don't know how to do it. Campaigns can also use SQL instead of flat file databases. Again, I am a novice in that department. These forums may contain the info you seek, Xeryx.
Cloaking works differently depending on the version.
Stock SFC1, EAW, OP, and CE use a simple TrueRange*2+5 equation to get the effective range to the fully cloaked target.
OP uses an additional modifier, the so-called Cloak Chart, to adjust incoming damage.
OP Cloak Chart
33% Full damage
33% Half damage
33% Quarter damage
All fractional results are rounded down.
This chart is very effective vs Disruptors and Hellbores because the effective range is used to determine the weapon's strength instead of the true range. Star Fleet Battles uses true range for these weapons, so an OL Disruptor could do 10 points max instead of 6 points at a true range of 0 (0.99k) or 1 (1.99k). Photon Torpedo warheads don't degrade with range, so they work properly with this chart. Phasers and Fusion Beams use effective range. ESG's ignore the cloak as they should. PPD's can only hit a cloaked ship via a bug.
This chart is also crucial in surviving the high-speed Phaser-1 overrun. Without this chart, an attacking ship with 6 Ph-1 will do on average 21 points of damage to the cloaked ship every turn! With the chart, that is reduced to an average of 11 points.
The other effect of cloak is to break lock-ons of seeking weapons. Generally a ship must be going slowly (speed < 4) to have a good chance of making an incoming missile vanish or making a plasma torpedo strike for nothing. OP's cloak is very effective if the ship stops moving -- almost 100% of missiles and plasma torps are fooled by the cloak (Suicide Shuttles are immune however, a quirk well-known by the Gorn, and countered by Romulans via a Wild Weasel). The cloak in SFC1 and EAW and CE is not nearly as good at this -- all plasma will strike, but for moderately reduced damage (half, quarter, and very rarely a twentieth).
OP's cloak is a very valuable device for Romulans and Orions. Use it. Ships like the R-KVL, R-KE, R-RGK, and R-XCA are extremely hard to crack. The cloak in stock SFC1, EAW, and CE is occasionally useful for ships that cannot reach speed 30 (R-WE) but high speed or high ECM is often the superior tactic to the power-hungry come-and-kill-me croaking device.
In EAW 2.037 and CE 2.679, I set the effective range equation to be TrueRange*2+6. This is essential to make the cloak a worthwhile option in those games. Ph-1's typically slaughter cloaked units. Doing so makes the cloak very similar to the SFB version in terms of damage mitigation.
-
In a nutshell; Any and all (-) service dates are seen by the game as already commissioned (again watch the Auction you should see those ships available in the auction in and in the News you will never see them). They are not released year by year, I repeat they are not released the year of their in-service date, they are all released at one time. You would use these (-) in-service dates to supplement your early auction with ships for the first year, until more ships get commissioned.
Yep. Every ship with a negative YFA is available immediately in a campaign no matter what you do. That's a serious flaw in my opinion. But if you adjust those YFA numbers in the shiplist.txt, these ships can be produced over a great number of years...
Lets say my Vulcan Cruiser comes out in -100 normally (2163) as we reckon. Well, I can set that as the earliest date possible via YFA=0 in shiplist.txt. I start my campaign in Early Era (time.gf: BaseYear=2163, 0=0, 1=7, 2=35, 3=100) and the V-CA is available. I have to wait more than 60 years, however, for the F-CA to appear in the Dynaverse (old YFA=-33, new YFA=67)! That's how it should work.
To simplify this approach, just add 100 to all YFA's to get rid of the troublesome negative values for ships (planets will still have negative values, but that doesn't matter). Compensate by reducing the BaseYear to 2163 in time.gf and in the Year Tab for the SFC_Editor --- Last year of Early could be set to 100, last year of Mid could be set to 107, last year of Late could be set to 135, and last year of Advanced can be 200 (or even better 999).
So Early Era would run 100 years (instead of 1!), Mid Era would run 7 years, Late would run 28 years, and Advanced would run until the variable overflows (4 billion years?).
A good spreadsheet (Open Office Calc) can easily add 100 to the entire YFA and YLA columns in shiplist and ftrlist -- "TAB delimited" files. It'll do the right addition such that -50 becomes 50, -10 becomes 90, 12 becomes 112, etc. No need to edit a thousand entries by hand. Just edit two columns and be done.
-
Just browsing the StarfleetOP.exe with IDA today. Found
what looks like the variable for Overloaded Phaser-X.
Obviously the Ph-X chart is multiplied by 1.5 to get the OL Ph-X damage. This 4-byte float variable is shared by 12 functions so we can't safely change it. We can either create a new variable with the pi filler or change the offset to a different existing variable. The offset of this variable in the associated Phaser-X function is found in IDA at 0x4E5AED.
fmul ds:float_1point5
D8 0D 28 72 79 00
Change that to D8 0D ## ## ## 00
## ## ## is little endian. So I could use 58 75 79 to change this offset to find the float value 2.5 in IDA at 0x797558.
StarFleetOP.txt
Tab Phasers
E5AEF: 4b 16 // Offset to Ph-X overloaded damage multiplier // 28 72 79 00
E5BC9: 4b 16 // Offset to Ph-X overloaded damage multiplier for HUD (Average) // 28 72 79 00
E5C25: 4b 16 // Offset to Ph-X overloaded damage multiplier for HUD (Max) // 28 72 79 00
E5BFA: 4b 16 // Offset to Ph-X overloaded damage multiplier for HUD (Min) // 28 72 79 00
397270: 1f // Custom value for Ph-X overloaded damage multiplier at 70 72 79 00 // junk
I set up a space for a custom value, such as 1.25 or 1.75. It'll only work if the 4 offsets above it are set to 70 72 79 00. If you don't do anything, the Ph-X will continue to do 1.5 * regular damage when overloaded.
-
Cool, thanks for the YFA explanation I completely understand. As for the 1.5x damage of OL PhX. That's awesome. Much appreciated. If you happen to run into the PhB 3x variable that keeps eluding me please let me know.
Besides the function that redirects the PhX OL to 1.5x of the Ph1 chart; is there anything else there that can be useful such as a redirect or calling of a particular function. My initial goal concerning the overloaded PhX was to see if I could call for another color so that the PhX would essentially act as Ph1 but when overloaded would change color.
-
No luck with the Phaser-B vs shields variable. I followed the damage with a debugger. Seems the Ph-B reads the chart, grabs a 15, let's say, and sends that to somewhere mysterious (literally var10 which is ignored in the rest of the function). The shield damage allocator must modify it -- and its location has not been discovered. All damage coming off the PhB table is full strength, even against ships with strong shields. The damage gets divided by 3 (or multipled by 0.33 or 0.3333333ish) later. It must work this way to process Hellbores and Enveloping Plasma too. I've looked at all the Ph-B's top layer functions -- none use a divide by three or multiply by 0.33.
I noticed that the Phaser-A and Phaser-B have a "Load zero" function for the HUD's minimum damage calculator. Max and average are ok. This is misleading for the Ph-A. It's only noticeable with Ph-B at range 0.99k or less. I'd need 21 consecutive bytes of space to fix each of these calculators -- borrowing the format from the max-damage calculator while switching one offset to the final row of the chart.
-
Hmmmm. Well who knows, sometimes when you aren't looking for something things pop up.
Thanks again though. ;)
-
I did re-confirm my testing results; That if the start year in the EXE is not the same as the one in your campaign Time file, Dates will indeed be out of sync. I attached the screenshots, please note that my years were kind of going fast and I was three years late snipping the Auction screenshot. You can download the jpg and check the time stamps, they are legit.
All ships list were the same, and all years have been compensated for by adding 10 years to the YFA's because my mod starts in 2253. I also made sure I saved my changes in the EXE. :D
I went with 2263 (Time tab "Date Introduced") in the Exe, and 2253 in the Campaign Time.Gf file. I started in the late era and initially, I was seeing ships with a YFA of 2285 and I should not have seen any ships past 2278. Then in 2279 a ship popped up and showed a YFA of 2289. The ship attached in the screenshot became available in 2281 with a YFA of 2291. As expected, it confirms a 10-year shift forward does exist.
When my Starting dates are the same, then there is no time shift. I tested this both before and after this test, and only changed the date introduced tab, while ensuring it was saved all 3 times.
Hypothesis; The Main game clock (MGC) from EXE always starts at the same date, this is set in the Exe with the Time tab "Date Introduced", regardless of what is set in the Time.gf. You just can't see that (MGC) time running in the game, it is in the background. This also proves that the (MGC) time in the EXE is the one used for the ships list and fighter list (as the label suggests) for both skirmish and campaign modes. Furthermore, even though you can see the time flow within the campaign. I believe the Time.gf just provides a cosmetic overlay for the campaign. This is the most logical explanation, as to why there is a time shift present if they are not the same, that I can present.
You were correct about the Skirmish years, they do not affect the campaign and cannot cause a time shift.
Maybe trying dates of 2300 would work better for you, I am completely miffed as to why your testing did not show a time shift as mine has. Maybe there is a valid date range?
My Assest.gf was set to this
Name = "Assets"
[Paths]
Maps = ".\MetaAssets\"
Scripts = ".\Assets\Scripts\"
Campaigns = ".\Assets\Scripts\Campaigns\"
[Files]
ShipSpecs = ".\MetaAssets\shiplist.txt"
FighterSpecs = ".\MetaAssets\ftrlist.txt"
CurMap = ".\MetaAssets\MiddleMap.mvm"
Thank you, Tar, for the explanation on the cloaking. One last question on that; Does the +5 mean that is +5 columns on the damage chart or +5K added to range?
I also had no luck finding any campaign debugging codes on this forum. Just Volley info and Mission script stuff.
I wanted to also ask if this game has a cache file. I believe everything is loaded into memory at the start of the game.
-
I'll test the year stuff again. The BaseYear in time.gf seems to be minimally important, as we agree -- you could start with 0 or 5000, it doesn't matter. The "Date Introduced" in the .exe is important. And we're close to verifying its function...
Edit: I don't see any time shift, Xeryx.
StarfleetOP.exe
Date Introduced = 2263 (or 2253 or zero -- it doesn't matter)
time.gf
BaseYear = 0
0=0
1=15
2=30
3=45
Everything is like clockwork. I start a Late Era campaign (0000 + 30). The visible campaign clock shows 30.0 for the initial date as expected. Economy runs for year 31.0. A bunch of WE30's are available, a few WE28's too. Economy runs for year 32.0. A couple WE32's are in the shipyard, while the WE28's are mothballed. No ship appears before its YFA. Maybe I'm missing something.
I wouldn't use the Vessel Library to test a campaign because it can't view the campaign shiplist in MetaAssets, only the one in Assets\specs, which may be different. If you want a F-DSCS to appear in the 30th year of your Early Era campaign, set its YFA to 30. It will certainly appear no sooner than the 30th year. Make things easy on yourself by using BaseYear=0 in time.gf. The clock will therefore display the exact integer that is compared with the shiplist's and ftrlist's YFA data.
If you start a campaign in Mid Era as BaseYear + 15, you'll have to wait 15 years for that same F-DSCS to show up. The clock will tick from 15.0 to 30.0, and there you go, a F-DSCS in the news and now for sale in the shipyard.
The campaign time always starts at zero behind the scenes because it is based on YFA, not 2263 or 163 or any other ascii string. The only way to modify this starting point is to use time.gf's fast-forward buttons:
0=0 // "Early" -- Don't do anything. All ships with negative YFA values are ready.
1=15 // "Mid" -- Fast-forward such that ships with YFA's up to and including 15 are ready.
2=30 // "Late" -- Fast-forward such that ships with YFA's up to and including 30 are ready.
3=45 // "Advanced" -- Fast-forward such that ships with YFA's up to and including 45 are ready.
----
Cloak details...
In OP2.563, all units firing at a fully cloaked ship must double the true range and then add 5.0k to obtain the effective range.
F-CA fires 4 OL Photons at a nearby cloaked R-WE...
True range = 1.9k
Effective Range = 1.9k*2 + 5.0k = 8.8k
Photons therefore have a 50% chance to hit (they use the range 5.0-8.9 column) assuming the Fed has more ECCM than the Romulan's ECM, which is likely. The cloak itself does not produce additional ECM, but the War Eagle may use ECM like any other ship. Although not much energy is available for ECM if a ship cloaks, arms Plasma, reinforces shields, moves, etc.
Overloaded Photons that hit may be modified for damage because of the Cloak Chart -- 1/3 do Full (16), 1/3 do Half (8), 1/3 do Quarter (4). So we can expect two torps to hit. Probably one of them will strike for reduced damage. Common damage yields would be 32, 24, 20, 16, 12 with an average around 21.3. The Fed-CA will receive 4 points in feedback for every Overloaded Photon that hits at this true range.
-
I wouldn't use the Vessel Library to test a campaign because it can't view the campaign shiplist in MetaAssets, only the one in Assets\specs, which may be different.
That is simply not true while in the campaign, it will as long as both ships lists are the same, which both of mine are. You can right click on a ship in the auction and see its stats. It will not work if there are different ships lists, which you may have. I keep mine the same when modding. These are also the normal settings in the assets.gf file, that everyone else would have. Which also brings me to this conclusion, that Taldren has 2 of the same ships lists for a reason and it wasn't to be able to play 2 different games. That is just something someone else found out later on, by editing the assets.gf file. Otherwise, Taldren would have made the assets.gf file the way you have it, is that not a correct assumption? I now you have a heavily modded game and all, but many of us do not.
You are not reproducing the same conditions that I have, if your settings are not the same, and that maybe why you are not seeing the same thing I am.
BTW: When I change Base year to Zero this is what my campaign displays for a year on the late campaign a 10, and that is not the way I want my game. I want the year to display properly (2253) and not cause issues with ship availability. Do you even display the year properly in your campaign? like 2263 or is it 0? Tonight, I will change the assets file to see if it makes a difference.
[Clock/StartingDate]
BaseYear = 0
0 = 0
1 = 10
2 = 25
3 = 40
You may be onto something with having the base year as zero though in the Time.gf file. I fully understand how the YFA and YLA's in the ships list work as I have been working on it for a few months now, that is really pretty basic stuff. My ships list YFA's are setup correctly, it wouldn't work otherwise. I also always save my ships list and fighter list from my masters to both files in the metaassets and the assets\specs directory. I save my changes 3x when I make them so that my ships list are always the same version.
I think the best way to reproduce this error is to have someone else test as well.
-
You can right click on a ship in the auction and see its stats.
Wow. I did not know that. That's an easter egg for me. Ha. Anyway, the right-click will check the shiplist.txt, but in the wrong folder. It reads from ..\Assets\specs, never ..\MetaAssets. I might be able to hexedit this bug so that the campaign interface always reads from the specs in MetaAssets. Regardless, if your shiplists are identical, Xeryx, this shouldn't matter.
Testing...
Now I see why you were referencing the Vessel Library and why that was important to you for the campaign. "Date Introduced" would need to make sense. In a stock StarfleetOP.exe, 2263 is added to the YFA to produce the in-service date. If you add 10 to the YFA shiplist data and reduce the Date Intro from 2263 to 2253, what happens?
time.gf
BaseYear=0 //Y0.0
0=0 // YFA controllers
1=15
2=30
3=45
Date Introduced
2263 setup: R-Eagle YFA=-12 (2251) // available instantly in any era
2253 setup: R-Eagle YFA=-2 (2251) // still available instantly in any era because it is a negative number :knuppel2:
2263 setup: R-Falcon YFA=-5 (2258) // available instantly in any era
2253 setup: R-Falcon YFA=5 (2258) // available in Y5.0
Better to use -100 Date Intro and +100 YFA, and fast-forward all the eras, right?
time.gf
BaseYear=0
0=85 // Early starts in 2248
1=100 // Mid starts in 2263
2=115 // Late starts in 2278
3=130 // Advanced starts in 2293
Date Introduced=2163
R-Eagle YFA=88 // available in Y88.0 (2163+88=2251)
R-Falcon YFA=95 // available in Y95.0 (2163+95=2258)
So you'd need to wait 3 years for that Eagle to arrive if you start in Early Era.
The Falcon would show up in ten years in that case.
I'll do more tests to confirm.
-
Now I see why you were referencing the Vessel Library and why that was important to you for the campaign. "Date Introduced" would need to make sense. In a stock StarfleetOP.exe, 2263 is added to the YFA to produce the in-service date. If you add 10 to the YFA shiplist data and reduce the Date Intro from 2263 to 2253, what happens?
I did this step, in my mod. I added 10 years to the YFA so they show up on the proper dates. With the EXE set to 2253 and Time.gf file set to 2253..all the ships come out as scheduled.
My point is this, if the two Start dates are mismatched then ships will not arrive when they are supposed to (using the date in the campaign screen).
Please see the posts above for my results when you mismatch the numbers.
You only need to change the starting Date in the Time.gf to see the time shift. Use 2280 or something, or maybe a +10 year shift (as compared to the EXE) to see what I mean, and negative numbers in the ships list are not affected by this for the early era, however, if they have a YLA of anything other than 999 then they may not show up in certain eras.
The Start date in the EXE is the master game clock and is what the ships list uses so changing it is irrelevant.
-
I figured out the problem with Vessel Library. It always reads from ..\Assets\specs\shiplist.txt when you right-click on a ship's designation in the campaign interface. That is a bug which I might be able to fix. The singleplayer Dynaverse, however, always loads the files listed in ..\MetaAssets\ServerProfiles\SinglePlayer\assets.gf for shipyard production.
Name = "Assets"
[Files]
ShipSpecs = ".\MetaAssets\Tar\shiplist.txt"
FighterSpecs = ".\MetaAssets\Tar\ftrlist.txt"
CurMap = ".\MetaAssets\MiddleMap.mvm"
This works for me. Try it out. Put a unique ship in there. It'll appear in the campaign shipyard. The path to shiplist.txt is not hardcoded.
Many people played on mPlayer/Gamespy and also played the singleplayer campaign with custom shiplists. We didn't right-click in a campaign on a ship designation because it would give a black screen (or we didn't even know that you could get into the Vessel Library). We didn't swap spec files everytime we wanted to play a free-for-all on mPlayer.
I don't know if the multiplayer Dynaverse can only read from ..\MetaAssets\shiplist.txt. There is no assets.gf file in MetaAssets\ServerProfiles\Multiplayer.
-
Boy I'm confused so I will remain Señor Lurker till you figure this out. :crazy2:
-
My point is this, if the two Start dates are mismatched then ships will not arrive when they are supposed to (using the date in the campaign screen).
You only need to change the starting Date in the Time.gf to see the time shift. Use a 10 year shift either way
The Start date in the exe is the master time, and is what the ships list uses so changing it is irrelevant.
Huh? The start date in the .exe is important. It is added to the YFA to show the in-service date in the Vessel Library.
I don't see a mysterious hardcoded ten-year shift. Can you get an 11-year shift? Can you get a 9-year shift?
I'm trying to understand your terms so I can see what you see.
I have used a BaseYear of zero and everything stays in sync in terms of YFA. No surprise, right? Once that is working properly, I add the cosmetic BaseYear that I want to the ticker, such as 2248. Then everything is accurate: Vessel Library, Ship Production, and Clock...no matter which era I start in.
StarfleetOP.exe clock = 2163
time.gf
BaseYear=2245
0=85 // Need not start at 0!
1=100
2=115
3=130
No problems.
Perhaps this is 6 of one, half-dozen of the other. :o
-
I went and looked at my Assets.gf file
and this is what is says:
Name = "Assets"
[Paths]
Maps = ".\MetaAssets\"
Scripts = ".\Assets\Scripts\"
Campaigns = ".\Assets\Scripts\Campaigns\"
[Files]
ShipSpecs = ".\MetaAssets\shiplist.txt"
FighterSpecs = ".\MetaAssets\ftrlist.txt"
CurMap = ".\MetaAssets\MiddleMap.mvm"
This is exactly the way it is supposed to be Tar. Sure I could change the subdirectory to look at a different ships list or fighter list. That is still irrelevant as well, as you said "It should not matter as long as the files are the same." I may do this in the future, however, if I want to be able to switch back to original files. There is probably a reason that the ships are displayed from the assets\specs folder for both the skirmish and campaign modes.
That still is not the cause of the time being out of sync. The only cause is the Time.gf being different from the EXE. If it were as simple as just the ships not displaying the date correctly, I wouldn't care so much. However, it does affect when ships are produced and decommissioned.
Are you 100% certain the files you are modding, are the same ones that are being used? I mean how many copies of the game do you have on the computer, and does the editing program you use remember what file it is. For example I use notepad++ and it has a memory and I have to check to make sure I am editing the correct file if I have more than one copy of a game. During my testing, I verified those files were the proper ones, plus I only have one copy of OP installed.
I have just installed a fresh copy of the game, and I will do some testing from it this weekend.
Don't worry about not seeing it man, focus on other important things. Besides this is more for modders wanting to change the game from the original. Which there probably is only 2 on this board..LMAO :D
-
OK. As long as you know how to keep the clocks working appropriately, that's good enough for me. I think there is more than one way to set things up and get the right results. A 2+3 = 1+4 sort of thing.
I'll look for the right-click shipyard link to Assets\specs\shiplist.txt. I'd like to fix that bug. I bet I can alter that to MetaAssets\shiplist.txt. It'll read the right campaign specs -- at least in the default location.
-
I'll look for the right-click shipyard link to Assets\specs\shiplist.txt. I'd like to fix that bug. I bet I can alter that to MetaAssets\shiplist.txt. It'll read the right campaign specs -- at least in the default location.
That sounds almost like a good idea, but ultimately, shouldn't that be specific for the campaign game? Is it the same call for the vessel library? Plus then it wouldn't work right for you unless you replace your default shipslist in the metaassets directory.
-
I'll look for the right-click shipyard link to Assets\specs\shiplist.txt. I'd like to fix that bug. I bet I can alter that to MetaAssets\shiplist.txt. It'll read the right campaign specs -- at least in the default location.
That sounds almost like a good idea, but ultimately, shouldn't that be specific for the campaign game? Is it the same call for the vessel library? Plus then it wouldn't work right for you unless you replace your default shipslist in the metaassets directory.
I found the functions tonight. I can modify the hardcoded paths. The game always loads the shiplist.txt found in Assets\Specs into the Vessel Library. So this is why Dynaverse players instruct you to maintain duplicates of your specs in MetaAssets and Assets\Specs. I am sure that Taldren wanted these specs to be independent -- but they only got 4/5ths of the way there. The game will correctly load the campaign specs for Dynaverse production or the skirmish specs for a free-for-all, but the game isn't smart with Vessel Library data. The game loads the correct ftrlist.txt for spacedock in each mode too. So close.
I cannot change the shiplist that is read by the Vessel Library from the campaign window without messing up the Skirmish Mode. There is no obvious function to determine if you're in a campaign or a skirmish. Nope, the right-click just calls the shiplist from Assets\specs and we can take it or leave it. :buck2:
We can, however, completely forget about the traditional Dyna spec files in MetaAssets. If we change the MetaAssets\ServerProfiles\SinglePlayer\assets.gf to...
[Files]
ShipSpecs = ".\Assets\specs\shiplist.txt"
FighterSpecs = ".\Assets\specs\ftrlist.txt"
...then everything is accurate everywhere. You have exactly one set of specs.
But if you want to play with a modded shiplist on GameRanger or EvolveHQ you'd need to swap those two text files. A tiny batch file works well for that.
-
I'm working on the PPD damage estimator. Taldren simply stuck three identical copies of a function into getAverageDamage(), getMinimumDamage(), and getMaxDamage().
Each of these functions takes one argument (the range bracket, as a byte). So that's all the outside data I have. With this I decided to make the mimimum damage zero with a fldz. There is a 1% chance that a PPD will miss with all four pulses at range 4 to 10, so putting a zero in there is valid!
I created two new arrays of bytes that contain the max and average damage of a standard PPD while remaining in a bracket for 4 pulses, and linked them to the respective estimators.
I tested this in game and I like it a lot. The PPD's don't show that misleading 5-5(5) data anymore. I am not yet able to adjust this estimator for Overloaded or Underloaded mode. These functions do not receive any bytes that would indicate the mode chosen. I figured that puzzle out. So the PPD estimator will work for UL, OL, and normal modes. :-)
------------------------Range---------------------------
| 4-10* 11-15 16-20 21-25 26-30 31-40
Damage | 6 5 4 3 2 1
Accuracy| 83% 72% 58% 42% 28% 17%
Max | 24 20 16 12 8 4
Avg | 22 18 13 8 4 1
UL-Max | 12 10 8 6 4 2
UL-Avg | 10 8 5 3 1 0
OL-Max | 36 NA NA NA NA NA
OL-Avg | 34 NA NA NA NA NA
*Range 8 is limit for OL
-
More goodies :D
-
Progress in spacedock...
-
I know I'm slightly changing the recent topic, but now that Hex Editing has become a popular thing in the SFC community in recent years, has anyone figured out a way to increase the 6 ship limit for SFC3 skirmishes? I realize 6 teams is very difficult to extend, but more than 6 players (5 AI ships) should be easily possible for the game to handle, especially since the skirmish list looks like it can fit a whole lot more.
This has always been one of the game's biggest limitations IMO. Playing LAN skirmishes with 2 friends would be a whole lot more interesting if we could fight a fleet of opponents instead of just being limited to a 3v3.
-
Adding a 7th player would require a rewrite of many UI, network, and script functions. It is a huge task for one person. A team of ten people with C++ source code could do it. A couple of guys with hex editors...barring some unforeseen brilliant hack, it'll never happen.
The UI is the easiest aspect to mod. The multiplayer scripts don't have any data for player 7. Thousands of arrays would have to be increased by one. The entries for player 6 could be copied and edited, but the API would break. The networking stuff...I have no idea. That's the hardest. I can't see the workings of the peer-to-peer stuff with a hex editor.
I'm surprised that anyone is hampered by the 6-player limit in SFC nowadays. If so, there are 7 people who have a reason to download IDA and try to figure it out. Maybe they can be successful.
-
Tar,
Is it possible to redirect a phaser to another damage chart other than its own damage chart?
Another question would be separating the PhG from utilizing the Ph3 chart and redirecting it to use its own chart in another location, let's say toward the end of the exe where there would be room for a chart.
Adam
-
Tar,
Is it possible to redirect a phaser to another damage chart other than its own damage chart?
Another question would be separating the PhG from utilizing the Ph3 chart and redirecting it to use its own chart in another location, let's say toward the end of the exe where there would be room for a chart.
Adam
An alternative phaser has to have the same amount of range brackets as the original. So I can't make a Ph-1 use the Ph-3 chart. It will read outside of this chart, perhaps doing a million points of damage or negative damage.
I could easily create a duplicate damage chart of the Ph-3. I might be able to link the Ph-G to this new chart. It's been a while since I looked at the phaser functions. It would take some serious rewriting if the flow chart for phaser selection shares a common box for Ph-3 and Ph-G...
I figured out the .mvm format tonight. No need for artifex.
Here's EarlyMap.mvm
Version/Data/Offsets
data=2368 // 940h, beginning offset of map data
text=15820 // 3DCCh, end of .mvm file
1C // 28, number of hexes west to east
0F // 15, number of hexes north to south
1A4 // 420, total number of hexes
Hex 0,0 is the first 32-byte structure (Lyran's northwest corner on a typical map)
Hex 1,0 is second 32-byte structure...
Hex 27,14 is last structure.
05 00 00 00 // 5 = Economy
00 00 00 40 // 2.0f = Impedence
05 00 00 00 // 5 = Defense for empire and cartel
06 00 00 00 // 6 = Lyran Empire in control of region
05 00 00 00 // 5 = BeastRaiders Cartel in control of region
01 00 00 00 // 1 = Blackhole1 as terrain
00 00 00 00 // 0 = No planet
00 00 00 00 // 0 = No base
etc.
You must use little-endian hexadecimals though! So ten is 0A 00 00 00, not 10 00 00 00. Impedence is a float, the rest are integers.
[Classes/Regions]
0="Neutral"
1="Federation"
2="Klingon"
3="Romulan"
4="Gorn"
5="Lyran"
6="Hydran"
7="Mirak"
8="ISC"
[Classes/CartelRegions]
0="Neutral"
1="OrionOrion"
2="OrionKorgath"
3="OrionPrime"
4="OrionTigerHeart"
5="OrionBeastRaiders"
6="OrionSyndicate"
7="OrionWyldeFire"
8="OrionCamboro"
[Classes/Terrain]
0="(none)"
1="Blackhole1"
2="Blackhole2"
3="Blackhole3"
4="Blackhole4"
5="Blackhole5"
6="Blackhole6"
7="Asteroid 1"
8="Asteroid 2"
9="Asteroid 3"
10="Asteroid 4"
11="Asteroid 5"
12="Nebula 1"
13="Nebula 2"
14="Nebula 3"
15="Shipping Lane"
[Classes/Planets]
0="(none)"
1="Homeworld 1"
2="Homeworld 2"
3="Homeworld 3"
4="Core World 1"
5="Core World 2"
6="Core World 3"
7="Colony 1"
8="Colony 2"
9="Colony 3"
10="Asteroid Base 1"
11="Asteroid Base 2"
12="Asteroid Base 3"
[Classes/Bases]
0="(none)"
1="Starbase"
2="Battle Station"
3="Base Station"
4="Weapons Platform"
5="Listening Post"
I made a 3x3 micromap. Intense action would occur here. Lots of drafting one would assume.
-
Dude!
That's awesome. One of my dreams is to create a map but artifex was so annoying and buggy. Thank you so much for finding these variables for the map. I look forward to fiddling with this tomorrow. Awesome find!
Is there anyway to incorporate this into the exe editor or something?
Adding a base to a hex; only one for that list or can you have a base station and a listening post?
Adam
-
As for the phaser, I kind of figured it had to match the amount of brackets. That's fine for me, it's no biggie when you have a chance if possible let me know if it can be done, if it's too much no worries. The map find has me more excited lol
Thanks again
Adam
-
As for the phaser, I kind of figured it had to match the amount of brackets. That's fine for me, it's no biggie when you have a chance if possible let me know if it can be done, if it's too much no worries. The map find has me more excited lol
Thanks again
Adam
I was wrong. I swapped the PhG call for the Ph4 call. My PhG's were doing 20 damage per pulse. But they were still under the PhG range limit of 2.99k. And the damage estimator still assumes a PhG yield of course. No crash. No change in graphics or audio. PhG's don't have to use the Ph3 chart.
StarfleetOP.exe
IDA 0x4E37B3
E8 F2 04 00 00 -> E8 43 05 00 00
-
Dude!
That's awesome. One of my dreams is to create a map but artifex was so annoying and buggy. Thank you so much for finding these variables for the map. I look forward to fiddling with this tomorrow. Awesome find!
Is there anyway to incorporate this into the exe editor or something?
Adding a base to a hex; only one for that list or can you have a base station and a listening post?
Adam
Seems that you can't select more than one base-type item. Choose one: SB, BATS, BS, Platform(?), or LPost.
I was amazed that a nebula or a blackhole added to the map actually influences the missions. I thought it might be random. But it seems directly related. Put a blackhole in the hex -- your patrol mission has a blackhole. Neat.
I think that d4v1ks can make a modification to the SFC Editor if he has the time. (He's a busy fellow.) The format is almost the same. Address, variable type, data. The tricky part is displaying hexagons. I'd be happy with a plain rectangular grid.
My 3x3 grid with regular SFB distribution of empires:
5 7 4
2 1 3
6 0 8
The "Tholians" have the asteroid field and starbase in the spot with the zero.
These maps might crash if you put in more than three homeworlds per empire, or use values outside of the expected range -- usually >1000.
-
I completely understand, I know Carlos is very busy and I have no problem doing it the hex way.
That's what I thought, about the one type per hex, I kind of remembered that while fiddling with artifex so many years ago.
As for the home worlds, it's been a while since I played campaigns but are there more than one home worlds within an empire?
And lastly, how does one tackle the cartel boundaries? If I'm not mistaken, cartel boundaries aren't the same as their host empires boundaries. They tend to overlap other empires so that sometimes a cartel can literally be within two or more main empires territory.
-
It's right there in the .mvm.
The OP Dynaverse is two-layered, as we all know. Each hex has separate values for the controlling empire and cartel.
So my map can have a 12-hex Romulan region that overlays a 50% Syndicate (6 hexes) and 50% Camboro (6 hexes) area. I'd just set each hex accordingly.
RS RS RS RC
RS RS RC RC
RS RC RC RC
Instead of "R", I use 03 00 00 00 as the Empire Region integer for the Roms. The Cartel Region would use 06 00 00 00 for Syndicate and 08 00 00 00 for Camboro. You can leave some parts neutral with 00 00 00 00.
Start with a 3x3 map for tinkering. It'll make sense without much work. The try a 6x6 map maybe.
-
Gotcha, will do. Thanks again.
-
Such a interesting topic to work on...
Good work Tar!
I will employ such discoveries in a future map editor.
-
I put together a CustomMap.txt for the SFC Editor. It can edit a 4x4 campaign map. Extra data doesn't matter! So your raw material can be EarlyMap.mvm, MiddleMap.mvm, or LateMap.mvm. (It can't however be conquest.mvm because that one is missing stuff in the header so the offsets are not correct in CustomMap.txt.)
The SFC Editor needs to work on .exes. So I had to change CustomMap.mvm to CustomMap.exe.
/*
Dynaverse Custom Map 1.0
Uses the SFC_Editor created by d4v1ks and Tar
Assembled by Tar on 9 February 2017
* Syntax
Offset : [[Rows x] Columns] Type [Base] [R] [// [Description [(restrictedValues)]] [// [Tooltip]]]
[ ] = Optional arguments
Offset = _Hexadecimal memory address
Rows/Columns = Must be numbers above 1
Type = b (int8), ub (uint8), c (utf8 char), op (byte), s (int16), us (uint16), u (utf16 char), i (int32), ui (uint32), f (32bit float), l (int64), ul (uint64), d (64 bit float)
Base = 2 (binary), 8 (oct), 10 (decimal, default), 16 (_Hex)
R = Restricted mode. Will force the user to input one of the values in the description.
restrictedValues = Values (ex: 1,2,3) , or range of values (ex: 1 To 7)
* Commands
Md5 = Adds a new checksum to the UI
Tab = Starts a new tab in the UI
* Comments
// A single line
/* One or
Lines
*/
*/
Tab Dimensions
940: 1i r // Width in Hexes (3 to 100)
944: 1i r // Height in Hexes (3 to 100)
948: 1i r // Width x Height (9 to 10000)
Tab 0_Hex
94C: 1i r // Economic Strength (0 to 35)
950: 1f r // Impedence (0.0 to 100.0)
954: 1i r // Defensive Strength (0 to 100)
958: 1i r // Controlling Empire (0 to 8)
95C: 1i r // Controlling Cartel (0 to 8)
960: 1i r // Terrain Type (0 to 15)
964: 1i r // Planet Type (0 to 12)
968: 1i r // Base Type (0 to 5)
Tab 1_Hex
96C: 1i r // Economic Strength (0 to 35)
970: 1f r // Impedence (0.0 to 100.0)
974: 1i r // Defensive Strength (0 to 100)
978: 1i r // Controlling Empire (0 to 8)
97C: 1i r // Controlling Cartel (0 to 8)
980: 1i r // Terrain Type (0 to 15)
984: 1i r // Planet Type (0 to 12)
988: 1i r // Base Type (0 to 5)
Tab 2_Hex
98C: 1i r // Economic Strength (0 to 35)
990: 1f r // Impedence (0.0 to 100.0)
994: 1i r // Defensive Strength (0 to 100)
998: 1i r // Controlling Empire (0 to 8)
99C: 1i r // Controlling Cartel (0 to 8)
9A0: 1i r // Terrain Type (0 to 15)
9A4: 1i r // Planet Type (0 to 12)
9A8: 1i r // Base Type (0 to 5)
Tab 3_Hex
9AC: 1i r // Economic Strength (0 to 35)
9B0: 1f r // Impedence (0.0 to 100.0)
9B4: 1i r // Defensive Strength (0 to 100)
9B8: 1i r // Controlling Empire (0 to 8)
9BC: 1i r // Controlling Cartel (0 to 8)
9C0: 1i r // Terrain Type (0 to 15)
9C4: 1i r // Planet Type (0 to 12)
9C8: 1i r // Base Type (0 to 5)
Tab 4_Hex
9CC: 1i r // Economic Strength (0 to 35)
9D0: 1f r // Impedence (0.0 to 100.0)
9D4: 1i r // Defensive Strength (0 to 100)
9D8: 1i r // Controlling Empire (0 to 8)
9DC: 1i r // Controlling Cartel (0 to 8)
9E0: 1i r // Terrain Type (0 to 15)
9E4: 1i r // Planet Type (0 to 12)
9E8: 1i r // Base Type (0 to 5)
Tab 5_Hex
9EC: 1i r // Economic Strength (0 to 35)
9F0: 1f r // Impedence (0.0 to 100.0)
9F4: 1i r // Defensive Strength (0 to 100)
9F8: 1i r // Controlling Empire (0 to 8)
9FC: 1i r // Controlling Cartel (0 to 8)
A00: 1i r // Terrain Type (0 to 15)
A04: 1i r // Planet Type (0 to 12)
A08: 1i r // Base Type (0 to 5)
Tab 6_Hex
A0C: 1i r // Economic Strength (0 to 35)
A10: 1f r // Impedence (0.0 to 100.0)
A14: 1i r // Defensive Strength (0 to 100)
A18: 1i r // Controlling Empire (0 to 8)
A1C: 1i r // Controlling Cartel (0 to 8)
A20: 1i r // Terrain Type (0 to 15)
A24: 1i r // Planet Type (0 to 12)
A28: 1i r // Base Type (0 to 5)
Tab 7_Hex
A2C: 1i r // Economic Strength (0 to 35)
A30: 1f r // Impedence (0.0 to 100.0)
A34: 1i r // Defensive Strength (0 to 100)
A38: 1i r // Controlling Empire (0 to 8)
A3C: 1i r // Controlling Cartel (0 to 8)
A40: 1i r // Terrain Type (0 to 15)
A44: 1i r // Planet Type (0 to 12)
A48: 1i r // Base Type (0 to 5)
Tab 8_Hex
A4C: 1i r // Economic Strength (0 to 35)
A50: 1f r // Impedence (0.0 to 100.0)
A54: 1i r // Defensive Strength (0 to 100)
A58: 1i r // Controlling Empire (0 to 8)
A5C: 1i r // Controlling Cartel (0 to 8)
A60: 1i r // Terrain Type (0 to 15)
A64: 1i r // Planet Type (0 to 12)
A68: 1i r // Base Type (0 to 5)
Tab 9_Hex
A6C: 1i r // Economic Strength (0 to 35)
A70: 1f r // Impedence (0.0 to 100.0)
A74: 1i r // Defensive Strength (0 to 100)
A78: 1i r // Controlling Empire (0 to 8)
A7C: 1i r // Controlling Cartel (0 to 8)
A80: 1i r // Terrain Type (0 to 15)
A84: 1i r // Planet Type (0 to 12)
A88: 1i r // Base Type (0 to 5)
Tab 10_Hex
A8C: 1i r // Economic Strength (0 to 35)
A90: 1f r // Impedence (0.0 to 100.0)
A94: 1i r // Defensive Strength (0 to 100)
A98: 1i r // Controlling Empire (0 to 8)
A9C: 1i r // Controlling Cartel (0 to 8)
AA0: 1i r // Terrain Type (0 to 15)
AA4: 1i r // Planet Type (0 to 12)
AA8: 1i r // Base Type (0 to 5)
Tab 11_Hex
AAC: 1i r // Economic Strength (0 to 35)
AB0: 1f r // Impedence (0.0 to 100.0)
AB4: 1i r // Defensive Strength (0 to 100)
AB8: 1i r // Controlling Empire (0 to 8)
ABC: 1i r // Controlling Cartel (0 to 8)
AC0: 1i r // Terrain Type (0 to 15)
AC4: 1i r // Planet Type (0 to 12)
AC8: 1i r // Base Type (0 to 5)
Tab 12_Hex
ACC: 1i r // Economic Strength (0 to 35)
AD0: 1f r // Impedence (0.0 to 100.0)
AD4: 1i r // Defensive Strength (0 to 100)
AD8: 1i r // Controlling Empire (0 to 8)
ADC: 1i r // Controlling Cartel (0 to 8)
AE0: 1i r // Terrain Type (0 to 15)
AE4: 1i r // Planet Type (0 to 12)
AE8: 1i r // Base Type (0 to 5)
Tab 13_Hex
AEC: 1i r // Economic Strength (0 to 35)
AF0: 1f r // Impedence (0.0 to 100.0)
AF4: 1i r // Defensive Strength (0 to 100)
AF8: 1i r // Controlling Empire (0 to 8)
AFC: 1i r // Controlling Cartel (0 to 8)
B00: 1i r // Terrain Type (0 to 15)
B04: 1i r // Planet Type (0 to 12)
B08: 1i r // Base Type (0 to 5)
Tab 14_Hex
B0C: 1i r // Economic Strength (0 to 35)
B10: 1f r // Impedence (0.0 to 100.0)
B14: 1i r // Defensive Strength (0 to 100)
B18: 1i r // Controlling Empire (0 to 8)
B1C: 1i r // Controlling Cartel (0 to 8)
B20: 1i r // Terrain Type (0 to 15)
B24: 1i r // Planet Type (0 to 12)
B28: 1i r // Base Type (0 to 5)
Tab 15_Hex
B2C: 1i r // Economic Strength (0 to 35)
B30: 1f r // Impedence (0.0 to 100.0)
B34: 1i r // Defensive Strength (0 to 100)
B38: 1i r // Controlling Empire (0 to 8)
B3C: 1i r // Controlling Cartel (0 to 8)
B40: 1i r // Terrain Type (0 to 15)
B44: 1i r // Planet Type (0 to 12)
B48: 1i r // Base Type (0 to 5)
-
As for the phaser, I kind of figured it had to match the amount of brackets. That's fine for me, it's no biggie when you have a chance if possible let me know if it can be done, if it's too much no worries. The map find has me more excited lol
Thanks again
Adam
I was wrong. I swapped the PhG call for the Ph4 call. My PhG's were doing 20 damage per pulse. But they were still under the PhG range limit of 2.99k. And the damage estimator still assumes a PhG yield of course. No crash. No change in graphics or audio. PhG's don't have to use the Ph3 chart.
StarfleetOP.exe
IDA 0x4E37B3
E8 F2 04 00 00 -> E8 43 05 00 00
I was playing with the 0.25 float located at 4E377C, (795BF0), by changing it to 0.5, the Phaser G expended 2 shots, the capacitor needed to charge and once it reached 25 percent it fired another, then again until the phaser expended its 4 shots. By adjusting 4E34C2 the phaser G only fired one shot and needed to wait till the capacitor reached full power again, i'm still doing more testing.
eh, i give up, I rather find a way to redirect the TRBs to use the phaser icons so I can select one in the game without having to group them since the GUI for them aint working, will that be an easier task (to redirect the TRBs to use phaser GUI instead of the half ass PPDs that arent finished?)
-
On the bright side, I found the 1.5 multiplier applied to the PhX Overload.
As always with hexediting, you spend hours looking for one thing and wind up finding another.
-
I was playing with the 0.25 float located at 4E377C, (795BF0), by changing it to 0.5, the Phaser G expended 2 shots, the capacitor needed to charge and once it reached 25 percent it fired another, then again until the phaser expended its 4 shots. By adjusting 4E34C2 the phaser G only fired one shot and needed to wait till the capacitor reached full power again, i'm still doing more testing.
eh, i give up, I rather find a way to redirect the TRBs to use the phaser icons so I can select one in the game without having to group them since the GUI for them aint working, will that be an easier task (to redirect the TRBs to use phaser GUI instead of the half ass PPDs that arent finished?)
Good find. Sounds like you can turn the PhG into a non-gatling phaser. Fires once per turn. But yeah, it'll take some work elsewhere to accomodate this change (damage estimator, energy costs, custom damage tables). What has caused you to give up on this approach?
Hmm...I haven't tried to assign the TRB to an alternate UI (wherever that may be). If a jumptable is read (e.g. weapon graphics assignments), that would seem to be the easiest modification.
TRB weapon identities are 21h and 22h. So the 21h and 22h (33rd and 34th) entries will jump to PPD. Maybe they would work better jumping to Disruptor. Don't know if the sprites.q3 would need to be adjusted too.
-
My approach failed. I managed to change the PhG pulse to utilize 1.0 phaser capacitor as opposed to the 0.25. As a result it slowed it down a bit as the subsequent pulses had to wait for more phaser capacitor recharge.
As for the TRBs, I just want the single weapon hardpoints to utilize the phaser on and off panel as oppose to the unfinished blank it currently uses.
I will test out the shi var 2 and see if that helps.
-
On the bright side, I found the 1.5 multiplier applied to the PhX Overload.
As always with hexediting, you spend hours looking for one thing and wind up finding another.
I posted the offset of the PhX overload modifier a while ago.
http://www.dynaverse.net/forum/index.php/topic,163394152.msg1123055667.html#msg1123055667 (http://www.dynaverse.net/forum/index.php/topic,163394152.msg1123055667.html#msg1123055667)
I'll try to find the variables that give the PhG its four pulses. We've found two of them so far. Customizable pulse quantities would be good to add to the SFC Editor.
If a ship has exactly one Phaser, changing the 0.25 to 1.0 works for a PhG. It behaves like a purple Ph3. But if the ship has additional phasers, the PhG can utilize the common energy in the capacitor. This is a problem for us. I'll have to look at the PhG with a debugger to find the function that keeps track of the four PhG pulses. Removing the gatling effect isn't as easy as I had hoped (via 0.25 -> 1.0).
-
You did, I never noticed you posting the 1.5x modifier for the PhX. Nevertheless thank you.
I do enjoy the normal PhX being able to fire 2x per turn and really utilizing the phaser capacitor. Thank Tar, my eyes were getting really tired of staring at numbers/letters all day. Felt like the matrix.
-
After 47 new sprites, 47 new bitmap assets, 10 new state buttons, a few string corrections, and some scenes fixed, we released a 2564 sprites candidate 1 preview on hotandspicy forums.
If features:
- loading screen fix
- new romulan A6 AMD stateButton fix
- new 9 race AMD_C weapon button's fix
The TRBL and TRBH weapon was also unlocked on SFCOP 2564.
And the MIRV damage estimator was fixed.
More coming... 8)
-
2.564 work-in-progress...
HUD damage estimators fixed for PhA, PhB, ESGL, PPD, MIRV.
New customizable variables for SFC Editor:
EPT damage multiplier
PhX overloaded damage multiplier
ESG Lance attack strength
Missile speed BPV costs (applies to multiplayer)
MIRV bloom time
AMD rate of fire
AMD ammo supply
PlasD ammo supply
Myopic range for missiles
Fighter-based missile speed classes (slow/med/fast)
Maximum ship speed (0 to 31)
YFA for medium and fast missiles
Skirmish era time spans
New features:
ADD30 (aka "AMD C") anti-drone device enabled -- this thing has 30 ammo per rack! designed for starbases
Each TRBL and TRBH hardpoint can use the PhA/ESGL panel (instead of the broken panel)
PhG given its own weapon charts
Bug fixes...underway
I'll just paste the beta changelog...
1. PhA_MinDam estimator fixed.
2. PhB_MinDam estimator fixed.
3. EPT variable isolated.
4. PPD Min Dam estimator fixed.
Added arrays for UL and OL.
5. Ph-X OL multiplier isolated.
6. HB hold cost isolated.
7. Vessel library bugs. Not Fixed!
8. AMD estimator not quite right. Enemy fighters do not validate estimator (stays yellow font on Klink HUD).
Enabled Avg Damage anyway for every other unit.
WIP.
9. PPD estimator enhanced
10. Missile speed cost display. Can't show float, so show x100 (i.e. 50 = 0.50).
Done.
11. ESGL_Dam isolated.
12. ADD30 enabled.
13. TRB can use any icon. But A6_panel is blank.
Enabled functional alternates (PhA or ESGL)!
14. PPD fire hose bug. Gauge shows bug, but doesn't cause it. Very hard to diagnose.
Cant fix this one. Move on.
15. MIRV bloom variable isolated. Note that MIRV bus has 2 hitpoints and a warhead of 2!
16. Missile Myopic range. Custom variable.
17. New Drone Max Dam for estimator.
18. New Drone Avg Dam for estimator.
19. Fighter missile speed class (slow, medium, fast) is now moddable.
DroI can be slow, DroVI can be fast -- whatever you want.
20. Ship max speed is moddable (0 to 31).
21. Cloak chart's misery multipliers have been isolated.
22. The ESG estimator assesses the capacitor per hardpoint now so it cannot underreport.
If the capacitor has 5 points, each hardpoint thinks it can use that energy. Which it can, but both can't use it...
So it'll estimate 40 dam, instead of 20 dam. Phasers work like this too.
Improved but not perfect.
WIP.
23. TR Beam Min Dam for estimator.
24. Mauler Min Dam for estimator.
25. Mauler accuracy isolated.
26. ESG cycle isolated.
27. HUD should always shows ESG potential damage since it is a sphere that'll whack anything.
Fixed.
28. Stop writing to "Above8bitTextures.txt" on every mission! (useless debug code)
Done.
Doublecheck this...
Done.
29. Customizable mine/t-bomb/NSM explosion strength, endurance, detonation speeds, activation range.
Done.
30. strings.txt |ErraticsAreOn|...Maneuvering erratically...
The inactive "ErraticMissile" warning now notifies player of EM at customizable frequency.
Bug: spams "transporter can't be used now"...
Bypass spam.
Done.
31. Isolated TBomb calls to range variable (cursor and deployment)
Done.
32. WW voiding-speed variable found (40.1d). Added to editor. Increased value slightly to account for asynchronous WW failures. WW's automatic decel trigger found (40.0d). Added to editor.
Done.
33. Hotkeys for H&R toggle, SelectAllWeapons, Shuttle Conversion, and PPT enabled. aaStrings needs an update -- done.
Done.
34. Plasma Snare effect can be assigned to exactly one of the several Plasma types. (Pick one.)
Done.
34. Plasma Damage estimator adjusted. Average damage is a fraction of maximum damage, instead of 100%.
Done. (Can be enhanced later to account for the different decay rate of each Plasma Type.)
35. Disruptor no longer doubly penalized by cloak, such that it "hits" for zero damage. It now uses an approximation of true range for damage purposes, but continues to use effective range for accuracy. This conforms to an important SFB rule that Dave Ferrell would have put in SFC if he had more time and energy. Photons, Phasers, and Plasma are effected by cloak correctly...the Dizzy, however, just needed a tweak.
Done.
36. Converted shuttles have greater endurance -- no good reason a Suicide Shuttle should run out of gas after 18.0k.
Done.
37. Fixed Photon and Hellbore endurance. (Was 10,000 freaking turns!)
Set to 1 turn for a sane range of 500k and 1000k, respectively.
Done.
38. Ship-to-ship tractor engagement range can be modded.
testing...
If the range is large, rotation results in extremely fast movement of tractored object. Recommend 0.99k to 2.99k.
Done.
39. Fighter missile rack capacity added to editor.
Fighters get 2 shots if the arc for DroI/DroVI is "ALL" or any other valid arc. If the arc is "2" they get 3 shots, if the arc is "3" they get 4 shots, similar to ships' reloads. (The column for "shots" has ALWAYS been ignored for DroI and DroVI.)
Fighters can now have many missiles that fire one at a time every 30 seconds. For example, a custom DroI rack capacity of 4 will result in 8 sequential launches if the ftrlist arc is "ALL", or 12 attacks if the arc is "2", or 16 attacks if the arc is "3".
40...
-
Well done!
-
cool sh*t!
-
This is amazing.
Please tell me I can adjust my top speed as well as cloak effective range with this?
Literally like, pissing myself in excitement that hexediting the exe to this level is possible.
-
Where can I download the latest versions of some of these great tools, especially for SFC OP?
I got the SFC OP exe editor, version 1.3.3 a few years ago, and it has been awesome.
Thanks guys.
KC
-
Where can I download the latest versions of some of these great tools, especially for SFC OP?
I got the SFC OP exe editor, version 1.3.3 a few years ago, and it has been awesome.
Thanks guys.
KC
I invite you to visit our little corner >> here << (https://hotandspicyforums.com/starfleet-command-f3/)
If anyone is interested in the things we developed in the last 2 years probably there is the place you should look for.
-
Where can I download the latest versions of some of these great tools, especially for SFC OP?
I got the SFC OP exe editor, version 1.3.3 a few years ago, and it has been awesome.
Thanks guys.
KC
You're welcome.
-
Hi guys,
The amount of work that you've done is simply incredible. Going over the threads on the last 2 years was truly wild.
But I haven't been able to find any downloads that would allow editing or revising.
Can you send me to any? update on the SFC OP exe editor (after 1.3.3)? Map editor for SFC OP? Anything else?
Well, even if not, I sincerely appreciate all of your work.
I've been using SFC since the beginning. My handle is based on the name of my kid, born when I started using SFC. He's 18 now. You've given the game new life. I so appreciate it.
Thanks
KC
-
If you have 2.564 preview, you've got the latest tools. The SFC Launcher is a different story. Carlos has explained that on hotandapicyforums.com
-
I can't seem to find it.
KC
-
I can't seem to find it.
KC
You can locate and download the new 2564 patch in our little forums section bellow.
It features all the bug fixes, enhancements and tools we made in the last +2 years and the new planets and space backgrounds.
You can also find there links for compatibles packages, like OPplus411, Fleetpick, etc, in the form of ZIPS, that you can just open and unzip to the games folder, as you wish.
https://hotandspicyforums.com/starfleet-command-orion-pirates-2500-2564-patch-t25292.html#p254917
-
Thanks so much.
I'm also really looking forward to the mission map editor. thanks.
KC
-
I'm an electronics engineer by profession. Unlike IT engineers, we're used programming in assembly language for whatever processor, microcontroller or PIC we're dealing with. Nobody uses Hex dump, unless they are a masochist. It's easier to feed the hex code into a monitor programme so it is displayed in assembler, in this case for the 80x86.
I've been programming in assembly language since 1977 with the Signetics 2650 processor on my first computer, moving onto the Z80, 6502, 6800, 68000, 8088, 8086, 80x86, 8031, 8049, 8o51, 80251, PIC, etc. and whatever new processors that will appear in the future. It has become second nature and a mindset. It's why electronics and computer engineers know themselves to be superior in skills to IT engineers.
I've programmed the PC in assembly language a few times in the past, including graphics displaying moving objects, creating multiple nested arrays, etc. without using C or C++.
C++ writes more than 20 times the amount of actual code needed to perform the task, due to the way it compiles. This is due to the included libraries of background function code it needs to add. All high level language compliers do this. It's a trade off between simplifying down software creation and cluttering up memory space when executed. These will be thing like keyboard scanning, mouse tracking, screen display routines, IO routines, etc. as the creators of C++ assume that the majority of coders are (A) too stupid to do something as simple as write a few bytes of assembly code to track a mouse or (B) too lazy too if they do know how to.
Clues to look when reverse engineering somebody else's assembly code on the PC:
Any calls to INT 27 preceded by register loading of values, either immediate or from a memory location, will be a graphic pixel display call. This will typically be within a loop of some description.
As the SFC games code was created before Core processors, with their dedicated ALU's for interrupt calls, IO calls, Subroutines, etc. there will be a lot of register stacking occurring, to and from memory. This is why running the game on Core processors doesn't give any speed increase as the software is still using up clock cycles stacking registers instead of deligating to the dedicated assistant ALU's and registers.
If you run pre Core complied code on a Core processor you can still witness a stack overflow error, something impossible on code purely created to run on a Core processor.
You also cannot run code complied for a Core processor on a pre Core processor.
Stacking and unstacking the registers in sequential and reverse sequential order to the stack space reserved in the code's memory map. This will indicate a subroutine's start and termination points. What is happening in between the stacking and unstacking is worth investigation.
A typical sequence of events would be: Stack all processor registers -> load registers for pixel coords, colour, brightness, duration -> call INT 27 -> reload all processor registers from stack.
On a Core processor running Core code: Load Interrupt registers for pixel coords, colour, brightness, duration -> INT 27.
When reverse engineering code the experts use a paper and pen / white board diagram methodology tool called a Jackson Structure to chart out gradually what the code is doing, to pinpoint where changes can be made and what needs to be done.
I keep putting off reverse engineering SFC 1 so that I can add in more weapons, such as SFB Lasers and Particle Beam Cannons.
-
I keep putting off reverse engineering SFC 1 so that I can add in more weapons, such as SFB Lasers and Particle Beam Cannons.
That is a cool project.
Hope everything works out for you.
It is a good feeling when we achieve something, even if it is only a hobby to relax.
-
Nobody uses Hex dump, unless they are a masochist.
Lol.
-
I can remember trawling through the hex dump code for a Z80 based stand alone system that monitored oil well pumps.
I was looking for a specific moment when the thing freaked out as there was a hardware fault on a batch of 10 boards due to go out the next day. They would run fine until they went to use the onboard modem, which is when the who computer system would freak out.
I was single stepping through the code with a logic analyser hooked up to the data bus. The moment reached the IO call to switch in the modem page ROM, the next byte on the data bus was wrong as it didn't match the corresponding address in the programme memory.
It transpired that D7 was being held low constantly and this was because of a middle layer track etching fault short circuit on the 3 layer PCB. This was between the Modem page ROM -Enable and D7. It was a production error on 10 boards due to be on a DHL flight at 8 AM that morning. It was 4 AM and I was all alone in the factory, as if I couldn't fix it then the only other option was to phone God. Oh, and there was a penalty clause looming if they weren't on the plane to the US. "You're our last hope Andy", they said, "We don't have God's telephone number!!". No pressure on me then.
I fixed the fault, took all the boards through test, assembly, module test, more assembly, testing, QA testing, packaged and ready for despatch when the DHL truck arrived at 7 AM. I'd been awake for 24 hours.
What was my reward for devoted service and saving the company's ass?? Being screwed over by the same company a few months later, which caused me to resign with immediate effect (you're allowed to do this in the UK under the Magna Carta) following a face to face shouting match with a manager after being blamed for something that had nothing to do with me.
They sacked the manager and he finished a month after me. The reason?? Losing a star player from the company.
I went to work for a rival, then went back into college and university education for a few years.
Loyalty and devotion to an employer is a two way street.
-
Nice work there.
It is a good experience.
-
Bump
2.564 work-in-progress...
HUD damage estimators fixed for PhA, PhB, ESGL, PPD, MIRV.
New customizable variables for SFC Editor:
EPT damage multiplier
PhX overloaded damage multiplier
ESG Lance attack strength
Missile speed BPV costs (applies to multiplayer)
MIRV bloom time
AMD rate of fire
AMD ammo supply
PlasD ammo supply
Myopic range for missiles
Fighter-based missile speed classes (slow/med/fast)
Maximum ship speed (0 to 31)
YFA for medium and fast missiles
Skirmish era time spans
New features:
ADD30 (aka "AMD C") anti-drone device enabled -- this thing has 30 ammo per rack! designed for starbases
Each TRBL and TRBH hardpoint can use the PhA/ESGL panel (instead of the broken panel)
PhG given its own weapon charts
Bug fixes...underway
I'll just paste the beta changelog...
1. PhA_MinDam estimator fixed.
2. PhB_MinDam estimator fixed.
3. EPT variable isolated.
4. PPD Min Dam estimator fixed.
Added arrays for UL and OL.
5. Ph-X OL multiplier isolated.
6. HB hold cost isolated.
7. Vessel library bugs. Not Fixed!
8. AMD estimator not quite right. Enemy fighters do not validate estimator (stays yellow font on Klink HUD).
Enabled Avg Damage anyway for every other unit.
WIP.
9. PPD estimator enhanced
10. Missile speed cost display. Can't show float, so show x100 (i.e. 50 = 0.50).
Done.
11. ESGL_Dam isolated.
12. ADD30 enabled.
13. TRB can use any icon. But A6_panel is blank.
Enabled functional alternates (PhA or ESGL)!
14. PPD fire hose bug. Gauge shows bug, but doesn't cause it. Very hard to diagnose.
Cant fix this one. Move on.
15. MIRV bloom variable isolated. Note that MIRV bus has 2 hitpoints and a warhead of 2!
16. Missile Myopic range. Custom variable.
17. New Drone Max Dam for estimator.
18. New Drone Avg Dam for estimator.
19. Fighter missile speed class (slow, medium, fast) is now moddable.
DroI can be slow, DroVI can be fast -- whatever you want.
20. Ship max speed is moddable (0 to 31).
21. Cloak chart's misery multipliers have been isolated.
22. The ESG estimator assesses the capacitor per hardpoint now so it cannot underreport.
If the capacitor has 5 points, each hardpoint thinks it can use that energy. Which it can, but both can't use it...
So it'll estimate 40 dam, instead of 20 dam. Phasers work like this too.
Improved but not perfect.
WIP.
23. TR Beam Min Dam for estimator.
24. Mauler Min Dam for estimator.
25. Mauler accuracy isolated.
26. ESG cycle isolated.
27. HUD should always shows ESG potential damage since it is a sphere that'll whack anything.
Fixed.
28. Stop writing to "Above8bitTextures.txt" on every mission! (useless debug code)
Done.
Doublecheck this...
Done.
29. Customizable mine/t-bomb/NSM explosion strength, endurance, detonation speeds, activation range.
Done.
30. strings.txt |ErraticsAreOn|...Maneuvering erratically...
The inactive "ErraticMissile" warning now notifies player of EM at customizable frequency.
Bug: spams "transporter can't be used now"...
Bypass spam.
Done.
31. Isolated TBomb calls to range variable (cursor and deployment)
Done.
32. WW voiding-speed variable found (40.1d). Added to editor. Increased value slightly to account for asynchronous WW failures. WW's automatic decel trigger found (40.0d). Added to editor.
Done.
33. Hotkeys for H&R toggle, SelectAllWeapons, Shuttle Conversion, and PPT enabled. aaStrings needs an update -- done.
Done.
34. Plasma Snare effect can be assigned to exactly one of the several Plasma types. (Pick one.)
Done.
34. Plasma Damage estimator adjusted. Average damage is a fraction of maximum damage, instead of 100%.
Done. (Can be enhanced later to account for the different decay rate of each Plasma Type.)
35. Disruptor no longer doubly penalized by cloak, such that it "hits" for zero damage. It now uses an approximation of true range for damage purposes, but continues to use effective range for accuracy. This conforms to an important SFB rule that Dave Ferrell would have put in SFC if he had more time and energy. Photons, Phasers, and Plasma are effected by cloak correctly...the Dizzy, however, just needed a tweak.
Done.
36. Converted shuttles have greater endurance -- no good reason a Suicide Shuttle should run out of gas after 18.0k.
Done.
37. Fixed Photon and Hellbore endurance. (Was 10,000 freaking turns!)
Set to 1 turn for a sane range of 500k and 1000k, respectively.
Done.
38. Ship-to-ship tractor engagement range can be modded.
testing...
If the range is large, rotation results in extremely fast movement of tractored object. Recommend 0.99k to 2.99k.
Done.
39. Fighter missile rack capacity added to editor.
Fighters get 2 shots if the arc for DroI/DroVI is "ALL" or any other valid arc. If the arc is "2" they get 3 shots, if the arc is "3" they get 4 shots, similar to ships' reloads. (The column for "shots" has ALWAYS been ignored for DroI and DroVI.)
Fighters can now have many missiles that fire one at a time every 30 seconds. For example, a custom DroI rack capacity of 4 will result in 8 sequential launches if the ftrlist arc is "ALL", or 12 attacks if the arc is "2", or 16 attacks if the arc is "3".
40...
-
Absolutely amazing Tar. That’s a long list. Can only imagine what you could do with the actual source code.
-
Let’s not forget what’s yet to come, unbelievable accomplishments btwn Tim, Carlos and TAnimal. It’s much appreciated. Thank guys.
-
Still working on StarfleetOP.exe...
Up to 2.564 H&S 1.1c
PFs can be directly enabled for all races and cartels without Rod O'Neal's donor scheme. Or all empires can deploy ftrlist fighters.
Fighter and PF minimum speed can be set from 0 to 31, instead of 20. AI ships can have a minimum desired speed of 0 to 31, instead of 8.
HETs require energy while ship is using Erratics.
PF's can have spare parts.
Nearly all weapons can be given a special ability, like enveloping damage, stun, implosion, snare, stun...
PFs can use Dis1, PlaF, PhoF and FusF with custom precharges.
PhoF and FusF can use true Phot and Fus stats/UI.
Energy for HETs and EM can be customized.
Minimum HET chance can be made greater or less than 16.67%.
Three empires can have faster or slower AI fighters/PFs than the remaining factions even when given identical stats.
...