Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Roses

Pages: 1 ... 89 90 [91] 92 93 ... 131
1351
Utilities and 3rd Party Applications / Re: DFHack Spells *New Scripts incoming soon!*
« on: April 11, 2014, 07:02:05 pm »
Thats good to hear, I guess I will just ask him then and see if the interactions user is stored anywhere. If it is, great!, if not I will jury rig something with announcements and put a big asterisk on all the things that require the users id.

EDIT: Contacted Mr. Adams, he said that the information of who caused the syndrome is not stored anywhere. I will continue to try and make the announcements method more reliable, and make mention of all the flags what require the users id.

1352
Utilities and 3rd Party Applications / Re: DFHack Spells *New Scripts incoming soon!*
« on: April 11, 2014, 06:13:47 pm »
I have thought about it, but given the fact that we are basically hacking into his code (albeit in the nicest way possible), I am not sure he would take kindly to a question concerning the inner workings of the code. I will attempt to try a couple more things and look through some more of the df-structures to see if there is anything I see. If all else fails I suppose it can't hurt to ask.

1353
Utilities and 3rd Party Applications / Re: [SUGGESTIONS] for DFhack plugins
« on: April 11, 2014, 06:10:26 pm »
Well I know you can see what animals a race has access to with;
Code: [Select]
df.global.world.entities.all[X].resources.animals.pet_races
df.global.world.entities.all[X].resources.animals.pet_castesBut I have never tried adding or subtracting available pets and such, I have no idea if it would work.

There is also wagon_races, pack_animal_races, wagon_puller_races, mount_races, minion_races, and exotic_pet_races.

Also under resources there is options for metals, stones, items, plants, etc... Also have not tried adding or subtracting from these lists.

1354
Utilities and 3rd Party Applications / Re: DFHack Spells *New Scripts incoming soon!*
« on: April 11, 2014, 01:39:00 pm »
All I am trying to do is reliably get the target and user of an interaction when it is used. Like how you can currently say \UNIT_ID, I would like to instead have \TARGET_ID and \USER_ID.

The only way I have found so far is to read announcements (generated from CDI:VERB and CDI:TARGET_VERB) to determine the users name and find the unit that way. The problem with that method is when there are several interactions being used at once, I have not found a reliable way to make sure the correct announcement is tied to the correct action. It may be that the announcements (VERB and TARGET_VERB) are linked in some way, if that is the case then I could read the targets announcements and determine from there, although it may have the same problem as it does now, where many interactions, used simultaneously, results in incorrect assignment of \USER_ID.

1355
Utilities and 3rd Party Applications / Re: DFHack Spells *New Scripts incoming soon!*
« on: April 11, 2014, 01:01:41 pm »
Quote from: ag on April 11, 2014, 10:54:11 am
Quote from: Putnam on April 10, 2014, 02:31:00 pm
If anything, "unit" would be the one who did the interaction and "unit_syndrome" would be the one who didn't.

If you look at the XML properly, you will note that unit_syndrome is a structure type, and it has nothing whatsoever to do with doing interactions. This method is involved in per-tick processing of syndromes already active on a unit.

Hmm, thats too bad.

The only thing left that I can think about is a more rigorous analysis of the announcements. There are these two types;
Code: [Select]
        <enum-item name='INTERACTION_ACTOR'/>
        <enum-item name='INTERACTION_TARGET'/>Maybe I can trigger an announcement check right when the script is run? The only problem with that is that I was getting some cross chatter between multiple interactions being used at the same time.

I'm surprised there isn't a more direct link between units that use interactions and their targets, or maybe its just buried somewhere else. Anyway, I will try and see what I can do with the announcements, if anyone has any ideas I am all ears.

