General Thread

by Aardappel on 01/05/2002 01:55, 15527 messages, last message: 03/01/2024 13:02, 12566917 views, last view: 11/08/2024 09:38

for questions, announcements etc.

   Board Index   

#9699: try this :

by rock.n.rol_ on 12/13/2007 06:47

http://www.cubeengine.com/forum.php4?action=display_thread&thread_id=1516

reply to this message

#9700: Re: try this :

by rock.n.rol_ on 12/13/2007 06:49, refers to #9699

Dammit, my post #9733 was meant as repy to #9731, sry for confusing ;)

reply to this message

#9701: Re: try this - or 'a little help please' :

by steve_e on 12/13/2007 10:25, refers to #9700

Which is this link here:
http://www.cubeengine.com/forum.php4?action=display_thread&thread_id=1516

reply to this message

#9702: Re: try this - or 'a little help please' :

by rock.n.rol_ on 12/13/2007 19:41, refers to #9701

Vista showed a side-by-side configuration error with sauerbraten, when sauer didn't run on vista. In this thread, eihrul explained what to do to make it run.

reply to this message

#9703: adding dynlights

by hicks on 12/13/2007 22:16

I've been trying to add a dynamic light around the player, but I can't find the vector that stores the player's coordinates.

Sorry to be a burden :(
It's probably in the most obvious place...

reply to this message

#9704: Re: adding dynlights

by MovingTarget on 12/13/2007 22:26, refers to #9703

There is no cubescript variable that stores the player's position, at least not that I know of.

reply to this message

#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

   Board Index