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 - Coolthulhu

Pages: [1] 2 3 ... 241
No overmap data is preserved after a reset.
There is no explicit "mapgen seed" as in some games. Instead mapgen uses the same random number generator as the rest of the game, meaning that the generated map depends on how you explore it.

But there could be a separate generator just for mapgen, and that could be useful and "fun".

Take all your crap off the map, then delete the few megabyte file with name like o.x.y, where x and y are the overmap coords.
If you aren't sure if you got the right ones, move somewhere else (outside game directory) instead of deleting.
Then delete or rename the same coords in "maps" subdirectory, except this time the last number is z coords. You want to delete all the z-levels for the overmap.

Though note that if you purge an overmap your character is in, on loading the save your character will spawn in a fresh world, with nothing but own inventory.

Abstract, one tile "this engine is connected to drivetrain" part.
Multi-tile would be a giant pain to manage with current vehicle construction system. It would require an overlay or some other big UI rework.

Is there any way to reset an overmap? Or at least re-hide the revealed area again?

Reset: No, unless you want to regenerate the whole chunk.

Re-hide: there are files with "seen" in name. If you delete those, the character those are for will forget the overmap with given coords.

Chunk coords are seen on the in-game map. It's the most significant numbers - one chunk is 180x180 "squares" (the unit used on map), with each square being 24x24 in-game tiles.
Chunk is always 2 numbers - x and y. Z coordinate is saved in the file - that is, each overmap chunk is as tall and deep as it can be, there can be no chunks over or below it in z-coords.

Having a separate worldgen seed could be a great thing, at the very least for debugging worldgen.

As I said above, it would be most likely migration code that would attach actual drivetrains to engines, for free.

The Toolbox - Code Help / Re: Help with my first profession mod/code.
« on: June 22, 2017, 08:27:51 AM »
If I wanted to submit this to the community when I am done is there a preferred method to do so?

Make an account on github, fork the game code, add your profession to "More Professions" mod and commit the change, test the change to make sure it works, pull request the changes to the main game.
Sounds complex, but "fork repo" is literally just pressing a big green button and then OK, committing changes can be done through github web UI which is easy to use, pull request is also announced as a big green button in the github UI.

One hint which is best said early on than late: replace all tabs in your jsons with spaces. Most text editors allow searching for tabs, Notepad++ and some more advanced ones allow automatic replacement of tabs with spaces.

If the profession is found well balanced and/or well received, it may be moved to core game later on.

Vehicle part UI is already terrible, doubling the number of engines is a good way to make it worse.

The Toolbox - Code Help / Re: Help with my first profession mod/code.
« on: June 21, 2017, 08:16:34 PM »
1. No, it has to be approximated by comparing it to other professions and noticing that it's certainly better than some weak one (and thus needs higher point cost than the weak one), but certainly worse than some strong one (and thus needs a lower point cost than the strong one).

2. Does that knife fit in the sheath? Could be accidentally changed letter or typo in copying.

5. This is mostly for the technical questions, not balance. Drawing board is for figuring out how should it feel and play and getting suggestions regarding themes, Toolbox is for getting it to work.

Pretty sure that's a bug, most likely caused by incorrect range calculations failing to terminate the projectile under owner's feet/1 tile before, instead treating it as projectile all the way.

Sounds like crafting inventory not invalidating on the turn it is changed.

Is there a way to fix NPC's broken limb?

Splint, as for player.
You should be able to see the "healing" status in NPC status menu if the splint is worn correctly.

The problem is that you don't have "engine" part, it's "V12 engine", "V8 engine" and so on.
Moving engine data to items would break mods (not exactly the biggest deal but still) and would make it hard to identify which kind of engine was used (this one is a problem that would require UI rewrite).

So I'd much rather go with a new drivetrain item instead.
It would probably be simpler code-wise too.

You're neglecting the fact that these would all be good changes to the vehicle system.  In principle, we want to treat vehicles as melee/ranged targets the same as monsters. The remainder of the issues are amenable to simple workarounds.

Some of those (targeting, monsters understanding vehicle monsters) would be really clunky to implement without common creature/vehicle "addressing", for example each targetable object having a persistent target ID.
The more features would this require before it is functional, the lower the chance of it ever happening and lower the chance of it working sensibly if implemented. So a good way to approach it is to implement usable, needed, features that share common requirements with it - creatures targeting turrets, "perfect" vehicular pathing, vehicles breaking in half - and only then add the vehicle monsters on the tested, well-written foundation.

Pathing between buildings, trees, or other furniture is what makes multi-tile pathing hard, if you eliminate those, the remainder is easy.

Do you have some specific trick in mind?
I see it as A* with each rotation+velocity (quantified) being a separate "layer" of nodes (essentially 5D space - 3D position + 2D velocity vector), with each obstacle being stretched (in the cache) to the size of the vehicle, with the vehicle being shrunk to a moving point. From what I know, this is the most common way of doing this. This wouldn't have any problems with avoiding small obstacles, though it could be too paranoid about them.

Everything related to protection is relatively neatly wrapped in item.cpp, in item::damage_resist and the functions it calls. Assume to_self is false (it's only true for attacks against the item and not the wearer).

Pages: [1] 2 3 ... 241