Regarding the SVN problem: My suggestion is to start the SVN server, check each repo out with git SVN brigde (e.g. Tortoisegit has it integrated right into the clone dialog) and then upload it as a git repo. You can have the full history from SVN this way. You just need to do this correctly. I have some SVN repos checked out as git repo just before it got shut down this way. But not all of them.

That worked out. Thanks a lot.

I found a solution to create hitboxes for stuff without having to do it manually, except for small details you can do by hand.

This thing is called convex hull V-HACD, it is a method that scans the 3d object and makes a bunch of convex hulls covering it.

https://github.com/andyp123/blender_vhacd

Here are a example, hope it helps everyone.

ATTENTION: for the script to work, you need to have this addon on your Blender as it uses it https://extensions.blender.org/add-ons/web3d-x3d-vrml2-format/

alt text

alt text

alt text

Here is the vid:
https://www.youtube.com/watch?v=cj3j3bZDjpA

Maybe an issue with the light settings (the system actually is meant to be relative dark). Dunno.

I still have not had much time testing the new version and therefore can not tell if certain stuff/issues from the old version still are valid or not. I wanted to collect and discuss them with you all at once but then RL came between.
I just went through my notes and well, the latest update covered a significant amount of topics I wanted to discuss.
However, a few issues I noticed in the last version were:

Dxt1 1bit alpha textures were not rendering correctly (the alpha channel was interpreted as black) Material type “BtDetailMapMaterial” and its variations were not rendering correctly (mostly observed on station interiors); the tilemaps were missing completely

I don’t know if these issues were known already or are still in the current version of the renderer. Like I mention, I am very short on time lately and could not test it yet.

I have a few additional questions and suggestions in my notes.

the ingame slider for metalness, roughness etc. … I was wondering if there is a way to make a texture completely matte with these sliders (I struggled to find working settings); if not, it’s still ok and probably better using dds textures instead; I was just wondering. In the original description you mentioned to use ATI2 for the normalmaps and certainly everyone working with textures could eventually figure this out by testing, but maybe you can include the info about the channel layout into that description post. There is ATI2 and swizzeled ATI2 where red and green channels are swapped. Depending on what tools and exporters are used this info can be helpful. Is it planned to apply the full feature set of the renderer also to static asteroids? Dynamic asteroids already make use of it but static ones so far do not make use of normalmaps etc.
I believe that this specifically would highly improve how the game looks since asteroid fields and debris fill large parts of the game. Converting the static ones into dynamic ones might be a solution but has disadvantages in other areas. Do you have any information if fog settings in cutscenes or bases are rendered differently now? I noticed that specifically where fog is used in the scripts the lighting looks very different. I at this point would assume that in DX the direction lighting that often is used in the scripts had a very different impact on this setting. The fog now seems to be stronger. I used to have a question about “tone mapping” but since thats the only keyword I wrote down to this topic months ago… dunno… I’ll ask again when I remember the question I had. Last but not least something that might be a bit specific (maybe not). Many mods these days get updated by some kind of autoupdate feature that is either hash based and/or have a version based way to identify if files need to be updated.
If the renderer files are distributed via such an autoupdate the config.cfg file is at risk to be overwritten on the client each time the autoupdate runs (for some mods this means with every launch of the game). That in return means that players can not save any settings because next time the game launches the config file get overwritten.
In my mod I have some features which allow players to store their personal settings in files but also allow me to update such files if really required by using a version index.
e.g.: [VersionHistory] Version=1.1beta1 [Settings] MSAAMode=0 AnisotropicFilteringMode=0 ToneMappingType=0 ShadowNumSplits=4 ShadowmapSize=4096 ShadowCastingLights=2 EnableNewLighting=1 EnableShadows=1 EnableEnvMaps=1 EnablePostProcessing=1 EnableLightScattering=1 EnableParallaxMaps=1 EnableHQDiffuse=1 EnableShadowPCF=1 EnableAsteroidShadows=1 LightScatteringSunLimit=8 EnableClusteredShading=1 MaxNumberOfLightsIndex=1 ReplaceFakeLights=1 EnablePointLights=0 EnableAutomaticExposure=1 AlwaysUseAccurateSRGBConversion=1

So players can store their settings without the config.cfg being overwritten as long as the version of the file on the update server and on the client are identical. If version 1.1beta2 is available then an updated config file (with the addiontal settings) could be downloaded.
This would allow online distribution of updates of the renderer via mods without blocking players from accessing the renderer menu and storing their settings.
I don’t know exactly how other modders distribute their updates when they have an autoupdate. I can only guess there.
The example above is how I can imagine a working solution (since I have multiple similar config files players already can store data to but also can be updated once a new version is available). Important would be that when storing the settings in game the [VersionHistory] remains untouched while only the [Settings] part gets updated.
Does that make sense? Yes, no, maybe?

A final note: I kept the renderer running with the Here is the vid:
https://www.youtube.com/watch?v=cj3j3bZDjpA

Maybe an issue with the light settings (the system actually is meant to be relative dark). Dunno.

I still have not had much time testing the new version and therefore can not tell if certain stuff/issues from the old version still are valid or not. I wanted to collect and discuss them with you all at once but then RL came between.
I just went through my notes and well, the latest update covered a significant amount of topics I wanted to discuss.
However, a few issues I noticed in the last version were:

