Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Roses]

I'm not sure if I could keep track of kills that way. although presumably it is possible since the game tracks kills, and the finished praying 100 times would be easy. Just increment the prayer counter every time the reaction is performed, at 100 you get a new ability, at 1000 a better ability, etc...

Yes, just the last blue portal will be active. It is possible that I could add a reaction that activates and deactivates portals, so that you could have many built, but only two active at a time, and switch which ones are active. It's also possible I might be able to expand the number of portals (I should say it IS possible, but I am not sure how robust the system would be, I could foresee many problems). Right now one persistent variable is the perfect size to handle two portals. I would have to think about how to make an arbitrary number of portals, it is possible that through some clever use of addReactionToShop(reaction_name,shop_name) I could allow for many different portals, but for now I am happy with just two portals (and the activate/deactivate reactions).

[Meph]

No idea how many portals make sense. I would say adding items would be more interesting, because more portals dont allow new techniques, but allowing items does. Or liquids. Teleport magma from the magmalake.

I noticed one problem: Without the "teleportbase" in the dfhack init, it doesnt work. But with the line in the init, dfhack shows red errorlogs every now and then, because the buildings are missing. Or when you load the game and no map is active. It doesnt cause any trouble, but I know that some people will see this errormessage and report it as a bug. ^^

[Roses]

Yeah, I mean I could hand make other portals that would work similarly to the way they work now, but if I was going to go for multiple portals I would want to change the functionality so that an arbitrary number of portals could be used instead of a specific number like 3 or 4.

Hmm liquids would be interesting. I will try to get items and liquids working, although I'm not sure how best to place the liquids once they have been teleported.

I will look into the red errorlogs and see if there is something I can do to stop those. If you have them handy could you copy them here?

[Meph]

They occasionally pop up while you play.

Code: [Select]

...\hack\scripts/teleportbase.lua:9: Cannot read field vector<building_def*>.-1: index out of bounds.
stack traceback:
        [C]: in function '__index'
        ...\hack\scripts/teleportbase.lua:9: in function
<...\hack\scripts/teleportbase.lua:4>
[DFHack]#
Edit: Once you build the teleporters it goes away.

[Roses]

I'll bet it pops up whenever you build a vanilla building... I see exactly where the error is. I will fix it.

[Putnam]

I think I can get the teleportation buildings to work with persistent storage. This should allow for the buildings to work even if you quit DF and start back up again. It may be limited to one entry and one exit portal though... I can't think of a reliable way to link multiple portals, but I will think about it more.

You can concatenate the building ID with whatever your normal key is--for example, save it as "PORTAL_ROSES/"..building.id or whatever it is. You could then store the first int as the ID of other building it goes to, which can then be used to find the location of it.

[Meph]

I'll bet it pops up whenever you build a vanilla building... I see exactly where the error is. I will fix it.

Yep, thats it.

[Roses]

I think I can get the teleportation buildings to work with persistent storage. This should allow for the buildings to work even if you quit DF and start back up again. It may be limited to one entry and one exit portal though... I can't think of a reliable way to link multiple portals, but I will think about it more.

You can concatenate the building ID with whatever your normal key is--for example, save it as "PORTAL_ROSES/"..building.id or whatever it is. You could then store the first int as the ID of other building it goes to, which can then be used to find the location of it.

Thats a good idea. I'll think more on what can be done.

[Roses]

New set of scripts and bug fixes. Please note that some of the older scripts have been changed to need more arguments.

• Bugfix: All scripts that accept a radius are now inclusive in range.
• Change Name: cyclone.lua -> propel.lua
• Change Name: radiuseffect.lua -> changefixed.lua
• Change Name: weather.lua -> customweather.lua
• Addition: added descriptions to each script
• Change Function: changefixed.lua now increases or decreases the current value (accepts negative values). Can be used to "cure" units of paralysis and such.
• New Script: changeboolean.lua used to change boolean flags for a set time period.
• New Script: changepercent.lua used to change a percentage amount of specific values (currently only works for blood_count)
• New Script: teleport.lua, build buildings that can be used to teleport between them, needs teleportbase.lua to work

