42 replies to this topic

[The Bloody History of Communism]

letir, on 18 July 2020 - 01:42 PM, said:

You got it completly backwards.

You know which ally behind of you, thanks to the map, minimap and markings.

What you don't know it's something like stealth COM running up to your butt, or SHC taking good position for backstab, or wolfpack going to flank your lance.

Harassers relying on the restricted vision of the enemy to be sucessful in backstabbing. Window for attack with low-ranged weapons could be extremly narrow in the chaos of battle. Quick "back mirror" button would allow players to react and counteract such tactics. Even ability quickly turn sideways and call for help could completly deny a kill.

Again there is just a simple navigational usage for this. Huge *** mechs get stuck on the tiniest of minutia in the game. Trees, small buildings, rocks, ravines, slopes, cliffs, ramps etc. All of those can sometimes be far deadlier to an assault than an enemy mech because you have to distract away from combat to just drive the 18 wheeler.

[Nightbird]

A rear camera will reduce your FPS by 40-50%, since your computer has to render twice as much geometry even though the rear camera will only occupy a small portion of your screen.

[Nesutizale]

letir, on 18 July 2020 - 01:42 PM, said:

You got it completly backwards.

You know which ally behind of you, thanks to the map, minimap and markings.

What you don't know it's something like stealth COM running up to your butt, or SHC taking good position for backstab, or wolfpack going to flank your lance.

Harassers relying on the restricted vision of the enemy to be sucessful in backstabbing. Window for attack with low-ranged weapons could be extremly narrow in the chaos of battle. Quick "back mirror" button would allow players to react and counteract such tactics. Even ability quickly turn sideways and call for help could completly deny a kill.

Yes skilled players could actualy use this to check for approaching backstabbers. Mh...

There are two points that come to my mind in that regard.

- Make the rear view less clear/small so that a quick toggle won't do it. A player would need to focus longer on the rear view to acutaly make out a light running in the back. That way a quick toggle wouldn't do you any good, you would have to actualy look closely at the image to see movement. Maybe you could have a black&white image with a lot of grain in it on a secondary screen in the cockpit. That way a player has to focus on either the front or the back.

- Light units would need a bit more coordination then they have now. Waiting either for the main force to attack the enemy so that the enemys attention is clearly to the front or be fast with hit and run tactics.
I have seen both tactics allready beeing used by lights very effectifly with suddenly haveing a stealth mech in between your team and people not notecing them or sinipers that where good enought to get back into coevr that even while I knew what direction the shot came from I coulnd't see them. A view toggle wouldn't help in either situation.


A complete different approach that comes to my mind...

- Sound alarm like when you drive a car backwards that informs you how close something is behind you
- When you don't like sound how about an graphical indicator like the hit indicator that lights on when you are at a certain distance from an object...lets say 10m ?

Both wouldn't reveal a light mech trying to sneek around but still give you some indicators for your surrounding when driving your mech. Would that be a comprimise?

[The Bloody History of Communism]

Nesutizale, on 18 July 2020 - 02:28 PM, said:

Yes skilled players could actualy use this to check for approaching backstabbers. Mh...

There are two points that come to my mind in that regard.

- Make the rear view less clear/small so that a quick toggle won't do it. A player would need to focus longer on the rear view to acutaly make out a light running in the back. That way a quick toggle wouldn't do you any good, you would have to actualy look closely at the image to see movement. Maybe you could have a black&white image with a lot of grain in it on a secondary screen in the cockpit. That way a player has to focus on either the front or the back.

- Light units would need a bit more coordination then they have now. Waiting either for the main force to attack the enemy so that the enemys attention is clearly to the front or be fast with hit and run tactics.
I have seen both tactics allready beeing used by lights very effectifly with suddenly haveing a stealth mech in between your team and people not notecing them or sinipers that where good enought to get back into coevr that even while I knew what direction the shot came from I coulnd't see them. A view toggle wouldn't help in either situation.


A complete different approach that comes to my mind...

- Sound alarm like when you drive a car backwards that informs you how close something is behind you
- When you don't like sound how about an graphical indicator like the hit indicator that lights on when you are at a certain distance from an object...lets say 10m ?

