Dev's Limit Breaking 101 Techniques

Nieckey · wrote on 27 Apr 2009, 13:40

Actually, FLServer not allowed more than 1 player login with one in-Server ID, but to bypass the limit is easy: Player can change the Online ID with other one before they join server.

foxUnit01 · wrote on 29 Apr 2009, 23:30

04/29/09:
– Indexed w0dk4’s collision detection min check distance (increasing this will fix issues with the sur collisions on objects > 130k from center of system)

04/28/09:
– Indexed M0tah’s chat-block offset (stops chat from being displayed, useful for filming)

foxUnit01 · wrote on 5 May 2009, 15:51

05/05/09:
– Indexed M0tah’s hack to prevent mission failures due to attacking a neutral/friendly object - recommended if using mission scripting for sandbox purposes

viper · wrote on 8 May 2009, 17:48

Was bored xD

0xBF1D1D in freelancer.exe, 0x5E01B = 1.1 the RGB color as Hex value of the message: New Player and so on….

FriendlyFire · wrote on 10 May 2009, 22:47

Added a critical hex value:

– 0.8f in server.dll, 0x???, 0x8AE78 = resale % for ships (server-side, must match variable above or 1.1 server dll will kick client for cheating) ~FriendlyFire

I changed resale value and was getting instant kick on everyone attempting to buy a new ship. Turns out this value had also to be changed ::)

foxUnit01 · wrote on 11 May 2009, 00:26

05/10/09:
– Indexed Viper’s RGB color as Hex value of the messages “New Player” etc.
– Indexed FriendlyFire’s resale % for ships (server-side)

foxUnit01 · wrote on 11 May 2009, 00:44

Added an htm version of the offsets editing tutorial, with pictures displayed alongside the text; it may be found at http://www.memes.no/88flak/downloads/beta/1.0-1.1_Offsets_Tutorial.htm

w0dk4 · wrote on 13 May 2009, 16:39

0x13DFAC common.dll (v1.0) - 1.74f - multiplier for fill_dist in CmnAsteroid::CAsteroidField::near_field calculation, increase this to make FL render asteroid fields from greater distances.

This is extremely useful for massive, high range (high fill_dist) asteroid fields.

btw.: The target bracket offset should not be used when you are having any asteroid field in your mod, since this offset is used in a lot of asteroid calculations and will mess them up!
I posted a workaround in the other thread, the best solution is to allocate a new float entry in free memory space and then reference that for the target brackets.

OutCast · wrote on 13 May 2009, 18:44

Thanks, w0ddy I’ve been wondering if there’s an offset like that.

Btw, took a quick look at 1.1 common.dll, and there’s only one offset with 1.74f - 0x13DFDC, so i guess that’s it

Now let’s see how my 8600gt will manage with those fields and with AA 8x forced ;D

w0dk4 · wrote on 13 May 2009, 19:06

Well, this is not for general visibility, but the “popping” effect on large fill_distances (asteroids dont fade in when you approach the field, they pop in).

This is also only a problem for super-large asteroid fields, so as long as you are not dealing with super large asteroid fields, it wont really make a difference

JONG · wrote on 13 May 2009, 19:37

Hi w0dk4.

If I make my mod asteroid fields to dynamic asteroids, change this can increase “popping” effect or not?

foxUnit01 · wrote on 14 May 2009, 16:44

Hey neat. Flak’s fields are 100% dynamic fields, so I’ll see if this does anything for 'em. Either way, with static fields, I always thought it was strange that you didn’t start seeing actual asteroids until you pretty much entered the field - the 2D billboard rings look fine from a distance, but they’re damned ugly up close.

w0dk4 · wrote on 15 May 2009, 00:35

@foxUnit01:

Hey neat. Flak’s fields are 100% dynamic fields, so I’ll see if this does anything for 'em. Either way, with static fields, I always thought it was strange that you didn’t start seeing actual asteroids until you pretty much entered the field - the 2D billboard rings look fine from a distance, but they’re damned ugly up close.

Exactly! Here’s why I needed that offset btw:

http://www.youtube.com/watch?v=mqyIxFHZtR8

FriendlyFire · wrote on 15 May 2009, 02:34

Do I notice video lag?

And looking at that vid reminds me how finding a way to fix the camera’s distance from the ship would be a marvellous thing…

foxUnit01 · wrote on 15 May 2009, 03:52

Oh man that’s so awesome.

JONG · wrote on 15 May 2009, 04:39

@foxUnit01:

Hey neat. Flak’s fields are 100% dynamic fields, so I’ll see if this does anything for 'em.

If its work, please let me know, thanks.

foxUnit01 · wrote on 15 May 2009, 08:43

– Moved System Editing section closer to the top, under Visibility, as the two sections have similar utility
– Added w0dk4’s offset to render asteroid fields from greater distances, under System Editing

JONG · wrote on 15 May 2009, 18:55

I was tested to increase the FL render asteroid fields distances at dynamic asteroid fields values, and here is what I got:

change 1.74f to 10f: no obvious change
change 1.74f to 100f: increase a little of visibility
change 1.74f to 2000f: increase a little of visibility same like I change its values from 1.74f to 100f

So I think this edit will only for static asteroid fields, not for dynamic asteroid fields.

BSGVenom · wrote on 16 May 2009, 06:09

i cant see any diffrence at all -_-

Vital · wrote on 17 May 2009, 08:33

Found another one.

0xBB1DA Content.dll (v1.1) - 2000f - distance from the patrol zone that patrol_path encounters begin to spawn.
Note: so far tested only with patrol zones and patrol_path behaviour encounters.
This is not the distance from the end of the patrol(suprisingly), but from the patrol zone.

Say, you have patrol that begins near New London and ends near Cambridge gate. So between these to points if you are closer to the patrol than 2000 m, patrol encounters will spawn.

This is not from the middle of the patrol.
Say, your patrol has size 75030000. in this case encounters will spawn 2375 - 2750 away from the patrol. If your patrol has size 130000, they will spawn 2000 away from it or closer.