Currently working on addings liquids and items into the teleport command, as well as adding additional portal options. As always please post any bugs you may find, or any suggestions for future scripts.

[Roses]

Three new ideas that I will be implementing soon.

1. Fully customizable radius, no longer will the x and y direction be forced to be the same. Now you can make "wall" like interactions by specifying the extent separately in x, y, and z.

2. Logic for target finding built into the scripts so you can specify if an effect should target only enemies, only fort members, or everyone (with possibilities for more options).

3. A check for syndrome immune classes and creatures on area effects. (Hoping to be able to add a check for actual SYN_CLASS arguments as well, but right now I am not sure where that information is stored)

[Putnam]

What exactly are you confused about on SYN_CLASS storage?

[Roses]

Well I saw how you check for the creature class and creature immunities in itemsyndrome, so those checks will be easy to emulate. I just need to come up with something like that for the SYN_CLASS tags. I think I saw where they were stored when I was playing with gm-editor earlier, so its less confusion and more just making sure I understand how it all works.

[Putnam]

Check out projectileExpansion.

[Roses]

Large new update. All previous versions are no longer compatible with the updated versions.

• Bugfix: Targeting was ignoring some map squares in all routines
• Addition: Teleport can now handle items. If specified it will move all items within a radius to the appropriate portal
• Addition: Targeting will now take into account syndrome classes, creature classes, creature castes, and tokens. Behaves similarly to how interactions behave in vanilla. See more below.
• New Script: addsyndrome.lua, now you can add syndromes (that are specified in an inorganic) through a script. This allows for syndrome additions in various other scripts that only allow script inputs

The addition is actually a fairly large and complex deal. It adds several new [SYN_CLASS] tags that are needed, but makes up for this inconvenience with great flexibility and usability. Some example of things you can do with the new targeting system;

• Allow only specific creatures
• Allow only specific creature classes
• Allow only specific syndrome classes (NOT POSSIBLE IN VANILLA)
• Forbid all of the above
• Require and Forbid based on a large amount of different tags (MANY MORE THAN VANILLA)

The tags that are eligible for requireing/forbidding are listed in tokens.txt, to give an example you can now make syndromes and other interactions that only target megabeasts, demons, titans, fliers, amphibious, etc.... (pretty much anything that is possible to be specified in the raws) 

NOTE: I have taken the Use and Example sections of each script off of the forums. They can still be found in the actual script files.

EDIT: Forgot to mention that change to the teleport.lua, the changes have been updated.

[Rumrusher]

Code: [Select]

function Mega Corpse-Explosion (unit_list)
  local items={}
  for _,checked_item in pairs(df.global.world.items.other.ANY_CORPSE) do --actually you could iterate over only corpse pieces... But i'm too lazy
    if checked_item.flags.on_ground then --add/remove more checks before then if you want to explode not ALL the corpses
      table.insert(items,checked_item) --add to the list of target items
    end
  end
if #items==0 then
    print"no corpses"
else
local Corp={}
local Corp=getcorpse(df.global.world.items.other.ANY_CORPSE)
  for k,v in pairs(Corp) do