Both wouldn't reveal a light mech trying to sneek around but still give you some indicators for your surrounding when driving your mech. Would that be a comprimise?

I like your "rear lidar" approach, that vehicles today do currently use. As a programmer, I can tell you this would certainly require a lot more computational resources. Because you would have to have a matrix of all the available objects capable of stopping a mech moving backwards (that alone would take some time), then you would have to filter out false positives that are behind but not within the current vector of travel. It seems to me having the human make that call with a toggle to a "webcam" or a "rear view camera" as implemented in modern vehicles is the easiest solution both computationally and engineering wise. I honestly think something like this could take roughly 2 hours to code and that is with complete naivety to their codebase.

[Nesutizale]

A list of "Mechstoppers" should exits, shouldn't it? I mean they have to do collision checks allready to stop a mech.

As for reduceing the resource hunger, maybe you can only run the check when the mech is in reverse instead of all the time. I mean its only of interest for backwards movement anyway. So you could use the same mechanic that checks for forward collisions allready for backward collisions and just add a warning when there is something you can collide with.

The rear-view might be easier to do programming wise but I think it would take up a lot of resources on the graphic side as you would have to calculate and render a complete new view. Basicly doubleing the resources needed for that view.

[RickySpanish]

The Bloody History of Communism, on 18 July 2020 - 02:59 PM, said:

I like your "rear lidar" approach, that vehicles today do currently use. As a programmer, I can tell you this would certainly require a lot more computational resources. Because you would have to have a matrix of all the available objects capable of stopping a mech moving backwards (that alone would take some time), then you would have to filter out false positives that are behind but not within the current vector of travel. It seems to me having the human make that call with a toggle to a "webcam" or a "rear view camera" as implemented in modern vehicles is the easiest solution both computationally and engineering wise. I honestly think something like this could take roughly 2 hours to code and that is with complete naivety to their codebase.

As a programmer, I can tell you that periodic collision checks are certainly pretty darn cheap, especially done client side.

Edited by RickySpanish, 18 July 2020 - 10:13 PM.

[Thorn Hallis]

As far as I remember it had something to so with the engine not being able to render two different views on one screen.

[LordNothing]

Nightbird, on 18 July 2020 - 02:14 PM, said:

A rear camera will reduce your FPS by 40-50%, since your computer has to render twice as much geometry even though the rear camera will only occupy a small portion of your screen.

its not really that bad, especially if you are under utilizing your video card, like hitting 75 when your monitor can only do 60. a render target about a quarter of your screen resolution isnt going to be that much of an impact to your fps. if it does there are other things you can do. for example you dont have to update it every frame, it would still be useful if you update it every 2 or 3 frames. you can also turn off some things like shadows and other effects, or shortening your far clipping plane distance. you can get the impact as low as 10% with the correct settings provided you aren't already struggling to get 60.

advanced zoom already looks like its using render targets, though that could be a screen space effect (either way it would look low res like it does).

Edited by LordNothing, 19 July 2020 - 12:12 AM.

[Thorn Hallis]

Remember the original advanced zoom? That was extremly low res.

[LordNothing]

Thorn Hallis, on 19 July 2020 - 12:18 AM, said:

Remember the original advanced zoom? That was extremly low res.

i think the game was intended to have this feature, thats why all the early on mechs had those screens. but it looks like they didnt get very far into developing the other parts before they got rid of their not-potato coder. render targets of 1k or less are preferable (0.5k is ok for small screens like the ones in the cockpits).

Edited by LordNothing, 19 July 2020 - 12:30 AM.

[VonBruinwald]

LordNothing, on 19 July 2020 - 12:00 AM, said:

its not really that bad, especially if you are under utilizing your video card, like hitting 75 when your monitor can only do 60. a render target about a quarter of your screen resolution isnt going to be that much of an impact to your fps. if it does there are other things you can do. for example you dont have to update it every frame, it would still be useful if you update it every 2 or 3 frames. you can also turn off some things like shadows and other effects, or shortening your far clipping plane distance. you can get the impact as low as 10% with the correct settings provided you aren't already struggling to get 60.

I get 45... 50 on a good day.

[Nesutizale]

