Print

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

[Reelya]

Yup, i didn't know about those files, but it's handy.

This looks like some pretty simple modeling where things are point masses. Having individual fields for XYZ location, velocity and acceleration isn't that great. In a proper physics simulation there would be at least one matrix or quaternion in here to account for object location and orientation in space.

Also note that parabolic is a flag. Which means it exists to be turned on or off. We have no direct evidence that this is being used all the time or whether it's placeholder stuff that's not active.

[Putnam]

It's used specifically in minecarts, has existed since 0.34.08.

EDIT: Oh, I missed the patch notes from 0.34.09:

Code: [Select]

All flying units use new minecart parabolic flight paths
turns out i've been mistaken about that for 6 years

EDIT 2: Yeah, the devlog from 4/20/2012 was the first one mentioning them:

Code: [Select]

The struck units move in parabolic arcs now (instead of the old fly straight then fall straight down).

[Miles_Umbrae]

Question: Isn't movement, spatial occupation, and graphical representation three distinct and separate parts of the games coding?
Also: Isn't movement through a one-square space like for example a door subdivided into 10 on either of the X, Y & Z axes?

[Putnam]

position and movement are 1:1 with graphics, movement is not "move 1/n tiles every tick" but "move to this tile in n ticks"

[Reelya]

Which also allows far more efficiency. For example, if you move n-distance every tick, then every object needs to be moved on every tick, and you need to run real-time collision detection against 3D bounding boxes for every item in the scene against every other item in the scene. 100 world items means potentially 10000 collision detections per frame, or applying a complex graph system to reduce the number of checks.

Whereas what Putnam is describing is just much much faster to compute. You know that a particular object will move in 300 ticks, so you just make a list of all active things. For example, if there are 1000 objects but nothing is going to happen for 200 ticks, you're not running 200 x 1000 update functions for each object for those 200 ticks, you just look "oh, the next thing moves in 200 ticks, so advance the clock by 200 then move that object. Then, work out when that object moves again, and insert it back into the queue wherever it belongs. Now, what's next to move?" Also, things being 100% in or out of a cell means you can just have a true/false flag for whether there's anything in a tile, and you can maintain a list of stuff there for each tile that needs one.

[Miles_Umbrae]

With spatial occupation I meant how much of a square an entity occupies.
For example, a dog takes up less of a square than a dwarf or cow does.
Several dwarves can pass by each other in the same square simultaneously.

[Putnam]

That's... totally wrong. Occupancy rules are as follows:

1. Any amount of units that are lying down can occupy a tile.
2. Exactly one unit that is standing can occupy a tile.

These are the only rules. Size has nothing to do with it. You can fit 100 dragons in a tile, but all of them have to be lying down except one.

[Miles_Umbrae]

That's... totally wrong. Occupancy rules are as follows:

1. Any amount of units that are lying down can occupy a tile.
2. Exactly one unit that is standing can occupy a tile.

These are the only rules. Size has nothing to do with it. You can fit 100 dragons in a tile, but all of them have to be lying down except one.

Strange then that I seen several dwarves and/or animals occupy the same square a few ticks...

[Fleeting Frames]

All of them expect on have been lying down.

[Putnam]

That's... totally wrong. Occupancy rules are as follows:

1. Any amount of units that are lying down can occupy a tile.
2. Exactly one unit that is standing can occupy a tile.

These are the only rules. Size has nothing to do with it. You can fit 100 dragons in a tile, but all of them have to be lying down except one.

Strange then that I seen several dwarves and/or animals occupy the same square a few ticks...

Odd indeed, since what I said was determined by memory hacking and is relied upon for the DFHack teleport script, which I wrote.

Code: [Select]

local unitoccupancy = dfhack.maps.getTileBlock(unit.pos).occupancy[unit.pos.x%16][unit.pos.y%16]
 local newoccupancy = dfhack.maps.getTileBlock(pos).occupancy[tonumber(pos.x)%16][tonumber(pos.y)%16]
 if newoccupancy.unit then
  unit.flags1.on_ground=true
 end
 unit.pos.x = tonumber(pos.x)
 unit.pos.y = tonumber(pos.y)
 unit.pos.z = tonumber(pos.z)
 if not unit.flags1.on_ground then unitoccupancy.unit = false else unitoccupancy.unit_grounded = false end
As you can see, there are only two flags that determine unit occupancy: "unit" and "unit_grounded". If the tile occupancy's "unit" flag is set, no unit entering that tile can stand in it. This is the only rule here.