T:V Customizable huds

Status
Not open for further replies.
VaporTrail, maybe you don't get it?

Since when was it mandatory that Client-Side scripting allow access to "certain information" that really shouldn't be accessable through 'scripting', not the 'client', as you stated? I really don't think anyone's begging for unlimited data, as you also stated. Tribes obviously had limitations, in case you didn't realize it.

Everyone know's what's possible with scripting, given the appropriate data. This is obvious. But, there's also a thing called restrictions, ever heard of this? Yeah, there's always loopholes with this as well, but that's a whole new issue.

Patching script related holes shouldn't be an issue, ither. Obviously, they need to know about them, to fix them. This is a given. Do you think they auto-magically create exe hacks and just auto-magically fix them? No, they ither get information about them in their fuckin email or they, probably, just find them on the internet like every other idiot.
 
No, I get it.

What they're doing is instead of taking a cheap ass sheet of drywall that's been hit with a hammer a dozen times before it even makes it to the construction site and putting that up, they're putting on a nice fresh clean sheet of drywall.

The trick with patches is that it costs MORE to patch up a lot of holes, than to not allow them to be a problem in the first place.

No scripting == No scripting exploits.

However, I don't remember anyone saying that Scripting will officially be nixed completely (however, I haven't been anywhere NEAR dillegent in following the discussion before now) which implies a limited scripting.

Thier drywall may or may not have a few cracks in it, but it will be easier to patch any holes that happen to develop than having it start with enough holes to make swiss cheese jealous.
 
The list continues, now it's cost and security. Anything else you want to add to the list? The list of copouts is endless.

From what I've read, pure speculation, the servers will allow only scripts that are pre-determined by the server admin.

Whatever, I'll wait to pass further judgement until I actually have the game on my HD. Talking about it is getting old...
 
Most of the legit scripts out there either display info about game status, equipment status, or server status. They could create suitable huds to display that, and set them as options and add a hudmover feature. I don't think t2's default huds were that bad.

They could disable scripting, put in a security about in-ram program edits, and secure everything they can, but without putting it on a secure device like a console, they can't ever make it 100% cheatproof. Someone could make a program that scans all the on-screen data for a red triange then aim slightly below it and fire, like they did for t2. Without knowledge of such a program, you can't write against it. They (and most of us) will be satisfied with enough security that it doesn't have cheats for a year or so.
 
Chikaze said:
They (and most of us) will be satisfied with enough security that it doesn't have cheats for a year or so.

Hence the whole balancing act. Security is a must. Without security, the game can become a "Cheaterstrike" imitation in very short order. Frankly I could do without dropping into the game for the first time and getting blasted with a 300m direct hit mortar shot 10 seconds after I set up my first portable inventory station or turret.

If cutting down on scripting's flexability means that the next HappyMod is delayed by a month or two, I feel it's worth it.
 
i think its quite obvious you dont have a clue how happymod works.. while there is a method to retrieving positions of objects in t2 from script, its rather crappy due to how long it takes to retrieve. (.25 second delay roughly) hm2 uses.. guess what.. exe hacks. it could allow 400m spamming of inventories without a scripting engine. happymod in t1 was a graphics driver hack. happymod in t2 was a exe hack. happymod in t:v will be an exe hack. scripting exploits are extremely minor compared to what exe hacks can do. id suggest getting a clue before calling for the removal of something thats improved the experience of tribes players for the last 5 years.
 
Jesus, people, read the threads before replying. No one said they didn't need to know about the exploits before they can patch them.

Not to mention, I've done huds that don't contain information pertinent to Tribes. IRChud or ICQhud for example... obviously these are innovative and not your normal stat-type huds that could easily be implemented by Irrational.

edit: This is in reply to Chikaze, and whoever else keeps saying "blah blah they can't patch exploits they don't know about" and idiots that think huds are only useful for data pertinent to Tribes.
 
Last edited:
You're right, I have no idea. I don't care to either.
I don't script (beyond making very minor alterations to other's scripts), I don't cheat.

The key word in the sentance concerning HappyMOD was "If".

If limiting scripting delays the appearance of the next HappyMOD, I think it's a good thing.

