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.

Topics - bloop_bleep

Pages: [1] 2 3

Forum Games and Roleplaying / A question about how forum games are normally run

« on: August 14, 2022, 11:53:13 pm »

A question for the GMs out there, if you have a forum game where each player controls an individual character in a group setting, in particular where each turn is some non-trivial amount of in-game time like a week long, how do you mechanistically handle the situation where character A posts their turn, then character B does something on their turn which character A objects to? Do you just let B run out their turn and A can respond later? Should A edit their own turn post?

Utilities and 3rd Party Applications / Minecart Fall Loading! [v1.1] -- Minecarts pick up things that fall onto them

« on: March 10, 2020, 04:30:43 am »

DFFD for source file and Windows binaries: http://dffd.bay12games.com/file.php?id=14917
GitHub repository: https://github.com/bloop-bleep-b12/minecart_fall_loading

This is a plugin that allows items OR units that fall on top of a minecart to be a loaded into that minecart, if they can fit within the minecart. This, I believe, is an important addition, because it allows automatic minecart loading without direct dwarf interaction, in a simple way, without making it TOO easy =P. In the base game, only automatic minecart unloading is possible.

Think of the possibilities! We could have minecarts passing items from one to another, with a dumping track stop next to a hole over another minecart. Imagine dwarves dumping finished items down chutes right outside their workshops, to be spirited away by a waiting minecart, without the need for the stockpile walk after the job is done. I have considered constructing a horrifying recursive goblin grinder, where goblins are pelted from afar with the corpses of their previously fallen comrades, until the ground underneath them gives way, allowing a minecart below to scoop up their own cadavers. The efficiency is exponential!

All with minimal dwarf interaction, and a relatively simple mechanic.

Please tell me what you think, and provide any bug reports or comments! Thank you!

NOTE: Currently only one unit at a time may be loaded into a minecart this way. This restriction is artificially created by me, so could be easily changed if people feel against it. Also make sure to pit units from at least 2 z-levels above minecarts in order for them to loaded.

EDIT: Also I would appreciate any technical advice on how to search for items (which may be in the air) in a specific tile? Currently I'm looping through all active items, which I assume is not the most efficient way. Is it true that if an item is not a projectile, then it is recorded in the df::map_block* in which it is located?

Utilities and 3rd Party Applications / Possibility of creating multi-tile creatures (now under development)

« on: January 19, 2019, 02:44:55 am »

So, I was thinking that it might not be completely impossible to implement multi-tile creatures with DFHack.

The basic idea I had was this -- multi-tile creatures would consist of a "parent" creature and many "child" creatures. The parent creature is the creature that gets exposed to legends mode and historical records ("<name> is a <parent creature>. It was one of the first of its kind." or "This <parent creature> has devoured ten in its lust for blood!"), while the child creatures get exposed to direct adventure/fortress mode gameplay. The children would each represent one tile of the creature, and would be connected to each other using a network of either dragging or grappling references. Units in adventure mode or fortress mode would interact with each child creature separately, attacking its components as if it were standalone.

There are several accomplishments that have to be made in order for this to work:

Prevent children creatures from being exposed to legends mode records. Some of this can be accomplished by adding [DOES_NOT_EXIST] to children creatures, but creating them anyway when it is determined that a multi-tile creature should be spawned. Additionally, whenever a child creature becomes a histfig, through killing a fortress member or something similar, the histfig endowment could be passed along to the parent creature, or deleted if the parent is already a histfig.
Prevent parent creatures from being exposed to direct adventure/fortress mode gameplay. For this, I am very doubtfully guessing that it might be sufficient to just set the position to (-30000, -30000, -30000), as if the unit is offloaded, and nullifying any position-dependent data like pathing information. Something else might be needed, though.
Bridge the gap between parent and children creatures, so that effects to one happen to the other as well. The most important aspect of this is that injuries to one class of creature correspond to injuries to the other class of creatures. This just might be accomplished, just might, by making the parent and child creatures share the same body part pointers (though of course each child would only have the body parts that logically should be part of itself.) Another thing that this implies is that when parent creatures appear in adventure/fortress mode, the child creatures spawn as well. This can be done by nullifying parent creatures on loading as described above and creating all the child creatures according to the body parts of the parent.
Implement AI for the whole multi-tile creature. Quite possibly the hardest of the bunch. This has two categories.
- Peaceful movement AI. Using dragging references, it might be possible to avoid doing very much at all -- only one of the children would be allowed to path (the only one that is not being dragged), and the rest would just follow behind.
- Combat AI. At first this can just be left to the default -- only the child creatures able to touch the opponent will attack, and the rest of the body would stay in place. (Or perhaps the pathing child will charge at the opponent, bringing the rest of the body which will attack as well?) Once a more sophisticated combat AI is desired, one possibility is very temporarily placing the parent creature on top of the attacker, and letting it choose an attack. Then whichever body part(s) are chosen to attack will begin to move towards the opponent. The time cost for each attack could be dynamically changed to account for the time needed for the requisite child creature to move into place.

