Dev's Limit Breaking 101 Techniques

Is there any way to prevent scanners from being transferable? So that you could have scanners being visible but not buy/transfer them from one ship to another?

Aigle-Imperial wrote:
Is there any way to prevent scanners from being transferable? So that you could have scanners being visible but not buy/transfer them from one ship to another?

Sorry - not smart to give you an answer and again sorry for hijack it!
1. But similar, I made new scanner which only one ship has it (nomad fighter) and is available trough /restart command. Also it suppose to be used for rep-fixer which through playercontrol plugin I can set it as item that cant be lost/seen.
This doesn’t work! Any hint why?

2. While I’m at this thread please give me next info.

adoxa wrote:

freelancer.exe    0A8004    05->1A = show current worth in multiplayer ~adoxa

What this suppose to show me? What worth? Where?
In contact list? Cash amount?

I did make a change to file but is it correct way?

2. While I’m at this thread please give me next info.

adoxa wrote:

freelancer.exe    0A8004    05->1A = show current worth in multiplayer ~adoxa

What this suppose to show me? What worth? Where?
In contact list? Cash amount?

A picture (or two) is worth a thousand words.

http://underverse.us/viewtopic.php?f=2&t=2523

@Aigle: A little tricky. Simple enough to test scanner instead of engine.

freelancer.exe	0808AC	0C->14 = prevent transfer of scanner (but allows engine) ~adoxa
freelancer.exe	080941	0C->14 = prevent selling of scanner (but allows engine) ~adoxa

```EngClass bypasses this test altogether, though.

@sumanuti: It shows your current worth in the reputation window, like in single player. That is the correct way.

@DwnUnder: Not very helpful when you have to register first.

Thanks

Adoxa, did you /could you make a bypass for the tractor swap when exchanging ships at a shipdealer?

It’s annoying to have to put back your own scanner and tractor when they are swapped, and its easy to forget and lose a higer class scanner or tractor in the process.

This prevents everything (engines/scanners/tractors/powerplants) from being transferred. Untested.

freelancer.exe	07B020	83F8->EB22 = prevent transfer of equipment ~adoxa

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?

MultiCruise is M0tah’s. I have “restrict ships with can_use_moors from using trade lanes” (from here) on my todo. I don’t have a clear idea how, so it can wait.

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+40

with 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).