Tremulous Forum
General => Feedback => Topic started by: m0wlwurf on February 10, 2007, 06:03:09 pm
-
In my opinion Tremulous needs a scripting language that allows mappers to modifiy brushes and connect them to serveral conditions, for example: A train that carries only a speciefied ammount of humans deppending on their weight.
I am thinking of an language similar to ICARUS which is used in Jedi Academy.
-
a train, i'm up for...a weight limit, no....but...the general idea is a good one and shold be looked into
-
trains are already possible, thats not the point the point is that it only moves if the hummies aren't to heafy or adjusts the speed depending of the weight, another example is a Password protected door, the key to open the door is randomly created on mapstart, the player has to check out the key at a terminal and has to enter it directly at the door or at a numpad, by shooting at the numbers on the pad or by opening a menu (like that at armory) where he can enter it by keyboard or mouse. That could be usefull to make maps more interactive or adding a task for humans in the (hopefully) upcoming siege mode.
-
I want to remind you that multiplayer maps should be as simple as possible
even doors are not good for MP maps
-
Dont depend on people paying attention to whats going on around them. If they run up to it and nothing happens then they will forget about it.
-
I want to remind you that multiplayer maps should be as simple as possible
even doors are not good for MP maps
I know, that example with the password protected door wasn't as good, but you can do many things that are actually really difficult do manage, like a dialing stargate which dasprid was (is/will) working on (talked about in hammunaptra thread) or just a simple teleporter which must we activated to be usable or which points to different locations... or a script that locks some doors if there are to less people on a map. Scripts can also used to modify the gameplay under serveral conditions...
Dont depend on people paying attention to whats going on around them. If they run up to it and nothing happens then they will forget about it.
Do you talking about the pw-door? It was just an example, and people would get know about it throw a target_print or something that give them the information (isn't an extension to motd that renders html already planed?)
-
Hey, you are the second guy who needs scripting language in trem. I need it too. Would be really great for mission based maps. But I would prefer LUA as language.
-
Hey, you are the second guy who needs scripting language in trem. I need it too. Would be really great for mission based maps. But I would prefer LUA as language.
ditto plus it is already implemented in xreal.
-
like a dialing stargate which dasprid was (is/will) working on (talked about in hammunaptra thread)
I stole taht idea and i'm working on a stargate map :D
-
I want to remind you that multiplayer maps should be as simple as possible
even doors are not good for MP maps
I disagree. Currently, the shoot 'em up aspect is focussed on almost exclusively. I want to see more strategy. Complex maps that require team play could be very good.
-
Hey, you are the second guy who needs scripting language in trem. I need it too. Would be really great for mission based maps. But I would prefer LUA as language.
I have never worked with lua, but from what i can see from the wikipedia article lua has an cool syntax.
ok lets use LUA, and if it is correct that xreal already implented LUA adding to trem should be much more easy as copying something like ICARUS.
-
Instead of a mapping scripting language, i would prefer a simple one that can be used for clients, say for binds. One that had basic logic (if, else, and, or, then, etc), variable variables ($playercount$, $nextstage$) and garbage collection.
-
Instead of a mapping scripting language, i would prefer a simple one that can be used for clients, say for binds. One that had basic logic (if, else, and, or, then, etc), variable variables ($playercount$, $nextstage$) and garbage collection.
it would be way too easy to abuse a client side scripting language that can do conditional branching and knows things about the game state.
-
Let us first try to make some maps that are worthy of coding a scripting system.
-
Let us first try to make some maps that are worthy of coding a scripting system.
Amen.
-
Let us first try to make some maps that are worthy of coding a scripting system.
10 points
-
Ah, but what about maps that were never started because of a lack of a scripting system?
Besides, integrate a scripting system, and Soubok would be just looking for excuses to add it to pulse.
-
Instead of a mapping scripting language, i would prefer a simple one that can be used for clients, say for binds. One that had basic logic (if, else, and, or, then, etc), variable variables ($playercount$, $nextstage$) and garbage collection.
it would be way too easy to abuse a client side scripting language that can do conditional branching and knows things about the game state.
Maprotation has logic and variables.
-
Instead of a mapping scripting language, i would prefer a simple one that can be used for clients, say for binds. One that had basic logic (if, else, and, or, then, etc), variable variables ($playercount$, $nextstage$) and garbage collection.
it would be way too easy to abuse a client side scripting language that can do conditional branching and knows things about the game state.
Maprotation has logic and variables.
maprotation isn't client side.
-
Instead of a mapping scripting language, i would prefer a simple one that can be used for clients, say for binds. One that had basic logic (if, else, and, or, then, etc), variable variables ($playercount$, $nextstage$) and garbage collection.
it would be way too easy to abuse a client side scripting language that can do conditional branching and knows things about the game state.
Maprotation has logic and variables.
maprotation isn't client side.
but he has a point
we already have some kind of a scripting language
we just needs something capable of getting stage and activator(team,credits,equipment,weapon) of trigger
then for example for a button in gtkradiant you set script = btcs/button1
btcs.script file is just
---------------
btcs/button1
{
if(alienstage==1&&activator.team==human)
target="door1";
else
target="door2";
}
---------------
so a button opens one of the two doors dynamically
:( my design sucks anyway
-
Ah, but what about maps that were never started because of a lack of a scripting system?
If you cannot make a good map because of the abcense of a scripting system, you lack mapping skills and should practice more. A scripting system is only an addition to a map making it even better(or worse), not the basis on which to build a map.
-
For example, how many of us like to realay "5k to next stage guys!" or the like? A script would automate this, and then you just bind it to one key. So you could press, say F3, and have F3 bound to "say $tonextstage$k to go guys!", and say you had 2 kills to next stage. All anyone else would see is "Paradox|SST+Op|: 2k to go guys!"
-
Instead of a mapping scripting language, i would prefer a simple one that can be used for clients, say for binds. One that had basic logic (if, else, and, or, then, etc), variable variables ($playercount$, $nextstage$) and garbage collection.
it would be way too easy to abuse a client side scripting language that can do conditional branching and knows things about the game state.
I'd also love to see a simple scripting system, but I'm curious how it could be abused. I can't imagine how at all. Care to explain?
-
a simple (Stage==1) ? buy prifle : buy lucy
system couldn't really be abused, and you could have a few vars, like your stage, creds, equipment, and teams.
Loops would be bad, especially for spam.
Events would be very useful, but also abusable, but the conditionals would be great.
Obviously I would prefer bash in the console, but that isnt ever going to happen :(
-
Ah, but what about maps that were never started because of a lack of a scripting system?
If you cannot make a good map because of the abcense of a scripting system, you lack mapping skills and should practice more. A scripting system is only an addition to a map making it even better(or worse), not the basis on which to build a map.
He never said that the person can't make good maps without a scripting system. Just that some maps would be pointless without one, or that some maps could be much better with one.
Note the use of "could" meaning that an average newb probably couldn't, but a skilled mapper could.
-
Seems like we got 2 topics going on at once, one for a mapping scripting language, and one for a client scripting language. Should i split the posts?
-
a simple (Stage==1) ? buy prifle : buy lucy
system couldn't really be abused, and you could have a few vars, like your stage, creds, equipment, and teams.
Loops would be bad, especially for spam.
Events would be very useful, but also abusable, but the conditionals would be great.
Obviously I would prefer bash in the console, but that isnt ever going to happen :(
what about "buy lucy;buy prifle"
at s1 it wont buy anything
at s2 it wont buy luci will buy pulse
at s3 it will buy luci so wont buy pulse
anyway client side scripting is useless you can harcode stuff in to client if you know what you are doing
-
Let's face it guys, we can talk forever about this, but who is actually going to code it?
-
Seems like we got 2 topics going on at once, one for a mapping scripting language, and one for a client scripting language. Should i split the posts?
Depends, Is you job anti-spam or keeping order? if the latter then yes.
-
Let's face it guys, we can talk forever about this, but who is actually going to code it?
Dunno, but anyone interested could chime in here. http://tremulous.net/phpBB2/viewtopic.php?p=49126
-
I prefer shotgun in s1 and lasgun in s2.
How am I going to make a single bind that picks my favorite weapon for the stage I'm in?
-
Let us first try to make some maps that are worthy of coding a scripting system.
True enuf. Pulse is a beautiful map, but WTH is going on in the control room?
Push the buttons for door A and door B - sometimes the buttons turn red or green and sometimes they don't. And where are these doors anyway? The logic on that map, even without a scripting language, is incomprehensible -- I can't imagine why anyone would want to get and enter passwords!