adoxa wrote:
In single player, this hack will generate additional damage. For example, I changed the Javelin to do 10 damage and Flint to a Rheinland battleship (rm_r_battleship). Firing a missile into the center hits two groups (Rh_main_lod1/DpMain & Rh_midfrnt_lod1/DpMidFrnt) for 20 damage. Applying the patch then does 30 damage - the two groups plus presumably the ship as a whole.

The damage is actually found a little further down, in the function at 0x(6ce)9690. In SP, GetRadius returns a valid value, but in MP it is returning 0. I think the real problem is with something used by GetBoundingSphere. That’s as far as I went, back to you, M0tah…

Did some more testing, and I couldn’t get CArchGroup::GetRadius to be called at all, in either MP or SP (though 0x9690 is). You are referring to that call in 0x9690, correct?

Huh, I’ve actually never experienced this problem. Maybe it’s due to certain firewall or antivirus software?

Well, for me I think it’s three primary reasons:

[olist]* I’ve learned a lot from working on the various FL-related projects I’ve contributed to, and continue to do so. Working on these projects helps me to become a better programmer and modder, which allows me to accomplish some pretty neat stuff.

• I like helping out other people. Most of my software is open-source in the hope that others will learn from and extend it. I also learn a lot by looking at the code others write.
• I like to stretch the boundaries of what’s possible, and create something new. FL is one of my favorite games, so it was natural to experiment with it.[/olist]

Decided to investigate the issue; here’s what I found.

0x0C->0x00 in server.dll, 0x960C = fixes explosion damage at full strength
```This should fix the issue (it has in my testing so far).

Explanation
FL hardcodes three different multipliers of damage for explosions - 1, 2/3, 1/3, and 0, depending on how far away from the center of the object the explosion is. As far as I can tell, this is computed using the following mapping:
Distance^2 -> Strength
<= (Explosion radius)^2 * 0.1111… -> 1
<= (Explosion radius)^2 * 0.4444... -> 2/3
<= (Explosion radius)^2 -> 1/3
> (Explosion radius)^2 -> 0
So when the hit is farther than the explosion's radius away from the root of the ship, no damage is dealt. The above hack fixes the multiplier at 1 regardless of the distance.

It would be lovely if hexadecimal numbers could be entered into the IDS field of the DLL Editor.

Sounds like there’s something wrong with your paths then - make sure the path to the libs relative to the project files is correct. For example, if the Code::Blocks project is in src instead of a subdirectory you’ll need to adjust the paths to be ./source/libs/ *.lib (remove the leading .).

Yeah, I remember that there was some weirdness with it - I believe that someone actually needed to visit the base for it to work, or something like that.

Universe::IBase *base = Universe::get_base(iBaseID);
base->lSpaceObjID;
```And no problem. :)

Have you taken a look at the code in BaseDestroyed()?

//...
	uint iID;
	pub::SpaceObj::GetDockingTarget(iObject, iID);
	Universe::IBase *base = Universe::get_base(iID);

```pub::SpaceObj::GetDockingTarget is what you're after.

http://www.thefreecountry.com/ is also a good site to find freeware and open source programs.

Moonhead wrote:
Aren’t there any skilled app builders to update FLEd-Ids? Or is that against some code of honour without asking Dixi first?

As far as I know FLEd-Ids’s source was never released.

If your cpu is a 64-bit one then you will need XP-64.

Not at all, regular XP will work fine on a 64 bit CPU. You’ll just be limited to 3 GB or so of RAM.

Huh, I used the SDK files straight from my XP partition, I’ll have to test actually installing it. Also, the PSDK-amd64.exe is just the 64 bit version of the SDK as far as I know; the amd is there just because the first 64 bit x86 processors were made by AMD.

Nobody’s actually written a new renderer back-end as far as I know, but quite a few mods use a DX8 hook that adds bloom. See here, for example.

[EDIT]
There is a much simpler way to accomplish this (with items in bases) without waypoints. I am currently investigating the plausibility of this.

Yeah, you could definitely implement it using items and docking restrictions so they would need the item to dock at the base.

As for dynamically creating the waypoints, I haven’t experimented with it at all but I’d guess it would be possible to do (just not sure how exactly).

Have you tried updating your video drivers? From your description of the problem it sounds like it could be driver related.

Apologies for the late response, but I just tested my old setup (VC 2003 Toolkit + Windows 2003 Platform SDK + Code::Blocks) on Windows 7 and it works fine after a few configuration tweaks.

How-to:
1. Download and install the Visual C++ Toolkit 2003.
2. Download and install the Windows Server 2003 Platform SDK.
2. Download and install Code::Blocks. Code::Blocks should automatically detect the toolkit compiler.
3. Import the Visual Studio solution file. This can be done by opening File|Import project|MS Visual Studio solution and selecting the file in the project-vc7 directory.
4. Try compiling FLHook. This didn’t work for me the first time, as the search directories for the compiler weren’t set up properly (it couldn’t find windows.h). If this is the case, add the Windows Server 2003 Platform SDK include and lib directories to the Compiler and Linker search directories respectively. This can be done in the Settings|Compiler and debugger dialog.
I next had linker issues, which were related to not having the correct libraries specified in the linker settings. Right-click on the FLHook project and select Build options. Switch to the Linker settings tab. In the Link libraries list you should see some …/source/libs/ entries. Add a .lib to the end of those entries. Finally, add shell32 and user32 to the list. When you’re done it should look like this.
5. Compile FLHook. It should all work now, though there will probably be some warnings. I was able to get rid of the linker warnings by removing /debug from the Other linker options. It also didn’t specify any compiler optimization for the release build - you’ll probably want Maximize speed (/O2) on.

Thanks, I’ve added all of the old files back.

I’m having some trouble accessing my newly-created account. After activating it, I wasn’t able to login (it just said “Invalid user or password” ). I then used the “Lost password” function. After re-entering my password it said “Lastname is invalid”. It seems to have choked on the ↑ character I entered for my last name, and I can’t actually login to fix it. Username is M0tah.

As for new project requests, here’s the list (all of the ones from the old Forge):

Project name : DelayDisplay
Project nickname : DelayDisplay
Description : Adds cooldown timer display in the weapons HUD - weapons with a 1 second or higher refire delay will have the time remaining printed next to the ammunition (or in its place if the weapon does not use ammunition).

Project name : MultiIntro
Project nickname : MultiIntro
Description : Allows more than three intro screens to be displayed. It will also pick one at random when returning to the intro screen instead of sticking to the one chosen at startup.

Project name : MultiCruise
Project nickname : MultiCruise
Description : Allows engines to have cruise speeds that are different than the CRUISING_SPEED constant via a cruise_speed entry in [Engine] blocks.

I’d also appreciate being added to the FLHook Plugin project so I can re-add my plugins.

Thanks.

StarTrader wrote:
Or maybe someone can de-engineer Ioncross for me to get rid of the 24 weapon check?

Looks like there’s three offsets you’ll need to change: 0x7d026, 0x7d417, and 0x7d7da. All three are the number of weapons it checks for (normally 25, since it’s checking if it’s greater than or equal to it). Since they’re bytes you can probably go up to a max of 127. Or you can change the bytes at 0x7d028, 0x7d419, and 0x7d7dc to 0x00 to bypass the check.
All of these are in FLServerOperator.exe, mk.V.1.