Dev's Limit Breaking 101 Techniques
-
…. just an experience thrown in:
If you got very expensive ships + equipment parts,
price variants can make up fantastic trading possibilities.Once I had to wonder, how fast all those pilot suddenly got real rich.
-
Just to make sure to not mess anything up…
Adoxa wrote in the above mentioned post:
That section also contains “ship_repair_cost = float” (default 0.33). This affects the repair value of the ship and its groups, but not equipment…
So I assume the default ratio (your offset FF):
default repair price ratio (1) common.dll 57FA 0.33 ```is used whenever this entry "ship_repair_cost" isn´t present at all in a BaseInfo-Section ? Greets J.R. -
Just to let you know: I’ve added my findings from http://the-starport.net/freelancer/forum/viewtopic.php?post_id=62352#forumpost62352 to the wiki entry.
In case anyone has the low res texture bug, this fixes it. -
foxUnit01 wrote:
10/25/15: -- Added note to Gold_Sear's multiplier for min cruise speed in formation, as this hack seems to bork up asteroid fields -- Corrected attribution for disable charfile encryption hacks to AdoxaSo I’ve fixed point 3 of my todo list at least partially.
common.dll 8C331 7A 19 -> 90 90 make formation leaders independent of escorts (this will make formation leaders able to flee) PART 1 ~Gold_Sear common.dll 8C35C DC 0D 88 DF 39 06 -> 90 90 90 90 90 90 make formation leaders independent of escorts (this will make formation leaders able to flee) PART 2 ~Gold_Sear common.dll 8C4D3 7A 23 -> 90 90 make formation leaders independent of escorts (this will make formation leaders able to flee) PART 3 ~Gold_Sear common.dll 8C4E4 75 12 -> 90 90 make formation leaders independent of escorts (this will make formation leaders able to flee) PART 4 ~Gold_Sear ```This will prevent formation leaders from waiting for their escorts before fleeing while in combat, making them able to properly flee. More precisely, it will prevent them from waiting for their escorts before engaging cruise. It also has effect in non-combat situations. Todo (concerning engage cruise): - Make a fleeer cruise all the way. Every 20 or so seconds, a fleeer will drop out of cruise and then about 3 seconds later engage cruise again, even when there are enemies. Of course, he should be cruising all the way. This behavior is also shown by tradep_trade_traders. - Prevent formation leaders from standing still in cruise. This sometimes happens when e.g. a transport is fleeing from pirates but its escorts are engaging the pirates, when a formation enters an 'important' zone (such as damage, interference or spacedust), or even when just reaching the next section of the patrol path. - Make traders cruise all the way to the destination. When a trader approaches a jump gate or base to about 3km, he will suddenly drop out of cruise and immediately engage cruise again. Of course, he should be cruising all the way to the destination. I haven't tested this thoroughly yet, but it looks like as if this happens when the convoy switches from goto to dock. Thus, a possible fix is to prevent the formation leader from checking the dock distance and instead either dock immediately or dock within dock acknowledge range. -
Moonhead wrote:
Here it is, a piece of text that moved me more than any poetry could have done. Copied-and-saved from The Lancer Reactors Modding Forum, preserved from ancient times, copied from harddisk to harddisk: the Holy Planets Visibility Limit Hack!FriendlyFire
Flight Commander
Original posting
posted 10/4/2005 18:31 PST
–------------------------------------------------------------------------------
I was fiddling with a problem I had with scales and I was looking for the mythic 250k draw limit. I found it!Open up your Freelancer.exe with your favorite Hex Editor. I use Hex Workshop.
Search for a 32 bits Float value of “250000” ( Without “” ).
The first and only result is the good one. Change it to, say, 1000000 ( 1000k ) and save, then try to boot the game ( Singleplayer is better for this as it does not have the ship explosion bug when you are too far away from the center of the map ).It will work!
Hope this helps making even greater mods.
FriendlyFireEdited by - FriendlyFire on 10/4/2005 6:32:23 PM
Bring me my bow of burning gold!
Bring me my arrows of desire!
Bring me my spear! O clouds, unfold!
Bring me my chariot of fire!
:worship:Oh that reminds me: nebula’s also get weird when your too far from ’ em… But I can’t remember of the above-mentioned hack also covered that. or if that one even has been solved.
(post 345)
I’m posting this here since there’s a good chance that this will lead to another offset for the list.
@Moonhead, FriendlyFire, adoxa
So I was playing with big planets and large systems, and, to my unpleasant surprise, I stumbled onto another draw limit for planets.You can try it out yourself. First, make a planet that has a large radius, for example 200000 (manhattan will do as well but is not as easy to see); simply pick a planet’s sph file, copy it, rename it, and change the float at the end of the file – that’s the radius. Then add to solararch.ini and put it somewhere (it does not matter where). For testing purposes, increase the cruise speed to something like 30000. Launch FL, go to the system you placed the planet in, and fly away from the planet. Now at about 1200-1400K away from the planet (depending on how big your planet is), it will suddenly disappear from screen!
More thorough testing indicates that the limit seems to be exactly 1428148 units away from the planet’s center (so 1428148-radius away from the surface). This is given the planet is exactly centered at screen, when not in center the above mentioned distance is increased.
In contrast to FF’s limit, which gives some flickering before disappearing, this limit causes sudden disappearance, similar to this.
Unfortunately I didn’t find any offset for the limit (yet) or how to fix it.
PS: On another note, FF’s limit does apply to nebulas and suns, they are rendered just fine from huge distances, but not planets.
-
Hi again,
When making a veritcally oriented trade lane (so it also travels vertically) and setting proper [c]rotate[/c] settings for the rings, travelling in the [c]next[/c] direction works just fine, but in the [c]prev[/c] direction the vertical component is not swapped, causing weird behavior. The following patch fixes it.
common.dll 06191E DD 05 D0 E2 39 06 D9 FF -> D9 E8 D9 E0 D9 EE D9 C1 = swap vertical component of trade lane travel in prev direction (fixes issues with vertically oriented trade lanes) PART 1 ~Gold_Sear common.dll 061941 C7 44 24 24 00 00 00 00 D9 54 24 20 D9 5C 24 30 C7 44 24 2C 00 00 00 00 D9 54 24 24 D9 54 24 28 C7 44 24 30 00 00 80 3F D9 54 24 2C D9 54 24 34 C7 44 24 34 00 00 00 00 -> D9 54 24 3C D9 44 24 54 = swap vertical component of trade lane travel in prev direction (fixes issues with vertically oriented trade lanes) PART 2 ~Gold_Sear C7 44 24 3C 00 00 00 00 D9 E0 D9 5C 24 54 D9 44 DD 05 D0 E2 39 06 D9 FE 24 60 D9 E0 D9 5C 24 60 D9 C1 D9 5C 24 20 D9 54 D9 44 24 48 D9 E0 D9 5C 24 28 24 48EDIT: indexed to wiki. Also indexed formation leader independency patch to wiki.
-
I’m probably doing this wrong but I am trying to add the FPS limit via the hack.
I went to the part 1 offset and changed 200 to 60 (I guess I am misunderstanding this part).
I went to the offset and changed the values as described in part 2.I loaded up fraps for it’s overlay and it shows a fluctuating range up to around 170s range.
Am I doing this wrong?
Should the max FPS now be 60? -
Gold_Sear wrote:
[…]a veritcally oriented trade lane (so it also travels vertically) and setting proper [c]rotate[/c] settings for the rings […] The following patch fixes it.
Nice one!!
Making vertical (or at least, ‘climbing’, under a 45° angle) tradelanes was one of the first things I tried in modding. But I essentially only had (and still have) insight to the extent of what I could see in the .ini files so I couldn’t fix it. They worked btw, but traveling downwards the ship was weirdly positioned (nose up, its bottom pointing to the traveling direction).
-
@adoxa:
I think so:
changed value to 2 million -> draw limit increased to ~2800K
changed value to 1e38 -> Manhattan (and Pittsburgh) remains visibleThanks!
-
Are there similar hacks for msg_id_prefix in universe.ini (don’t append dash)
At the following locations in [c]content.dll[/c], replace [c]64[/c] with [c]65[/c]: 037148, 039684, 039AA3, 039CE1, 03AA92, 03AE02, 03BA22, 03F0A6, 03BA220, 03F0A6, 041A74, 041C75. This effects the same items as the previous patch (which would jump over the append code; this makes it append an empty string). I don’t know what effect it would have elsewhere (meaning if you explicitly add the dash to [c]universe.ini[/c], there are occasions where you’ll end up with two dashes).
gcs_refer_faction in faction_prop (don’t append _short)?
Didn’t look into this, but at 116324 in [c]content.dll[/c] is the string for [c]_short[/c], so change that to 00 and see what happens…
-
Right, I should have thought of that. Okay, at 036F5F, 0385B1, 03948E, 03A123, 03A42B, 03D8DF, 03E547, 03EB48, 03EC5C, 0401C8, 040C3B, 04172C, 045DB0 and 045EC4 replace [c]2C[/c] with [c]28[/c]; then at 116328, write in [c]gcs_refer_faction_player_short[/c].
-
I should mention another two findings by adoxa:
1:
adoxa wrote:
Ah, I should have done another search with underscores.
You’ll find the defaults as two ints at [c]18C754[/c] in [c]common.dll[/c]. The function is only used by [c]Act_PlayerEnemyClamp[/c].Alternative:
common.dll 08E86A 7E31->EB39 = disable PlayerEnemyClamp, instead making NPC target selection random ~adoxa ```I don't recall if it completely deactivates the scripted [c]Act_PlayerEnemyClamp[/c] function, but it has the desired effect when not in a mission. **2:** [Making npcs global, not local to base](https://the-starport.net/freelancer/forum/viewtopic.php?post_id=37919#forumpost37919), found by adoxa; makes a visited NPC at a bar also visited at other bases. Indexed (to Misc section). **3:**: [Removes exclusion zone clipping](https://the-starport.net/freelancer/forum/viewtopic.php?post_id=39612#forumpost39612), prevents far clipping of exclusion zones. I should also **warn** that [adoxa's solution to the 130k asteroid rendering limit](https://the-starport.net/freelancer/forum/viewtopic.php?post_id=25444#forumpost25444) has serious side effects: change of 7 to A results in the asteroids mostly not being rendered and even if so, then spawned in a regular pattern instead of pseudorandomly. I'd suggest we'd have another, closer look there. EDIT: this last statement is **not true** :oops: I used [c]hispania_debris_field[/c] to test, but apparently that one isn't representative. My mistake…. EDIT2: looking more closely, it is still partially true, using F instead of A; now the asteroids do get spawned, but in a very regular pattern. Conclusion: careful raising these two bytes -
w0dk4 wrote:
The problem with asteroids not being able to be rendered is due to how FL computes unique IDs.
Because after a certain size of the position vector the unique id computation function fails, asteroids will no longer be spawned.At Freeworlds, we simply made the function always return “some” id, no matter if its a broken ID.
Maybe adoxa can fix the code for larger vectors, the function responsible is:
unsigned long __cdecl CmnAsteroid::compute_cube_id(class Vector const &)
in common.dll (062A6010)
@w0dk4: did you apply this patch?
common.dll 460B6 77 3B -> 90 90 = always render static asteroids PART 1 common.dll 460BE 77 33 -> 90 90 = always render static asteroids PART 2 common.dll 460C5 77 2C -> 90 90 = always render static asteroids PART 3 ```Or something similar? I'm asking because adoxa's patch on this subject has side-effects (see above post).
