MPR++ v0.2.6c open for alpha testing

MPR++; support/discussion/questions

Moderator: thunderchero

User avatar
Spocks-cuddly-tribble
Code Master
Code Master
Posts: 1870
Joined: Sun Apr 27, 2008 2:00 am

Re: MPR++ v0.2.6c open for alpha testing

Post by Spocks-cuddly-tribble »

Hi Flocke,

just out of curiosity some questions about MPR++ and whether it can address (by its design and implementation) below issues:

1.) In old days, phaser animations in huge battles caused a tacial combat initial turn lag. Can MPR++ remdering improve this (i.e. is it way to go for death-match multiplayer and massive-fleets mods)?

2.) Can it render/fix the pulse weapon animations (aka plasma) or is this issued by trek.exe? Unlike torpedos, the pulse projectiles are not represented as own objects with position data but just with a certain animation time run along the phaser vector. Problems are:

- animation vector doesn't match the trajectory (i.e. nose not fixed forwards)
- the size scale is inproper handled and mistakenly coupled to other objects (clicked-on ships iirc)
- missing shots cause projectiles to keep bouncing around the target (animation should be terminated or trajectory maintained)

3.) Enables it rendering of torpedo launcher hardpoints (with firing animations)? Since MPR++ keeps the original hob-files for all battle calculations, and torpedos are set as objects by trek.exe, the answer should be no.


Btw when seeing your name I sometimes picture that cuddly ice bear typing your posts. But then again, if you were that ice bear, escaped from the zoo by pretending to have died, why would you risk still using your old name? Unless of course you want the swat teams to trace your IP, so that you can ambush and eat them, when they are trying to capture you. :wink:
I don't know how many bugs is too many but that point is reached somewhere before however many in BotF is.
User avatar
Flocke
BORG Trouble Maker
BORG Trouble Maker
Posts: 3179
Joined: Sun Apr 27, 2008 2:00 am
Location: Hamburg, Germany
Contact:

Re: MPR++ v0.2.6c open for alpha testing

Post by Flocke »

Hi SCT,

putting aside the known issues and outdated libraries, it's all about time to invest.

Some changes however might break MP or imply to implement some alternate network communication.
And other changes require additional research given mpr++ for now doesn't have access to the actual combat data but just the hob positioning (although I did some research in that regard). That's also responsible to why in some cases it doesn't render phasers fired from behind cause it is clipped by the BotF rendering.

But let me get a bit deeper to answer your questions.

Spocks-cuddly-tribble wrote: Tue Apr 14, 2020 11:27 am 1.) In old days, phaser animations in huge battles caused a tacial combat initial turn lag. Can MPR++ remdering improve this (i.e. is it way to go for death-match multiplayer and massive-fleets mods)?
The current implementation no. I'm not sure what calculation is done but I guess there is code to select targets, calculate whether a target is hit and what damage is caused and I'm not surprised when it is done for each phaser fired by single. Even for vanilla BotF the lag likely is not related to the rendering itself. If at all it is physics calculation. All of that is likely done ahead and mpr++ doesn't hook any of this.
It's a simple matter of more phasers mean more combat calculation.

In mpr++ however is an experimental mode implemented that bypasses the whole combat code and would allow to implement something own when the participating ships is known and it is found how to apply the combat outcome.
For mp games as a simple rule however any user interaction somehow needs to be transmitted to the clients. So either the current code needs to be hooked and matched, which for sure will be limiting and require alot of asm analysis, or some own network communication needs to be implemented, that could be limited to synchronize combat while the rest still is done by BotF.

Spocks-cuddly-tribble wrote: Tue Apr 14, 2020 11:27 am 2.) Can it render/fix the pulse weapon animations (aka plasma) or is this issued by trek.exe? Unlike torpedos, the pulse projectiles are not represented as own objects with position data but just with a certain animation time run along the phaser vector. Problems are:

- animation vector doesn't match the trajectory (i.e. nose not fixed forwards)
- the size scale is inproper handled and mistakenly coupled to other objects (clicked-on ships iirc)
- missing shots cause projectiles to keep bouncing around the target (animation should be terminated or trajectory maintained)
For the current phaser hob rendered, the animation vector can be fixed easily. In fact mpr++ already uses phaser animations that align to the fire direction. Also the scale is not an issue. mpr++ only uses starting and end positions for the phaser fire. All the rest is defined by the hob replacements.
And of course the animation can be stopped once it fully passed. However, when a ship moves while firing, the rendered phaser hob moves as well and here it gets tricky.

Currently mpr++ renders replacements for each hob BotF issues to render so 1to1. Due to the render clipping of BotF mpr++ however only knows start and target position of phasers in view and it can't identify some unique shot when it gets back into view. Therefore without further research it could look pretty awkward when the beginning of a detected phaser shot is used to issue some own pulse weapon rendering, just because it comes into view.

Say a phaser comes into view in the last few frames of the combat turn. Mpr++ doesn't know it already has been fired seconds before. So shall it issue a plasma weapon fire and what to do when the next turn begins? The damage is already applied, the target possibly destroyed, but plasma rendering is just about to start?

