Home » Tiberian Technologies / Blackhand Studios » Tiberian Technologies Forum » Changelist for scripts.dll 4.0
|
|
|
|
 Re: Changelist for scripts.dll 4.0 [message #336717 is a reply to message #336622] |
Sun, 22 June 2008 10:37   |
Naamloos
Messages: 771
Registered: April 2004
Location: The Netherlands
Karma: 0
|
Colonel |
|
|
Very impressive work! I got a few questions though.
| Quote: |
A change to stop objects that are 100% hidden by other objects from being drawn (something called Occlusion Culling)
|
Ok, I just want to be sure here. This is basically VIS without having to manually set up VIS sectors? If so, exactly what "objects" are affected by this? Terrain, characters, vehicles, projectiles, particles? And how well has this been tested?
| Quote: |
A change to the loading of mix files on startup. As of now, any mix file without C&C_ on the front will be loaded as will any of the stock westwood C&C_ maps if they exist.
Add hud.ini keyword so that mods like Reborn and RA:APB can specify a new prefix instead of C&C_ to be used by the above mentioned mix file load code (does not affect the code that displays the list of valid maps in the map list)
|
Got a question which is a little related to this. Will it be possable to make map names appear different ingame (loading screens, ect) and completely ignore the filename, and look somewhere else instead? Basically if a map file was named "RA_NorthByNorthwest.mix", have it appear ingame as "North by North-west"?
I disagree with removal of key game features!
[Updated on: Sun, 22 June 2008 10:38] Report message to a moderator |
|
|
|
|
|
| Re: Changelist for scripts.dll 4.0 [message #336743 is a reply to message #336717] |
Sun, 22 June 2008 12:38 |
 |
saberhawk
Messages: 1068
Registered: January 2006
Location: ::1
Karma: 0
|
General (1 Star) |
|
|
| Naamloos wrote on Sun, 22 June 2008 12:37 |
Ok, I just want to be sure here. This is basically VIS without having to manually set up VIS sectors? If so, exactly what "objects" are affected by this? Terrain, characters, vehicles, projectiles, particles? And how well has this been tested?
|
It culls by first attempting to draw the AABB (worldbox?) of a PhysClass onto the already drawn scene with color and depthbuffer writes off. It then counts the pixels that would have been rendered, if above 0 it would draw the object regularly. It'd cull basically anything you can set a physics type on. However, it's not ment as a complete replacement for VIS, and depending on how the map is set up may cull very little.
|
|
|
|
| Re: Changelist for scripts.dll 4.0 [message #336747 is a reply to message #336622] |
Sun, 22 June 2008 12:56 |
=HT=T-Bird
Messages: 712
Registered: June 2005
Karma: 0
|
Colonel |
|
|
Things I want to see:
The rest of current BIATCH functionality incorporated into TT. (There are fixes for some low-probability/high-consequence netcode exploits in recent versions of BIATCH as well as the handy AntiBigHead feature and the PT hack detection. Also, this would be a good time to release our RoF detector.)
Integration between tt.dll and BI's work on plugins (at the very least the two should both be able to be loaded and running at the same time, at best TT.dll should be able to take advantage of our (BI's) work and use it to implement its hook API calls when running on a suitably equipped FDS, and this would allow it to include support for server-side console-command creation and other useful server-side hooks that TT.dll could not provide by itself for client-side security reasons).
Enhanced chathooking (not only chat filtering capabilities, but the ability to obtain the destination of dark blue pages and teamchat messages).
As part of the BI plugin integration, support for a "TT.dll loaded and ready" hook API that early-load DLLs can use to make calls into TT.dll. This will only work on the serverside, of course.
HTT-Bird (IRC)
HTTBird (WOL)
Proud HazTeam Lieutenant.
BlackIntel Coder & Moderator.
If you have trouble running BIATCH on your FDS, have some questions about a BIATCH message or log entry, or think that BIATCH spit out a false positive, PLEASE contact the BlackIntel coding team and avoid wasting the time of others. |
|
|
|
| Re: Changelist for scripts.dll 4.0 [message #336749 is a reply to message #336622] |
Sun, 22 June 2008 13:16 |
_SSnipe_
Messages: 4121
Registered: May 2007
Location: Riverside Southern Califo...
Karma: 0
|
General (4 Stars) |
|
|
John i got a few ideas
1)fix lightning (wont work via chat hook but turning if off does)
and wire mod (dont work with new 3x scripts iv heard and tryed to test and got nothing
2)(this is something iv been wanting for coop) when a player pass thru a zone pms them a message i type in serverside but ONLY one pm per player and when they pass thru again nothing happens so one pm per person one time only
3)make the jfw_custom_send_multiply_customs rest after being used
i tryed to make it loop but it only works once and then no longer works after the first time, i had post on it a while back
4)a better send custom on zone enter and make it so it dont do it again after passing thru the zone more then once.(like walk thru and sends a custom once and thats it)
5)when take ss make it show a small message on the side saying it was token
6)also make it so you can take ss of pt menu
thats all i got for now i hope you atleast take them into consideration
EDIT:dont forget you should try to have BIATCH read of the servers objects file i changed damage of a gun serverside and when i join to test it i got banned by my opwn server
[Updated on: Sun, 22 June 2008 13:28] Report message to a moderator |
|
|
|
| Re: Changelist for scripts.dll 4.0 [message #336754 is a reply to message #336747] |
Sun, 22 June 2008 13:33 |
 |
Scrin
Messages: 1310
Registered: January 2007
Location: Cold City
Karma: 0
|
General (1 Star) |
|
|
my main suggestion which should be added (with ss)
add True RGB collor (12) code inside hud..err.. TT.ini to main screen's (top) weapon image icons...(default icons have green collor, 3.4.4.scripts got code to change collor for weapon icons only for custom hud displaying (by default right corner on your game screen, whare you can see your bullets amount, but havent code to do same feature with main weapon icons (i talk about this---> (your 4.0 bug fix quote): '' | jonwil wrote on Sun, 22 June 2008 03:55 |
A change to the "next weapon" and "previous weapon" code so it will skip weapons that are empty. You can still use the number keys (1 for pistol, 2 for rifle etc) to access these weapons.
This code will also not skip weapons that have a zero ammo count
|
'''
to make clear what the hell i talked about i can say in easy form: when you have like all or half weapons in wol game and you got all of weapons from bumber '7' and you need to swap like from sbh laser rifle to railgun or repair gun,you look at small green weapon icons on your screen's top (laser gun,laser chaingun/rail/pic/repair...) so this icons must have feature inside TT.ini to set WeaponIconCollor=12 (true .dds RGB) (but keyword ''WeaponIconCollor'' already have in 3.4.4, so you can create some new keyword...?)
here screenshot: (i send pm with that SS to Saberhawk and to Jerad Grey long time ago ,but i have no answers. (these 2 dudes keep ignoring me for some fucking weird reason!)
why not add this good feature?
|
|
|
|
| Re: Changelist for scripts.dll 4.0 [message #336783 is a reply to message #336743] |
Sun, 22 June 2008 14:35 |
Naamloos
Messages: 771
Registered: April 2004
Location: The Netherlands
Karma: 0
|
Colonel |
|
|
| Saberhawk wrote on Sun, 22 June 2008 21:38 |
It culls by first attempting to draw the AABB (worldbox?) of a PhysClass onto the already drawn scene with color and depthbuffer writes off. It then counts the pixels that would have been rendered, if above 0 it would draw the object regularly. It'd cull basically anything you can set a physics type on. However, it's not ment as a complete replacement for VIS, and depending on how the map is set up may cull very little.
|
I'm not sure I fully understand the first part there, but you mean it will always still draw the 'box' around a physical object and decide whether or not to render the object if anything at all of it is visible?
Unless I'm getting it wrong this is basically what VIS does, just a different method. If so, why can't this become a full replacement for VIS? Assuming it can be improved and all that...
I know many modern games use a script-side 'culling' method rather then Renegade's VIS as it simply takes too much time to do VIS. This is also why most maps in games are a bit maze-like with a lot of walls to optimize the use of these systems.
[Updated on: Sun, 22 June 2008 14:39] Report message to a moderator |
|
|
|
| Re: Changelist for scripts.dll 4.0 [message #336934 is a reply to message #336783] |
Sun, 22 June 2008 17:14 |
|
saberhawk
Messages: 1068
Registered: January 2006
Location: ::1
Karma: 0
|
General (1 Star) |
|
|
| Naamloos wrote on Sun, 22 June 2008 16:35 |
| Saberhawk wrote on Sun, 22 June 2008 21:38 |
It culls by first attempting to draw the AABB (worldbox?) of a PhysClass onto the already drawn scene with color and depthbuffer writes off. It then counts the pixels that would have been rendered, if above 0 it would draw the object regularly. It'd cull basically anything you can set a physics type on. However, it's not ment as a complete replacement for VIS, and depending on how the map is set up may cull very little.
|
I'm not sure I fully understand the first part there, but you mean it will always still draw the 'box' around a physical object and decide whether or not to render the object if anything at all of it is visible?
Unless I'm getting it wrong this is basically what VIS does, just a different method. If so, why can't this become a full replacement for VIS? Assuming it can be improved and all that...
I know many modern games use a script-side 'culling' method rather then Renegade's VIS as it simply takes too much time to do VIS. This is also why most maps in games are a bit maze-like with a lot of walls to optimize the use of these systems.
|
Yes, it will always draw the bounding box and decide if it will be visible or not off of that. But that's just 20 polygons, and with no textures, lighting, or even actual rendering turned on, it's instantaneous.
Most modern games use occlusion culling to cut down on objects to render, *but* in those cases the engine was designed to take advantage of occlusion culling. Renegade wasn't. And we can't fake being designed for it either because we have no control over draw order. Because the draw order can be seriously messed up at times, occlusion culling can't be completely depended upon.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Changelist for scripts.dll 4.0 [message #337034 is a reply to message #336934] |
Mon, 23 June 2008 05:00 |
Naamloos
Messages: 771
Registered: April 2004
Location: The Netherlands
Karma: 0
|
Colonel |
|
|
| Saberhawk wrote on Mon, 23 June 2008 02:14 |
| Naamloos wrote on Sun, 22 June 2008 16:35 |
| Saberhawk wrote on Sun, 22 June 2008 21:38 |
It culls by first attempting to draw the AABB (worldbox?) of a PhysClass onto the already drawn scene with color and depthbuffer writes off. It then counts the pixels that would have been rendered, if above 0 it would draw the object regularly. It'd cull basically anything you can set a physics type on. However, it's not ment as a complete replacement for VIS, and depending on how the map is set up may cull very little.
|
I'm not sure I fully understand the first part there, but you mean it will always still draw the 'box' around a physical object and decide whether or not to render the object if anything at all of it is visible?
Unless I'm getting it wrong this is basically what VIS does, just a different method. If so, why can't this become a full replacement for VIS? Assuming it can be improved and all that...
I know many modern games use a script-side 'culling' method rather then Renegade's VIS as it simply takes too much time to do VIS. This is also why most maps in games are a bit maze-like with a lot of walls to optimize the use of these systems.
|
Yes, it will always draw the bounding box and decide if it will be visible or not off of that. But that's just 20 polygons, and with no textures, lighting, or even actual rendering turned on, it's instantaneous.
Most modern games use occlusion culling to cut down on objects to render, *but* in those cases the engine was designed to take advantage of occlusion culling. Renegade wasn't. And we can't fake being designed for it either because we have no control over draw order. Because the draw order can be seriously messed up at times, occlusion culling can't be completely depended upon.
|
And there is no way to change the draw order at all unless you have *magic words* the W3D source code...
Hmm. Ok then here comes another question then. I'd like to know if anything is changable about LOD? (level of detail) It's currently based on both range AND a specific number of polygons being rendered. If it's possable to make it only range-dependant so let's say you get max detail objects within 100 meters, lesser between 100 and 400, and lowest detail at 400+. (possably a 4th where the model is removed completely). I'd like to hear your opinion on this being possable or not.
[Updated on: Mon, 23 June 2008 05:04] Report message to a moderator |
|
|
|
| Re: Changelist for scripts.dll 4.0 [message #337083 is a reply to message #337034] |
Mon, 23 June 2008 11:12 |
|
saberhawk
Messages: 1068
Registered: January 2006
Location: ::1
Karma: 0
|
General (1 Star) |
|
|
| Naamloos wrote on Mon, 23 June 2008 07:00 |
| Saberhawk wrote on Mon, 23 June 2008 02:14 |
| Naamloos wrote on Sun, 22 June 2008 16:35 |
| Saberhawk wrote on Sun, 22 June 2008 21:38 |
It culls by first attempting to draw the AABB (worldbox?) of a PhysClass onto the already drawn scene with color and depthbuffer writes off. It then counts the pixels that would have been rendered, if above 0 it would draw the object regularly. It'd cull basically anything you can set a physics type on. However, it's not ment as a complete replacement for VIS, and depending on how the map is set up may cull very little.
|
I'm not sure I fully understand the first part there, but you mean it will always still draw the 'box' around a physical object and decide whether or not to render the object if anything at all of it is visible?
Unless I'm getting it wrong this is basically what VIS does, just a different method. If so, why can't this become a full replacement for VIS? Assuming it can be improved and all that...
I know many modern games use a script-side 'culling' method rather then Renegade's VIS as it simply takes too much time to do VIS. This is also why most maps in games are a bit maze-like with a lot of walls to optimize the use of these systems.
|
Yes, it will always draw the bounding box and decide if it will be visible or not off of that. But that's just 20 polygons, and with no textures, lighting, or even actual rendering turned on, it's instantaneous.
Most modern games use occlusion culling to cut down on objects to render, *but* in those cases the engine was designed to take advantage of occlusion culling. Renegade wasn't. And we can't fake being designed for it either because we have no control over draw order. Because the draw order can be seriously messed up at times, occlusion culling can't be completely depended upon.
|
And there is no way to change the draw order at all unless you have *magic words* the W3D source code...
Hmm. Ok then here comes another question then. I'd like to know if anything is changable about LOD? (level of detail) It's currently based on both range AND a specific number of polygons being rendered. If it's possable to make it only range-dependant so let's say you get max detail objects within 100 meters, lesser between 100 and 400, and lowest detail at 400+. (possably a 4th where the model is removed completely). I'd like to hear your opinion on this being possable or not.
|
No, and that is counter-productive of LOD. Just tweak the static and dynamic LOD numbers (usually) located in HKLM/Software/Westwood/Renegade/System Settings/
|
|
|
|
| Re: Changelist for scripts.dll 4.0 [message #337128 is a reply to message #336622] |
Mon, 23 June 2008 16:00 |
dr3w2
Messages: 485
Registered: September 2006
Location: Ottawa,Canada
Karma: 0
|
Commander |
|
|
Will the new anticheat work with the hud.ini files?
For example, hud.ini , mapname.ini .
As of right now renguard rejects these files.
n00bstories Server Administrator
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Goto Forum:
Current Time: Sat Apr 12 03:31:49 MST 2025
Total time taken to generate the page: 0.01304 seconds
|
Search
Help
Members
Register
Login
Home