Question, how many coders do we have here that could work on this?
I have this crazy idea of an "MWOpen" project. Takeing MWO, crack it open to work on it with a specific goal in mind. For example implementing a working rear view, then pitch that part of the code to PGI.

It wouldn't be meant to create a player run servers or something like MW:LL just to create a "prove of concept" envoirment where people from the community can fiddle around with ideas, test them and then present PGI with the results.
Maybe that way stuff like the rear view, improvemnts in performance, balanceing, map creation and so on could be implemented.

When the costs in time and money would be low enough, maybe then we can get PGI to officialy implement the stuff we as community have worked on.

Maybe my view is a bit naiv but I think PGI could only win that way.
- No one would modify their source directly so it wouldn't break the running game
- PGI would still have full control about what makes it into the game
- Least resource intensive way of getting stuff into the game
- Have more creative input
- Several small teams or single persons could run many different ideas in parallel
- Find new talents

In the end I think something like that could increase MWO lifespan as well as get new content and features into the game and by that make the game again more interesting and maybe, just maybe get people back into MWO. Should we manage that it also means better matches and more money to be made.

[LordNothing]

VonBruinwald, on 19 July 2020 - 12:33 AM, said:

I get 45... 50 on a good day.

that might be why they didnt do it. perhaps they figure the average player just dont have the specs. but i still got my bets on lazyness/stupidity. it aint happening anyway soon so i guess the point is moot.

Edited by LordNothing, 19 July 2020 - 05:44 AM.

[LordNothing]

Nesutizale, on 19 July 2020 - 02:59 AM, said:

Question, how many coders do we have here that could work on this?
I have this crazy idea of an "MWOpen" project. Takeing MWO, crack it open to work on it with a specific goal in mind. For example implementing a working rear view, then pitch that part of the code to PGI.

It wouldn't be meant to create a player run servers or something like MW:LL just to create a "prove of concept" envoirment where people from the community can fiddle around with ideas, test them and then present PGI with the results.
Maybe that way stuff like the rear view, improvemnts in performance, balanceing, map creation and so on could be implemented.

When the costs in time and money would be low enough, maybe then we can get PGI to officialy implement the stuff we as community have worked on.

Maybe my view is a bit naiv but I think PGI could only win that way.
- No one would modify their source directly so it wouldn't break the running game
- PGI would still have full control about what makes it into the game
- Least resource intensive way of getting stuff into the game
- Have more creative input
- Several small teams or single persons could run many different ideas in parallel
- Find new talents

In the end I think something like that could increase MWO lifespan as well as get new content and features into the game and by that make the game again more interesting and maybe, just maybe get people back into MWO. Should we manage that it also means better matches and more money to be made.

that would be great, now we just need to get pgi to let me have their source code. mwll never got its render to texture to work either. that game too had placeholder areas for them, but they were never filled in. supposedly cryengine doesn't expose enough of its low level render api code to make it work (and thats likely a lame excuse developers like to give when they cant figure out how do it), and it would require an engine wizard.

Edited by LordNothing, 19 July 2020 - 06:00 AM.

[Lord Sevenous]

The Bloody History of Communism, on 18 July 2020 - 01:07 PM, said:

Why cant a mech in 3060? Ludicrous.

A Mech in 3060 has 360° sight compressed to 180° a on a viewscreen.....

But in a 2012-2020 Computer Game this would look really bad (Disorientating/motionsickness.....) and would be a muder to program/balance in a multiplayer Game.

NEVER EVER bring logic or real science into the Battletech Lore.
People are trying to explain away errors that were made to build a pleasing Tabletop Game for the last 30years....

[Nesutizale]

LordNothing, on 19 July 2020 - 05:53 AM, said:

that would be great, now we just need to get pgi to let me have their source code. mwll never got its render to texture to work either. that game too had placeholder areas for them, but they were never filled in. supposedly cryengine doesn't expose enough of its low level render api code to make it work (and thats likely a lame excuse developers like to give when they cant figure out how do it), and it would require an engine wizard.

Two thought that I have in regard of them releasing the code..can't one decode the given files? I think it was done for other games, also with lots of difficulty from what I heard. Still it was possible.