Dxt1 1bit alpha textures were not rendering correctly (the alpha channel was interpreted as black) Material type “BtDetailMapMaterial” and its variations were not rendering correctly (mostly observed on station interiors); the tilemaps were missing completely

I don’t know if these issues were known already or are still in the current version of the renderer. Like I mentioned, I am very short on time lately and could not test it yet.

I have a few additional questions and suggestions in my notes.

the ingame slider for metalness, roughness etc. … I was wondering if there is a way to make a texture completely matte with these sliders (I struggled to find working settings); if not, it’s still ok and probably better using dds textures instead; I was just wondering. In the original description you mentioned to use ATI2 for the normalmaps and certainly everyone working with textures could eventually figure this out by testing, but maybe you can include the info about the channel layout into that description post. There is ATI2 and swizzeled ATI2 where red and green channels are swapped. Depending on what tools and exporters are used this info can be helpful. Is it planned to apply the full feature set of the renderer also to static asteroids? Dynamic asteroids already make use of it but static ones so far do not make use of normalmaps etc.
I believe that this specifically would highly improve how the game looks since asteroid fields and debris fill large parts of the game. Converting the static ones into dynamic ones might be a solution but has disadvantages in other areas. Do you have any information if fog settings in cutscenes or bases are rendered differently now? I noticed that specifically where fog is used in the scripts the lighting looks very different. I at this point would assume that in DX the direction lighting that often is used in the scripts had a very different impact on this setting. The fog now seems to be stronger. I used to have a question about “tone mapping” but since thats the only keyword I wrote down to this topic months ago… dunno… I’ll ask again when I remember the question I had. Last but not least something that might be a bit specific (maybe not). Many mods these days get updated by some kind of autoupdate feature that is either hash based and/or have a version based way to identify if files need to be updated.
If the renderer files are distributed via such an autoupdate the config.cfg file is at risk to be overwritten on the client each time the autoupdate runs (for some mods this means with every launch of the game). That in return means that players can not save any settings because next time the game launches the config file get overwritten.
In my mod I have some features which allow players to store their personal settings in files but also allow me to update such files if really required by using a version index.
e.g.: [VersionHistory] Version=1.1beta1 [Settings] MSAAMode=0 AnisotropicFilteringMode=0 ToneMappingType=0 ShadowNumSplits=4 ShadowmapSize=4096 ShadowCastingLights=2 EnableNewLighting=1 EnableShadows=1 EnableEnvMaps=1 EnablePostProcessing=1 EnableLightScattering=1 EnableParallaxMaps=1 EnableHQDiffuse=1 EnableShadowPCF=1 EnableAsteroidShadows=1 LightScatteringSunLimit=8 EnableClusteredShading=1 MaxNumberOfLightsIndex=1 ReplaceFakeLights=1 EnablePointLights=0 EnableAutomaticExposure=1 AlwaysUseAccurateSRGBConversion=1

So players can store their settings without the config.cfg being overwritten as long as the version of the file on the update server and on the client are identical. If version 1.1beta2 is available then an updated config file (with the addiontal settings) could be downloaded.
This would allow online distribution of updates of the renderer via mods without blocking players from accessing the renderer menu and storing their settings.
I don’t know exactly how other modders distribute their updates when they have an autoupdate. I can only guess there.
The example above is how I can imagine a working solution (since I have multiple similar config files players already can store data to but also can be updated once a new version is available). Important would be that when storing the settings in game the [VersionHistory] remains untouched while only the [Settings] part gets updated.
Does that make sense? Yes, no, maybe?

On a final note: I kept the renderer running with the large address aware flag, that we discussed earlier and have not had a single crash in the past months nor have I received any reports of any issues from other players. That one crash issue, I reported earlier certainly was related to that. The issue can be considered resolved and maybe it might be worth adding info to the initial instruction post how to apply LLA. It might prevent some headaches if somebody else runs into such an issue.

I encountered this same issue as the other thread with the same name and resolved to try to figure out the cause.

Original Thread (2016):
https://the-starport.com/forums/topic/5790/lag-spikes-server-and-client-on-same-machine

Similar Thread (2010):
https://the-starport.com/forums/topic/2600/odd-lag-running-fl-and-server-on-same-machine

To bring others up to speed (again), the issue only occurs when running Freelancer on the same machine that you’re running FLServer. There are frequent stutters that result in the imagine freezing and the mouse unable to move. This is very disruptive, particularly in combat. It does not affect clients connecting to FLServer from a different machine.

The only thing I could come up with is that 0 Ping causes problems with sync. FLServer is not fast enough for 0 ping and the client will pause waiting for data from the server; particularly NPC spawns. I guessed this might be the problem based on my very crude knowledge of MP programming in Unity. MP coding, due to latency, is like trying to predict the future and to rubber band everyone back in place.

The fix? Introduce lag/latency.

There is a utility used to introduce artificial lag to Localhost (ie. 127.0.0.1 loopback) called Clumsy. Running it with a Lag of 125ms causes a return time of ~500ms according to the server selector. This in turn creates a buffer for FLServer to get “ahead” of the client.

While this did not eliminate all pauses, it did eliminate the majority of them. From multiple times a minute, sometimes back-to-back, to only an occasional one every ~5 minutes for me.

I hope that someone else can test this and see if it also works for them. There may also be better utilities to accomplish this. I don’t know what effect this will have on other clients, but if you’re playing alone on a server you’re running at least it will minimize the freezing.