Are there any thoughts on this, and further suggestions on how this might be done? I might start working on this, after I get my moving-machines plugin up to the point I want it.

General Discussion / Things that made you facepalm today

« on: December 07, 2018, 08:20:03 pm »

What have you done recently that made you connect your face rapidly with your hand and/or desk or other nearby convenient object?

Facepalm moments directly related with Dwarf Fortress should be directed here.

DF Modding / bloop_bleep's Moving Fortress Parts Mod! (v0.4 released)

« on: November 28, 2018, 10:33:50 pm »

Current version -- v0.4

This is a mod that implements moving fortress parts in Dwarf Fortress. The tar file for download (and installation instructions) can be found here, and the github repository can be found here. The former contains both the source file and a 64-bit Linux binary, so you'll have to compile the mod yourself if the binary doesn't work for you.

Using the mod is (fairly) simple -- build a bunch of floors to be the platform for your moving machine, designate them as such by opening the designation menu and pressing 'P' to select Platform mode, build whatever buildings you want on the platform, then build wheels (in workshop menu) off the side of your moving machine (or in the middle in a gap), and then attach them to windmills via any conduit you desire and watch it run! (Make sure to build the wheels *before* whatever machine components you're attaching to them directly, though, otherwise they won't link.)

This mod is still in somewhat rough condition, because currently there is no handling of units on the moving machines, moving machines can only run down hills, not up them, and no rotation. Everything but the last shouldn't be extremely difficult to implement, though.

The mod is now functional and (somewhat) stable!

Please report any bugs in this thread, and try to upload the 'moving-machines-log.txt' file in the DF folder to pastebin or elsewhere so that I could see precisely where it is going wrong!

Planned changes, roughly in order:

Fix platform designation menu. So far there is no green '+' to show the first selected corner, and you cannot change back to another designation mode unless you exit the designation menu first. DONE, released! (v0.2)
Add unit handling. DONE, released! (v0.2)
Add support for multilevel moving machines. DONE, released! (v0.3)
Distinguish moving machine platforms from normal constructions in some way, perhaps by using reverse video? POSTPONED, no obvious way to do this.
Add ability to drive up hills as well. DONE, released! (v0.3)
Implement damage to moving machines due to collisions.
Implement damage to terrain due to collisions.
Misc. cleanup (map edge collision detection, moving machine merging, etc.) DONE, released! (v0.4)
Better plugin data saving/loading. DONE, next release.
More realistic physics, such as elastic collisions, and more closely matching acceleration/deceleration down ramps. DONE, next release.
Boats in fortress mode.
ADVENTURE MODE DEATHMOBILES.

I'm planning to eventually add drills and other !FUN! implements to the game to make these things even more useful. Enjoy!

DF Modding / What viewscreen struct refers to the build menu?

« on: November 16, 2018, 03:17:02 am »

What viewscreen struct in DF refers to the building menu? I tried df::viewscreen_buildinglistst, but it turns out that refers instead to the 'R' list rooms menu, while df::viewscreen_buildst seems to refer to individual building menus, given the sole member of type df::building*. It is simply not supported in DFHack?

DF Community Games & Stories / Olonaroth, Fortress of !!SCIENCE!! and Engineering

« on: March 23, 2018, 03:10:54 pm »

There have definitely been many, many advances in dwarven !!SCIENCE!! over the years, what with Turing-complete computers, werebeast clocks, etc. But there is definitely quite a lot more to explore. Hence, this fort. Olonaroth ("Gearedmagic") will be a fort dedicated entirely to engineering, mechanics and other dwarven !!SCIENCE!! of various kinds. I've created a medium world with a 500-year history and lotsa civs and volcanoes. I've already chosen a pretty interesting embark, with all of the following features:

