It's a RAP 4, nice to look at, but fires a .43 caliber paintball, and it's kinda mixed reviews when it comes to them, you either get a lemon or you dont, they seem to break alot from what i've heard, your better off getting an ATS(advanced tactical systems) if you want an excellent mag feed gun, fires standard .68 caliber paintballs... Whoops, im going off topic.Napalmas wrote:Check this outTactical Advantage wrote:Ohh, paintball!!! I love Paintball, here's a pic of my marker...![]()
http://kcheseny89.tripod.com/bmp/index.album?i=0&s=1
On the other hand, Knight, Im sure PR will come through with a great Realistic Mod.
http://www.asiapaintball.com/news.htm
How real will PR be???
-
Tactical Advantage
- Posts: 587
- Joined: 2005-02-10 20:43
GOD BLESS AMERICA AND OUR ALLIES
-
Figisaacnewton
- Posts: 1895
- Joined: 2004-11-23 05:27
-
Beckwith
- Posts: 1341
- Joined: 2005-03-25 17:00
the thing about limited deats would take away the rambo and make alot more cowards hiding in corners and alot more snipers sneaking around trying to get as much bang for your buck, limiting the tanks to only spawing at the beginning of the round i dont feel is a good idea as theyll eather A. last 30 seconds and then you have to go 80% of the round without thus leaving you with an infantry map that could be quite hugeKnight wrote:In my original post my point was that I prefer a starting set of vehicles for each side and when they are destroyed they are lost and do not respawn again at the player base.
So the number of vehicles at the beginning of the match and the middle and end will be the same. The only difference being whether they are functional and moving around or destroyed/disabled and sitting in one spot.
The difference between moving vehicles and static ones as far as lag is concerned is probably negligable as moving ones need animating and position updating and static destroyed ones give off smoke. Although, the static ones probably don't ever need any data to be passed around as once their position and value have been set to static/destroyed then the individual computers only have to contintue to draw them and animate the smoke/sound of fire. Whereas active vehicles need their positions passed around constantly.
My ideal would be no or limited (perhaps 5 at most) respawns per player and vehicles that once used up in combat can not be replaced during that round.
In that case the protections of ones hardware would ad a vital strategic element to the team play.
The limited soldier respawn combined with the time penalty to respawn would make rambo style play rare.
think of it this way if what your suggesting was done on a map like El Alamien once the armors gone after the first minute or so of the round each time after that when you respawn your talking about a very very very very long walk to get to any of the bases let alone the farther out ones
as far as a dead vehicle not causing strain on the lag im almost certain your wrong, im not a coder and make not statement to suggest i am but id like to think i understand a sound "theory" from an un-sound one your idea that because it isnt moving it doesnt need to be updated doesnt make sense, the computer needs to rebuild each frame with every aspect of the enviroment static or active, and if your doing 40 or so frames thats alot of info having a bunch of objects around that arent neccessary causes unneeded strain on the netcode,
basically the conclusion on this is , Yes on a 12-32 pub server or an 8 on 8 clan match its not going to kill anyones game play, but for big battles in tournaments or larger pub servers of over 50-64 people from all over the world which is the way i play, you realise that things like this arent in anyway adding to the gameplay expirience, and can easily be left out.

-
Ugly Duck
- Posts: 975
- Joined: 2004-07-26 02:23
Work it the same way you work the way soldiers spawn. When someone dies they will have a respawn(hopefully between 30-60 seconds). During this period their dead body should be sitting there, they may spend any portion of that time "Criticaly Wounded" depending on the severity of their wounds. But dead or incapacitated, their body should remain there for their entire respawn period.
Vehicles should work the same way, I believe someone said that they already did, so I don't see any problem. In fact the only problem I have with dead vehicles in BF is the fact that in a matter of half a second they go from a completely functional vehicle to a black charred piece of metal that looks like someone threw it threw it in a volcano and let it sit for a while. Instead it should look relatively similar to the original vehicle, probably on fire with smoke coming out of the hatches/windows/whatever opening you want. If it's a tank you might here some ammo cooking off. If possible the hole could be shown where the impact(s) took place with smoke coming from there too! Lag would not be too concerning, because there would always be the same # of vehicles on the field as said before. The difference being some are on fire, some are not.
Vehicles should work the same way, I believe someone said that they already did, so I don't see any problem. In fact the only problem I have with dead vehicles in BF is the fact that in a matter of half a second they go from a completely functional vehicle to a black charred piece of metal that looks like someone threw it threw it in a volcano and let it sit for a while. Instead it should look relatively similar to the original vehicle, probably on fire with smoke coming out of the hatches/windows/whatever opening you want. If it's a tank you might here some ammo cooking off. If possible the hole could be shown where the impact(s) took place with smoke coming from there too! Lag would not be too concerning, because there would always be the same # of vehicles on the field as said before. The difference being some are on fire, some are not.
-
Beckwith
- Posts: 1341
- Joined: 2005-03-25 17:00
Ugly im with you on having the vehicles disappear as they respawn but this guy doesnt want them to respawn and yes your rite the way it is currently is that the destroyed vehicle only lasts till it respawns as for the vehicles imediately going black thats so that people can easily realise thats its a destroyed vehicle and not an active one so they dont sit there pounding the **** out of it wondering why it wont blow plus if you saw any of the Iraqi destroyed tanks after the first Gulf War they looked pretty black and charred

-
JS.Fortnight.A
- Retired PR Developer
- Posts: 3469
- Joined: 2004-07-23 12:00
IRT Solodude23:
Yeah its still good! Its still good!
http://www.globalsecurity.org/military/ ... 142357.jpg
Yeah its still good! Its still good!
http://www.globalsecurity.org/military/ ... 142357.jpg
Project Reality Operations Lead v0.2-0.3


