I think the maximum key length is a quake map is 1024 chars, so your scripts can't become giant.

Also: wow, this is pretty cool. Not sure if it makes sense to add another scripting language to quake (since quakec is effectively a scripting language) but short of adding a quakec interpreter or something, this is a good alternative. 

i actually thought it was 128.. i sometimes break that with the 'wad' field in worldspawn (as it lists all the wads i have in worldcraft including paths) and have to take some unused wads out or merge a couple of them. i even moved them all to c:\t\ and gave them all really short names to help prevent it.

maybe it was only like that with an old engine/compiler? can't remember if it was a quake or qbsp error now..

this sounds interesting anyway, not sure what the 'surprise' is but look forward to it :) 

some compilers had smaller limits i think, but the official max is 1024 if i recall correctly.

maybe i should investigate this... 

Yeah, the limit from the engine is 1024 although I'm pretty sure that's only limited by the buffer size in the tokeniser. I did mean to mention that but it slipped my mind.

I have been thinking about whether this is the best way to produce scripts. There would be advantages to reading them from an external file too - it's easier to edit them on the fly than recompiling a map, and easier to read them there too. It seems a bit crazy to be including a new file every time you need a one-line script, so maybe both are needed. 

It seems a bit crazy to be including a new file every time you need a one-line script, so maybe both are needed.

could just have one file per bsp, and define all the functions you want in that file. Then, the entity can be set up with "touch" "myfunction"

Or, you could just search all files in a given directory for the named function, leaving the developer to decide how many script files he wants to maintain. (one huge vs. many small) 

I think I'd prefer to not search all files, to avoid the risk of collisions. Once you have this kind of scripting mappers don't need to create whole new mods for small tweaks. You lose a bit of the benefit of that if people need to keep their maps in separate folders to avoid interference.

Code reuse isn't high priority for scripting anyway, so it's fair to make people cut and paste for new maps. It would be easiest if the on-script-file's scripts were all just made named functions in the JS "context". That way you'd set them with "touch" "myfunction()" - defining an anonymous function which calls "myfunction". That sounds a bit convoluted, but it leaves the name resolution up to the JS engine, rather than having to hack it into the QC recognition. It would also leave the option for short scripts to be embedded into the map, which I think is cute at least.

Also, for the foolhardy who want longer scripts now: use the eval() function on unused string fields on your entity, concatenated together! What could go wrong? 

this is wild! o.o

but definitely put the scripts in an external file (preferably like idtech4 with a mapname.script file or something simple like that), then simply putting the script function's name into whatever function slot you want on your entity. no way would i type a complex script into an entity field. 

 

Take a look at preach's wad line in his js01.bsp 

looks like hammer has it's own limit on max key field characters? 

Yeah, it's just a pain to keep removing and adding them in hammer - especially since you need to restart before they're actually removed.

To add some useful content, I thought I'd explain a bit more about JS Objects, how they relate to entities in this engine, and type-safety stuff.

One of the key differences between Javascript and QuakeC is that Javascript is dynamically typed. This means that if you declare a variable like heal_count, you don't declare what kind of data it can hold. If you assign a Number to it then you can use it in calculations. Later on you could assign a String to heal_count, and this would not cause an error. If a function is expecting a particular kind of data and receives another one, then it may try to coerce the data, for example automatically converting a Number into a String.

There is a potential problem here. What if we start assigning the wrong types in the JS context to variables that QC (or worse the engine itself) will need to read? This would be bad, so we prevent it. Whenever you attempt to get or set a variable in JS which was imported from QC, a special c++(*) function handles the conversion, and does not modify the underlying variable if the conversion fails. Similarly, all world fields are read only, in the same way that they are in QC - although here the failure is silent rather than game-ending. I am hoping to add JS exceptions for these conditions in the future.

The same kind of protection is afforded to entities themselves. Although every QC entity is represented by a corresponding JS Object, this doesn't mean that every JS Object has a matching entity created. In fact, you would need to use the standard QC builtin to create a new entity (except that I haven't coded functions yet). This does mean that you are free to create new Objects in JS if it will help your script - did I mention that JS supports arrays and maps?

Since the entities are Objects, you can also add new fields to them. The example map actually demonstrates this - heal_count is not an unused QC value but an entirely new field. JS does not add these properties globally to all Objects or even all entities. Instead heal_count is only found on this one entity. Of course, you cannot access these new fields from QC.


*Yes, the interface to the V8 engine is written in c++, adding a 4th language to the equation. Not for the faint-hearted...