Freelancer Community Network
Reminder: Internet Explorer 6 or below are NOT supported.
HomeHome
ForumForum
WikiWiki
DownloadsDownloads
ForgeForge
Multiplayer Connection Tutorial
Collapse/Expand Random Image
Collapse/Expand Login
Username:

Password:

Remember me



Lost Password?

Register now!
Collapse/Expand Chat
Collapse/Expand Who's Online
35 user(s) are online (19 user(s) are browsing Forum)

Members: 0
Guests: 35

more...
Collapse/Expand Donations
Monthly costs: -30€
Income (ads): +5€
Donations (last month): +0€

Current balance: -125€
(last updated 10/2018)

Please make a donation if you want to help keeping The-Starport online:

Bitcoin address:
Thanks!
Collapse/Expand Links
Collapse/Expand Advertisement
There are currently 79 users playing Freelancer on 32 servers.
October. 19, 2018

Browsing this Thread:   2 Anonymous Users



 Bottom   Previous Topic   Next Topic  Register To Post

« 1 ... 64 65 66 (67)


Re: Dev's Limit Breaking 101 Techniques
Home away from home
Joined:
2010/2/22 0:47
Group:
Registered Users
$$$ Supporters $$$
Senior Members
Posts: 861
Offline
Quote:

Gold_Sear wrote:

[...]a veritcally oriented trade lane (so it also travels vertically) and setting proper rotate settings for the rings [...] The following patch fixes it.


Nice one!!

Making vertical (or at least, 'climbing', under a 45° angle) tradelanes was one of the first things I tried in modding. But I essentially only had (and still have) insight to the extent of what I could see in the .ini files so I couldn't fix it. They worked btw, but traveling downwards the ship was weirdly positioned (nose up, its bottom pointing to the traveling direction).

Posted on: 2017/10/8 16:26
Top
Re: Dev's Limit Breaking 101 Techniques
Home away from home
Joined:
2009/8/16 2:58
From Qld, Aus.
Group:
Registered Users
FLServer Admins
Trusted Speciality Developers
Senior Members
Posts: 1847
Offline
Quote:
Gold_Sear wrote:
So I was playing with big planets and large systems, and, to my unpleasant surprise, I stumbled onto another draw limit for planets.


See if this does the trick: rendcomp.dll 014053 1000000f.

Posted on: 2017/10/10 9:09
Top
Re: Dev's Limit Breaking 101 Techniques
Not too shy to talk
Joined:
2015/1/18 12:56
From The Hague, EU
Group:
Registered Users
Posts: 87
Offline
@adoxa:
I think so:
changed value to 2 million -> draw limit increased to ~2800K
changed value to 1e38 -> Manhattan (and Pittsburgh) remains visible

Thanks!

Posted on: 2017/10/13 18:07
There is always something to do.
Top
Re: Dev's Limit Breaking 101 Techniques
Quite a regular
Joined:
2010/11/8 16:38
Group:
Registered Users
Senior Members
Posts: 125
Offline
Quote:
content.dll 04B101 adoxa don't append dash to msg_id_prefix in mbases.ini PART


Are there similar hacks for msg_id_prefix in universe.ini (don't append dash) and gcs_refer_faction in faction_prop (don't append _short)?

Posted on: 12/16 12:26

Edited by Xalrok on 2017/12/16 15:30:18
Top
Re: Dev's Limit Breaking 101 Techniques
Home away from home
Joined:
2009/8/16 2:58
From Qld, Aus.
Group:
Registered Users
FLServer Admins
Trusted Speciality Developers
Senior Members
Posts: 1847
Offline
Quote:
Are there similar hacks for msg_id_prefix in universe.ini (don't append dash)

At the following locations in content.dll, replace 64 with 65: 037148, 039684, 039AA3, 039CE1, 03AA92, 03AE02, 03BA22, 03F0A6, 03BA220, 03F0A6, 041A74, 041C75. This effects the same items as the previous patch (which would jump over the append code; this makes it append an empty string). I don't know what effect it would have elsewhere (meaning if you explicitly add the dash to universe.ini, there are occasions where you'll end up with two dashes).

