MPR++ v0.2.6c open for alpha testing
Moderator: thunderchero
- Spocks-cuddly-tribble
- Code Master
- Posts: 1883
- Joined: Sun Apr 27, 2008 2:00 am
Re: MPR++ v0.2.6c open for alpha testing
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.
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.
I don't know how many bugs is too many but that point is reached somewhere before however many in BotF is.
- Flocke
- BORG Trouble Maker
- Posts: 3196
- Joined: Sun Apr 27, 2008 2:00 am
- Location: Hamburg, Germany
- Contact:
Re: MPR++ v0.2.6c open for alpha testing
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.
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.
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.
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
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.
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.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)?
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.
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.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)
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.
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.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.
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
- thunderchero
- Site Administrator aka Fleet Admiral
- Posts: 7848
- 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
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
vanilla plasma fire from the same point.
it is tough to do but have paused replay of romulan warbird just as a torpedo fired when it appeared out if thin air
vanilla plasma fire from the same point.
Re: MPR++ v0.2.6c open for alpha testing
can i please get the link for mpr++ & the download file for BOFT that works with 1366x768?
- Flocke
- BORG Trouble Maker
- Posts: 3196
- Joined: Sun Apr 27, 2008 2:00 am
- Location: Hamburg, Germany
- Contact:
Re: MPR++ v0.2.6c open for alpha testing
sent you the link but you probably better go with dxwnd here
mpr++ has some render issues with 1366x768.
Re: MPR++ v0.2.6c open for alpha testing
i used 800x600 & mpr++ & making it full screen on a 1080p display. Works well that way.
- Spocks-cuddly-tribble
- Code Master
- Posts: 1883
- Joined: Sun Apr 27, 2008 2:00 am
Re: MPR++ v0.2.6c open for alpha testing
Thanks for your elaborations, Flocke (and sorry that I confused you with Knut, maybe due to Flocke beeing a girl ). Very interesting.
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.
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.
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.
Lol, that reminds me of a native BotF bug, where an already destroyed ship sometimes kills its opponent with its phasers (not torpedoes).
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 ): viewtopic.php?f=4&t=3469#p46374thunderchero 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
vanilla plasma fire from the same point.
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.
- thunderchero
- Site Administrator aka Fleet Admiral
- Posts: 7848
- 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
my memory is not what it used to be....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.
I even stated this 12 years ago lol
viewtopic.php?f=275&t=500&p=6969#p6969
Re: MPR++ v0.2.6c open for alpha testing
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
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
The Elite Gaming Clan of the MSN Gaming Zone
Peace, Love & Unity
- Flocke
- BORG Trouble Maker
- Posts: 3196
- Joined: Sun Apr 27, 2008 2:00 am
- Location: Hamburg, Germany
- Contact:
Re: MPR++ v0.2.6c open for alpha testing
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
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
Re: MPR++ v0.2.6c open for alpha testing
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.
- Flocke
- BORG Trouble Maker
- Posts: 3196
- Joined: Sun Apr 27, 2008 2:00 am
- Location: Hamburg, Germany
- Contact:
Re: MPR++ v0.2.6c open for alpha testing
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
- neytiri455
- Cadet 1st Year
- Posts: 3
- Joined: Sun Jun 12, 2011 2:00 am
Re: MPR++ v0.2.6c open for alpha testing
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
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
- Flocke
- BORG Trouble Maker
- Posts: 3196
- Joined: Sun Apr 27, 2008 2:00 am
- Location: Hamburg, Germany
- Contact:
Re: MPR++ v0.2.6c open for alpha testing
Hi neytiri455, you absolutely don't need mpr++ to get botf running, but sent you the link anyhow
- neytiri455
- Cadet 1st Year
- Posts: 3
- Joined: Sun Jun 12, 2011 2:00 am