General Thread

by Aardappel on 01/05/2002 01:55, 15527 messages, last message: 03/01/2024 13:02, 11851698 views, last view: 07/05/2024 00:40

for questions, announcements etc.

   Board Index   

#9705: Re: adding dynlights

by hicks on 12/13/2007 22:30, refers to #9704

oops sorry, I meant in the source code. I think a struct would be defined for the players motion. Guessing it's line 78 physent ents.h. "vec o" looks to be it, but where has this struct been created for the player before so I can just grab the coordinates from there.

reply to this message

#9706: Re: adding dynlights

by hicks on 12/13/2007 22:42, refers to #9705

Actually I think I've just found it. Been searching for days. "player->o"

reply to this message

#9707: Re: adding dynlights

by MovingTarget on 12/13/2007 22:53, refers to #9706

Yes, you found it. player->vel is the velocity.

reply to this message

#9708: tape/flare or type/flare?

by demosthenes on 12/14/2007 08:32

Hirato and I were discussing tonight whether the docs have a typo in them regarding type four particles. I think they don't, and that tape/flare is their name, but Hirato is of the opinion that it should be type/flare instead. Could someone who knows (preferably whoever wrote it) clear this up for us?

Thanks in advance.

reply to this message

#9709: Re: tape/flare or type/flare?

by Hirato Kirata on 12/15/2007 00:25, refers to #9709

if it truly is "tape". can you at least point out the most appropriate definition form the dictionary?
I'm just asking as it makes absolutely no sense to me to be 'tape' instead of 'type'.

http://dictionary.reference.com/search?q=tape&x=0&y=0

reply to this message

#9710: Re: tape/flare or type/flare?

by SheeEttin on 12/15/2007 00:31, refers to #9709

#2: A long, narrow strip of paper, metal, etc.

Ever seen a tapeworm?
You don't want to.

reply to this message

#9711: Scriptable monsters

by MovingTarget on 12/15/2007 00:59

Alright guys, how exactly would you guys like to see scriptable monsters implemented? What properties do you think should be modified? Would you like to initialize the whole monster in one function, or just modify single variables? Could you give an example of the syntax of the CubeScript functions and/or variables that you would feel comfortable with? Thanks!

reply to this message

#9712: Re: Scriptable monsters

by Hirato Kirata on 12/15/2007 01:53, refers to #9711

For the idea I have, health, ammunition, and damage are musts. I suspect we can set them the rpg way with r_health r_damage, etc.

as we already have two attributes, for monsters, may I suggest that the third variable link to an entry in the script which sets its strength like so

level_monster_1 = [ r_name "Mr Ogro"; r_weapon 1; r_damage 20; r_speed 110; r_jumpvel 150; r_friendly 1; ignoreff 0; if (= $alive 1) [echo "Hi"]]

r_name sets the monster's name. Like when he's killed, or kills you, the echo message will say you were killed by mr ogro.
r_weapon just sets the ID of the weapon he's equipped with, in this example, he has a shotgun.
We'll pretend the damage is a fixed number, and that speed and jumpvel are percentages.
Friendly will just state if the monster will attack the target on site, or wait for the player to attack him first.
The ignoreff states whether they'll ignore friendly fire.
The $alive just checks if the monster is alive, and executes a script accordingly.

for monsters IDs (var2), if possible can we receive 2 additional commands. providing equal functionality in loading monsters as mapmodelreset and mapmodel and does for mapmodels. Of course with a defaults-monsterlist done already

The paramaters of course could be "loadmonster (Scale) (name) (vweps) (pain sound) (deathsound)". only scale and name ahs to be provided, the others of course will set to sensible defaults. So it can be added to the docs as

loadmonster S N (V P D)


The 4th parameter could be scripts.
waypoint entities will make this so much easier. some vars we can use

