<<Prev Next>> Scroll to Bottom
Stuff goes here
L1[02:09:14] ⇨
Joins: travis-ci
(travis-ci!~travis-ci@ec2-54-162-122-17.compute-1.amazonaws.com)
L4[02:09:14] <travis-ci>
Railcraft/Railcraft#112 (mc-1.12.2 - aaafb43 : CovertJaguar): The
build is still failing.
L5[02:09:14] ⇦
Parts: travis-ci
(travis-ci!~travis-ci@ec2-54-162-122-17.compute-1.amazonaws.com)
())
L6[02:45:33] ⇨
Joins: travis-ci
(travis-ci!~travis-ci@ec2-54-225-37-46.compute-1.amazonaws.com)
L7[02:45:33] ⇦
Parts: travis-ci
(travis-ci!~travis-ci@ec2-54-225-37-46.compute-1.amazonaws.com)
())
L10[02:45:33] <travis-ci>
Railcraft/Railcraft#113 (mc-1.12.2 - 67b7200 : CovertJaguar): The
build is still failing.
L11[03:17:09] ⇨
Joins: travis-ci
(travis-ci!~travis-ci@ec2-54-197-79-122.compute-1.amazonaws.com)
L12[03:17:09] <travis-ci>
Railcraft/Railcraft#114 (mc-1.12.2 - fa1791e : CovertJaguar): The
build was fixed.
L15[03:17:09] ⇦
Parts: travis-ci
(travis-ci!~travis-ci@ec2-54-197-79-122.compute-1.amazonaws.com)
())
L16[04:12:38] ⇨
Joins: Nirek
(Nirek!~Nirek@ip68-11-40-69.no.no.cox.net)
L17[04:13:17] ⇨
Joins: travis-ci
(travis-ci!~travis-ci@ec2-54-225-37-46.compute-1.amazonaws.com)
L18[04:13:17] <travis-ci>
Railcraft/Railcraft#115 (mc-1.12.2 - 3a7cfc5 : CovertJaguar): The
build passed.
L21[04:13:17] ⇦
Parts: travis-ci
(travis-ci!~travis-ci@ec2-54-225-37-46.compute-1.amazonaws.com)
())
L22[04:42:12]
<Simn039> !faq
L24[07:12:19]
<zzzzrex> one day I'll get my
beloved railcraft back :(
L25[07:13:20]
<Trinsdar> Whenever's fine for me
as I'm working on a couple mods myself, both which are ic2
classic addons. One is secret
L26[07:24:16]
<Trinsdar> The other one is an addon
called ic2c extras adding a couple things from ic2 experimental.
I'm not going to say anymore as I don't want to advertise
it.
L27[07:42:02]
<Resuz>
@CovertJaguar, perhaps RC would cache rail network data so it will
use less resources to compute route?
L28[07:42:42]
<Resuz>
BTW, I love that idea!
L29[07:43:10]
<Forecaster> what idea
L30[07:52:39]
<Resuz>
automatic routing to choosen destination
L31[07:53:20]
<Forecaster> railcraft will not do
that
L32[07:53:59]
<Forecaster> not beyond what's
there currently
L33[07:56:40]
<Resuz>
Well, I don't know what there is currently, since I'm not
a ptreon ?
L34[07:57:07]
<Forecaster> it's the same system
as in prior versions
L35[07:57:41]
<Forecaster> the routing hasn't
changed in 1.12
L36[11:05:57] ⇨
Joins: Vexatos
(Vexatos!~Vexatos@p200300C107205E439B9CC796481E4959.dip0.t-ipconnect.de)
L37[11:18:23]
<liach>
@Resuz railcraft does not compute a rail network. only traincarts
and signals do so
L38[11:51:16]
<Darkelarious> @liach just for funs
'n giggles, what would it take to make that happen?
L39[11:51:30]
<Darkelarious> or better rephrasing,
how could interaction between train and track be improved?
L40[12:01:51]
<Forecaster> it's not going to
happen, like CJ said, there is nothing wrong with the routing
system
L41[12:15:58]
<liach>
@Darkelarious That tracking is relatively expensive and performance
costly; as a result, even if rc needs to add it, it will be in a
module disabled by default, or the performance will be too
bad
L42[12:18:04]
<Its_Chris_2003> I like the routing
system. @Resuz just go play train simulator if you wanna get that
complex, but expect minecraft stuff to be basic because it's
minecraft, there are limitations mate
L43[12:19:20]
<liach>
in fact it's not that hard if sponge is present. sponge posts
some block change events that can let mods/plugins update less
frequently (sponge events are for more than one blocks)
L44[12:19:55]
<Its_Chris_2003> ooooh
L45[12:20:00]
<Its_Chris_2003> thats interesting
ngl
L46[12:20:25]
<Its_Chris_2003> i'm no coder,
but can you apply those rules to a cart?
L47[12:20:44]
<Its_Chris_2003> i play so many
simulation and sandbox games and get into so many codes, they can
all get confusing xD
L48[12:23:50]
<liach>
The most important issue is how to restore a map after blocks
changed
L49[12:38:12]
<Its_Chris_2003> ye
L50[13:00:19]
<CovertJaguar> To be fair, the charge
network already does something similar, so I have considered
it
L51[13:00:55]
<CovertJaguar> It would need to be a
more detailed graph than the charge network yes, but doable
L52[13:02:38]
<CovertJaguar> Then I started thinking
about how you define destinations, how the train decides when to
turn, what the user interface looks like, and frankly it
didn't seem worth the design effort alone to bring all those
bits together into something elegant and intuitive
L53[13:03:15]
<CovertJaguar> Additionally you then
lose the power of conditional routing that the current system
has
L54[13:04:40]
<CovertJaguar> Another problem was
trains traveling down tracks they shouldn't, like loading
tracks for other trains, just because it's the shortest
route
L55[13:06:05]
<CovertJaguar> Which would mean some
method of prioritizing routes, possibly another track for making
routes less likely, and it just kept getting more complicated
L56[13:06:52]
<CovertJaguar> Not just from an
implementation standpoint, but from a user standpoint as well
L57[13:09:08]
<CovertJaguar> It works in Factorio
because trains can ignore stations and because the routing is tied
into the signalling, and because factorio is a 2D map that is
always 100% loaded and quite a bit smaller
L58[13:12:08]
<CovertJaguar> Automatic routing in
Railcraft wouldn't be able to handle launcher tracks or
elevators either, which would probably mean some other track for
forcing a route to traverse non track terrain. By the time the
system was feature comparable to the existing system anyone using
it would need to understand node graphs and A* and the traveling
salesman problem.
L59[13:13:12]
<CovertJaguar> I suspect at that point
people would prefer the existing system ?
L60[13:17:03]
<Darkelarious> i'm thinking more
towards the "human" version , where trains can drive
through red
L61[13:17:21]
<Darkelarious> which could translate
to a red signal, but no stopping tracks
L62[13:17:30]
<Darkelarious> of course, the first
reaction would be "but that's stupid"
L63[13:17:58]
<Darkelarious> on the other hand, what
if trains could literally halt in front of a signal without
additional blocks?
L64[13:18:35]
<Darkelarious> implementation wise it
would be a bitch though
L65[13:19:56]
<CovertJaguar> That's not too
hard, the signal is already scanning the closest track, having it
look for and stop locomotives is simple enough
L66[13:20:52]
<CovertJaguar> But I rather liked the
idea of a complex system arising out of simple parts that is a big
theme of minecraft
L67[13:21:15]
<Darkelarious> true that
L68[13:22:26]
<Darkelarious> what I truly would like
to see is more ?cosmetics? towards electric rail, like the overhead
line, portals to hold them and end-portals for dead tracks
L69[13:22:41]
<CovertJaguar> Portals?
L70[13:22:52]
<Darkelarious> those posts around
electric tracs
L71[13:22:54]
<Darkelarious> tracks
L72[13:23:06]
<CovertJaguar> The pantographs will
probably come someday
L73[13:23:40]
<Darkelarious> but also the regular
things around it
L74[13:23:46]
<Darkelarious> right now i use steel
fences and iron bars
L75[13:23:49]
<Darkelarious> which looks great
L76[13:23:59]
<CovertJaguar> Especially if we do add
a long range power transmission layer, it will require a lot of the
same code as pantographs
L77[13:24:11]
<Darkelarious> but at corners/dead
ends there's no way to add the finish
L78[13:24:45]
<Darkelarious> what if you get the
power from the tracks as it is now, and just do a check "if
overhead line drive else stop"?
L79[13:25:15]
<CovertJaguar> The main holdup is
drawing and placing the wires
L80[13:25:20]
<Darkelarious> myeah
L81[13:25:47]
<Darkelarious> and what kind of wire
would you use? single line? double line?
L82[13:25:59]
<Darkelarious> and real lines zigzag a
bit
L83[13:26:01]
<Darkelarious> and such
L84[13:26:24]
<Darkelarious> you can make it as
crazy as you want, but i'd settle for iron bars and iron
fences that connect to it properly
L85[13:26:38]
<Darkelarious> or some combo-block
that functions to hold them
L86[13:27:04]
<CovertJaguar> Drawing lines opemgl is
easy enough, but you need some way to attach them to posts and it
fill the gap in between with blocks
L87[13:28:01]
<CovertJaguar> It's not
complicated especially, force track emitter is basically the same
thing, but it is a bit more effort than a simple block
L90[13:30:10]
<Darkelarious> ( \*proud of the last
one being an own photo \* )
L91[13:35:33]
<CovertJaguar> It's probably
possible to accommodate both designs without looking to strange in
either configuration
L92[13:38:53]
<CovertJaguar> Probably a block that
you place on top of the existing post blocks in Railcraft, that
extends lines between it and the next one
L93[13:39:59]
<CovertJaguar> The main issue is how
to pair them
L94[13:40:41]
<CovertJaguar> Probably a special
wiring tool or something, similar to the signal tuner and signal
surveyor
L95[13:41:29]
<CovertJaguar> I don't know what
line ends look like
L96[13:57:17]
<CovertJaguar> What would help is some
photos of electrified mining trains
L99[14:01:16]
<CovertJaguar> Minecarts are really
short compared to standard trains, meaning very tall
pantographs
L101[14:02:54]
<CovertJaguar> I like this one, looks
a lot like our locomotives
L103[14:29:30]
⇨ Joins: ImQ009
(ImQ009!~ImQ009@89-64-45-113.dynamic.chello.pl)
L104[14:33:13]
<Darkelarious> immersive engineering
did nice things with wires
L105[14:52:38]
<CovertJaguar> Yes, the power poles,
that's kind of the idea
L106[15:05:23] ⇦
Quits: ImQ009 (ImQ009!~ImQ009@89-64-45-113.dynamic.chello.pl)
(Quit: Leaving)
L107[15:09:42]
<AlexJ6301> Just going back to routing
- the current system could really do with a much longer ticket
string, or just more strings to pattern match in the ticket. Yes,
with the current system you have to plan your routing code system,
and implement it everywhere, but that’s kind of fun to invent. For
a large rail network, though, you are limited by the 63(?)
characters in the ticket...
L108[16:17:01]
<CovertJaguar> There has been talk of
ticket books, sequential lists of tickets
L109[16:17:49]
<CovertJaguar> 63 characters is enough
to get you anywhere in the USA, I don't see why you'd
need more =P
L110[16:18:59]
<CovertJaguar> the limit is there
mostly because of GUI limitations
L111[16:19:16]
<CovertJaguar> there aren't great
solutions
L112[16:20:01]
<Natesky9> Yeah, the entity system
doesn't work well for trains, given the limitations of the
game
L113[16:23:38]
<CovertJaguar> Forge might have
finally fixed the disappearing/duping entity bug
L114[16:23:49]
<CovertJaguar> the other major bug is
locomotive reversal
L115[16:24:08]
<CovertJaguar> other than that it
works alright
L116[16:24:39]
<CovertJaguar> there has been talk of
making minecarts tougher against mobs so there is less random
skeleton train deaths
L117[16:25:28]
<CovertJaguar> I guess the other major
problem is trains getting cut in half by chunkloading
L118[16:25:49]
<CovertJaguar> that one is kind of
hard to completely eliminate
L119[16:26:22]
<Natesky9> Why not make the entire
train one entity?
L120[16:26:53]
<Natesky9> That sounds weird, but hear
me out
L121[16:27:21]
<Natesky9> When you link cards
together, they essentially become as one object
L122[16:27:25]
<CovertJaguar> its been considered
before, but have you seen the minecart code?
L123[16:28:15]
<Natesky9> Oh, I know it's a
complete and utter hack
L124[16:28:20]
<CovertJaguar> even if we assume we
can solve the loader/unloader issue of drilling down to a specific
cart, we'd still have to make the crazy thing follow the
tracks
L125[16:28:33]
<CovertJaguar> and it would
incompatible with other mods
L126[16:30:35]
<CovertJaguar> we'd be talking an
EntityMinecart that holds other EntityMinecart objects
L127[16:31:26]
<Natesky9> What if you stored the
whole train data inside the "main" cart of a train, and
then treated it like a parent/child, where trains loaded don't
exist without a parent
L128[16:32:00]
<CovertJaguar> carts riding a cart I
guess....which can be done with current code, though the rendering
would need a rewrite
L129[16:32:28]
<CovertJaguar> also the collision
boxes would be nasty, but possibly solvable with multi-part
entities like the Tunnel Bore does
L130[16:32:38]
<Natesky9> *thinks back to the boat
tentacle video*
L131[16:33:08]
<CovertJaguar> I mean its not
impossible....but the rendering would be complicated even if its
mostly just a refactor of the current render code
L132[16:33:48]
<Natesky9> There are just so many odd
obstacles that require odd solutions
L133[16:33:48]
<CovertJaguar> and we'd still be
held enslaved to the whims of the orientation code
L134[16:34:40]
<CovertJaguar> though in theory our
Train Minecart wouldn't need to use Mojangs Minecart
code
L135[16:34:57]
<CovertJaguar> and could override it
all and provide a better solution for orientation
L136[16:35:07]
<CovertJaguar> but maths....lots of
maths...
L137[16:35:41]
<Natesky9> Well, at the core of it,
trains only go in 4 directions, right? So to solve the locomotive
reversing issue, each track can only go straight, left, or right on
each new track it travels to
L138[16:36:09]
<CovertJaguar> corners have 360
degress of rotation
L139[16:36:21]
<Natesky9> If we assume that minecarts
are spaced exactly 1 block between
L140[16:36:28]
<Natesky9> What do you mean?
L141[16:37:07]
<CovertJaguar> well the client render
code already takes an approximate minecart position and
interpolates it onto the nearest track, so that's not super
hard
L142[16:37:59]
<Natesky9> If a cart enters from the
east, it can only return west in a straight track, North or south
in a turn, or, in special junction tracks, it's dependent on
the state of the track
L143[16:38:03]
<CovertJaguar> because for what ever
reason the server->client sync code drops several digits of
precision
L144[16:38:40]
<Natesky9> Yeah, that used to fuck up
boats too
L145[16:39:46]
<CovertJaguar> anyway, it could be
done and there are obvious solutions to most of the problems, but
it would be a lot of work
L146[16:40:22]
<CovertJaguar> and I have to wonder
how it would handle super long trains
L147[16:41:06]
<CovertJaguar> you'd probably
need some kind of travel history to know where to render the
carts...and God forbid that we try to reverse the direction of
travel
L148[16:41:14]
<Natesky9> Well, at the moment, super
long trains are not feasible
L149[16:42:15]
<Natesky9> I haven't had any luck
with trains over 8
L150[16:42:38]
<CovertJaguar> yeah that's about
the limit, what the main issues you encounter?
L151[16:42:57]
<CovertJaguar> I don't get enough
hands on experience with this stuff
L152[16:43:37]
<Natesky9> Just general cart jamming,
locomotive reversing
L153[16:43:57]
<CovertJaguar> by jamming you mean
like carts flipping position in the train?
L154[16:44:21]
<CovertJaguar> I guess that does
happen sometimes
L155[16:44:48]
<Natesky9> Yeah, happens alot,
especially near locking tracks and even at low speeds
L156[16:45:22]
<CovertJaguar> I wonder if it might be
possible to add some code to repair trains that get shuffled like
that...hmm
L157[16:46:07]
<CovertJaguar> I'm not really
sure what causes it, probably just the lack of precision due to
only 20 ticks per second
L158[16:50:27]
<CovertJaguar> I have a solution...it
should be pretty simple to make it so that carts in a train
can't collide with each other
L159[16:50:45]
<CovertJaguar> as long as the linkage
code is stiff enough on compression, it should work out
L160[16:51:30]
<Natesky9> I think part of the problem
*is* the compression
L161[16:53:30]
<CovertJaguar> yeah, but the reason it
can't fix itself is because of the carts colliding with each
other
L162[16:54:17]
⇨ Joins: Icedream
(Icedream!~icedream@212.83.173.97)
L163[16:54:54]
<Natesky9> What if
L164[16:55:17]
<Natesky9> The carts don't
collide with any other carts in the train
L165[16:55:46]
<Natesky9> And have a set distance
from each other, starting with the parent, or head of the
train?
L166[16:56:13]
<CovertJaguar> well the linkage code
already has set distances between carts that it tries its best to
maintain
L167[16:56:34]
<CovertJaguar> fixed distances
don't really work as the only way we can move carts is by
applying forces
L168[16:56:48]
<Natesky9> But if you've locked
two separate cats on the same train, it tries to fight
L169[16:57:22]
<Natesky9> Also, any forces should be
applied to the parent cart
L170[16:57:25]
<CovertJaguar> oh the bouncy trains?
yeah, damping could probably be higher
L171[16:57:34]
<Natesky9> Not individual carts
L172[16:57:52]
<CovertJaguar> how would you move the
child carts then?
L173[16:58:07]
<CovertJaguar> you can't really
just save "move it to x,y,z"
L174[16:58:16]
<CovertJaguar> you can't really
just say "move it to x,y,z" [Edited]
L175[16:58:23]
<Natesky9> They inherit the
parent's momentum
L176[16:58:29]
<Natesky9> But don't affect
it
L177[16:58:38]
<Natesky9> Except to communicate their
drag
L178[16:59:02]
<CovertJaguar> ah... I tried that
once, making child carts follow the lead exactly...I ran into issue
with determining who was the leading cart
L179[16:59:42]
<Natesky9> If not the cart in front,
it should be the lowest entity id
L180[16:59:43]
<CovertJaguar> I ended up with
"getLeadCart(){ // do magic here }"
L181[17:00:01]
<Natesky9> That assures that you only
ever have one
L182[17:00:04]
<CovertJaguar> define
"front"
L183[17:00:53]
<Natesky9> Well, when you link two
carts, both carts are a valid "front"
L184[17:01:11]
<Natesky9> Unless one is
"sided", like a locomotive
L185[17:01:17]
<CovertJaguar> yeah, each train has
two valid options....which do you pick?
L186[17:01:34]
<CovertJaguar> its based on the
direction of travel, but that changes, frequently
L187[17:01:35]
<Natesky9> I guess whichever direction
it moves in
L188[17:01:54]
<Natesky9> Direction changes are fine,
that actually helps
L189[17:01:56]
<CovertJaguar> and I never figured out
how to tell which direction is train is moving in reliably
L190[17:02:07]
<Natesky9> States
L191[17:02:39]
<CovertJaguar> well...the tunnel bore
uses states for that, but its harder to apply to a minecart that
needs to turn
L192[17:02:47]
<Natesky9> Each rail has one input,
one output
L193[17:03:09]
<Natesky9> If you assume that the
tracks can not change halfway through transit
L194[17:03:44]
<Natesky9> (Which solves another
common problem)
L195[17:03:56]
<Natesky9> Cart pinching
L196[17:05:57]
<CovertJaguar> ah... yeah I think I
know to which you refer
L197[17:06:28]
<CovertJaguar> hmm....why is the
locking track not stopping my train....ugh
L198[17:06:54]
<CovertJaguar> main reason I
can't do any of this fancy stuff....everything else is
broken....
L199[17:07:09]
<Natesky9> Actually, have you looked
at llama code? Serous question
L200[17:07:45]
<CovertJaguar> llama?
L201[17:09:53]
<CovertJaguar> oh...interesting.... I
didn't know that was a thing
L202[17:10:00] <MrConductor> *
<CovertJaguar> in his own little world
L203[17:10:47]
<Natesky9> Yeah, llama caravans
L204[17:11:12]
<Natesky9> You lead one, and the rest
follow single file
L205[17:11:19]
<Natesky9> Try it out
L206[17:11:39]
<CovertJaguar> hmm... looks like
simple flocking formations
L207[17:11:54]
<CovertJaguar> which is similar to
what I'm already doing with trains
L208[17:12:51]
<CovertJaguar> I've not tried a
linear flock before, but I have made flocks of space ships fly in
formation in a 2D game before
L209[17:13:49]
<CovertJaguar> again, its mostly just
a simple result of apply outward forces if too close and inward
forces if too far
L210[17:13:51]
<Natesky9> Yeah, boids I think
they're called?
L211[17:15:09]
<Natesky9> See if you can look more
into the vanilla code, I'm not sure if it is flocking
L212[17:15:53]
<Natesky9> They move too instant, it
doesn't look springy iirc
L213[17:16:14]
<Vectrobe
(Paul17041993)> less flocking and more "I'm going to
follow this one entity"
L214[17:16:38]
<Vectrobe
(Paul17041993)> with pathing cloned over
L215[17:17:04]
<Natesky9> Yeah, holding wheat is
kinda a forced flocking, but only because they're too
thick
L216[17:17:26]
<Vectrobe
(Paul17041993)> sorta
L217[17:17:52]
<CovertJaguar> it looks like it just
looks for the nearest leashed llama and then adds a follower to it,
and then each successive llama follows the tail of the
caravan
L218[17:18:14]
<Natesky9> You ever get swallowed by a
cow nosh pit?
L219[17:18:21]
<Vectrobe
(Paul17041993)> proper flocking involves either a
weight/velocity map, or otherwise monitoring the velocity of all
nearby entities
L220[17:19:02]
<CovertJaguar> yeah, it seems to be
using pathfinding rather than forces
L221[17:20:39]
<Vectrobe
(Paul17041993)> at any rate, whole trains should share the
forward-backward velocity to each cart
L222[17:20:57]
<Vectrobe
(Paul17041993)> with a pinch of offset velocity
L223[17:21:07]
<Natesky9> Railcraft 2.0 *inspired by
llamas*
L224[17:21:36]
<Natesky9> You could even do without
the offset
L225[17:21:57]
<Vectrobe
(Paul17041993)> the offset would be to counter carts being in
odd positions
L226[17:21:57]
<Natesky9> That's almost just
cosmetic
L227[17:22:17]
<Natesky9> What do you mean
L228[17:22:47]
<Vectrobe
(Paul17041993)> like, when you link carts, they run at different
velocity for a fraction of time, to balance out their
distances
L229[17:23:59]
<Vectrobe
(Paul17041993)> each cart would keep that 'offset'
velocity, but would have the majority of their velocity value
synced with the whole train
L230[17:24:40]
<Vectrobe
(Paul17041993)> engine carts would simply add/subtract to that
synced value
L231[17:25:22]
<Natesky9> Side effect of the current
system, if the carts sync their momentum, there won't be any
compressive forces
L232[17:25:26]
<Vectrobe
(Paul17041993)> technically it'd make the trains act like
an EMU, but for minecraft it's a better option than the 20t/s
springyness
L233[17:25:58]
<Vectrobe
(Paul17041993)> there could be an additional
'compress' variable though
L234[17:26:37]
<Natesky9> Mmm, let's focus on
getting it to work smoothly first
L235[17:27:02]
<Natesky9> Then maybe add
features
L236[17:30:20]
<Vectrobe
(Paul17041993)> on another note, I wonder if I should resurrect
this in rc... ?
L238[17:35:25]
<Natesky9> Actually
L239[17:36:06]
<Natesky9> What's that one snake
game where you eat things to grow, and you eat other snakes by
biting their tails
L240[17:37:45]
<Vectrobe
(Paul17041993)> nokia snake?
L241[17:37:56]
<Vectrobe
(Paul17041993)> jk, slither.io
L242[17:38:18]
<CovertJaguar> enter the
idiot....locking tracks only lock when _NOT_ powered....its been
way too long...
L243[17:38:18]
<Vectrobe
(Paul17041993)> basically the same thing as llamas
L244[17:38:50]
<Vectrobe
(Paul17041993)> imo I'd expect them to lock when
powered
L245[17:39:20]
<Vectrobe
(Paul17041993)> but also, it makes sense for them to lock when
unpowered
L246[17:40:06]
<Vectrobe
(Paul17041993)> oh wait are they tooltip'ed?
L248[17:40:52]
<Vectrobe
(Paul17041993)> censor plz
L249[17:41:29]
<CovertJaguar> the first loco has two
carts attached, they have collisions turned off (I presume, I did
it right), the second loco is compressing the train
L250[17:42:05]
<CovertJaguar> I need to make sure
they aren't colliding
L251[17:42:06]
<Vectrobe
(Paul17041993)> oh you semi-removed vanilla's and now using
your own phys?
L252[17:42:24]
<CovertJaguar> been using my own
physics for this stuff since day 1 =P
L253[17:42:40]
<Vectrobe
(Paul17041993)> wellye
L254[17:42:44]
<CovertJaguar> vanilla manages keeping
them attached to the tracks, I do everything else
L255[17:49:25]
<CovertJaguar> hmm...its not as simple
as I assumed
L256[17:49:31]
<Natesky9> Well, the thing is, you
don't want trains to share a track, right?
L257[17:53:52]
<YukaiDragon> this is a very weird
question but does ore spawn in a specific biome, talking about the
poor ore
L258[17:54:47]
<Natesky9> Should be everywhere
L259[17:55:10]
<Natesky9> If you want to test,
there's a test config that spawns it in the sky instead
L260[17:58:17]
<Vectrobe
(Paul17041993)> everywhere, but wide spread
L261[17:58:37]
<Vectrobe
(Paul17041993)> so stripminig wont exactly work
L262[17:58:44]
<CovertJaguar> some biomes have more
of some kinds than others
L263[17:58:48]
<Vectrobe
(Paul17041993)> so stripmininig wont exactly work [Edited]
L264[17:58:51]
<CovertJaguar> mountains mainly
L265[17:58:55]
<Vectrobe
(Paul17041993)> so strip mining wont exactly work [Edited]
L266[18:03:27]
<Natesky9> Nice to see you back, by
the way, CJ
L267[18:05:18]
<CovertJaguar> ok, I have successfully
made minecarts ghost through each other
L268[18:05:47]
<CovertJaguar> that does not seem to
be enough to untangle trains unfortunately
L269[18:05:53]
<CovertJaguar> the linkage code
prevents it
L270[18:06:35]
<Natesky9> No, because you're
still treating it like a spring
L271[18:07:21]
<Natesky9> A train is more like a
chain than a rubber band in terms of physics
L272[18:08:38]
<CovertJaguar> assuming I could solve
the "front cart" problem... it still wouldn't work
to base position off position in the train right? because of
corners
L273[18:08:44]
<CovertJaguar> hmm
L274[18:09:51]
<Natesky9> Assuming that carts are
exactly 1 block apart
L275[18:10:02]
<CovertJaguar> more or less
L276[18:10:55]
<Natesky9> Let's just say for
math reasons
L277[18:11:10]
<Natesky9> If carts are exactly 1
meter apart
L278[18:11:46]
<Natesky9> You will always be able to
go from front to back, and tell what positron the carts will be
at
L279[18:12:08]
<CovertJaguar> that only works in a
straight line, on flat terrain
L280[18:12:36]
<Natesky9> Can also worth on corners
and slopes
L281[18:12:42]
<CovertJaguar> how?
L282[18:12:50]
<Natesky9> Since the actual position
is interpolated
L283[18:13:34]
<CovertJaguar> I'd have to do
some kind of ugly track scanning
L284[18:13:50]
<CovertJaguar> and that would break
hard on switches and junctions
L285[18:16:27]
<CovertJaguar> also the client seems
to be handling junctions wrong again....bleh
L286[18:16:32]
<CovertJaguar> everything always
broken
L287[18:17:17]
<CovertJaguar> it wrong in both
directions but only some of the time!
L288[18:17:24]
<CovertJaguar> and speed doesn't
matter
L289[18:18:20]
<CovertJaguar> at least its just
cosmetic
L290[18:18:55]
<Natesky9> Sorry, I'm kinda at
work, so I'm off and on
L291[18:20:09]
<CovertJaguar> I turned off all the
bounding boxes and collision boxes on minecarts but I can _still_
push them around with my avatar.... right...
L292[18:22:53]
<Natesky9> You have any debug draw
functions?
L293[18:23:13]
<CovertJaguar> for bounding boxes? I
think there is something like that
L294[18:24:13]
<Natesky9> No, I mean custom
ones
L295[18:25:10]
<Natesky9> To help you track down
bugs
L296[18:25:41]
<CovertJaguar> I have train aura on
the goggles for tracking down linkage errors
L297[18:27:26]
<YukaiDragon> i was wondering that
because I cannot find tin and other ones im really needing XD
L298[18:28:48]
<Natesky9> Oh, the ores
L299[18:31:33]
<CovertJaguar> I guess if I remove
collisions (if that's possible to do selectively) and then
make the spring more a chain, with a expansion force from the
centroid of the train....it might work?
L300[18:33:16]
<CovertJaguar> if carts are always
pushed away from the center, to their maximum distance allowed from
the next linked cart....it should sort itself out
L301[18:34:55]
<CovertJaguar> it could get a bit
weird with big trains going around circles....but that's all I
can think of
L302[18:37:42]
<CovertJaguar> its been a long time
since I looked at spring forces....hmm
L303[18:39:23]
<CovertJaguar> I should be able to
turn off near distance forces pretty easily...
L304[18:40:49]
<CovertJaguar> well....it did
something....and then it crashed.... lol
L305[18:42:05]
<CovertJaguar> what it didn't do
was a very good job of keeping the carts close together
L306[18:42:51]
<CovertJaguar> ugh... more concurrent
modification of the train object....presumably because the carts
got too far apart
L307[18:43:12]
<CovertJaguar> now I have to remember
where that code is
L308[18:44:46]
<CovertJaguar> also ...... Saving
224,208 Trains...
L309[18:45:24]
<CovertJaguar> on a world that only
ever had maybe a half dozen trains
L310[18:46:01]
<CovertJaguar> I can't do
anything without finding a dozen other bugs
L311[18:48:51]
<Natesky9> I definitely want to help,
if you can wait a bit for me to get done with work
L312[18:49:08]
<CovertJaguar> well I'll try and
fix the train issues for now
L313[18:49:29]
<Vectrobe
(Paul17041993)> I havnt checked as of late, is there any form of
'line' interface for rails? or is it purely
scan-the-block-below and snap-in?
L314[18:50:06]
<CovertJaguar> for carts? they
generally just look for the nearest track and snap to it
L315[18:50:06]
<Vectrobe
(Paul17041993)> I guess not...
L316[18:50:10]
<Vectrobe
(Paul17041993)> yea
L317[18:50:45]
<Vectrobe
(Paul17041993)> was thinking a line system where carts only have
a point stored in the line system, but that sounds 'too
complex for minecraft'
L318[18:51:51]
<Natesky9> If the rails connected,
like some sort of cable network, then yeah
L319[18:52:12]
<Natesky9> But the problem then lies
with*eddy* cable network
L320[18:52:12]
<Vectrobe
(Paul17041993)> what really bums me about writing mods; my
systems hit a point in designing where I'd rather make it my
own game, than continue to implement it....
L321[18:52:28]
<Vectrobe
(Paul17041993)> *eddy*?
L322[18:52:29]
<Natesky9> But the problem then lies
with *every* cable network [Edited]
L323[18:53:48]
<Natesky9> Yes, but then you lose the
platform which would otherwise make your work visible
L324[18:53:58]
<Vectrobe
(Paul17041993)> yea, that's just it
L325[18:55:21]
<Vectrobe
(Paul17041993)> are signal blocks connected to a network system?
or simply linked between tile entities?
L326[18:55:59]
<Natesky9> Iirc, the other end does
not need to be chunkloaded, so I assume a network?
L327[18:56:11]
<Vectrobe
(Paul17041993)> mm
L328[18:56:47]
<Natesky9> But trains within the block
need to be loaded
L329[18:57:53]
<Vectrobe
(Paul17041993)> oh now there's an idea...
L330[18:58:24]
<Vectrobe
(Paul17041993)> trains that run on a line system would be able
to run over unloaded chunks
L331[18:58:38]
<Vectrobe
(Paul17041993)> that sounds interesting...
L332[18:59:05]
<Vectrobe
(Paul17041993)> problem is, implementing a line system over the
mc rails might be rather memory intensive
L333[18:59:54]
<Vectrobe
(Paul17041993)> even with chunk-relative containers, you'd
still need to store rail locations and their types
L334[19:00:14]
<Vectrobe
(Paul17041993)> power's a bit of an issue as well...
L335[19:00:31]
<Natesky9> Yeah, that's been
discussed
L336[19:00:37]
<Natesky9> Several times
L337[19:00:55]
<Natesky9> But it's not as easy
as, say, factorio
L338[19:01:51]
<Vectrobe
(Paul17041993)> yea
L339[19:02:12]
<Vectrobe
(Paul17041993)> kinda why they opted for a single track type
too
L340[19:03:51]
<Vectrobe
(Paul17041993)> I think I might experiment with it anyway
though, as I've been wanting to make an extended-block-data
library anyway
L341[19:04:38]
<Vectrobe
(Paul17041993)> one that allows for 'wide meta' as
opposed to TE's everywhere
L342[19:05:19]
<Natesky9> You check out the new
charge system in railcraft?
L343[19:10:39]
<Vectrobe
(Paul17041993)> yes and no?
L344[19:11:42]
<Natesky9> No more tile entities for
electric tracks
L345[19:11:53]
<Vectrobe
(Paul17041993)> my fork's out of sync atm as I was looking
to fix another mod's compatibility
L346[19:12:02]
<Vectrobe
(Paul17041993)> oh cool
L347[19:28:08]
<CovertJaguar> signals just store
their pairs position and use that to search for carts, even across
unloaded chunks
L348[19:29:13]
<CovertJaguar> charge does build a
graph outside of the world, and any routing or signalling system
that needed to do pathfinding could do the same
L349[19:29:50]
<CovertJaguar> but these are
complicated systems, not necessarily that costly if done right,
still complicated no matter what
L350[19:44:01]
<Natesky9> Yeah, and there's
still the issue of rails not actually being necessary, or a core
mechanic of gameplay
L351[20:15:39] ⇦
Quits: Vexatos
(Vexatos!~Vexatos@p200300C107205E439B9CC796481E4959.dip0.t-ipconnect.de)
(Quit: Insert quantum chemistry joke here)
L352[20:27:09]
<Natesky9> I'd *love* them to be
at least half as practical as hoppers
L353[20:28:18]
<Natesky9> But, being entities, they
are just impractical and unreliable
L354[22:02:16]
<YukaiDragon> fiddled with the config
settings and ores are still barely spawning hmm,,,
L355[22:04:46]
<CovertJaguar> the skygen setting is
your friend
L356[22:05:08]
<CovertJaguar> if you want it to be
more frequent you will need to change the noise cloud scalars
L357[22:07:07]
<CovertJaguar> @YukaiDragon
railcraft.cfg->worldgen->skygen
L358[22:07:57]
<CovertJaguar> use only on throwaway
worlds ;)
L359[22:08:38]
<YukaiDragon> whoa
L360[22:08:47]
<YukaiDragon> damn...umm....thats a
lot of ore in the sky
L361[22:11:42]
<CovertJaguar> so...preliminary
results from centroid forces are.... mixed....
L362[22:11:51]
<CovertJaguar> it works....sort
of
L363[22:12:13]
<CovertJaguar> but causes phantom
forces and corner issues
L364[22:15:38]
<YukaiDragon> that was a lot XD
L365[23:55:17] ⇦
Quits: Icedream (Icedream!~icedream@212.83.173.97) (Ping timeout:
180 seconds)