Dev's Limit Breaking 101 Techniques
-
– 1.74f in common.dll, 0x13DFAC, 0x13DFDC - multiplier for fill_dist in CmnAsteroid::CAsteroidField::near_field calculation, increase this to make FL render asteroid fields from greater distances ~w0dk4 (~OutCast for 1.1 version of offset)
I was thrilled to discover this was found out. Unfortunately it doesn’t work
I could find the value at the offset mentioned, changed it, but still beyond 130K from a system’s center, asteroids are not rendered; only the billboards and dyniamic asteroids are there.
Does anybody actually know how to create a proper asteroid field beyond the 130K from the system center?
Thanks!
-
I’m sure I used it before and it worked.
-
FriendlyFire wrote:
I’m sure I used it before and it worked.Can you remember what value you replaced the 1.74 with?
I’ve tried 17.4, 9.99 and 0.174 (the last one after the first two failed, to see if it should be decreased instead of increased)
-
Moonhead wrote:
– 1.74f in common.dll, 0x13DFAC, 0x13DFDC - multiplier for fill_dist in CmnAsteroid::CAsteroidField::near_field calculation, increase this to make FL render asteroid fields from greater distances ~w0dk4 (~OutCast for 1.1 version of offset)
I was thrilled to discover this was found out. Unfortunately it doesn’t work
I could find the value at the offset mentioned, changed it, but still beyond 130K from a system’s center, asteroids are not rendered; only the billboards and dyniamic asteroids are there.
Does anybody actually know how to create a proper asteroid field beyond the 130K from the system center?
Thanks!
It does work. It’s in the FW:ToW mod right now. Maybe there’s something else you’re missing?
-
– 1.25f in freelancer.exe, 0x1C9804, 0x1C9804 = multiplier for distance at which brackets around non-targeted ships in space will appear (1.25 = ~3km, 37.5 = ~93km, etc)
I messed with this and encountered a side effect. It messes with the tractor beam effect, or at least did in my mod making it invisible. Soon as i reset the value, it was back to normal.
-
Sushi wrote:
It does work. It’s in the FW:ToW mod right now. Maybe there’s something else you’re missing?
I believe you people when you say it works! Just doesn’t do it for me, sofar.
I’ll look into it again, and maybe upload or link to a minimod regarding this. Or, if I fix it, let you know what I did wrong (might be useful for other people).
-
@Gibbon: Revisit my earlier post for an alternate address.
-
Concerning the Asteroids:
I realize I might have misunderstood what this hack is supposed to do!– 1.74f in common.dll, 0x13DFAC, 0x13DFDC - multiplier for fill_dist in CmnAsteroid::CAsteroidField::near_field calculation, increase this to make FL render asteroid fields from greater distances ~w0dk4 (~OutCast for 1.1 version of offset)
“render asteroid fields from greater distances” - that might refer to a visual thing: the player sees the asteroids from a greater distance when the hack is applied.
But what I want is something completely different from that.
As it is now, the game seems to keep an invisble circle in the starsystems of about 130K (measured in-game) from the center. Beyond that circle, asteroids will not be created! An asteroid field lying on this invisible circle will have asteroids within it, and none outside of it, altough it shows up on the navmap like it’s a complete field. (This limit does not apply to dynamic asteroids and billboards - they are created beyond the circle)
So, what is the hack supposed to do?
1. Expand the seeing of asteroids by the player? or
2. Expand the limit in which the game will create asteroidsIf it’s option 1, then it makes sense I don’t get the hack working, as I am expecting the wrong this. If it’s option 2, then I remain very puzzled.
-
adoxa wrote:
Doing a search for 130000 actually found one:[ExclusionBand]
fade = 1500, 2500, 100000, 130000 ; default valuesThat of any help?
Hmm… Don’t think so, I don’t have exclusion bands in my asteroids.
And - I am not talking about mere visibility. I’m talking about asteroids actually being there (or more precisely not being there)
Thanks for nthe suggestion though.
-
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)
-
Okay, open up common.dll (v1.1), jump to offset 0x460a9, change 7 to 8, same at 0x460af. That should increase it to ~260k (x and z, respectively; y remains at ~65k), presumably at the expense of removing them further from the center, from 256 to 512 (big deal). As you may have guessed by now, use 9 instead of 8 to increase to ~520k (1024 from the center).
-
adoxa wrote:
Okay, open up common.dll (v1.1), jump to offset 0x460a9, change 7 to 8, same at 0x460af. That should increase it to ~260k (x and z, respectively; y remains at ~65k), presumably at the expense of removing them further from the center, from 256 to 512 (big deal). As you may have guessed by now, use 9 instead of 8 to increase to ~520k (1024 from the center).I just replied, but my connection failed :-x
Anyway, great that you found it. But -weeehh- I use common.dll version 1.0… Is there a way to recalculate the offsets? Or doesn’t it work that way?
In Common.dll 1.0:
0x460a9 = 59
0x460af = 0CI guess these are totally unrelated values, being a different version?
-
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)
Hi! Had overlooked your post. Thanks for the info though (not that I can do anything with it, but Adoxa apparently does!)
Maybe I should just abandon the idea and simply use customized dynamic asteroids. I remember someone found out you can redefine the normal asteroid models as dynamic asteroids, and have up to nine fields overlap each other.
And then, IIRC, there is a value in constants ini that can modify collision damage.
(Which brings up another idea that might be a cool project for Adoxa: enable the game to have the constants in constants.ini redefined in per star system. Would that be possible?)
-
I’d argue that there is no good reason to be using 1.0 anymore. I urge anyone still working with it to move to 1.1, if only for the security features provided by 1.1’s cheating detection and most importantly FLHook. Having both client and server running 1.1 does not matter so long as the server does, but it’s a lot easier to develop a mod with only one version
-
adoxa wrote:
Sigh, just when I thought everyone was using 1.1… 0x463c9 & f.
:worship: Thx!!!
friendly fire wrote:
I urge anyone still working with it to move to 1.1,
I must confess I have no ideas how to that…
And I have some recollection it was disadvised against on the old (TRL) forum. Can’t remember what the reason was, but it was a good oen. Apparently, the issue has been overcome, but I’d like to know what & how.
Besides, although I have a legally purchased copy, I have a no-cd version that ‘fell off a truck’, and that’s a 1.0 . Is there a no-cd patch for 1.1?
-
adoxa wrote:
Sigh, just when I thought everyone was using 1.1… 0x463c9 & f.IT WORKS!
