Print

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

Have few types but with many possible functions for each.  The simpler option

38 (42.2%)

Have many different types that each takes a particular input, for long assembly lines

29 (32.2%)

Have many types, allow using the wrong ones, but using them correctly lets the items have quality levels

23 (25.6%)

Total Members Voted: 69

[IndigoFenix]

I would like to see those powered seige engines.  Are they written in lua?  I haven't been able to get dll plugins to work.  Being able to trigger reactions from a distance would be helpful.

Easy access to liquids was the main intent behind the driilig rig, although that's still up in the air.

The upgraded mining/woodcutting equipment is a good idea.  Can you raise skill levels with itemsyndrome, or do I have to write a new script?

I'll see if I can get something new up in a few days.  Probably nothing major, but the prospecting stuff is fun to play around with.

[Meph]

Can you raise skill levels with itemsyndrome

I know that you can use itemsyndrome to add an interaction that triggers syndrometrigger that runs a script to raise the skills. So "pick up epic mining drill and instantly become epic miner", but I dont know how to take that skill away when you drop it.

[IndigoFenix]

So it looks like I greatly overestimated what is possible as far as anatomy is concerned.  Most body plan data refers directly back to the raws, so altering it for a single creature isn't possible, and tissue layer details are linked directly to an indexed material in the creature itself, so replacing a tissue layer on one part of the body isn't an option either.  I can replace one material in the body with another (replace all skin with metal, for instance) and change the injury status of different parts but that's about it.

On the plus side, geology is pretty easy to play with, at least as far as its shape is concerned (materials are trickier - each layer has only a few materials in it and the tiles refer back to one of those, so you can't make, say, a chunk of slade appear outside of its element).  Although I still haven't figured out how to make cave ins and liquid flow respect the chunks of rock being deleted.

[arcturusthelesser]

I personally think that to give gnomes access to this kind of advanced mining would be a crime against dwarf-kind. While of course metal is an important resource, I think it'd be a mistake, flavor speaking, to allow them to dig more easily than the race who above all focus on digging, stonework, etc. I think in keeping with the more naturalistic tendencies of gnomes it might be fitting to give them some sort of treemancy (I think that's the word?) so they could be capable of building constructs out of nothing but good nature karma or maybe seeds. I don't know, maybe that would only be appropriate with elves, especially as gnomes only really have a special relationship with animals so far.

. . .

besides, I doubt I'm alone in thinking that there's no way these guys could take on the circus. The clowns would laugh at them.

[Meph]

arcturusthelesser: See it from this point: If indigofenix developes a new dfhack method for fancy mining that is added to the gnomes, it can surely be altered and added to the dwarves as well, giving them a superior version. The point is that IndigoFenix writes Gnomes, and if he doesnt write these scripts, no one does.

[IndigoFenix]

I got the drilling rig to work.  Not exactly the way I wanted it to - the materials of the pipe sections used aren't retained - but it extends, retracts, makes vertical holes, and sucks up liquids.  I have to find out how to make it work from a distance though, for reasons that should be obvious.  Right now all it can do is make the upper caverns slightly damp, or light a gnome on fire.

[IndigoFenix]

In retrospect, the easiest solution was also the most obvious - have the sucked-up liquids come out the level below the workshop instead of the workshop itself.  Make sure there's some room for them to flow out though, or it'll flow out the top and you'll have flooding or roasting pretty quickly.
You can drill through water or magma, but a hole will be left at the bottom if you retract the drill all the way.  The liquid inlet is one z-level below the bottom of the drill.

_	[]	[]	[]	_	<--The workshop
~	~	||	~	~	<--Liquid outlet
=	=	||	=	=
=	=	||	=	=
=	=	||	=	=
=	=	||	=	=
=	=	||	=	=
=	=	||	=	=
		||			<--Bottom of drill shaft
~	~	~	~	~	<--Water/Magma

It hasn't been fully tested yet... I'm not sure what happens if you drill into the HFS.  But the basic functions are working.

I'm going to have to find a way to make it automated with the addition of power...basically a better pump stack.  That's the next project: figuring out how to make powered workshops that do things by themselves when powered.

So anyway...updated with geological prospecting and the drilling rig.

[Stronghammer]

Awesome. Seems like great progress all around. Its nice to see a more industrialized race, that time period can be so fun. Cant wait for powered workshops that automate. It would greatly speed up my cloth industry, or frankly any industry.

[IndigoFenix]

Well, that's the question.  The obvious use for powered workshops is fast, automated factories that produce items without quality levels.  The thing is that gnomes are generally seen as meticulous craftsmen who like working with their hands and value quality over quantity.  So, even though they should have the technology for the assembly line, they'd probably never think of it in the first place.  And if they did, they probably would scoff at its use.