Therefore it should better be based on the actual shot fired and not on the hob placement.

Last time I debugged the asm combat code I managed to track some of the ship stats but couldn't match individual ships to the hobs being rendered.
Would make much more sense to bypass the hob rendering completely but hook the ship placement and phaser fire somewhere deeper in the asm code so it is not getting clipped and there is access to more combat data.

Spocks-cuddly-tribble wrote: Tue Apr 14, 2020 11:27 am 3.) Enables it rendering of torpedo launcher hardpoints (with firing animations)? Since MPR++ keeps the original hob-files for all battle calculations, and torpedos are set as objects by trek.exe, the answer should be no.
When instead of the hob placement we'd detect when a torpedo is actually fired, what target it has and from what ship it is fired, we could easily define hardpoints for the ship replacements and pick one for proper rendering like you say.

As of now mpr++ doesn't know whether a torpedo hob near some ship is being fired by the ship or whether that ship is going to be hit by the torpedo. Nor does it know in what direction the torpedo hob is going to move.

Unlike the plasma weapons however we can do far better guessing here. For one we can guess a torpedo that's not yet tracked by position is fired when a ship near-by is of same race. Obviously this might fail in some rare cases but it's not likely to be visible, specially when waiting a few frames to start the movement projection. Second BotF has far less clipping issues with the tiny torpedos than with the long phaser hobs when fired from behind. Once it gets into view and if not fired by a ship, the rendering can simply proceed 1to1.

So unlike the other two tasks this by far is the easiest to realize in current state of mpr++.


Hope I could lay out the current works of mpr++ a bit better now. :)


The cuddly icebear 'Flocke' from Nürnberg btw is still alive but living in france by now.
My nick however I already used prior to when the ice bear was born, see https://web.archive.org/web/20071031171 ... ofile=9566 ;)
User avatar
thunderchero
Site Administrator aka Fleet Admiral
Site  Administrator aka Fleet Admiral
Posts: 7824
Joined: Fri Apr 25, 2008 2:00 am
Location: On a three month training mission, in command of the USS Valiant.

Re: MPR++ v0.2.6c open for alpha testing

Post by thunderchero »

On a side note, torpedoes do not use hardpoints, they fire from center of model.

it is tough to do but have paused replay of romulan warbird just as a torpedo fired when it appeared out if thin air :grin:

vanilla plasma fire from the same point.
User avatar
wpaul1991
Cadet 1st Year
Cadet 1st Year
Posts: 1
Joined: Sat Apr 18, 2020 7:39 pm

Re: MPR++ v0.2.6c open for alpha testing

Post by wpaul1991 »

can i please get the link for mpr++ & the download file for BOFT that works with 1366x768?
User avatar
Flocke
BORG Trouble Maker
BORG Trouble Maker
Posts: 3179
Joined: Sun Apr 27, 2008 2:00 am
Location: Hamburg, Germany
Contact:

Re: MPR++ v0.2.6c open for alpha testing

Post by Flocke »

wpaul1991 wrote: Sat Apr 18, 2020 7:41 pm can i please get the link for mpr++ & the download file for BOFT that works with 1366x768?
sent you the link but you probably better go with dxwnd here
mpr++ has some render issues with 1366x768.
User avatar
Mr_Sloan
Ensign
Ensign
Posts: 48
Joined: Sun Mar 29, 2020 11:43 am

Re: MPR++ v0.2.6c open for alpha testing

Post by Mr_Sloan »

i used 800x600 & mpr++ & making it full screen on a 1080p display. Works well that way.
User avatar
Spocks-cuddly-tribble
Code Master
Code Master
Posts: 1870
Joined: Sun Apr 27, 2008 2:00 am

Re: MPR++ v0.2.6c open for alpha testing

Post by Spocks-cuddly-tribble »

Thanks for your elaborations, Flocke (and sorry that I confused you with Knut, maybe due to Flocke beeing a girl :wink: ). Very interesting.:up:

Looking forward to rear torpedo launchers (just kidding). IIRC the phaser/plasma fire angle can be influenced to fire backwards via the unknown phaser values of the ship's trek.exe slots, regardless of the slot's direction in the model.

Flocke wrote: Thu Apr 16, 2020 12:17 pmthe target possibly destroyed, but plasma rendering is just about to start?
Lol, that reminds me of a native BotF bug, where an already destroyed ship sometimes kills its opponent with its phasers (not torpedoes).


thunderchero wrote: Thu Apr 16, 2020 1:03 pmtorpedoes do not use hardpoints, they fire from center of model.

it is tough to do but have paused replay of romulan warbird just as a torpedo fired when it appeared out if thin air :grin:

vanilla plasma fire from the same point.
Of course, since BotF doesn't have torpedo launcher to use it must trick it that way. As you said possible reason for un-centered ships wrt to model radius and shield glitch(great testing/research btw :up: ): viewtopic.php?f=4&t=3469#p46374