1356
Utilities and 3rd Party Applications / Re: DFHack Spells *New Scripts incoming soon!*
« on: April 10, 2014, 05:26:04 pm »
Quote from: Warmist on April 10, 2014, 02:53:34 pm
Quote from: Putnam on April 10, 2014, 02:31:00 pm
If anything, "unit" would be the one who did the interaction and "unit_syndrome" would be the one who didn't.
Even if that is true, there is no easy way to get to unit when you know unit_syndrome. Also the last argument is "df::unit_wound**" so maybe it's used to create new wounds? Not sure how that works.

Well I was hoping that they would both be available so that a plugin could read both when called. I will contact angavrilov and ask what they know, and possibly try and determine what exactly is being pointed to. Hopefully both the caster and target will be available.

1357
Utilities and 3rd Party Applications / Re: DFHack Spells *New Scripts incoming soon!*
« on: April 10, 2014, 11:03:51 am »
Hmmm, it looks like someone already did the work, and unfortunately it doesn't look like the information I want is there, unless unit_syndrome means the unit who casted the syndrome. I suppose I will check if that is the case.

EDIT: Do you know who might have done the research on that vmethod? Might save me time to just talk to them.

1358
Utilities and 3rd Party Applications / Re: DFHack Spells *New Scripts incoming soon!*
« on: April 09, 2014, 04:15:12 pm »
So using those links that Putnam gave, I have started to play with Interposing the vmethod. So far I have

Spoiler: interposetest.cpp (click to show/hide)

Which I got by copying the eventful.cpp and readjusting it for the vmethod I am interested in. The only problem I am having now is the bolded parts in the code, namely;

1. I don't know how to reference the specific vmethod I am interested in. The eventful.cpp ones all have names for their vmethods, and the one I am interested in does not.
2. Similarly, I am unsure what the proper way to reference a pointer is without knowing what it is pointing to. The eventful.cpp ones have things like df::unit*, but again, I do not know anything about the pointers.

Any thoughts? I may move this question over to the DFHack main thread, since it is getting far from the point of this thread, but I figured I would ask here first since we have already been talking about it.

1359
Utilities and 3rd Party Applications / Re: DFHack Spells *New Scripts incoming soon!*
« on: April 07, 2014, 09:29:07 am »
Thanks, I will take a look at this, this week. Hopefully I can manage to figure something out.

1360
Utilities and 3rd Party Applications / Re: DFHack Spells (linked to DFHack script collection) Overhaul
« on: April 06, 2014, 09:30:25 pm »
Quote from: Warmist on March 19, 2014, 02:20:35 pm
Quote from: Roses on March 18, 2014, 08:48:26 pm
Alrighty. I'm not sure how to investigate the vmethods either, so I will ask around and see what I can come up with.
Dissassemble, or interpose it and try to make sense of it. (or ask for someone to do it :) ). I only got that the 4th being triggered when applying(?) the effect. And the first value is probably target unit.

What do you use for interposition of DF code? I figured I should really try and nail this problem down, or lots of the coding I have been doing for scripts will be pretty useless.

1361
Utilities and 3rd Party Applications / Re: DFHack Spells *New Scripts incoming soon!*
« on: April 03, 2014, 07:37:56 pm »
For reference, this is the stuff that handles the creation and modification of persistent variables.

