Dev's Limit Breaking 101 Techniques

Ruppetthemuppet wrote:
Hi folks, with the TSP forum upgrade imminent, we’re shifting stuff from the wiki over to a new system, this includes Limit Breaking 101!

I’ve ported the tsp-wiki page over to the new format, and will be doing a pass of this thread to add any offsets that haven’t been included yet.

The new page can be found here: https://wiki.the-starport.net/FL Binaries/Limit Breaking 101/ It pulls from this repository: https://github.com/TheStarport/KnowledgeBase, and auto-updates when there’s a change.

If you’d like to contribute to the page, feel free to either make a PR or give someone on the Galactic community discord a shout for direct access. We’re still ironing out a few issues, and are in the process of porting the wiki content as a whole over.

Euhm… a few questions if I may:
(1) Will the 101 list from the wiki here disappear?
(2) I can’t seem to append my new offsets to the new 101 list, how do I do that?

Gold_Sear wrote:
(1) Will the 101 list from the wiki here disappear?

Eventually, yes, but we’re going to make sure everything is ported over and folks who want to contribute know how to contribute first. I’m not responsible for the forum changes, but have been assured that when they happen the old wiki will persist in an archived format until we’re happy we’ve reached parity. It’s going to be around for quite a while longer whatever happens.

Gold_Sear wrote:
(2) I can’t seem to append my new offsets to the new 101 list, how do I do that?

If you head to https://github.com/TheStarport/KnowledgeBase, and clone it, you can make changes via pull request. If you don’t want to deal with the hassle of that and waiting for someone to authorize the PR, shoot me a DM with your email address/github account, and I can add you to the contributors list so you can make additions to main directly! Right now we’re using .md files that are built into the wiki pages automatically, so any changes made to the repository are reflected on the wiki almost immediately.

@adoxa: is this DWORD-alignment faster or more secure (or for another reason I might not think of)? Or is it just for consistency?

Faster (ostensibly) and consistency.

Ruppetthemuppet wrote:
Hi folks, with the TSP forum upgrade on the horizon, we’re shifting stuff from the wiki over to a new system, this includes Limit Breaking 101!

I’ve ported the tsp-wiki page over to the new format, and will be doing a pass of this thread to add any offsets that haven’t been included yet.

The new page can be found here: https://wiki.the-starport.net/FL Binaries/Limit Breaking 101/ It pulls from this repository: https://github.com/TheStarport/KnowledgeBase, and auto-updates when there’s a change.

If you’d like to contribute to the page, feel free to either make a PR or give someone on the Galactic community discord a shout for direct access. We’re still ironing out a few issues, and are in the process of porting the wiki content as a whole over.

I was about to ask for a darker theme as the standard one was burning my eyeballs, then i saw the light button, looks much better with the dark theme imho

I’ve indexed all of the new offsets found by Gold_Sear on the new page, and combed this thread for any I might have missed before, sorry it took a while to to get to!

This has come up a few times in discussion on the Discord, but how do folks feel about splitting the page up by category and having a central index for these? The md file is so large VS code won’t auto format it at this point!

@Ruppetthemuppet: the issue about the offset for my NavMap zoom move limit has been resolved, so can you please add them to the list on KnowledgeBase (or just pull my request)?

This has come up a few times in discussion on the Discord, but how do folks feel about splitting the page up by category and having a central index for these? The md file is so large VS code won’t auto format it at this point!

I see now that there is no possibility to jump between sections, so this would probably be a good idea, to group the separate files in the folder e.g. ‘Limit Breaking 101’.

Sorry it took so long to accept the PR! I’ve fired you an invite to the contributors team so you can commit directly if need be in the future.

There is in fact a contents/directory tree down the right-hand side, but I think on certain screen resolutions it doesn’t show up. Will investigate the possibility of contents blocks (where relevant)

CA02->0000 freelancer.exe 02477A adoxa
Laz Enable Borderless Window (disable caption flags) (PART 1)
CA02->0000 freelancer.exe 02490D adoxa
Laz Enable Borderless Window (disable caption flags) (PART 2)

I just had a player request regarding the borderless window. Since removing the border he can no longer move the window (he said he likes to play with 4:3 resolutions). I did not expect this to ever be an issue but I guess I was wrong.
Tested it and the FL window is stuck to the top left corner of the screen. Without border no way to drag the window to the center (or anywhere else).
For now I proposed to use winexplorer to set a custom position for the Freelancer process.
Alternative to that I was wondering if its possible to enable something like the WS_SYSMENU option on FL somehow. That way alt+space would open a context menu with a move option.
Any ideas if that is possible?

Use [c]0A00[/c] instead of [c]0000[/c] (at least, it works on 10).

cool, thx
Will try it this evening.

Just a quick request! Have found an offset adjacent to [c]139B74: use thruster hp_type for cloaking device[/c].

Changing [c]40 17 2D[/c] at [c]139AF0[/c] to [c]C0 DE 26[/c] in common.dll allows me to mount armour equipment on the thruster hp_type, but doesn’t actually mount the model on the hardpoint! As a result I can mount an infinite number of armour modules on the hardpoint.

It appears there’s an extra check involved for equipment marked as internal here, does anyone know if there’s an offset that would allow me to mount the armour externally and avoid this issue?

[c]DCC1[/c] is the armour [c]class_type[/c] and/or [c]139AFC[/c] from [c]00 BA 29[/c] to [c]10 A7 27[/c] to consider it attached (might not work).

Cloaking Devices surprisingly are/seem to be External Equipment. Armour may be Internal Equipment. This could be the reason why certain checks do not work properly here. But that’s just a guess.

adoxa wrote:
[c]DCC1[/c] is the armour [c]class_type[/c] and/or [c]139AFC[/c] from [c]00 BA 29[/c] to [c]10 A7 27[/c] to consider it attached (might not work).

This partially works! The hardpoint restriction is enforced when the armour is mounted, which is most of what I wanted. However: the equipment model itself is unfortunately not mounted on the HP. I’ll check around a bit and double-check I’ve not stuffed up implementing the model itself.

Another request! it appears that player scanner range for NPCs in MP is capped around 6500m, does anyone know where this value might be changed? It doesn’t appear to be in limit breaking, but I feel like I’ve seen this one floating about before.

In the NPC Behaviour section

500i content.dll 06C470 Dev max range at which NPCs will scan your cargo
2500f content.dll 06C717 Dev max range at which NPCs will initiate scan of your cargo

When I say scanner range, I mean the range at which the player can see NPCs, not the other way around! I’ve adjusted a few offsets, but it unfortunately appears to be capped in multiplayer and I’ve not had any luck raising it past that point.

I changed [c]ge_s_scanner_01[/c] to [c]range = 25000[/c] and increased [c]086AEC/F0[/c] to 49e6. With two players 7K apart I also saw NPCs at 7K (and briefly one player saw an NPC at 21K).

Well this is very strange, these offsets don’t seem to change the MP behaviour at all for me! It’s 100% the scanner. If I move out of range and back, the NPCs persist at least out to 12-14k. Could there be another value (not scanner range, that’s set to 10,000!) that’s capping this?