I'm not sure how Warmist's powered workshops work, if he figured out how to make them interact with the regular DF power train.  Increasing the power needed for the whole device, shutting it down if the requirement is too high, connecting two separate machine assemblies... The system I have working now is a little different.  It doesn't change the power levels of regular machines, instead the workshops feed off the surplus power, which is allocated among them, and then can run a script every frame using their current power level as parameters.  So more power = more output, but if there's not enough power they don't shut down the whole machine.  So, technologically superior to DF technology, but not really running on the same system.  When Warmist comes out with what he's working on, I'll see how well the systems interact.

[Stronghammer]

That sounds really cool. As to the whole quantity verses quality you could use the system as a resource rather then a speed up. That way you still have gnomes working as meticulous craftsmen you just have a need for power for certain functions (like the drill). You could also have a "mine" that produces minerals as if it was an automated mine. You could create food processing centers that makes more edible meals out of food which requires power. The options are only limited by the application of your power idea. It does not necessarily have to speed things up. I dont know how scripting works but you always could go in the direction of quality and have power increase the quality of goods produced. Just some thoughts, your the modder so its your vision in the end.

Cheers 

[splinterz]

wow that drilling rig sounds goddamn amazing, very impressive work!

[IndigoFenix]

Just ran a test on the powered drill pump.

Test results: Success.
Fortress status: Mostly underwater.

The power-using script can't be modded through the raws yet, but that's the next step.  I'll package the drill and the machine power plugin together, along with any other 'special' power-using mechanisms I come up with.

Hm, where should the data for a power-using workshop be stored?  Workshop raws themselves don't have a lot of room for putting in extra information.  Most objects don't, that's probably why most plugins use inorganics and syndromes to store their data.  But it's messy.

[IndigoFenix]

I realized something.  It's actually possible to make a machine system that does everything the basic system does and more, updating properly regardless of the order you build machines in, adding, requiring, and allocating power, and so on.  There's just one problem: it would break any other machine-based plugins.

(Technical stuff:)

Basically the problem with DF machines is that they NEVER run a full-system check and update from scratch.  They don't need to, in unaltered DF - all they need to do is add or remove power whenever a machine component is added or removed from the system, or when a power source starts/stops giving power.  So any additional plugin that changes the actual power level has to do the same: only adding and removing power appropriately when it is connected or removed from the system.  The problem is that the index of the machines can be shifted around when a component is broken or a gear assembly is disengaged, which makes it nearly impossible to determine when and where the machine actually needs updating.

Unless the script runs a full-system check instead and updates the power levels accordingly.  Adding up all the machine components whenever something changes and resetting the system's power levels accordingly, then adjusting for all buildings that use the plugin.  The problem is that the machine updating script would have to take into account ALL custom power-using buildings, which means that they would have to follow a convention, which means that trying to run it alongside, say, the steam engine plugin or any of the new custom siege engines will prevent them from operating properly.

On the other hand, writing new, compatible versions of said machines wouldn't be especially difficult.

So... What to do?  Hijack the whole system, or not?

[Meph]

I think that question would be better situated at the dfhack area, where ag and warmist can see it.

[Meph]

Could you please add this to your entity file? Just at the very top, that way the GUI can find everything.

Code: [Select]

entity_gnome

YESGNOME[OBJECT:ENTITY]


################################################################
################################################################
###########       GNOMES          ##############################
################################################################
################################################################

[ENTITY:GNOMES]
[CREATURE:GNOME_CIV]

/// added by meph for the GUI
-----------------------------------------------------
/adds bad, medium or good materials for trade/sieges
[PERMITTED_REACTION:MATERIALS_DEFAULT]

/makes them good/evil
!BABYSNATCHER!

/allows playing adv mode
YESADVGNOMES[INDIV_CONTROLLABLE]

/allows playing fort mode
!NOCIVGNOME!CIV_CONTROLLABLE]
-----------------------------------------------------
/// end of edits

EDIT: I just embarked as Gnomes. You should probably get rid of the category titles from the dwarves, as well as the "THIS REQUIRES RESEARCH" buildings.

These ones:
[PERMITTED_BUILDING:SCIENCE_HELP]
PERMITTED_BUILDING:SCIENCE_HELP1
PERMITTED_BUILDING:SCIENCE_HELP2
PERMITTED_BUILDING:SCIENCE_HELP3
[PERMITTED_BUILDING:SCIENCE_HELP5]
[PERMITTED_BUILDING:SCIENCE_HELP4]
[PERMITTED_BUILDING:SCIENCE_HELP10]
[PERMITTED_BUILDING:SCIENCE_HELP11]
[PERMITTED_BUILDING:SCIENCE_HELP12]

And having things like the liquids spawner or the chemist, which require actual research tools as buildmats is probably a bad idea, since your gnomes dont have the dwarves researcher. If you really want to keep these buildings, it would probably be best to make a copy that uses different buildmats, like CHEMIST_GNOME and then add this to the chemist reactions that already exist.