-
Tactical Advantage
- Posts: 587
- Joined: 2005-02-10 20:43
-
JS.Fortnight.A
- Retired PR Developer
- Posts: 3469
- Joined: 2004-07-23 12:00
-
Tactical Advantage
- Posts: 587
- Joined: 2005-02-10 20:43
-
Knight
- Posts: 18
- Joined: 2005-05-09 14:34
yes i agree that on a large map with 60 players it could get annoying to have no vee-hickls.
I probably didnt express myself well enough. I was more aiming towards a vehicle spawns to people spawns ratio. I guess if it was a sub 32 player server that was going for 'total realism' then there would be no respawns for players and no respawns for vehicles. So if they got destroyed then it wouln'd matter cause the people who needed them would either be dead or already in the vicinity. That's the 'as close to real as we can get' scenario.
In such a case then learning to combine infantry with various air and land vehicles would yield some deeply strategic battles. You have a tank which is good against enemy infantry but you have to send a few of your infantry ahead and on the flanks to protect against portable anti tank defences.
On maps with respawns then the dynamic would change of course so you'd need reinforcement of vehicles.
On the matter of the lag. I think moving vehicles cause a little more taxation on the communications between the pc's. A destroyed vehicle does not need constant updates about it positions. It only gets a transmitted update if it moves. No need to keep sending data back and forth to say 'no change in the position of these vehicles.' So the graphcs still have to draw the vehicles whether they moves or not but the data flow between pc's is less if they A: are not moving and B get assigned the status that they can never move again.
I probably didnt express myself well enough. I was more aiming towards a vehicle spawns to people spawns ratio. I guess if it was a sub 32 player server that was going for 'total realism' then there would be no respawns for players and no respawns for vehicles. So if they got destroyed then it wouln'd matter cause the people who needed them would either be dead or already in the vicinity. That's the 'as close to real as we can get' scenario.
In such a case then learning to combine infantry with various air and land vehicles would yield some deeply strategic battles. You have a tank which is good against enemy infantry but you have to send a few of your infantry ahead and on the flanks to protect against portable anti tank defences.
On maps with respawns then the dynamic would change of course so you'd need reinforcement of vehicles.
On the matter of the lag. I think moving vehicles cause a little more taxation on the communications between the pc's. A destroyed vehicle does not need constant updates about it positions. It only gets a transmitted update if it moves. No need to keep sending data back and forth to say 'no change in the position of these vehicles.' So the graphcs still have to draw the vehicles whether they moves or not but the data flow between pc's is less if they A: are not moving and B get assigned the status that they can never move again.
-
Beckwith
- Posts: 1341
- Joined: 2005-03-25 17:00
im no bill gates but i dont think it works that way, everything needs to be refreshed with every changing frame thats just the way computers workKnight wrote:It only gets a transmitted update if it moves. No need to keep sending data back and forth to say 'no change in the position of these vehicles.' So the graphcs still have to draw the vehicles whether they moves or not but the data flow between pc's is less if they A: are not moving and B get assigned the status that they can never move again.
as far as lag yes a moving vehicle will cause MORE lag but a destroyed vehicle will still cause a UN-neccessary taxation that we can easily live without, if you had to choose one or the other id rather have a moving vehicle

-
Knight
- Posts: 18
- Joined: 2005-05-09 14:34
Becks,
there are in fact three separate operations that the processor has to make in this case.
The first is to graphically draw the item, which of course has to happen no matter what the state.
The second is to track it's change in location. If it has not moved then it's a feature of code optimization that the program will think like this, no update means no change. So the no update is it's self a process of a kind.
The absence of a message informing that he vehicle has moved is its self an instruction to draw it again in the same spot. Still, the lack of that instruction as space/processor time that can be used for other instructions.
Thirdly, the passing of information to and from each others computer takes up processor power/time. Again, the program/computers will not send messages to each other only to inform that there has been no change. That would waste a blip of bandwidth that can be used on other things. Common sense will be programmed into the code that tells all the computers that in the absence of a position update of any particular vehicle the assumption must be made by the program that it has not moved and should therefore be again drawn in the same spot.
Imagine you are the general of a pre radio era army. Would you constantly use man power and send dispatches to and from your different units just to inform that the enemy still has not changed position or would you just have the understanding that no update means no change? The latter saves the un needed use of manpower. Likewise, elegance of code design is what makes a great programmer.
These common sense systems are how programmers optimize the function of things such as graphics engines and net code. They strip all redundancy from the code in order to save a millionth of a second here and there.
there are in fact three separate operations that the processor has to make in this case.
The first is to graphically draw the item, which of course has to happen no matter what the state.
The second is to track it's change in location. If it has not moved then it's a feature of code optimization that the program will think like this, no update means no change. So the no update is it's self a process of a kind.
The absence of a message informing that he vehicle has moved is its self an instruction to draw it again in the same spot. Still, the lack of that instruction as space/processor time that can be used for other instructions.
Thirdly, the passing of information to and from each others computer takes up processor power/time. Again, the program/computers will not send messages to each other only to inform that there has been no change. That would waste a blip of bandwidth that can be used on other things. Common sense will be programmed into the code that tells all the computers that in the absence of a position update of any particular vehicle the assumption must be made by the program that it has not moved and should therefore be again drawn in the same spot.
Imagine you are the general of a pre radio era army. Would you constantly use man power and send dispatches to and from your different units just to inform that the enemy still has not changed position or would you just have the understanding that no update means no change? The latter saves the un needed use of manpower. Likewise, elegance of code design is what makes a great programmer.
These common sense systems are how programmers optimize the function of things such as graphics engines and net code. They strip all redundancy from the code in order to save a millionth of a second here and there.

