Event Spawns
Crudedragos opened this issue ยท 7 comments
As opposed to the traditional passive spawns. Some form of implementation to spawn entities on some event, death/crop break/block break/storm.
i.e. Tree ent spawning as log is broken
Implementation uncertain. Folder directory / File containing user written script(s) that return an entity string.
crop break / on player death / tree break
On the topic of combining "origin" with "modspawn", I've had no luck with the Lycanite's Phantom.
There could be a number of reasons why it's not working. My guesses are:
- it being due to the fact that Phantoms by default have 3 spawn conditions. They may spawn from an event (either DEATH or SLEEP) and they may spawn passively as a normal MONSTER in the End.
from the relevant Lycanite's config, shadowmobs-spwning.cfg
"spawn types" {
S:"Epion Spawn Types"=MONSTER, LUNAR
S:"Grue Spawn Types"=SHADOW, MONSTER
S:"Phantom Spawn Types"=DEATH, SLEEP, MONSTER
} - if I disable the event spawners for DEATH and SLEEP in the Lycanite's config, then the tag "modspawn" is essentially rendered useless, right? Yet if I leave the event spawners enabled, the Phantom will continue to be spawned by Lycanites without regard for the JAS restriction. Only the Phantoms spawned by JAS could possibly have their spawns restricted, yet those spawns would be in addition to the Lycanites spawns - defeating the original goal of stopping the Phantom from spawning within 2000 blocks from spawn.
As per your comment above, the only solution (if it is possible/feasible/wanted) would be to mimic the event spawns by use of tags. The utility of this would be welcomed not just by Lycanite's users, but also by those who wish to spawn other entities on events such as on crop break, on tree break, on entity death (I'm not sure what the event is for that but the Phantom spawns when player kills an entity - whether that entity is a cow or a zombie.)
You have summed up the current situation appropriately.
Still not sure how to add the events that users can use to spawn entities. I was thinking of attaching them to CreatureType, but it really doesn't make sense to attach it to any of the traditional objects. As they are relate to passive spawns (chunk spawing excluded, technically an event but will always need special treatment as it needs to be imported from vanilla).
If attached to CreatureType/LivingHandler/SpawnListEntry would each method only be called if that Entity died? What if you wanted to spawn a Phantom if a Chicken was killed by Fire. If all of them are called anyway, one single file is just as useful.
Further, What is each file acting on? The CreatureType/LivingHandler/SpawnListEntry is available from the Single-File solution as well from individual.
Realistically, methods are likely to be block IF-ELSE statements that iterate over the collection of nearby entities.
i.e.
IF(killed.IsPlayer() && !origin(0,2000)) {
return SpawnEntity('Phantom')
} ELSE IF(killed.isEntity('Berserker')){
// Search for nearby(distance<30) berserkers to enrage/heal/frighten
nearbyBerserkers = $ in (nearby() if ($.distance(killed) < 30 && ))
foreach(entity : nearbyBerserkers ) {
// Unsure what level of access could be given to entity
entity.setHealth(entity.getMaxHealth());
}
}
These could be split out, but spreading them out doesn't seem useful. They don't relate to anything but eachother.
All livinghandlers are with eachother, all spawnlistentries are with eachother. Each of the OnDeath conditions might as well be with eachother.
hmm. There would have to be room for percentage chance as well. It seems to me to be a lot like how a mod configures an entity's special drops. Instead of dropping a potato, ghast tear, etc, it's dropping an entity (such as a phantom). How on earth to use JAS restrictions with that sort of system, though..?
Re your last paragraph, I'm not sure if I understand rightly, would that mean a separate file for Events? Events could be defined and named in there, then called and restricted within the livinghandler? Or entirely within a file such as EventsHandler.cfg?
I tried telling Lycanite to get over here but he's without internet until the 22nd.
Re your last paragraph, I'm not sure if I understand rightly, would that mean a separate file for Events? Events could be defined and named in there, then called and restricted within the livinghandler? Or entirely within a file such as EventsHandler.cfg?
Yes. They would be called by the event. BlockBreak/PlayerDeath etc. If appropriate it. They would still have context to check if nearby entities are of a creaturetype/livinghandler type (or the same as the killed entity). (Edit: They are not stored inside any of the traditional objects, they would be there own thing)
Possibly as many files as you'd like inside an /Events/ folder. The file itself would define the event type to call it, and the expression to execute.
This would allow people to separate event logic if desired. And allows me to import defaults without mucking with already setup events.
o.O such a thing? http://fathertoast.wikia.com/wiki/Mob_Properties
I did not realise he already had "if_recently_hit:", "if_killed_by_x:", etc.. it's a long list. This is done in JSON but it is done. The ToastedFather is an interesting Father as well. Not unlike yourself, he's one of those exceedingly rare, seemingly oxymoronic beasts known as a "Good Human".
Shall I alert the good human?
No need to alert the good human. I'm not currently ready to write the events.
Though that source does provide some very good ideas for preconfigured functions for writeNBT functions / helpers.
It is also interesting looking at how he has setup his nested functions. This was one of the ways I considered moving the tag system in before I decided on MVEL.
External functions are also an interesting idea.