I don't care if it's HappyMOD, or an aimbot, or any other kind of cheat. If limiting scripting prevents it from appearing at all, or even delays it for 6-12 months the rewards far outweigh the price.

DEbig3 said:
id suggest getting a clue before calling for the removal of something thats improved the experience of tribes players for the last 5 years.

Please note, I'm not your average n00b, I've been through alot of that same 5 years. Not ONCE have I suggested removing scripting entirely, or if I have, I must have been fucking stupid.

What I have said is "Limiting" scripting. Stuff like Huds, Demo scripts, even auto taunt spam scripts are all fine and dandy with me. People got in an uproar over Mortar Spam waypoint generators , (I personally thought they were a godsend for a lot of HO that wanted an easier way to remember spam points rather than tape dozens of screenshots up next to thier monitors) so those might be where the line is drawn. Stuff that provides a real combat advantage could be considered a cheat, and in that context might fall under what needs to be limited.

I'm as against removing scripting as the next guy, but I don't want anything POSSIBLY resembling a cheat showing up in T:V. There was a lot of innovative stuff done with scripting, but innovation can work both ways.
 
Last edited:
DEbig3 said:
id suggest getting a clue before calling for the removal of something thats improved the experience of tribes players for the last 5 years.
Do I count as "having a clue"? How about they guys who wrote the Unreal engine? Do they have a clue? Or should we all consult DEbig3 on all things technical?

(btw, I really love these threads)
 
did you read my post at all? whether or not scripting is in t:v, the cheats will appear just as quickly as they did in t1 and t2. you cannot prevent cheating, you can only lessen the benefits it gives. the client doesnt need to know more than it can see..

thrax, you know better than that ;p
you have your own reasons to remove scripting, thats your call, but when someone starts calling for its removal based on his own ignorant theories, its time to correct him.
(i suspect a main reason supporting the lack of scripting would simply be the way the scripting engine in unreal is currently structured.. much simpler to secure if its designed from the ground up with purely clientside scripting in mind)
 
Last edited:
I'd rather consult a decent community member, than an over-zealous developer that hides behind copouts.
 
I'd rather consult a decent community member, than an over-zealous developer that hides behind copouts.

Does this mean I qualify?

Or does your definition of "decent" mean "has a similar opinion to mine"?

Scripting is good, scripting is fun. Scripting however has its bad side, the same with programming. For every godly scripter there's probably someone out there trying to write the next hot cheat.

They haven't succeded at it because (for the majority) the developers have taken precautions against such happening. It still happens because no matter how good, no one is infallible, and 6 months of developing is no match against someone who has all your code and 6 months of leisure time to break it. The best they can do is delay the cheats for as long as they can through security precautions, and then fix any holes as they arise and hope that costs allow them to.

If Thrax and team decide to remove scripting altogether, it will be removed. I think that would be a mistake. However, if they choose instead to limit scripting in certain ways, to improve security, than it's a price that must be paid for a better gaming experience for the majority.
 
Yogi said:
Those "novelties" are the character of the series. Skiing + jetpack = freedom of movement that no other game can match (even with vehicles).
I wish T:V had half the "freedom of movement" that Descent had back in '95?
 
x66 said:
What the hell is a client side hack job? I know you're a big time wannabe 'developer' dude, but, would you mind converting that to English for the rest of us?

*yawn*

yes, nofix, x66, oh master expert of negative energy... im not a wannabe coder who's claim to fame is crashing servers and being a little bitch (yea, i said that, but this is TW and you started it)

by "client side hack job" as compared to "REAL SCRIPTING" i refer to our ability, historically, to fiddle with code and assets on the client side end. not exactly a complicated definition.

i call it a HACK JOB, cuz outside tribes (where we actualyl were kinda FORCED into client side scripting)... this is basically deemed the source of cheats and the inappropriate way to do things.

obviously, now that our tribes scripting brethren are finally given the FREEDOM to really do proper coding from the server side (and even pushing assets to clients), we also have to face the security standards that exist IN THE REAL WORLD beyond tribes.

