Print

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

[mifki]

What is the extra viewscreen_dwarfmodest for?

That makes it so that it works even if the current viewscreen is something else.

That's not required even in this case. Just use df.global.gview.view.child instead of getCurViewscreen() - it will correctly place the new screen on the top of the stack even if the parent screen wasn't on top.

Spoiler (click to show/hide)

I'm using helper functions like this a lot in Remote.

Code: [Select]

function screen_main()
    return df.global.gview.view.child   
end

function execute_with_main_mode(mode, fn)
    local ws = screen_main()
    local q = df.global.ui.main.mode
    df.global.ui.main.mode = mode

    local ok,ret = pcall(fn, ws)
    if not ok then print (ret) end

    df.global.ui.main.mode = q
    return ret 
end


[Dirst]

Dirst: that's quite reasonable. I'll have to be careful it computes size correctly for different ages because that's important for combat. I probably won't bother making things like hair length be age appropriate unless someone really wants it.

It'd be fine for an initial version to only work for adults, the creatures I mentioned are full-sized from day 0.

Child sizes are tricky because growth is linear during the growth stage, rather than just a step function.

[lethosor]

What is the extra viewscreen_dwarfmodest for?

That makes it so that it works even if the current viewscreen is something else.

That's not required even in this case. Just use df.global.gview.view.child instead of getCurViewscreen() - it will correctly place the new screen on the top of the stack even if the parent screen wasn't on top.

You'd want to make sure that screen is actually a dwarf mode viewscreen, though. (Is this supposed to work in adventure mode?)

[mifki]

What is the extra viewscreen_dwarfmodest for?

That makes it so that it works even if the current viewscreen is something else.

That's not required even in this case. Just use df.global.gview.view.child instead of getCurViewscreen() - it will correctly place the new screen on the top of the stack even if the parent screen wasn't on top.

You'd want to make sure that screen is actually a dwarf mode viewscreen, though. (Is this supposed to work in adventure mode?)

In my case it can be dwarf mode only.
Oh, right, if this script is supposed to work in adv mode, then creating a new dwarf mode screen is required.

[taldarus]

Spawned a Hydra, worked fine.

Trying to spawn a civilian. Got an error about arg5 civ_id in function 'processArgs' and in main chunk.

Saw something about this in the post, tried with \\LOCAL and \LOCAL, using my custom race atm. Will revert to standard dwarfs later to verify it's not my boys. Pretty sure I tried it with dwarfs hours ago, but can't remember (at the time, I thought I was messing up how to use the code)

Seems to be universal error, got it for the dog too.

ADDM: Used in arena crashed df and hack.

[expwnent]

In later versions it will work in all modes. Currently it only works in dwarf mode.

Try civId and groupId instead of civ_id and group_id. A bug in the documentation.

[taldarus]

Perfect!

Spawned me a Queen & Soldier! They are, however, not actually my civilians. Both fall into the 'Other' category and are classified as friendlies.

Gonna try a friendly hydra.

Is there a way to automate this? I read through all material I could find, but no luck. I assume its something you need to introduce into the scripts code?

[expwnent]

Try setting both civId and groupId to \\LOCAL.

[taldarus]

Command used: modtools/create-unit -race CHIDDRIN -caste T0QUEEN -civId \\LOCAL -groupId \\LOCAL

I don't see/understand the difference.

EDIT: Changed GroupID to correct form GroupId

[expwnent]

That command should work, except you need groupId instead of groupID (but it would have complained if you did that wrong).

The difference between what?

[taldarus]

Spawned me a Queen & Soldier! They are, however, not actually my civilians. Both fall into the 'Other' category and are classified as friendlies.

then you said

Try setting both civId and groupId to \\LOCAL.

But I already did that, so I don't see how this would help.

[expwnent]

If you just set civId then they'll be members of your civilization but not members of your fort. They *should* be members of both if you use both -civId \\LOCAL and -groupId \\LOCAL, but it's possible it isn't working correctly. It seems to work fine for dwarves in vanilla.

[taldarus]

ah, ok, suggestions?

Edit: Added Hydra as a pet, it worked right up until I unpaused the game.

Stray Hydra and all. When game started to run, it froze immediately, and then crashed shortly after. An error box appeared, but disappeared before I could read it. DF error log is clean of any reference, but I doubt a dfhack error shows there.

Edit2: Oh, both civ members names are just numbers, I can give them if you want. Anything else you want tested?

Edit3: Tried adding the -flags tag to my race. It came up with this error:
bad argument #1 to 'ipairs' (table expected, got string)
stack traceback:
  [C]: in function 'ipairs'
...modtools/create-unit.lua:312: in main chunk

[expwnent]

Try version 0.2. It supports random civilization-appropriate names.

For the flags argument you need to do it like

-flags [ flag1 flag2 ]

and even if there's just one flag you have to do -flags [ flagName ]

[taldarus]

You sir are a scripting machine, vn!

Name is now 'blank', or I assume it is blank (Just says Peasant). I haven't spent any time working on the entity file, I just strip mined the dwarf one for pieces I wanted.

Still reads as friendly, not a civ member...

Tested saving and loading, looks secure...

Tested dog, in order to verify it is my race...and the dog shows up as a tame stray dog... forgot to have loo(k)ed when i did it, but he shows in the unit list. So it's my race

tried to add entity and creature, but its too many characters...