Dev's Limit Breaking 101 Techniques
-
in combination with adoxa’s multicruise.dll i thought of a following solution: adding a parameter to the shiparch, that would deside, whether a ship can or cannot dock with a tradelane. in that way, you could e.g. make large capitals cruise faster than regular ships but therefore not to have the advantage of tradelane travel. is this possible?
-
oh, my apologies to M0tah…
and thanks, adoxa. would be another rebalance of traffic^^ -
adoxa wrote:
This prevents everything (engines/scanners/tractors/powerplants) from being transferred. Untested.Thank you!
-
This just in…
freelancer.exe 11D072 8C->CC = allow 64 simultaneous firings PART 1 ~adoxa freelancer.exe 11D7C2 8C->CC = allow 64 simultaneous firings PART 2 ~adoxa
is what killed the JFLP roll… tested & proven 100%… dam shame…
just a heads up… for anyone using both -
Oops! Again, I didn’t look closely enough.
freelancer.exe 11D072 8C->CC = allow 64 simultaneous firings PART 1 ~adoxa freelancer.exe 11D2F9 A0->E0 = allow 64 simultaneous firings PART 2 ~adoxa freelancer.exe 11D553 A0->E0 = allow 64 simultaneous firings PART 3 ~adoxa freelancer.exe 11D7C2 8C->CC = allow 64 simultaneous firings PART 4 ~adoxa
-
Just curious, how does the game calculate the 64 limit out of E0/CC, I mean, none of them give you 64 or anything related. (Correct me if I’m wrong here)
-
E0=A0+40
CC=8C+40with 40 ofc being 0x40 equal to the decimal value 64
-
Gisteron, if you have E0=A0+40 and CC=8C+40, how do you have 32 in A0 and 8C then? Sorry, but this explanation is not really helpful.
-
A0=(4+1)*20
the 8C is probably a sum of some values or does not define the 32 at all… sure adoxa can explain better xD
anyway, if adding 64 makes the maximal fire amount rise by 32, it is possible that other offsets define the initial 32. otherwise you could set the A0 byte up to FF (with equal risings of the 8C byte) resulting in (FF-A0)/2+32 maximal fires. but that’s obviously wrong.edit: 0x_20_=32
-
A0=10*16=160
And you’re probably right on the initial 32.
-
@adoxa
sorry, for bumping this again… its about the nautical miles hacks. i used 2 decimal digits on the HUD and 3 on the contact list. i also set the “kilometers rather than meters” distance to 0 in the contact list and to 0.5N in the HUD. now, haven’t tested too much and figured out now, that some objects in the contact list still show kilometers. -
@Gisteron: Using BPatch to apply and FL Hack to set the ranges, I don’t experience that. Either you’ve applied it wrong, or I need more information (I don’t see anywhere else it writes it).
Regarding the firing count. It’s a local variable (WORD hpid[32]) so it uses the stack. 8C->CC increases the stack usage (WORD hpid[64]); A0->E0 increases the offset for the argument. These are actually int values, so you can easily add more (2 * number, keep number even). So if you wanted to add another 32: CC00->0C01 & E000->2001. You got lucky with this since it was at the top of the stack; if it was at the bottom, I probably wouldn’t have bothered, since a lot more offsets would have to change (which is also why I restrict the system enumerator (best path finder) to ten rather than increasing it).
-
thank you, adoxa, found the problem: it was the 10k longint limit of D2C32, freelancer.exe (distance over wich fractions of kilometers are not displayed - Dev). i raised the value to 500k (just to ensure it results in the same for larger systems than NY) and all objects in the contact list that could be displayed were shown with nm distances.
-
It should work whatever the value is - I had nm at the default 10k.
-
well, i didn’t use FL Hack to apply anything about this one. only a hex editor. and all changes are exactly the hack you called (with decimals only), the range over which “kilometers” rather than meters are displayed in both HUD and contact list and finally the distance over which fractions of “kilometers” are not shown anymore.
-
guess it fits in here: is there a way to make the engine and trail effects disappear when you kill the engine? and btw where to find LODs of docking and running lights?
-
When it comes to extremely large CMPs (like planetary surfaces), once you face a direction opposite the center of the CMP, the model is no longer rendered and will simply disappear. Usually, this is not a problem - if a regular base is not rendered when you can’t see it anyway; but in case of a planetary surface, it is not like that.
Mostly this issue can be fixed by changing the radius of the CMP, but for some reason this does not work for objects of such massive size.
Is there any way to keep these objects rendered anyway?
-
SURs have a far greater impact on this than any CMP value you can set.
-
If your SUR mesh is the same as the CMP mesh it will not dissappear. Aslong as the SUR is visible in the screen it will render whatever it is attached too.
532/1120