Welcome to the Second Life Forums Archive

These forums are CLOSED. Please visit the new forums HERE

Noob building a combat system and my head hurts....

Klaatu Quintus
I Market, Build & Script
Join date: 1 Aug 2006
Posts: 23
10-19-2006 12:29
I'm working on creating a little combat system for a proprietary shootout scenario; I don't have many $L and this is also an exercise intended to bring my scripting skills up from about a 2 level (on a scale from 1-10) to where I can hold myself out as a legitimate scripter for hire. I have RL coding xp, so it's about converting my knowledge to the quirks...er, opportunities of LSL.

I have been surfing the forum for hours now trying to piece together everything I need to do :-( Being a relative scripting noob, my head hurts now after reading about everything...guns, bullets, scanners...so I thought I'd cast my fate to the winds and let the ether come to my aide by asking for some advice from all of you. So, here goes:

1. Is there a tutorial(s) I can read or class(es) to take that will save me some time experimenting? (Fushichou Mfume's post at /165/3e/59177/1.html helped a bunch :-)

2. Anyone have some freebie scripts to get me started? I prefer to stand on the shoulders of giants...such as Ordinal Malaprop's targeting script at /54/89/138719/2.html . (see, I have been doing some homework :-)

3. Any sage advice from those who have just traversed this curve?

Any and all help will be deeply appreciated and remembered.

TIA,

Klaatu
Ordinal Malaprop
really very ordinary
Join date: 9 Sep 2005
Posts: 4,607
10-19-2006 13:24
Oh, well, thank you, though I'm really not much of a giant, believe me.

Certainly I've been thinking about an open-source combat system that should allow anyone to set up their own "circuit" as it were, by simply setting a channel and a password, or using public ones. I hope to have this done quite soon. I am also thinking at some point of starting courses, in UK time admittedly. But otherwise, well, if you would like to ask any questions on specific topics or even broad ones, I'm sure that myself and other contributors here would be happy to advise - everyone here is very helpful.
_____________________
http://ordinalmalaprop.com/forum/ - visit Ordinal's Scripting Colloquium for scripting discussion with actual working BBCode!

http://ordinalmalaprop.com/engine/ - An Engine Fit For My Proceeding, my Aethernet Journal

http://www.flickr.com/groups/slgriefbuild/ - Second Life Griefbuild Digest, pictures of horrible ad griefing and land spam, and the naming of names
Lee Ponzu
What Would Steve Do?
Join date: 28 Jun 2006
Posts: 1,770
Advice from a 3 to a 1
10-19-2006 14:38
Thre are a few courses, look in Search. There are tutorials. Search the web.

however, none of them are great or exhaustive. You just have to keep working and learning. One thing that might help is to get one of the Editor setups that do LSL syntax checking locally. This means you can write bigger pieces of code and cut and paste them into SL and know they have a good chance of compiling.

This can be much faster, and you can work when you cannot get in SL, such as ... well, we won't go there 9-)
Dimentox Travanti
DCS Coder
Join date: 10 Sep 2006
Posts: 228
10-20-2006 06:16
HInts,
the actual system. use collision not sensors,
for melee weapons, bind the keys with passthrough and fire off a sensor when they attack, if someoes close send a message to a chan saying /44 hit name and have the system on their side register damage.

That should allow for any wep to work with the system.
_____________________
LSL Scripting Database - http://lsl.dimentox.com
Lazarus Wake
Registered User
Join date: 9 Jan 2006
Posts: 33
10-20-2006 10:54
The first thing I would do is try to roughly lay out in your head what you want the system to do. Not necessarily the specifics of how it works but simply how it will play.

Probably the biggest question you will have to answer on this front is whether you want the system to work with the majority of weapons already coded. This has pretty big pluses and minuses. On the plus side there are a ton of weapons already out there. On the minus side, you've got no control over the weapons being used and it doesn't take too much scripting to make a weapon that can fire off thousands of rounds a minute and that never reloads, so you can count on people making/buying unbalanced weapons.

Restricting the weapons also frees you up to code things more efficiently. The move keys/sensor/broadcast trick is a good way to allow existing melee weapons to work in a new combat system but I suspect that melee weapons that fire an invisible 'bullet' that only travels a meter or so before derezzing will be more efficient. Likewise the bullets from guns could carry information such as 'burst' or 'shotgun' that would let you rez fewer bullets and simply use particles to create the visual effect. Of course the downside to this is now you have to build and code all the weapons.
Dimentox Travanti
DCS Coder
Join date: 10 Sep 2006
Posts: 228
10-20-2006 13:05
You could do what i am doing some guns have a signature for the bullets they res, I am attepting to detect signatures to ban certain guns from the system. Like Sebs.

The main point of the system i am creating is not the guns and melee its the special racial abilities etc.
Any one can go buy a rcs.. What makes your system diff?
_____________________
LSL Scripting Database - http://lsl.dimentox.com
Klaatu Quintus
I Market, Build & Script
Join date: 1 Aug 2006
Posts: 23
Excellent input so far
10-20-2006 14:44
All,

Great stuff so far!

Too modest Ordinal; keep me posted on your course. If you take more than a few weeks to get that together I'll likely be qualified to help teach it rather than consume it! (Yes, I'm an optimist :-)

Lee, will do....

Dimentox, your first message is a bit cryptic ATM, but I'm sure it will make sense when I get down to coding things.

Spot on Lazarus; having some prior coding xp, I have started with a design document, now a full 7 pages long, that calls out all of the components and what they each do. This also ensures that any buds who help me know their bit.

To give back a little of what you all are so graciously giving me, here is the outline:

Release History: This section helps everyone to know which bits were touched since the last release of the document.

Definitions and Abbreviations: Ensuring that we all have a common understanding of what's being described. (I've fallen on this sword before :-0)