local   upos=copyall(v.pos)
  print(k.."test")
  dfhack.timeout(10,"ticks",function() dfhack.maps.spawnFlow(upos,4,2,2,50000) end) --this spawns dragonfire after 100 ticks(you could change "100" to e.g. "math.random(0,1000)" for random timeouts)
  dfhack.timeout(50,"ticks",function() dfhack.maps.spawnFlow(upos,3,2,11,50000) end) --this spawns dragonfire after 100 ticks(you could change "100" to e.g. "math.random(0,1000)" for random timeouts)
  dfhack.timeout(60,"ticks",function() dfhack.maps.spawnFlow(upos,3,2,11,50000) end) --this spawns dragonfire after 100 ticks(you could change "100" to e.g. "math.random(0,1000)" for random timeouts)
  dfhack.timeout(70,"ticks",function() dfhack.maps.spawnFlow(upos,9,2,11,50000) end) --this spawns dragonfire after 100 ticks(you could change "100" to e.g. "math.random(0,1000)" for random timeouts)
  dfhack.timeout(70,"ticks",function() dfhack.maps.spawnFlow(upos,10,2,11,50000) end) --this spawns dragonfire after 100 ticks(you could change "100" to e.g. "math.random(0,1000)" for random timeouts)
  dfhack.timeout(70,"ticks",function() dfhack.maps.spawnFlow(upos,11,2,11,50000) end) --this spawns dragonfire after 100 ticks(you could change "100" to e.g. "math.random(0,1000)" for random timeouts)
  dfhack.timeout(70,"ticks",function() dfhack.maps.spawnFlow(upos,12,2,11,50000) end) --this spawns dragonfire after 100 ticks(you could change "100" to e.g. "math.random(0,1000)" for random timeouts)
  dfhack.timeout(70,"ticks",function() dfhack.maps.spawnFlow(upos,8,2,11,50000) end) --this spawns dragonfire after 100 ticks(you could change "100" to e.g. "math.random(0,1000)" for random timeouts)
  dfhack.timeout(10,"ticks",function() dfhack.maps.spawnFlow(upos,8,2,11,50000) end) --this spawns dragonfire after 100 ticks(you could change "100" to e.g. "math.random(0,1000)" for random timeouts)
  dfhack.timeout(15,"ticks",function() dfhack.maps.spawnFlow(upos,8,2,10,50000) end) --this spawns dragonfire after 100 ticks(you could change "100" to e.g. "math.random(0,1000)" for random timeouts)
  dfhack.timeout(20,"ticks",function() dfhack.maps.spawnFlow(upos,8,3,14,50000) end) --this spawns dragonfire after 100 ticks(you could change "100" to e.g. "math.random(0,1000)" for random timeouts)
  dfhack.timeout(25,"ticks",function() dfhack.maps.spawnFlow(upos,8,4,16,50000) end) --this spawns dragonfire after 100 ticks(you could change "100" to e.g. "math.random(0,1000)" for random timeouts)
  dfhack.timeout(30,"ticks",function() dfhack.maps.spawnFlow(upos,8,5,18,50000) end) --this spawns dragonfire after 100 ticks(you could change "100" to e.g. "math.random(0,1000)" for random timeouts)
  dfhack.timeout(90,"ticks",function() dfhack.maps.spawnFlow(upos,13,5,18,50000) end) --this spawns dragonfire after 100 ticks(you could change "100" to e.g. "math.random(0,1000)" for random timeouts)
  dfhack.timeout(90,"ticks",function() dfhack.maps.spawnFlow(upos,15,5,18,50000) end) --this spawns dragonfire after 100 ticks(you could change "100" to e.g. "math.random(0,1000)" for random timeouts)
  dfhack.timeout(80,"ticks",function() dfhack.maps.spawnFlow(upos,7,2,11,50000) end) --this spawns dragonfire after 100 ticks(you could change "100" to e.g. "math.random(0,1000)" for random timeouts)
  end
  end
        return true
endfun spell I have that warmist help when we discovered dragon fire and web shooting,
This baby will explode in a 15 tile raidus of the corpse then flood the area with Sea foam to prevent some horrible forest fires(and save the corpse for another try). Any poor sucker caught under this will be hit with lava fire and cave-in dust knocking them several Zlevels in the air. If you don't murder someone with this you'll stun and maim them just enough for you to go in for the kill/retry again. Also this triggers every corpse in the area so make sure if you use this in Fort mode that you don't have any one valuable near by or in adventure mode not to be carrying any dead companions.