so, my point... again... is if we have really slick HUDs and features that would normally be done client side in previous tribes games.... IF it is something actualyl valued by the community... THEN servers will support it. it's a non-friggin-issue.

as a mapper, i couldnt make "client side maps" in that sense. this is an online game... and folks have to now think of the scripting as part of a whole. i KNOW and understand that it feels like a slap in the face to some people, but let's try to get real on this issue and stop whining.

"scripting" is now to be thought of differently folks... and it's OK.
 
Last edited:
know why theres clientside scripting in tribes? because the the engines are two of the very few that actually have a robust clientside script engine. most other engines have a fairly simple console.. such as quake. just a method to enter commands
theres two distinct approaches to offering clients scripts.. theres the unreal method of serverside scripts, then theres the purely clientside method that tribes uses. both are perfectly viable, and neither is significantly better than the other. clientside scripting can be perfectly secure.. it all depends on what information the scripting engine is allowed to know about.
 
DEbig3 said:
know why theres clientside scripting in tribes? because the the engines are two of the very few that actually have a robust clientside script engine. most other engines have a fairly simple console.. such as quake. just a method to enter commands
theres two distinct approaches to offering clients scripts.. theres the unreal method of serverside scripts, then theres the purely clientside method that tribes uses. both are perfectly viable, and neither is significantly better than the other. clientside scripting can be perfectly secure.. it all depends on what information the scripting engine is allowed to know about.

again, i dont think client side scripting counts for beans... and apparently engine CODERS agree.

but seriously... i cannot wait till some of you talented dudes really dig into TV scripting... cuz you'll soon realize that tribes is NOT the standard. frankly, im still amazed at all the obsession on this matter, as most game modding is not at all done client side outside tribes1/2. we were not doing client side hack jobs because it was robust. we were doign it cuz we could...

edit: by that, i mean that i think folks will be pleasantly suprised at HOW MUCH MORE ROBUST unrealscripting within TV context will be than they ever could have dreamed of. you'll be able to do 200% more cool stuff once we collectively get beyond this confusion over "client side scripting." but it's gonna take work and better planning.

there wont be as many kiddie scripts folks can run on their own. big friggin deal.
 
Last edited:
DEbig3 said:
tse, it doesnt need to fit unreals client/server script relationship to qualify as true scripting. theres a line between supporting something and declaring that anything that doesnt fit its standards is wrong.. and youve apparently crossed that line.

actually, responding to this point is prolly more constructive.

look, yea, im being provocative by saying client side scripting != real scripting

first of all, it's REALITY for TV (tm).

i think it's probably healthy for scripters to reframe how they think of themselves as more widely as being "modders." maps, code, GUI, modeling assets... if you change/add them, you are technically modding. just like you cant have your own version of a map running locally... you can't run your own code, gui and models. it'll be ok.

in tribes2, we used to talk about "map mods" and "server mods" in respect to scripting... and i think we were heading down the right path in our thinking.

for TV, with the unreal engine, we are really gonna have to let go of our reliance on quick hack jobs. it's just that simple.

scripting has to be thought of AS modding, and as a server-based addition (read: option for servers to install).

as a standard... for game developers... client side scripting = hacking.

OBVIOUSLY a whole lot of really friggin cool things can and have been done 'client side' for tribes games. that's not the point.

im saying that if it's really quality products, it CAN and should be done as a proper modification/mutator in the future.

client side scripting != real scripting

but the products folks have done client side can be made into "real" scripts and in fact we're gonna see some AMAZING stuff in TV, im positive.

folks just gotta break out of the old tribes mentality...

in my not-so-humble opinion, it's a step UP not a step down.
 
Last edited:
i dont doubt that well see just as much quality in t:v as we have in past tribes games. like i said, i consider the two methods to be roughly equal.. i personally prefer clientside, due to the sheer customizability of it. im not sure if you can change the client script options with unreal.. for example, changing the text of a flag grab message. if you can do stuff like that without much trouble (on a per-client basis), then i dont see any problem with it. thats just one of those little touches of personality that add alot to the multiplayer aspect of the game.. i still havent messed with unrealscript very much. i guess i should checkout that runtime engine..
 
Status
Not open for further replies.
Back
Top