Rules: Describing the boundaries of the game play including timeline of events, players, scoring and the like. This is a match play model.

Registration: Defines the behavior of the object used for players to queue for play

Scheduler: This object manages the player queue and tracks if players remain available for their slot and adjusts the queue accordingly. This object tps the players to the battlefield.

Battlefield Controller: The player info is passed to this object when the players are tped to the field of play. This object acts as the referee during the match, tracking hits, kills and other scoring events.

Player Items: This section contains subsections for armor, weapons, and munitions. It defines the damage algorithm used for scoring describing how each player item impacts the scoring. The subsections detail the behaviors of items in that class to include limits and communication requirements with the Battlefield Controller object.

So, as you can surmise, I'm taking the custom weapons approach. This avoids the arms race and folks bringing in uber weapons, preserving the value of player skill. In order to score points, or even enter the field of battle for that matter, you'll have to be using integrated components.

To create a variety of items, enhancing the visual experience of the game, we will establish a system whereby the great armament builders can load our play script into their cool weapons and armor. I'll need to figure out some form of control on this front as we want to make a few $L on selling the scripts. (sage advice sought here :-)

Thank you all again, and for those just reading along; pipe up and get involved!
Lazarus Wake
Registered User
Join date: 9 Jan 2006
Posts: 33
10-23-2006 12:05
Since you are going the route of custom weapons I would probably experiment along the line of having all weapons emit a 'bullet' with a very quick lldie() event to keep the melee weapons from reaching too far. The bullets then transmit whatever information your system needs when they detect a collision with a player object.

An advantage of this system is that it should prove possible to make No Mod bullets that you can sell to other people who wish to make weapons for your system. This would give you some control over the weapons other people make since if you detect anyone making an unbalancing weapon you could invalidate the bullets that they use.

I need to note that I haven't done either of these things myself, yet. There may be some issues with timing with the lldie() command that makes extremely short range bullets problematic (though I believe Combat Samurai Island uses such a scheme) and I'm still trying to lay out in my head the specifics for a way to check bullets for validity without using too many extra cycles, but I'm pretty sure that can be done.