r4m0n changed the topic of #kspmodders to: Technical discussion ONLY (KSP related or not), for random shit-talking, join #shitshow (seriously)
GlassYuri has joined #kspmodders
<GlassYuri> when someone changes the font settings in visual studio, all instances of visual studio using the same account instantly change to that asshole's new settings
<GlassYuri> which is exactly what you want in a school setting
fcbayerndm has joined #kspmodders
Supernovy has quit [Quit: be right back]
Supernovy has joined #kspmodders
<SilverFox> nice
<GlassYuri> SilverFox, also I may have a basic path finding core (for now it only does dumb path following but it doesn't have any obvious design flaws)
<GlassYuri> it is based on the idea I had when talking to you and r4m0n, where the pathfinding doesn't allow middle connections, but uses it's own type of segment which can map to part of an actual segment, allowing middle connections at a higher level
<GlassYuri> this should mean that all I have to do different from a normal pathfinding implementation is to ensure no two pathfinding segments cover the same interval of an actual segment, which boils down to float comparison
fcbayerndm has quit [Quit: fcbayerndm]
<SilverFox> GlassYuri, like I said, and will keep saying, keep it damn simple and it'll be robust. Don't get all fancy with it, get the core as simple stupid as you can, then interface with it via higher level stuff
<SilverFox> you don't build an OS on C#
<GlassYuri> SilverFox, I'm already trying way too hard
<GlassYuri> so to advance to beyond where I am right now I have to load the track connections from file
<GlassYuri> which I cannot do in school as I don't have the tools I use to build parsers here
<GlassYuri> and when I do that I have to write an entirely new parser because the old one is garbage
<GlassYuri> that could take me a week
<r4m0n> stop using custom formats and make something using a simple format someone already made efficient parsers for :-P
<GlassYuri> r4m0n, I use json for everything that is not a legacy file format
<GlassYuri> as in, I use json for settings and localization
<r4m0n> then why the talk about a new parser?
<r4m0n> JSON is perfectly fine for whatever
<GlassYuri> new parser that sucks less at parsing a legacy file than the current parser
<r4m0n> you want to keep binary compatibility with that game you're based on?
<GlassYuri> since it's all text based file formats it's not *binary* compatibility
<GlassYuri> also worse, I'm building a framework which could be extended to be downwards compatible with multiple games
<r4m0n> still, save-format compatibility
<GlassYuri> r4m0n, read-compatibility at least, although I might go all the way and write as well
<GlassYuri> writing can be difficult because it of course has to handle all features not found in the original game somehow
GlassYuri has quit [Quit: webchat.esper.net]
purpletarget|zzzz has joined #kspmodders
NBones has quit [Ping timeout: 182 seconds]
DuoDex has quit [Ping timeout: 182 seconds]
NBones has joined #kspmodders
DuoDex has joined #kspmodders
m4v has quit [Ping timeout: 198 seconds]
m4v has joined #kspmodders
angavrilov||phone has joined #kspmodders
angavrilov|phone has quit [Ping timeout: 202 seconds]
Supernovy has quit [Quit: Goodnight.]
angavrilov has joined #kspmodders
m4v has quit [Ping timeout: 198 seconds]
m4v has joined #kspmodders
GlassYuri has joined #kspmodders
Micha has quit [Ping timeout: 182 seconds]
Micha has joined #kspmodders
angavrilov|phone has joined #kspmodders
angavrilov||phone has quit [Read error: Connection reset by peer]
m4v has quit [Ping timeout: 198 seconds]
m4v has joined #kspmodders
angavrilov||phone has joined #kspmodders
angavrilov|phone has quit [Ping timeout: 198 seconds]
m4v has quit [Ping timeout: 202 seconds]
m4v has joined #kspmodders
m4v has quit [Ping timeout: 198 seconds]
m4v has joined #kspmodders
m4v has quit [Ping timeout: 194 seconds]
m4v has joined #kspmodders
m4v has quit [Ping timeout: 198 seconds]
RandomJeb has quit [Ping timeout: 194 seconds]
m4v has joined #kspmodders
m4v has quit [Ping timeout: 194 seconds]
m4v has joined #kspmodders
m4v has quit [Ping timeout: 198 seconds]
m4v has joined #kspmodders
GlassFragments has joined #kspmodders
GlassYuri has quit [Read error: -0x1: UNKNOWN ERROR CODE (0001)]
m4v has quit [Ping timeout: 198 seconds]
m4v has joined #kspmodders
GlassFragments has quit [Ping timeout: 182 seconds]
GlassYuri has joined #kspmodders
GlassFragments has joined #kspmodders
GlassYuri has quit [Read error: -0x1: UNKNOWN ERROR CODE (0001)]
Kreuzung has joined #kspmodders
GlassFragments has quit [Read error: -0x1: UNKNOWN ERROR CODE (0001)]
GlassYuri has joined #kspmodders
Kreuzung has quit [Read error: Connection reset by peer]
GlassYuri has quit [Read error: Connection reset by peer]
GlassFragments has joined #kspmodders
GlassFragments has quit [Read error: Connection reset by peer]
GlassYuri has joined #kspmodders
RandomJeb has joined #kspmodders
GlassFragments has joined #kspmodders
GlassYuri has quit [Read error: Connection reset by peer]
GlassFragments has quit [Read error: Connection reset by peer]
purpletarget|zzzz has quit [Read error: Connection reset by peer]
purpletarget|zzzz has joined #kspmodders
GlassYuri has joined #kspmodders
<GlassYuri> ...what kind of fucked up float is "-1.#IND00000000" (encountered in actual file)
<GlassYuri> apparently that's NaN padded with zeroes
angavrilov||phone has quit [Read error: Connection reset by peer]
angavrilov|phone has joined #kspmodders
angavrilov||phone has joined #kspmodders
angavrilov|phone has quit [Ping timeout: 198 seconds]
GlassYuri has quit [Ping timeout: 198 seconds]
angavrilov|phone has joined #kspmodders
angavrilov||phone has quit [Ping timeout: 202 seconds]
GlassYuri has joined #kspmodders
VanDisaster has quit [Ping timeout: 198 seconds]
GlassYuri has quit [Ping timeout: 198 seconds]
VanDisaster has joined #kspmodders
Supernovy has joined #kspmodders
angavrilov has quit [Remote host closed the connection]
<SilverFox> ~tell GlassYuri Keep it stupid, simple
<FoxBot9000> SilverFox: Will do!~
<SilverFox> r4m0n, what's your opinion on google's parser uhhhhhhhhhhhh protobuf?
<r4m0n> a bit overcomplicated. it's decent enough for binary-mode communications
<SilverFox> do you have one you'd recommend above it?
<r4m0n> as everything, depends on use. what you need?
<SilverFox> fair enough
<SilverFox> don't need anything just yet, although, for my own version of this 2D track sim, I'll be storing a x by y grid of tiles, and those grids are considered "pages" to which it gets stored as a parent grid of all pages kinda deal, which can expand infinitely like minecraft
<SilverFox> wow, that's really similar to minecraft's system with their "chunks"
<SilverFox> so should I go with a system where the grid is always "full", and it can be run serially, or only store track data, and do a two-pass system?
<r4m0n> I'd store the grid data and metadata separately
<SilverFox> hmm, how so?
<SilverFox> I mean, what more is there to store that is considered metadata when only x,y and type are involved?
<SilverFox> I think those are the only things I really need to store
<r4m0n> we're talking about tracks, so unless you want to parse the whole track at runtime, which might span multiple chunks, you should save the pre-computed info you need
<r4m0n> the tilemap you should store in binary format using the least amount of info by tile that's reasonable
<SilverFox> naw naw, I don't care about multiple chunks, you're thinking of track as the whole thing, where a track is just a single piece
<r4m0n> if you just want to handle a 2D tiled map, that's just an image, really
<SilverFox> yeah, but wouldn't an image be harder to parse, compared to just binary storage of a list/2D array?
<r4m0n> if it isn't going to be too large, store raw. if not, either use RLE compression or toss it through gzip
<SilverFox> RLE compression?
<r4m0n> it's very effective for maps
<SilverFox> oh shit is this like "there's 20 of these <type> in a row" deal?
<SilverFox> so it just stores type and amount
<SilverFox> oh shit it is
<SilverFox> I came up with this a long time ago, but never implemented it because I realized it had the possibility to greatly fuck with filesize
<r4m0n> yep
fcbayerndm has joined #kspmodders
<SilverFox> this could actually be a legitimate use case for this though
<SilverFox> and tracks are generally long and straight and stuff
<SilverFox> oh sweet jesus, you can ascii the track types and RLE it, then RLE the binary data, WE MUST GO DEEPER
<r4m0n> only go as deep as you need :-P
<r4m0n> like I said, if it isn't going to be too large, just store it raw
<SilverFox> naw now I'm just curious how fucking deep you can go
<SilverFox> r4m0n, the only issue is if I start storing chunks as non-individuals
<SilverFox> where I make a list of chunks or something, but there's an issue here
<SilverFox> either I make a folder or naming scheme and have a fuck-ton of potential chunks that get generated, which means lots of smallish files, which is rather stupid to work with
<r4m0n> your chunks should be as large as it's viable to work with
<r4m0n> if it's 2D, you should be doing 1kX1k or more
<SilverFox> well, can we fit 1k x 1k on a console on a typical screen?
<r4m0n> why should what you display have anything to do with the map size?
<SilverFox> well, my plan was that a chunk was what could be displayed at one time
<SilverFox> you don't see multiple chunks, you see only one, and that's a full screen of stuff
<r4m0n> that's a Screen, not a Chunk :-P
<r4m0n> if you're doing smooth scrolling, you'll be showing at most 4 at a time
<SilverFox> well, a chunk can = a screen
<SilverFox> I don't see any reason why it should be bigger or smaller than what you can see