Update: For M3 I'll be adding support for global lists so you don't have to re-write so many of the same lists of items/entities that you may want to use across several different areas. They'll support an unlimited number of user-defined identifiers, for ease of recognition/use.
I may also add better control for list-contained entities, including inventory items and AI overrides.
Hm, i might be blind, but i can't find the way to spawn a weapon without ammo (so to use it, you would have to find the ammo first).
For explanation: [CUBE_ADD](2,2,3)(2,5,3) [ITEM_ADD]"Scroll: \"MIGHY Meteor\" [SPAWN_ITEMS]1 [OVERLAP]0 [REMOVE]0
That spell uses ingredients (read: ammo). The interesting part is, that the Scroll is found in the tower of that firemage (and you have to be quick about retriving it before the tower burns down in a way you can't reach it anymore *evilgrin*), but the 'burned earth' you need is found at a burned mill which is another 1X1 building not even on the same map every time (working as intended!)
No, you're right, I didn't add any way to spawn items without ammo.
That's a clever way to do spell components, but there's a more flexible and perhaps more "realistic" way through the special abilities system:
You can make the scroll a usable item by giving it an ability with the USE_ON_CELL trigger (so it'll be activated by 'u'), and put a special E_HELD_ITEM_CONSUME condition on the trigger. I just added this in the last version and I believe there's one example included in the last release, though it's for an entity ability and not a usable item--they work the same way. That condition will require that the entity be *holding* a certain item in either hand in order to use the ability, and will consume (destroy) the item once it's used. Similarly, there's an E_HELD_ITEM condition which will instead just require that the entity be holding the item, and not consume it (more like a magic focus).
I've got an expansive spellcasting system that includes components for some spells, which you'll be able to see in my mod. (I'll probably pre-release on the forum so you guys can check it out and test it, too, but I still need more time on it.)
Here's an example implementation of a spell that consumes a component: S_Gate "Gate" CAST_ON_CELL E_HELD_ITEM_CONSUME=="Ritual Candle" SELECT=1|TU_TYPE=PERCENT|TU_COST=90|EN_COST=60|METHOD=REFLEX DEFAULT DEFAULT "[name] chants over [poss] Ritual Candle." SPAWN_PROP - PROP="Abyssal Gate"|NUMBER=1|AIR_SPAWN=0|PARTICLE=Pandora_Mist_E DEFAULT DEFAULT "A Gate to an abyssal plane is opened." You could substitute CAST_ON_CELL for USE_ON_CELL to make it an item ability.
Sort of. I don't think there's a way you could have the scroll both require a component and offer another effect that *doesn't* require a component in the same menu, due to how the component checking works.
It is, however, possible to have it tell you you need a component if you don't have one, and describe what the scroll is supposed to do, or instead (assuming you have the component) use the scroll. This would be done with two separate abilities, each using the SELECT=0 data on the trigger (which is the default for that value, actually). If the normal casting ability is listed first, it would skip it if the condition is not met and use another ability instead which could be free of cost and just tell the player they're missing a required component. I don't have any specific examples of this off hand yet, since I'm not doing this in particular (not using any items that require components themselves)--instead I have my spellbooks (from which you learn spells) describe the required components so I don't have to re-state it when trying to cast the spell, as the user should already know they need a component. I maybe should add in another reminder message later, if I have time.
Post by strangeguy on Dec 30, 2012 19:58:47 GMT -5
When I realized you could use item lists for locations other than the right hand by looking at the police station spawning I was excited, until I realised the only place I really wanted to use it is for enemies wielding pistols in one hand and melee weapons in the other so I can randomise both weapons but since each [ITEM]
The spawning scripts are not exactly done how I would prefer since most every feature was initially added because it was used/needed for Cataclysm, and after that I just started tacking on more. (Issue: It wasn't designed from the ground up.) So while it's gotten a bit messier in R8.3, there are now more ways to do each thing, including a way to do what you're asking.
I should add that it's currently possible to do what you want in R8.2, though the solution may be less than ideal (in this case): You can create a list of entities, all identical except for their equipment variations, and spawn one randomly.
Not pretty, but it works. There are a lot of solutions to be found that can be labeled "not pretty, but it works", many of which I haven't used myself, or hadn't at the time Cataclysm was converted to a mod. Besides global lists there will be other new features in 8.3 that help with randomization, like conditional statements.
F=0195845 | | cataclysmScriptSpawnProp() | data-Farm/maps/cataclysm_spawning.xt contains unrecognized script command in line 113: "[POS]"
spawning.xt: [PROP]SPAWNPOINT_LEADER [POS](9,2,2)
Ok, made a test with 'A Rookie's Tale' and yes: No POS with PROPS.
Have to use [CUBE](9,2,2)(9,2,2).
I had a look in what I'd done in my mods because I knew I'd placed props in specific positions, when I realised why this is. If you are placing a prop somewhere specific you are meant to do so in blueprints. Still it might be worth adding the option, even if it isn't really needed.
I didn't originally add [POS] for props because that's essentially what blueprints are for, but if you have a huge mod and/or special props that you really only need one or two of on the whole map, those can be done through scripting to save on map keys.
I started to use scripting to spawn static props myself a lot later, too, especially for Rookie's Tale, but never went back to add that command since it wasn't too much of an issue to just use [CUBE] and copy the coordinates (you'll notice I still have some of those even in Ground Zero). The main reason for not adding it is it would require a whole new function to handle, and I'd have to copy and test a bunch of code, ideally integrating it with [CUBE] blah blah blah. Didn't seem like it would be worth it since later on the stupid "map key" system will be removed entirely--no more scripting necessary to add objects.
I've been tweaking the roadmap and it looks like the map editor could be only a couple major features away from implementation: first UI upgrades, then data overhaul and/or map editor.
Like in this example i made the cube in the red border as i thought the prop would be moved to the free cells, if it can't be placed. I think i'll simply reduce it to the green border, or even to a pos-like position as the alien will move around anyway.
[...] but if you have a huge mod and/or special props that you really only need one or two of[...]
It isn't a special one, i only need one or two of. It is a whole bunch of. One for each type of alien (navigator,leader,... except soldier) one for each UFO (soldiers to spawn around the map.) and one for each UFO to get the spawn started. The sheer amount and the fact, that they are invisible and get destroyed at the start of the mission would simply remove too much mapkeys for things that will never be seen in the game.
Ah, was just trying to guess at what you were doing.
The red square/cube you're using should be fine, since the game will attempt to find an empty position in that cube. However, it currently uses the all-too-simple method of simply generating random points and checking them, so if you are really unlucky then all the generated points will already have other props and it will eventually give up (I forget what I set the limit to, but it will check at least 10 times, maybe more).
Thus your prop should be successfully placed most of the time, unless you are generating a whole ton of props in there, in which case most of the cells are already full and you don't have much room left anyway. Try generating multiple times and you should see that it won't always fail.
The proper way to do this on my side would be to actually gather all *available* random positions and pick one of those, but I didn't implement that yet.