Second thought...how hard would it be to port over what we have to the current version of cryengine. That would also give you a map editor for free and I think as long as you don't use the version commercial its free.
Problem I see with that is either PGI would have to upgrade too or have a hard time reverse engineer any ideas back into the old engine.
On the other hand that could be a good chance to optimize the code. I would guess that, over time, the new cryengine has been optimized at a basic level, compared to the version MWO uses. Also MWO is using a modified one IIRC to begin with.

Anyway them releaseing the source would be the best possible option.

As for how hard it is to code in the rear view. The guys from StarCitizen, who also uses Cryengine as a basis, also heavy modified by now, have said they have quite some problem with getting "render to texture" and additional views to work.
While I don't understand the technical talk...what I got is "its difficulte to code/implement" and "takes a lot of processing power".

[LordNothing]

Nesutizale, on 19 July 2020 - 06:11 AM, said:

Two thought that I have in regard of them releasing the code..can't one decode the given files? I think it was done for other games, also with lots of difficulty from what I heard. Still it was possible.

Second thought...how hard would it be to port over what we have to the current version of cryengine. That would also give you a map editor for free and I think as long as you don't use the version commercial its free.
Problem I see with that is either PGI would have to upgrade too or have a hard time reverse engineer any ideas back into the old engine.
On the other hand that could be a good chance to optimize the code. I would guess that, over time, the new cryengine has been optimized at a basic level, compared to the version MWO uses. Also MWO is using a modified one IIRC to begin with.

Anyway them releaseing the source would be the best possible option.

As for how hard it is to code in the rear view. The guys from StarCitizen, who also uses Cryengine as a basis, also heavy modified by now, have said they have quite some problem with getting "render to texture" and additional views to work.
While I don't understand the technical talk...what I got is "its difficulte to code/implement" and "takes a lot of processing power".

anyone can decompile the binary blobs, but you need somone who is well versed in x86asm to do anything with that, those kind of coders are rare in the professional world and even rarer at a hobbyist level. not to say this kind of thing has never been done before. you also only have access to the client side even if you could pull it off. granted this is something that would be done client side but at a very low level in the engine.

you need to solve a lot of things to make it work.

where to place the cameras on the mechs (you might need to retrofit camera points on all mechs).

ability to juggle renderer configurations on the fly. doing this fast is critical.

you need to perform the texture renderings at the correct phase of scene rendering. where the scene is built and ready to render. in order to avoid doing a lot of nontrivial setup tasks twice. they also have to be rendered first otherwise you end up with a frame of latency. another critical thing for performance.

you need to schedule texture updates if they are not done every frame (this is a good idea as not everyone has the specs to update the textures every frame).

handle user settings, things like resolution and desired update frequency being the main ones.

Edited by LordNothing, 19 July 2020 - 06:37 PM.

[The Bloody History of Communism]

Reverse engineering from the compiled binary is off the table -- for a lot of reasons. They have to release the client side code which should be doable and low risk. Lots of companies do this nowadays (think ID software, doom series for instance).

Literally, this would be one extra bind, say "F10" hypothetically, that turns on a rear facing webcam viewpoint until the button is released or repressed (preference depending). This should not take long. Thats all we need, let the pilot use the information and dont worry about coding anything else more complex, keep it simple.

If this were to work out with this limited objective, I can see more of the "wish list" stuff being done this way in the future.

PGI/Russ -- if you are reading this, please comment on your thoughts and prospects of an open sourcing of the client code only.

TY!

[Nesutizale]

Okay in short it would be to complcated without the source but with the source it should be rather easy to do.

In that case PGI, please consider a release of the source as Bloody suggested, to create a testbed for some of the coders here to try to create new features or maybe even new content to keep MWO alive and maybe even improve it.

[LordNothing]

Nesutizale, on 20 July 2020 - 12:16 AM, said:

Okay in short it would be to complcated without the source but with the source it should be rather easy to do.

In that case PGI, please consider a release of the source as Bloody suggested, to create a testbed for some of the coders here to try to create new features or maybe even new content to keep MWO alive and maybe even improve it.

and that is provided they didnt code themselves into a hole they couldnt get out of. this happens more often than you think. less face a large scale rewrite which could easily double or tripple the price point for coder time which may already be the largest line item in the game's budget.

Edited by LordNothing, 21 July 2020 - 10:10 PM.