Code: [Select]
keys = arg[1] .. '_counters_1'
types = arg[2]
pers,status = dfhack.persistent.get(keys)
num = 1
if not pers then
dfhack.persistent.save({key=keys,value=types,ints={arg[3],0,0,0,0,0,1}})
else
if pers.ints[7] <= 6 then
if string.match(pers.value,types) ~= nil then
local valuea = split(pers.value,'_')
for i,x in ipairs(valuea) do
if x == types then pers.ints[i] = pers.ints[i] + arg[3] end
end
else
if pers.ints[7] < 6 then
pers.value = pers.value .. '_' .. types
pers.ints[7] = pers.ints[7] + 1
pers.ints[pers.ints[7]] = arg[3]
dfhack.persistent.save({key=pers.key,value=pers.value,ints=pers.ints})
elseif pers.ints[7] == 6 then
pers.ints[7] = 7
dfhack.persistent.save({key=arg[1] .. '_counters_2', value=types,ints={arg[3],0,0,0,0,0,0}})
end
end
else
num = math.floor(pers.ints[7]/7)+1
match = false
local valuea = split(pers.value,'_')
for i,x in ipairs(valuea) do
if x == types then
pers.ints[i] = pers.ints[i] + arg[3]
match = true
end
end
if not match then
for j = 2, num, 1 do
keysa = arg[1] .. '_counters_' .. tostring(j)
persa,status = dfhack.persistent.get(keysa)
local valuea = split(persa.value,'_')
for i,x in ipairs(valuea) do
if x == types then
persa.ints[i] = persa.ints[i] + arg[3]
dfhack.persistent.save({key=persa.key,value=persa.value,ints=persa.ints})
match = true
end
end
end
end
if not match then
pers.ints[7] = pers.ints[7] + 1
if math.floor(pers.ints[7]/7) == pers.ints[7]/7 then
print(pers.ints[7])
keysa = arg[1]..'_counters_'..tostring(num+1)
dfhack.persistent.save({key=keysa, value=types,ints={arg[3],0,0,0,0,0,0}})
else
persa.value = persa.value..'_'..types
print(pers.ints[7]-(num-1)*7+1)
persa.ints[pers.ints[7]-(num-1)*7+1] = persa.ints[pers.ints[7]-(num-1)*7+1] + arg[3]
dfhack.persistent.save({key=persa.key,value=persa.value,ints=persa.ints})
end
end
end
dfhack.persistent.save({key=pers.key,value=pers.value,ints=pers.ints})
end
I just got rid of the last bug that was bothering me, so I will be uploading the script (and a few others, like a delay script) this weekend most likely.

1362
DF Modding / Re: [MODDING] 0.34. QUESTIONS THREAD
« on: April 03, 2014, 12:36:22 pm »
I think you can just change the product to take the material of the wood. So instead of thin wooden blocks, you should get oak blocks.

1363
DF Modding / Re: [MODDING] 0.34. QUESTIONS THREAD
« on: April 03, 2014, 12:10:51 pm »
I think there have been a couple mods created that do just that. One that I remember is here.

1364
Utilities and 3rd Party Applications / Re: DFHack 0.34.11 r3
« on: April 03, 2014, 07:39:38 am »
So I have been using dfhack.run_script(name[,args...]), but it expects the arguments to be in the form dfhack.run_script(name,args[0], args[1], args[2], ...). Is there anyway to send just an array of arguments through and have it work? Or is there a lua command that does that?

1365
Utilities and 3rd Party Applications / Re: DFHack Spells *New Scripts incoming soon!*
« on: April 01, 2014, 09:08:48 pm »
In persistent variables, the text string stores the information of which counters are in the persistent variable. If you need more than 7 then another persistent variable is created for the unit.

EDIT: I currently don't notice any fps issues with multiple creatures referencing multiple persistent variables. Of course, because of the way persistent variables are handled more than 6 will cause greater slowdowns (still don't think they will be noticeable) as it will create a new persistent variable. Every 7 counters there after (on the same dwarf) will cause another persistent variable to be created. My suggestion to those that might use this system is to limit yourself to less than 13, and preferably, less than 6 custom counters on a given unit. My brief test seemed to indicate that the path finding of a new dwarf or invader causes more of an impact on the fps of your fort then adding the interactions which reference these persistent variables, but these tests were only done up to 100 Dwarfs and 13 counters on each Dwarf.

EDIT2: I should probably add in a deteriorating effect so that the counters slowly click back to zero, and, if they are at zero long enough, disappear from the unit. This will allow more freedom for counters and would be more realistic. You wouldn't expect a POISON counter to stick around for a year and then get triggered at the next invasion.

Pages: 1 ... 89 90 [91] 92 93 ... 131