Quote:
gcs_refer_faction in faction_prop (don't append _short)?

Didn't look into this, but at 116324 in content.dll is the string for _short, so change that to 00 and see what happens...

Posted on: 12/17 5:36
Top
Re: Dev's Limit Breaking 101 Techniques
Quite a regular
Joined:
2010/11/8 16:38
Group:
Registered Users
Senior Members
Posts: 125
Offline
Thanks Adoxa! Both of those worked. The only issue I encountered with the faction_prop hack is that bases and NPCs stop referring to the player as "Freelancer."

Posted on: 12/22 9:38
Top
Re: Dev's Limit Breaking 101 Techniques
Home away from home
Joined:
2009/8/16 2:58
From Qld, Aus.
Group:
Registered Users
FLServer Admins
Trusted Speciality Developers
Senior Members
Posts: 1847
Offline
Right, I should have thought of that. Okay, at 036F5F, 0385B1, 03948E, 03A123, 03A42B, 03D8DF, 03E547, 03EB48, 03EC5C, 0401C8, 040C3B, 04172C, 045DB0 and 045EC4 replace 2C with 28; then at 116328, write in gcs_refer_faction_player_short.

Posted on: 12/22 23:32
Top
Re: Dev's Limit Breaking 101 Techniques
Not too shy to talk
Joined:
2015/1/18 12:56
From The Hague, EU
Group:
Registered Users
Posts: 87
Offline
I should mention another two findings by adoxa:

1:
Quote:

adoxa wrote:
Ah, I should have done another search with underscores. You'll find the defaults as two ints at 18C754 in common.dll. The function is only used by Act_PlayerEnemyClamp.


Alternative:
Code:
common.dll 08E86A 7E31->EB39 = disable PlayerEnemyClamp, instead making NPC target selection random ~adoxa

I don't recall if it completely deactivates the scripted Act_PlayerEnemyClamp function, but it has the desired effect when not in a mission.

2: Making npcs global, not local to base, found by adoxa; makes a visited NPC at a bar also visited at other bases. Indexed (to Misc section).

3:: Removes exclusion zone clipping, prevents far clipping of exclusion zones.

I should also warn that adoxa's solution to the 130k asteroid rendering limit has serious side effects: change of 7 to A results in the asteroids mostly not being rendered and even if so, then spawned in a regular pattern instead of pseudorandomly. I'd suggest we'd have another, closer look there.

EDIT: this last statement is not true I used hispania_debris_field to test, but apparently that one isn't representative. My mistake....

EDIT2: looking more closely, it is still partially true, using F instead of A; now the asteroids do get spawned, but in a very regular pattern. Conclusion: careful raising these two bytes

Posted on: 1/20 14:54

Edited by Gold_Sear on 2018/1/20 15:07:26
Edited by Gold_Sear on 2018/1/20 18:05:22
Edited by Gold_Sear on 2018/1/20 18:11:43
Edited by Gold_Sear on 2018/1/20 18:14:56
Edited by Gold_Sear on 2018/1/20 21:48:30
Edited by Gold_Sear on 2018/1/20 21:49:08
There is always something to do.
Top
Re: Dev's Limit Breaking 101 Techniques
Not too shy to talk
Joined:
2015/1/18 12:56
From The Hague, EU
Group:
Registered Users
Posts: 87
Offline
Quote:

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)


@w0dk4: did you apply this patch?
Code:
common.dll 460B6 77 3B -> 90 90 = always render static asteroids PART 1
common.dll 460BE 77 33 -> 90 90 = always render static asteroids PART 2
common.dll 460C5 77 2C -> 90 90 = always render static asteroids PART 3

Or something similar? I'm asking because adoxa's patch on this subject has side-effects (see above post).

Posted on: 1/25 12:52
There is always something to do.
Top
Re: Dev's Limit Breaking 101 Techniques
Quite a regular
Joined:
2010/11/8 16:38
Group:
Registered Users
Senior Members
Posts: 125
Offline
Hello, I have another hack request. Is it possible to have the cargo scan window open on Internal Equipment instead of Commodities by default?

Posted on: 4/28 14:38
Top
Re: Dev's Limit Breaking 101 Techniques
Just can't stay away
Joined:
2012/5/22 20:21
Group:
Registered Users
Posts: 182
Offline
Quote:

Gold_Sear wrote:
Quote:

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)


@w0dk4: did you apply this patch?
Code:
common.dll 460B6 77 3B -> 90 90 = always render static asteroids PART 1
common.dll 460BE 77 33 -> 90 90 = always render static asteroids PART 2
common.dll 460C5 77 2C -> 90 90 = always render static asteroids PART 3

Or something similar? I'm asking because adoxa's patch on this subject has side-effects (see above post).


I just applied the above patch to my mod as i was having issues with asteroids not rendering after a certain distance. This has cured it with no side effects i can see, which isn't saying much to be fair. That said, the rocks render now and stop when they should do at the edge of the field. Nice find.

Posted on: 4/29 9:01
Top
Re: Dev's Limit Breaking 101 Techniques
Not too shy to talk
Joined:
2015/1/18 12:56
From The Hague, EU
Group:
Registered Users
Posts: 87
Offline
Indexed this; an improved version of removing non-targeted brackets.

Posted on: 7/23 18:08
There is always something to do.
Top
« 1 ... 64 65 66 (67)