Map Scripting

I've had this idea for a while, but haven't had a good example of why its needed until recently, when Zebus made his camera.

My thought is that Warsow could load map-specific AS the way it loads gametype-specific AS. To differentiate them, I propose the directory basewsw/progs/maps, under which would be placed .ms/.md/whatever other file extension we decide on. This would function as a .gt file does for gametypes, and would be named after the map using it.

The result is that maps would be able to load specific AS classes for use within the map. Zebus' cameras and more robust elevators are simply the beginning. You could also theoretically set up news tickers which read text from a file; you could even have something change that file realtime perhaps, allowing live data to be streamed in maps.

The potential downsides are that AS entities aren't antilagged, possible performance issues with many entities, and that people could override a map's entities if they really wanted to.

To address the first, even current elevators aren't antilagged, and that hasn't caused any major problems yet. Second, performance should only be considered secondary at this point; the potential gain outweighs it. Third, though someone COULD theoretically override a map's entities, replacing cameras with turrets, or disabling elevators, this can only be done serverside, which mitigates the downsides.

This is only the beginning. Please, O Great Community, help me devise more amazing environmental entities; for truly I tell you, should this come to be, not even the sky shall be OUR limit!

The biggest problem I see with this is it would be hard to make this pure.

I'm not sure I really see the problem tbh; the scripts are only ever loaded by the server. You'd only have to worry about particular servers messing with things, and even then it'd mostly just be cool.

There's more to this than the things I mentioned @ IRC.

However, we've talked about this with Vic, but can't promise anything quite yet.

Entity scripting itself isn't hard to implement. There is a conflict with how gametype scripts are loaded, tho, and it is that entity scripting requires entities readed before the scripts, and gametype scripting requires scripts readed before the entities because the gametype scripts can define map entities. This isn't a minor issue, it's a serious conflict.

Hmm, that makes sense. The way I'm looking at it is to load the map script just before the things declared in any given .gt, in the same way, but considering my lack of knowledge about the engine itself, my ideas may be disjointed from feasibility.

jal wrote:
Entity scripting itself isn't hard to implement. There is a conflict with how gametype scripts are loaded, tho, and it is that entity scripting requires entities readed before the scripts, and gametype scripting requires scripts readed before the entities because the gametype scripts can define map entities. This isn't a minor issue, it's a serious conflict.

What we talked about Vic was to allow _completely isolated_ separated scripts for maps which could not be loaded from GT scripts.

And to add:

There's also problem of this making a pretty hard deadlock for our AS API, right now making changes is pretty minor problem as we maintain our gametypes, and there's just handful of popular community gt scripts - but if this would spread out to maps, then it would become a maintainance nightmare.

But I'm still in favor of it, it would really bring to our engine/map capabilities to whole new level (for projects outside Warsow :))

this idea sounds good on paper but i dont think it will have much use and people dont find it that cool in game

Neither does having nice texturing and lighting... Don't be stupid.

crizis wrote:

jal wrote:
Entity scripting itself isn't hard to implement. There is a conflict with how gametype scripts are loaded, tho, and it is that entity scripting requires entities readed before the scripts, and gametype scripting requires scripts readed before the entities because the gametype scripts can define map entities. This isn't a minor issue, it's a serious conflict.

What we talked about Vic was to allow _completely isolated_ separated scripts for maps which could not be loaded from GT scripts.

Ye but you have to run it in a second AS engine which is pretty much the same thing but repeated. I obviously didn't meant it couldn't be done, but that conflicts make it much more work than it should be.

Obviously the map scripts would be limited to avoid conflicts with GT scripts if run in the same engine. Just basic entity spawn functions for custom classnames + 1 global function for initialization with some fixed-name, I think.

most stuff seems to be hardcoded with only one engine instance in mind..

Just committed this:

A hacky implementation of map scripts. AngelScripts are loaded from "progs/maps/mapname.mp" project files, containing the list of includes (GT scripts are loaded in the same way). Each map can implement spawn functions for custom entities and 4 hooks with hardcoded names:
- void MAP_Init() for map initialization
- void Map_Exit() for map shutdown
- void Map_PreThink() - function which will be called before any world entity has had its think function called and physics run for this frame
- void Map_PosTthink() - function which will be called after all world entities have had their think functions called and physics run for this frame

Note that the implementation is somewhat hacky due to angelwrap API limitations and may not work correctly in 100% cases.
(updated 2012-09-17 21:14:49)

I am incredibly happy right now :D