[WMCoolmon]

Or just have a spherical goal.

Edit: Actually, I could probably code an is-within-box SEXP.

Code: [Select]

is-within-box
-- object to check
-- top front right x
-- top front right y
-- top front right z
-- bottom back left x
-- bottom back left y
-- bottom back right z
Or:

Code: [Select]

is-within-box
--object
-- center x
-- center y
-- center z
-- box width
-- box height
-- box depth
It'd require a fraction of the work needed for it with SEXPs and would be much faster too.

[karajorma]

Or just have a spherical goal.

Far too easy I'd already thought of that and dismissed it as not challenging enough The SEXP would be nice though

[WMCoolmon]

SEXP is in CVS. I changed it a bit:

Code: [Select]

num-within-box
-- box center X
-- box center y
-- box center z
-- width
-- height
-- depth
-- ship or wing
-- ...
Note that if a wing is specified, it will only count as _one_ object for the count. So specifying "Alpha" and "Galatea" would give you 2, assuming everyone in the wing and Galatea were in the box.

[Sypher]

The is-within-box returns a boolean right?

Well if the goal would be a Ganymede, it could be spherical as well...

[karajorma]

It would be kinda pointless to do it with a sphere since you can just use a waypoint in the centre of the sphere. Unless WMC fanices giving us a is-distance-from location SEXP too. I'm sure I'd eventually find a use for it that wasn't just elimination of an unneeded waypoint

BTW I suppose I should point out that I like the first version of the proposed SEXP as by the look of it that allows non-rectangular boxes.

[Sypher]

Edit: Sorry misunderstood your post ...

// You know that there is a distance SEXP, but you need to use comparing operators (<, >, =) with it (well rather logical considering that it gives a integer...), when done in an event it returns a kind of sphere region (gonna try and mess with the proposed SEXPs, though, a rectangular goal would be way easier)...

Anyways, I will try to get a first playable version up by today or tommorow.

[WMCoolmon]

It would be kinda pointless to do it with a sphere since you can just use a waypoint in the centre of the sphere. Unless WMC fanices giving us a is-distance-from location SEXP too. I'm sure I'd eventually find a use for it that wasn't just elimination of an unneeded waypoint

BTW I suppose I should point out that I like the first version of the proposed SEXP as by the look of it that allows non-rectangular boxes.

Ehh, you should be able to do the same things with one that you could do with the other. Either way, all angles would be assumed to be 90 degrees. Basically if you want to convert: width = (top_front_right - bottom_back_left)/2, center_x = (top_front_right - (top_front_right - bottom_back_left)/2) and so on for the other two dimensions.

However it makes it harder to calculate because you'd have to throw in checks for if someone swapped sides, as 'left' 'right' and such are all relative.

[karajorma]

Oh. I see. I made a mistake reading the post

Yeah the second one is better

[CaptJosh]

I can think of a use for such a sexp already.

"Hold fire until you are within range X of the targets. Even if they're already shooting at you. I repeat, hold fire until range X!"

[karajorma]

You can use Distance for that though surely.

The only case I can think of for needing a spherical SEXP would be if you had something like a mission where you had to be within a certain range of the front of a moving vessel. In That case you couldn't simply use distance from a subsystem because that would still be true if you were behind the ship. Using the SEXP you could work out where the front was and then check if someone was say 1000m in front of it.

It's a bit of a stretch though.

[Flipside]

I remember the thread about doing a soccer game from ages ago, I still think that'd be fun, especially considering how deadly tackling would be

[Foxer]

More multiplayer features that I wish to see (and not mention in my previous post in this topic) is able to record 'demo' / 'replay' from the game, and play it anytime you want. Just like it is in Doom / Quake series and many other games. It can't be hard to do this (n00b programist think ).

Another (which is mentioned by Karajorma yet) is to improve variables in game, that clients can get modified values as good as host do now. I play Karajorma's King of the Hill and it was very good and fun (my feedback is here @ GW). Some code-work on variables can improve such ideas like KotH much.

Third for now: is to improve standalone application. Make it just a little bit more stable and add advance options like for example: DaBrain's idea about 24h in-game join server and more ...

[karajorma]

I think recording demos/replay might prove quite hard if the hooks to record everything aren't already in place in the code. (PS don't say something is easy if you don't want to be told to do it yourself )

The problem with getting variables fixed for multiplayer is that there is a very real chance that trying to get variable changes to update the clients could actually break multiplayer. We won't know till someone tries though.

As for DaBrain's 24h server I think I've already made clear I've got some very big plans for such a beast

[taylor]

I think recording demos/replay might prove quite hard if the hooks to record everything aren't already in place in the code. (PS don't say something is easy if you don't want to be told to do it yourself )

There are hooks already actually, they just aren't complete or optimized in any way.  I had at one time cleaned up the demo recording/playback code in order to do large and complex runs through a memory debugger but I no longer have that modified code.  And the demo save files were quite large, upwards of 35meg per mission, so it would need a lot of work to be generally usable.

The problem with getting variables fixed for multiplayer is that there is a very real chance that trying to get variable changes to update the clients could actually break multiplayer. We won't know till someone tries though.

Goober asked me about this not too long ago.  It's easily possible to do it without breaking old clients, however those old clients would ignore the variable changes.  Adding it wouldn't be difficult (at least for me since I know pretty much what to do) so I'll probably end up making the changes for this before too long, I just need the time.  I gave Goober the simplified rundown down on adding it though so he may decide to brave the multi code and add the changes himself before I get the chance.

[karajorma]

Excellent

It's not really a problem if older clients ignore the variable updates for now. I can just warn everyone to have a recent build and I've designed the missions I've made so that the default value for any string variable is something which is at least readable