A volcano for easy magma access
Sand, for a glassmaking industry (haven't done much with that)
A river for unlimited water and machine power
Warm, forested biome, so wood won't be a problem and the river won't freeze every winter
A nearby necromancer tower for fun with zombies
Neighbors will all the kinds of civs.

I've also compiled a list of three tenets for this fort:

Automation is king.
Dwarves are expendable.
No megaproject is beyond our abilities.

This might become a succession fort, but for now it's gonna be just me, though I cannot guarantee the consistency of updates. I might do some roleplaying for this, but I'm not very good at that so I'm not sure.

I'm currently thinking of projects I could attempt, but for now the objective is just getting our stuff inside and setting up basic accommodations. Update should come reasonably soon.

DF Suggestions / Modding functionality/changes we'd like to see

« on: March 20, 2018, 04:27:28 pm »

This is an attempt at aggregating all the various new modding additions or changes the community would like to see. Basically, anyone can make a proposition, and then other people can vote for it, so we can establish a sort of priority ladder for Toady to see. Try to make the propositions relatively simple, instead of adding enormous new systems on top of the current game.

I have already included two propositions of my own.

MODDING ADDITIONS

Suggestion	Votes
Allow syndromes to apply creature variations	1
Make inhalation syndromes work all of the time, so boiling materials with syndromes are more effective.	1
Allow commenting out of raws.	2

MODDING CHANGES

Suggestion

Votes

(BTW, anyone know how to format this more nicely?)

DF Modding / Frequency of CLEAN_SELF and CLEAN_FRIEND interactions?

« on: March 10, 2018, 01:47:27 am »

So, I've been trying to make my alchemy mod, which involves making a lot of creatures that act like alchemy components. These are able to do touch interactions with each other in order to move around mana, spells, and other ingredients. Now, I remember reading somewhere that GREETING interactions are now used much less often in recent versions. I'm hoping to make the delay between interactions to be preferably under 100 ticks, 500 ticks at most. Is that possible to achieve with GREETING interactions? If not, I was thinking of using CLEAN_FRIEND interactions instead -- basically, when the component corpses are crafted and then resurrected using an Alchemical Activator, they would transform into a creature that emits a vapor cloud, condensing some the vapor as a contaminant on itself. This would trigger a syndrome that turns the creature into the creature that actually performs the desired function. The point is, whenever a component's neighbor satisfies certain requirements, the component will attempt to perform a CLEAN_FRIEND interaction that performs the desired effect on the neighbor, but doesn't actually clean any contaminant (IE_GRIME_LEVEL will be set to zero.) This also fits my plan for ingredient movement system -- it requires that creatures that are currently holding an ingredient to occasionally perform a "renewal" interaction on themselves. The only USAGE_HINT I can see that allows this is CLEAN_SELF.

My question is -- how often are CLEAN_FRIEND and CLEAN_SELF interactions performed? Is their frequency high enough for my purposes? Also, can CLEAN_FRIEND interactions have both a SELF_ONLY and a TOUCHABLE target?

DF Modding / Why don't fixed-temps work in arena?

« on: February 23, 2018, 03:22:48 am »

I was wondering for a long time why my fixed-temp inorganic material wasn't working (the description with DFHack shows it's temperature at 10050U) -- and on a whim I decided to create a training axe made of nether-cap -- and yet, it also showed the temperature at 10050U. Is this a DFHack thing? Or do fixed-temps simply not work in arena?

DF Modding / Grenade mod!

« on: February 14, 2018, 11:42:49 pm »

Hello everybody!

After failing several times to compile DFHack so I can do some plugin programming, I've decided to try out raw modding again. Here I have an implementation of an old idea of mine -- a grenade mod! Grenades are used like so (they can only be used by adventurers for now):

Place the grenade in your hand or on the floor.
Go to the x menu and select "Unpin grenade," and then select the grenade you want to unpin. You now have an <<ACTIVE GRENADE>>.
Throw the grenade IMMEDIATELY afterwards or you will catch fire (you won't explode unless you wait even longer.)
After some amount of time (I didn't measure it exactly, but somewhere around 20-30 ticks) the grenade will explode, giving every creature in the vicinity EXTREME necrosis of the skin and pretty severe pain and bleeding of all tissues (as well as coughing out blood after some time, if they survive that long.)

Download the mod from here and unzip it into the /raw/objects folder inside your DF folder.

Feel free to copy or modify this in any way in your own projects, so long as you remember to give me credit.

(TBH, I'm not sure if this is fully functional since I don't the requirements for items to show up in mead halls, weapon stores and the like. I've made the grenade item an ITEM_WEAPON, is that enough?)

If anyone is interested in how this works feel free to ask me.

DF Dwarf Mode Discussion / How to allow volcanoes to generate in low elevations?

« on: February 09, 2018, 03:53:19 pm »

Hello everyone,

Does anyone know of a way to allow volcanoes to generate in low elevations? I've been making several volcano-heavy worlds, but I never get my desired embark surroundings because almost all the volcanoes spawn in the mountains, which generally don't have any trees, vegetation or soil. Is there a worldgen parameter I could change so that volcanoes can spawn at all elevations? Thanks.