But are you sure about the plasma hobs :?: IIRC in all my test they used same phaser hardpoints (given the plasma switch marker in trek.exe slot is set and all res files are there to avoid crashes). Easy to observe with a BoP.
Last edited by Spocks-cuddly-tribble on Sun Apr 19, 2020 8:50 pm, edited 1 time in total.
I don't know how many bugs is too many but that point is reached somewhere before however many in BotF is.
User avatar
thunderchero
Site Administrator aka Fleet Admiral
Site  Administrator aka Fleet Admiral
Posts: 7824
Joined: Fri Apr 25, 2008 2:00 am
Location: On a three month training mission, in command of the USS Valiant.

Re: MPR++ v0.2.6c open for alpha testing

Post by thunderchero »

Spocks-cuddly-tribble wrote: Sun Apr 19, 2020 9:25 am But are you sure about the plasma hobs :?: IIRC in all my test they used same phaser hardpoints (given the plasma switch marker in trek.exe slot is set and all res files are there to avoid crashes). Easy to observe with a BoP.
my memory is not what it used to be....

I even stated this 12 years ago lol
viewtopic.php?f=275&t=500&p=6969#p6969
User avatar
RSE_Dissy
2020-Vanilla
2020-Vanilla
Posts: 372
Joined: Sat Apr 26, 2008 2:00 am
Location: Yorkshire

Re: MPR++ v0.2.6c open for alpha testing

Post by RSE_Dissy »

Hey flocke,

How's it going? Hope all is good,

Can you throw me a download link for mpr++ please?
Just rediscovered the joy that is botf and wanna play some multiplayer again, I'm told this fix is the bomb
Hit me up 👍
Dissy of Red Squad Elite;

The Elite Gaming Clan of the MSN Gaming Zone

Peace, Love & Unity
User avatar
Flocke
BORG Trouble Maker
BORG Trouble Maker
Posts: 3179
Joined: Sun Apr 27, 2008 2:00 am
Location: Hamburg, Germany
Contact:

Re: MPR++ v0.2.6c open for alpha testing

Post by Flocke »

Hey Dissy!

Ha, well, it is mind blowing when you start it the first time indeed. But I didn't find time to investigate some serious issues that come with it.
So for MP you likely better play without or at least disable autosave and make sure all have mpr++ installed for the battles to work.

cheers and some good hunting ;)
User avatar
Mr_Sloan
Ensign
Ensign
Posts: 48
Joined: Sun Mar 29, 2020 11:43 am

Re: MPR++ v0.2.6c open for alpha testing

Post by Mr_Sloan »

is it possible to leave autosave and only deactivated it when there are problems? in the first 200 turns i had none so far (except no minor weapons, but they still do their damge)
Last edited by Mr_Sloan on Wed Jun 21, 2023 5:35 pm, edited 1 time in total.
User avatar
Flocke
BORG Trouble Maker
BORG Trouble Maker
Posts: 3179
Joined: Sun Apr 27, 2008 2:00 am
Location: Hamburg, Germany
Contact:

Re: MPR++ v0.2.6c open for alpha testing

Post by Flocke »

Mr_Sloan wrote: Wed Apr 29, 2020 3:41 pm is it possible to leave autosave and only deactivated it when there are problems? in the first 200 turns i had none so far (except no minor weapons, but they still do their damge)
sure plus in the GameSettings.ini you can disable the AUTOSAVE extension to revert to the native botf autosave
as far I know the autosave extension I wrote causes the end game video to crash, but in general mp games can become out of sync when the game is saved in the wrong moment, e.g. when a client saves just before last player ends the turn, therefore try disable it if you encounter more issues than usual ;)
User avatar
neytiri455
Cadet 1st Year
Cadet 1st Year
Posts: 3
Joined: Sun Jun 12, 2011 2:00 am

Re: MPR++ v0.2.6c open for alpha testing

Post by neytiri455 »

Hello Flocke,

i was informed to post here to get the MPR++ for the game? Im kindly request the things in need to have to get Botf running. :)

Regards,
neytiri455
User avatar
Flocke
BORG Trouble Maker
BORG Trouble Maker
Posts: 3179
Joined: Sun Apr 27, 2008 2:00 am
Location: Hamburg, Germany
Contact:

Re: MPR++ v0.2.6c open for alpha testing

Post by Flocke »

Hi neytiri455, you absolutely don't need mpr++ to get botf running, but sent you the link anyhow ;)
User avatar
neytiri455
Cadet 1st Year
Cadet 1st Year
Posts: 3
Joined: Sun Jun 12, 2011 2:00 am

Re: MPR++ v0.2.6c open for alpha testing

Post by neytiri455 »

Flocke wrote: Sat May 02, 2020 11:12 am Hi neytiri455, you absolutely don't need mpr++ to get botf running, but sent you the link anyhow ;)
Yeah, i forgot to mention the MP. Thanks for your fast respond

Cheers :)
Post Reply

Return to “MPR++”