level_monsterscript_1 = []
moveto (waypoint ID)
montype (number of level_monster alias)
turn (yaw to turn to) (how long to take)
attack (simple, he fires in the direction he's facing)
move (how long) (if you don't wish to use waypoints, use this)

That's all I could think of from the top of my head.

~Hirato Kirata

reply to this message

#9713: Re: Scriptable monsters

by Hirato Kirata on 12/15/2007 02:01, refers to #9712

sorry for double posting, but another variable that must exist just hit me.

r_respawn (respawns?) (how long to wait before it respawns respawning)

~Hirato Kirata

reply to this message

#9714: Re: Scriptable monsters

by steve_e on 12/15/2007 02:04, refers to #9711

My initial thoughts:

I think in a simplistic way if the monsters could be switched from 'attack' to 'friendly' 'MODE' (0, 1) would be useful with the ability to control all monsters (TYPE -1), a specific monster type (TYPE 0..7), or a specific monster (TYPE 0..7 TRIGGER N).

It would also be cool if there was a TIME option as well so that switching a monster from 'attack' to 'friendly' mode the monster would revert back to attack after N seconds, or -1 if it is permanently stays in it's mode state.

So, we might end up with something like this:
monster TYPE TRIGGER MODE TIME

I could see using this basic control to enable sneaking up on an entire monster TYPE for example if desired with the appropriate trigger set, or turning an attacking monster(s) into a friendly - playing a Jedi mind trick sort of thing to stop the monster(s) from attacking.

Further thought would indicate that something would need to switch the monster MODE automatically from friendly to attack if fired upon.

reply to this message

#9715: ..

by MovingTarget on 12/15/2007 04:53

Thanks for all your great input Hirato Kirata and steve_e! All that info should give me enough to start with, but if you think of anything else, feel free to speak up! Again, thanks for all your thoughts!

reply to this message

#9716: Re: ..

by Hirato Kirata on 12/15/2007 05:45, refers to #9715

I did think of something else. I'm busy making an RPG map for the FPS game module (basically none-linear SP with dialogue :) ).

One of the scripts I'll be writing is that of a shop keeper, selling the player ammunition. So I'd really love to be able to set the player's health, maximum health and ammunition levels in SP matches. Which'll avoid me having to write another horde of scripts that'll open doors sequentiality to sell the the ammo ;).

if anyone is curious on progress. I've so far written the scripts of the bank, and the major, And added quite a bit of ambience with skyboxes which change, and fog which fades. The basically layout of the inventory has been done, and even stats points have been added. And I completed a few scripts for bartering.
It's going to be one hell of a map

~Hirato Kirata

reply to this message

#9717: Re: ..9571

by steve_e on 12/15/2007 06:49, refers to #9716

I too would love to have control of health and ammo/weapons. A player without ammo and low health would need to tread carefully around monsters which in turn would create the need to control the monster(s) behaviour with a pickup of some description.

Also, during low fog levels (i.e., as the player you can't see squat) the monsters tend to still see you, so another reason for the control of the monster behaviour - player picks up a 'fog spell' and casts it so the monsters can't see him, hence they do not attack.

The idea of controlling monsters and player health/ammo creates all kinds of exciting possibilities!

reply to this message

#9718: Scriptable monsters

by Sascha@e on 12/15/2007 13:36

Scriptable monsters (in RPG mode) is in my TODO list, too. I'm currently aiming for the "fully script-controlled" way, i.e. have a script (per AI object) that is executed periodically to determine what to do, essentially rpgent::update() as a script, but called less often, with some basic reactions (like stopping moving when dead) hardcoded.
Calling the script and setting some basic actions (attack, turn, move, ...) is quite easy. The hard part is how to determine what to do. Currently, there's no way to query other objects in the world. Even the current (very simple) behaviour could not be done with a script (cannot determine if player is in range).
I've written an r_inrange function that loops over all rpgobj's within a given range. Each object (that's in range) is put on top of the stack and a script supplied to the function gets executed. I'm not yet sure this is the right way to do it, but that's mostly because I didn't quite get my head around the RPG stack idea yet. E.g., how do I change the players model from within an NPC script?
Another possible problem (with my approach) is performance. I know next to nothing about CubeScript execution times. Depending on that, even a small number of NPCs with moderately complex scripts could slow down the game considerably. I don't even know exactly what happens if a (single) script takes a long time to execute. Would it be "jerking" (i.e. stopping for a small amount of time periodically) or does Cube use some kind of multitasking?

reply to this message

#9719: ..

by Zodar on 12/15/2007 15:18

The ability to manipulate the statistics of monsters a bit more in-depth would be fantastic. Currently, there isn't a single monster in the game that's actually dangerous- the only danger comes from how many of them you have to face. But this could be pretty easily remedied if you could alter the HP, damage, and most importantly, rate of fire of a bauul, for example.

Another thing that would be interesting is the ability to tag a monster as being on a certain "side". This would be a simple number tag, but it would add a great deal of variety to a map. The player's side would be set (and locked, to prevent cheating with the console) by the map's cfg, and any enemies that are on the same side are non-hostile towards him. Untagged enemies are marked as side 0, which behaves like any other tag- they attack non-zero enemies. This could cause a little trouble with priority, but "prioritize the one who shot you last" seems to be pretty workable.

reply to this message

#9720: Re: ..

by Hirato Kirata on 12/15/2007 22:55, refers to #9719

Teams... why didn't I think of that. (actually I did, which is where my suggestion of ignoring friendly fire came in :) ). Nice one there Zodar.

~Hirato Kirata

reply to this message

#9721: Re: ..

by Zodar on 12/16/2007 00:23, refers to #9720

Sorry if I misconstrued your post, but it seemed like you were talking about monsters either being friendly/hostile to the player character. What I meant was the ability to have a larger number of sides, as determined by a number in the monster-ent's variables.

For example, say you have a group of ogros on one team attacking you. To deal with them without wasting time or ammo, you could lead them into a group of opposing rhinos or goblins, who would normally attack you, but instead prioritize the ogros as the main target. You watch safely on the sidelines, then open a door and release a pack of hellpigs to finish off the stragglers. It's a bit different from simply hostile or friendly- the monsters would have their own personal feuds to settle that you could play to your advantage, like how Bullsquids would always attack headcrabs in Half-Life.

Sorry if there was any misunderstanding, or if I came off as rude :I

reply to this message

#9722: Re: ..

by Hirato Kirata on 12/16/2007 01:06, refers to #9721

I was saying well done for elaborating on the teams. I'm just a bit hard to understand at times :P

~Hirato K

reply to this message

#9723: Re: ..

by Quin on 12/16/2007 05:12, refers to #9689

sensitivity 10
sensitivityscale 1

Not saying you "need" it that high (in fact, it's that high from my old quake days), just that it is possible to turn that fast if one wished (contradictory to real life).

reply to this message

#9724: ..

by JadeMatrix on 12/17/2007 01:20

O.o the posts on the AI-scripts is making me dizzy...

http://files.filefront.com/aicfg/;9269379;/fileinfo.html

My take. It uses f_life (a read-only variable) from my hud.cfg concept.

reply to this message

   Board Index