Return to “Suggestions”

Post

Re: A Reinterpretation of Research

#61
Gazz wrote:Nope. Not with procedural generation.

Even if the system is completely dumped from memory, the next time you visit it would be recreated from scratch, potentially including some "advancement" because the game time is now higher.
As long as you're not there to watch you simply won't be able to tell if the changes were affected by actual detailed actors or added like stage props on recreating the system.
Unless and until we have computers that can simulate the entire universe in detail and in realtime, games will contain large amounts of smoke & mirrors. =)
Just for the purposes of clarity: all systems you've been to before will be redrawn from the same seed (or whatever Josh uses to store system information), yes, but the determination of that seed will only occur the first time you visit (or when the universe is first started). I'm sure that's what you meant, but "regenerated" has connotations of a starting from a fresh seed to me and that surely isn't what the game is doing.

Other than when the system is generated, however, I don't really see what PCG has to do with it. If what you say is true, then actually every system other than the one the player is currently in can be "regenerated with some "advancement"". But this would make a mockery of there being a "living" universe, and would lead to some really bizarre and very obvious discontinuities in system development, inter-factional war, trade and material prices etc. etc. The lot.

It would only be valid to arbitrarily move a system forward independent of everything else if that system is so far away from the player that there really isn't any trade or warfare between the simulated area and the non-simulated area. Otherwise, it needs to be updated - even if only at low levels of detail and infrequently, IMO.
Post

Re: A Reinterpretation of Research

#62
that included a "even if it is completely dumped from memory" as like "nothing remains on your harddisk either".

but this will likely not happen.

you get to a system, it gets simulated, if you go further away it gets simulated in ever lower fidelity until it gets stored to disk when you are too far away for it to be feasible to be simulated.

and when you get back, the time passed gets speed simulated with low LOD until it has catched up with "your" time again.
Post

Re: A Reinterpretation of Research

#63
soo.... i've received some critique on my construction interpretation lately (for a reason...)
so i've come up with a change to that system.

first rename the "materialisators" to "manipulators"
(much of that critique was directed towards my "its a magic replicator, it can do STUFF" >.>)


so, second.
lets resort to my favourite solution:
spectra.

every manipulator has a "process spectrum" which denotes what it can do to the objects it handles
these spectra could be roughly compared to my weapon type spectra,
they represent the processes a manipulator can apply to the materials that are passed through it.

one part of the spectrum might say "smelting" another one might say "welding", or anything one could imagine

a processing step needs a certain target spectrum to be reached at the end.

so for example a simple ore refining process needs a big peak in "casting" but all casti nng equipment reduces "melting" peaks into negative areas if no "melt" peak is present before.

so you need to "melt" the ore to a high peak beforehand that you can "cast" the ore into the metal form.

processes would be adaptable in a certain range, for example the heating equipment could choose to which "melting level" it could work.
so that you can taylor your processes to your requirements.


rough idea and i couldnt provide some solid math on it right now.

suggestions / alternative ideas welcome :D
Post

Re: A Reinterpretation of Research

#65
Flatfingers wrote:This sounds like it might integrate with the various material manipulation processes I outlined in the Refining Gameplay Ideas Mined thread.
I had it in mind, but it wasnt a main design goal.
Flatfingers wrote: There'd need to be input rules defined for each type of possible output product. Is that a defect in this design, or a virtue, or just a simple necessity?
I think this would only require a few very general rulesets.

And when we dont name the "spectral" parts and just say that every line is another esoteric process form
We could just handwave what is actually done.


And its kinda all three of that cases.
the spectrum sheme is a somewhat elegant solution for unifying vast technologic variations.
Post

Re: A Reinterpretation of Research

#66
so, i have no nice long text on my computers idea for this whole modular framework, but i had a long and fun discussion about it with Talv and Sly

theres my recordings of that discussion.

hopefully someone can be bothered to read :3

its pretty focused on viruses/computer warfare, but i guess thats because they are the most active/prominent feature

Code: Select all

<+Talvieno> *waves*
<+Cornflakes> hoihoi
<+Talvieno> heyaa. (: how are you?
<+Cornflakes> bit tired
<+Cornflakes> and wanting to write up my stuff about including computers into the modular construction framework which i've outlined for LT
<+Cornflakes> but every time i think about it im unsure about inconsistencies
<+Talvieno> Inconsistencies such as....?
<+Talvieno> And what kind of "including computers"?
<+Cornflakes> njo, spaceships dont consist only of warp coils
<+Cornflakes> :P
<+Cornflakes> the computers which control spaceships
<+Cornflakes> and the software which is running on them
<+Talvieno> Are we talking about something on the level of 0x10c?
<+Cornflakes> nope
<+Cornflakes> im not that crazy
<+Talvieno> lol, yeah, he bit off way more than he could chew there.
<+Talvieno> Notch, I mean.
<+Cornflakes> not really about chewing
<+Cornflakes> it was more about maintaining interest...
<+Talvieno> That too.
<+Talvieno> Explain your computers to me?
<+Talvieno> Maybe I can help you out.
<+Cornflakes> hm
<+Cornflakes> it starts at how "modular" i want computers to make
<+Cornflakes> im torn about if i split working memory and processing power or if i should just merge them together
<+Talvieno> What effect would those have on gameplay?
<+Cornflakes> processing capacity is quite self explaining
<+Cornflakes> how much data you can process over time
<+Cornflakes> working memor would be how many programs you can have loaded at the same time
<+Cornflakes> so a weak processor with big working memory on it could have many programs ready to go
<+Cornflakes> but it could not have them acting at the same time
<+Cornflakes> for example you may have to turn down your sensor data analysis the moment you have to engage your fire control
<+Talvieno> And programs, I guess, would be things like HUD displays, radar analysis, active offensive virus programs...
<+Cornflakes> yep
<+Talvieno> (I like the virus idea.)
<+Talvieno> Sounds good so far.
<+Cornflakes> i have an idea for including that into the framework
<+Cornflakes> that=viruses
<+Talvieno> I probably ought to look up your pipelines again, it's been a long time since I read them.
<+Cornflakes> how do you come to that thought right now?
<+Cornflakes> oh, and communications pipelines would be a part of the computing stuff too ^^
<+Cornflakes> ^.^^
<+Talvieno> (that's how I came to that thought. =P)
<+Cornflakes> :P
<+Talvieno> So, which framework are we talking about exactly?
<+Talvieno> I may have missed it.
<+Cornflakes> well, i have the idea to make software a dedicated object in your computer
<+Cornflakes> so you'd literally have a "memory map" of your active software
<+Cornflakes> and not just a list of running stuff
<+Talvieno> Nice...
<+Cornflakes> pieces of software would be "rectangular" polygons filling up your memory
<+Cornflakes> and can interact with each other on their borders
<+Talvieno> Hmm... that would be interesting.
<+Cornflakes> firewalls would be literal walls around pieces of software
<+Talvieno> Your computer is tetris. lol
<+Cornflakes> not quite
<+Cornflakes> they'd be deformable
<+Talvieno> Ah, deformable.
<+Cornflakes> and their area dependent on the memory/computing needs they have
<+Cornflakes> im thinking about giving data ports out of the piece of computer a specific position too
<+Cornflakes> so you can firewall ports off
<+Cornflakes> but then i'd have the problem of intersecting programs...
<+Cornflakes> and going 3d would be a bit overkill
<+Talvieno2> "Would the programs' deformations be confined to rectangles, or could you have them in other, more complex shapes?"
<+Cornflakes> thats why i put "" over rectangular
<+Cornflakes> they could have arbitary forms
<+Cornflakes> but should tesselate to suqares/rectangles
<+Talvieno2> "For instance, could a "hub type" program snake its way between a set of programs, separating them, or could you have a program designed to entirely enclose and protect another from viruses?"
<+Talvieno2> Also, yes.
<+Talvieno2> 3d would be serious overkill and probably very difficult to view/maintain.
<+Talvieno2> Maybe for real life... but it would be a headache in a game, I'd think.
<+Cornflakes> "enclose and protect" would be the way to go for firewalls
<+Cornflakes> "in real life" would require computers to work in such a way first
<+Cornflakes> :P
<+Talvieno2> Lol, yeah.
<+Talvieno2> But if you DID make computers work this way in real life...
<+Talvieno2> 3d would probably be the way to go. :P
<+Cornflakes> i guess 3d would not be enough at times
<+Talvieno> Hm, possibly so.
<+Cornflakes> so, on programs and how viruses act
<+Talvieno> This could be a fun little minigame.
<+Cornflakes> mhm
<+Cornflakes> but possibly overkill in general
<+Talvieno> Well, I say "minigame", but I know it'd be running constantly.
<+Talvieno> No, I wouldn't think so.
<+Talvieno> Not if you could just let it do its own stuff and not worry about it.
<+Talvieno> If you had to actively keep an eye on it, yeah, that wouldn't be fun.
<+Talvieno> But if you could use it to engage in active warfare against someone else's computer...
<+Cornflakes> a program (and viruses) consist out of multiple parts (libraries) and can move through computer infrastructure
<+Cornflakes> that would be the idea

[few hours of pause]

<+Talvieno> Okay, explain to me how the programs have multiple parts.
<+Talvieno> And how they "move".
<+Talvieno> I figured they'd all be mostly locked together.
<+Cornflakes> well, parts are like components for other equipment
<+Cornflakes> smaller pieces of the whole that fulfil different purposes
<+Cornflakes> so your communication array controller may consists out of a data compression libary
<+Cornflakes> an encryption libary
<+Cornflakes> an encoding libary
<+Cornflakes> and some pieces for actually controlling the tranciever
<+Cornflakes> you can swap them to enchance/change functionality
<+Talvieno> That could get a little too complicated to be controllable, I feel... unless you write a heck of a UI for it.
<+Cornflakes> well, it could be handled like modular equipment
<+Cornflakes> in general you dont handle the individual pieces
<+Cornflakes> only the whole assemblies
<+Talvieno> Ahhh. And on occasion you can "pimp it out", maybe while docked safely somewhere.
<+Cornflakes> and part handling comes form minmaxing/engineering new assemblies
<+Cornflakes> yeah
<+Talvieno> Right. *nods*
<+Cornflakes> on the moving part
<+Cornflakes> thats one of the points where i dont know exactly how to handle it
<+Talvieno> Here's another idea...
<+Cornflakes> yeah?`
<+Talvieno> Some programs could have parts that are separate.
<+Talvieno> Viruses, for instance.
<+Talvieno> Uploading a virus to the enemy's computer could upload a program that splits itself and flanks/decoys its way past the enemy's antivirus protection.
<+Cornflakes> would that be hardcoded which programs are "modular"?
<+Talvieno> I think it would be something you could control, maybe controlled by parts/components.
<+Cornflakes> ah, i'd consider replication independent from "multiple parts"
<+Talvieno> Sort of like replication...
<+Cornflakes> i actually thought of that for viruses
<+Cornflakes> self replicating zerg swarm viruses :D
<+Cornflakes> :§
<+Cornflakes> :3
<+Talvieno> but the parts are controlled as one piece, with the same base AI so they can work together.
<+Talvieno> yeah XD
<+Talvieno> You're flying along and suddenly your HUD starts flashing red and alarms go off, and you pull up your computer...
<+Talvieno> and one by one, your programs are mysteriously falling off the grid.
<+Cornflakes> i think we could abstract the "boss AI" away as good swarm AI programming
<+Cornflakes> yeah
<+Talvieno> you could have something else that renders a program "invisible" unless hit with sophisticated enough hardware.
<+Cornflakes> i mused about "maintainance ports" on computer parts that can be walled off by the virus
<+Talvieno> So it looks like your systems are failing completely by themselves, unless you know what's going on.
<+Cornflakes> if you control them, you can see whats going on
<+Talvieno> I would say there ought to be a way to manually remove the virus, though, except in the most extreme cases.
<+Talvieno> Yeah, if you control them you can see the invisible programs.
<+Cornflakes> i'd say as always available option should be to turn off your computer, wipe working memory and reload from permanent storage
*** koo5 (~sirdancea@236.152.broadband3.iol.cz) has joined #limittheory
*** ChanServ sets mode +v koo5
<+Cornflakes> which should take a bit of time
<+Talvieno> *nods* That'd work. Let's hope you're somewhere you have time to let your computer boot up.
<+Talvieno> And have good startup software.
<+Cornflakes> longer than it would take to combat the infection the "proper" way
<+Talvieno> This could be seriously fun. :)
<+Talvieno> Yeah, another way you might combat it...
<+Talvieno> A sort of "minigame"...
<+Cornflakes> your virus
<+Talvieno> hmm?
<+Cornflakes> i'd have the "minigame" mostly in preparation
<+Cornflakes> you fight other viruses with your "virus"
<+Cornflakes> which targets other viruses
<+Talvieno> That too.
<+Talvieno> Another way I was thinking you could combat it is to "wall off" sections of your memory and then scan them, to check if what you see matches up with the usage for that section.
<+Cornflakes> mhm
<+Cornflakes> but for that you'd need control of the maintainance ports
<+Talvieno> If there's more memory in use than you actually see being used, it means there's a virus in there, and you can narrow it down further.
<+Talvieno> Could take a bit of hit and miss.
<+Talvieno> Know what would be [really] fun.
<+Cornflakes> for variation some programs may take different amounts of memory depending on their usage state
<+Cornflakes> yeah?
<+Talvieno> A virus designed to take over the ship's thrusters.
<+Talvieno> Force an enemy ship to fly into an asteroid or something.
<+Cornflakes> well, there are thrusters, theres control software for them :P
<+Cornflakes> but that would need to be a sophisticated virus
<+Talvieno> The "wall off" method might not work so well if the virus stays mobile.
<+Talvieno> Yeah, it would be.
<+Talvieno> More than just a virus, that's a virus + AI.
<+Cornflakes> taking over sensors and engines and then do somehing "useful"
<+Talvieno> mhm. Which would be bulky and thus easier to take out.
<+Cornflakes> a big chunkg of that virus could be drone control software
<+Cornflakes> drone firmware
<+Talvieno> Or. another idea.
<+Talvieno> You have a virus designed to change one thing...
<+Talvieno> your friend-or-foe ID...
<+Cornflakes> but honestly, to conserve fun for those on the receiving end, i'd say engines have an "emergency control" circuit on which you can use when your computer is shut of
<+Cornflakes> hehe
*** jocapivara (jocapivara@m-c.clients.kiwiirc.com) has joined #limittheory
*** ChanServ sets mode +v jocapivara
<+Talvieno> Someone's flying along with their civ and suddenly they show up as an enemy to everyone nearby.
<+Cornflakes> hm.. we could have different classes of "objects" in memory
<+Talvieno> And, yeah, emergency control would be good.
<+Cornflakes> code and data
<+Cornflakes> code can only be destructively interfered
<+Cornflakes> but data can be manipulated
*** jocapivara (jocapivara@m-c.clients.kiwiirc.com) has quit IRC: Quit: http://www.kiwiirc.com/ - A hand crafted IRC client
<+Talvieno> Here's a funny idea for a virus.
<+Talvieno> Going with the idea that ships don't have windows and you're just looking at a holoscreen...
<+Cornflakes> i seee }:3
<+Talvieno> Maybe the virus could be designed to make the ship's sensors "hallucinate"
<+Cornflakes> well, take over the sensor firmware...
<+Talvieno> Yeah.
<+Talvieno> So you think you're under attack by hundreds of ships. lol
<+Cornflakes> instant panic
<+Talvieno> Or you're dodging asteroids, or your buddies explode in random fireballs, etc.
<+Talvieno> Could be absolutely hilarious to watch if you're not on the receiving end. XD
<+Cornflakes> you panically sending of emergency messages and everyone thinks you an idiot
<+Talvieno> Lmao
<+Talvieno> "Yep, that's Jim again, being overdramatic as usual."
<+Cornflakes> lol
<+Cornflakes> "AAAARGH! AN ARMADA OF PIRATES"
<+Cornflakes> 1 pirate scout ship
<+Talvieno> XD Lmao
<+Talvieno> This is awesome. XD
<+Cornflakes> "the asteroids are moving 0o o0"
<+Talvieno> "Dude, why does everything look so disco?"
<+Cornflakes> hehe
<+Cornflakes> so
<+Cornflakes> back to "topic" lol
<+Talvieno> This is topic. :)
<+Talvieno> sort of.
<+Cornflakes> how does the "change stuff" mechanic actually work gameplay wise?
<+Talvieno> How so?
<+Talvieno> Like... how do you write a virus to do different things?
<+Cornflakes> well, how does a virus actually change stuff?
<+Talvieno> hmm.
<+Talvieno> My guess is, you have a choice. "write" your own viruses...
<+Cornflakes> i was personally thinking of an abstracted "dps" vs "hp" mechanic
<+Cornflakes> but that seems.. .odd
<+Talvieno> or buy them.
<+Talvieno> the former would require some "skill levels" in the random manner of LT, I guess.
*** koo5 (~sirdancea@236.152.broadband3.iol.cz) has quit IRC: Ping timeout
<+Cornflakes> well, i'd say research mechanic and "libaries" aka software parts
<+Cornflakes> on building software
<+Talvieno> That too.
<+Cornflakes> as the player himself is "stateless"
<+Cornflakes> so you can buy different libaries
<+Talvieno> The rest seems simple. Once you have a tech researched ("Hack thrusters 1.0") and some other techs ("Evade Firewall 3.1") ("Invisibility 4")
<+Cornflakes> and slot them together
<+Talvieno> Right.
<+Cornflakes> hack thrusters should not be something definite
<+Cornflakes> more like "hack 1.0"
<+Talvieno> Hack thrusters would be a conglomeration of a lot of different things.
<+Talvieno> Hack.
<+Cornflakes> find thrusters
<+Cornflakes> etc
<+Talvieno> Mhm. And you'd have to be able to hack the thruster firmware.
<+Cornflakes> which is software like any else
<+Talvieno> Something like "Shut off system" would be easy.
<+Cornflakes> mhm
<+Cornflakes> just destroy the firmware
<+Talvieno> yep.Something like piloting it into an asteroid would be hellishly difficult.
<+Cornflakes> a "pipe" system in the unix sense would be nice there
<+Talvieno> You'd have to hack sensors too, and have another piece to interpret sensor data.
<+Cornflakes> manipulate the data thats going into the thrusters
<+Talvieno> then another piece to search for nearby asteroids or large objects...
<+Cornflakes> you wouldnt need to interpret sensor data
<+Cornflakes> use the software thats already there
<+Talvieno> Ah, I guess so.
<+Cornflakes> tap into the the firmwares output
<+Talvieno> then a small AI core to hook it all together.
<+Talvieno> Something that simple wouldn't have to be much.
<+Cornflakes> with some "pathfinding" and "flight control" libaries in there
*** koo5 (~sirdancea@236.152.broadband3.iol.cz) has joined #limittheory
*** ChanServ sets mode +v koo5
<+Cornflakes> which hook into the engine firmware which is already there
<+Talvieno> Mhm. And all these get slotted into the same virus.
<+Talvieno> Heyaa, koo5. (:
<+Cornflakes> ahoihoi
<+Cornflakes> i think the simplest to [write] virus would be the "replace everything" variation
<+Talvieno> Or "destroy everything"
<+Cornflakes> in terms of "fly into an asteroid"
<+Cornflakes> the destroy everything would be the most basic one i guess
<+Talvieno> Mhm. That's easy. Just put a "hack" with a "destroy".
<+Talvieno> Maybe some "infiltrate firewalls".
<+Cornflakes> hm... theres the danger of having the most dangerous one being the most simple one to introduce into your enemies systems
<+Talvieno> Nah.
<+Cornflakes> firewall-destroy-replicate
<+Talvieno> I would do this:
<+Cornflakes> and a control virus would be much more complicated
<+Talvieno> make it easy to write a program to search for anything actively destroying systems.
<+Cornflakes> as it needs those components too
<+Cornflakes> and many more
<+Cornflakes> hm
<+Talvieno> If it destroys a system, it's a virus. You can use the location of the last destroyed system to figure out where the virus is.
<+Cornflakes> make destructive attacks the most visible ones?
<+Talvieno> so just put up firewalls and watch for them to go down.
<+Cornflakes> hm
<+Talvieno> Yep.
<+Talvieno> A sneakier one would be where they [evade] firewalls.
<+Talvieno> But harder to create.
<+Cornflakes> theres the question of how would that work exactly?
<+Cornflakes> gameplay wise
<+Talvieno> I would make it work by "drilling a hole" in whatever firewall is there and slipping through.
<+Talvieno> then the firewall closes behind it.
<+Talvieno> Or.
<+Cornflakes> hm
<+Talvieno> just make it "phase through" the firewall.
<+Cornflakes> that would be a very contained "destroy" function
<+Talvieno> That could get messy in terms of mechanics, though.
<+Cornflakes> maybe programs could work in a "conways game of life" like variation
<+Cornflakes> but that would be overkill... again
<+Talvieno> XD
<+Talvieno> I think that would ruin some of the fun of the program stuff, yeah.
<+Talvieno> little too complicated.
<+Cornflakes> "little"
<+Cornflakes> *cough*
<+Talvieno> Lol XD
<+Talvieno> okay, okay, yeah, a lot too complicated.
<+Cornflakes> hehe
<+Talvieno> XD
<+Cornflakes> so... phasing through would need to have a serious drawback in some variation
<+Cornflakes> to prevent it from becoming the default decision
<+Talvieno> The virus is completely vulnerable until it finds an empty spot.
<+Talvieno> It doesn't take up space, after all.
<+Cornflakes> i'd say it takes up space
<+Cornflakes> like any program
<+Talvieno> well, yes.
<+Talvieno> but if it's "phasing through" it needs a "landing zone", doesn't it?
<+Cornflakes> mhm....
<+Talvieno> So if you're jumping a tall fence, and you land on the other side and find fifty guys with guns pointed at you...
<+Talvieno> I'd say you'd be as screwed as a phasing virus that finds itself in front of a major antivirus program.
<+Cornflakes> mhm...
<+Talvieno> Here's an idea.
<+Talvieno> Programs could make "noise".
<+Talvieno> Not actual, audible noise, but.
<+Cornflakes> i see what you mean
<+Talvieno> Let's say a virus destroys something.
<+Cornflakes> makes a ton of noise
<+Talvieno> Yeah. *nods* okay. Well, if you phase through, you evade the firewall, but it creates "noise" that antivirus software can har.
<+Talvieno> *hear
<+Cornflakes> hm
<+Talvieno> You could put "stealth functions" on it.
<+Talvieno> make it create less "noise".
<+Talvieno> Then the antivirus would have to be in closer proximity to detect it.
<+Cornflakes> but being a bigger/less capable program
<+Talvieno> Right, that too.
<+Talvieno> The antivirus could be "split", too, in the same way as a virus, so it has "sentries" stationed throughout the memory.
<+Talvieno> The better the antivirus, the more sentries and the more capable they are, the faster they move, the better they attack viruses, etc.
<+Cornflakes> but the more storage they need
<+Talvieno> Yup, like any antivirus, and the more CPU they pull.
<+Cornflakes> i'd make it gameplay wise so that the antivir is basically a group of viruses itself
<+Cornflakes> with some basic rules in them
<+Cornflakes> lore wise it could be a "single" program
<+Talvieno> That works too.
<+Cornflakes> but gameplay wise it could be the same as a single virus replicated 10 times
<+Talvieno> And yeah, I did mean for it to be a single program, but replicated.
<+Cornflakes> and acting independentl
<+Cornflakes> y
<+Talvieno> Yes!
<+Talvieno> You could use this stuff to your advantage, too. If you know that ships from Percitron Beta VII tend to have X antivirus software, you could use a virus designed to take that particular antivirus software down.
<+Cornflakes> or just to evade it
<+Cornflakes> maybe work my "damage type" stuff in there too
<+Talvieno> Mhm. thus raising your chances. You'd have to have done your research first, though.
<+Talvieno> Damage type?
<+Cornflakes> the frequency based damage type stuff
<+Cornflakes> frequency=spectrum
<+Talvieno> ahhhh. *nods*
<+Talvieno> This is some good stuff. lol
<+Talvieno> I want  to use this mod. :P
<+Cornflakes> so every program has some "security holes" in ther
<+Cornflakes> which you can use
<+Cornflakes> if you know them
<+Talvieno> Right.
<+Talvieno> Know what would be funny. Some idiot decides to install two antivirus programs on their system, thinking it'd make their ship safer...
<+Talvieno> and each thinks the other is a virus...
<+Talvieno> and they wage war against each other.
<+Cornflakes> i dont think so that this should happen per default
<+Cornflakes> maybe as the result of some attack
<+Talvieno> Like the Thunderdome, but for programs.
<+Cornflakes> lol
<+Talvieno> Well, that's what they do in real life.
<+Talvieno> You install two antivirus programs, and they tend to try to hunt each other down.
<+Cornflakes> https://xkcd.com/350/
<+Talvieno> "HEY! This other program is editing the memory! KILL IT" "HEY! This program is trying to stop me from editing the memory! It must be a virus!"
<+Cornflakes> lol
<+Talvieno> And Lol, I remember that one. XD I thought that would be cool.
<+Cornflakes> i still dont think that that would be fun gameplay wise
<+Talvieno> eh, maybe.
<+Talvieno> Unless you like watching that kind of thing.
<+Talvieno> Or you want to see which antivirus program would win.
<+Cornflakes> i'd totally build such an aquarium, though.
 
capture every virus i get thrown at me and collect them in an isolated network
<+Talvieno> :D Would be fun. Hey, stations would have computers too.
<+Cornflakes> yep
<+Talvieno> Imagine hacking a station and switching it to fire at allies instead of enemies.
<+Talvieno> Or you could just pack it full of viruses like a bomb...
<+Talvieno> and whenever an enemy ship tries to hack it...
<+Talvieno> bam, their systems are down.
<+Cornflakes> ewar could be a profession
<+Talvieno> It could be. (:
<+Talvieno> This would probably be my favorite mod. lol
<+Cornflakes> hack communications channels and steal secret data
<+Talvieno> Mhm. Or send false data.
<+Talvieno> Fool them into thinking an armada is on the way.
<+Cornflakes> mhm
<+Cornflakes> or just change their map data
<+Talvieno> You could have a program to actively rewrite data stored on the computer with false coordinates... that might get really tricky and confusing, though.
<+Cornflakes> i'd personally say that only data in the working memory is vulnerable..
<+Talvieno> yeah, I guess so.
<+Cornflakes> and permanent storage is not touchable
<+Cornflakes> so when you have some problem you can rebuild your data
<+Cornflakes> except if the permanent storage gets destroyed
<+Talvieno> I'd like a virus to put a large trollface on the enemy's HUD... as it shuts down all their systems. but I guess that would be better suited to multiplayer. ):
<+Cornflakes> mhm
<+Talvieno> And yeah, permanent storage untouchable.
<+Cornflakes> but it would definitely something that rewards smarts and not playtime
<+Talvieno> mhm. For sure. I like that kind of thing.
<+Talvieno> Oh, and if you're worried about getting hack, you can always shut off data comms, right?
<+Talvieno> *hacked
<+Cornflakes> yeah
<+Cornflakes> but then you'd be shut of from your empire
<+Talvieno> Mhm.
<+Talvieno> Except for radio communication, perhaps.
<+Cornflakes> i'd not split that
<+Cornflakes> because, wheres the difference between the 2?
<+Talvieno> hmm... it's not very realistic, but.
<+Cornflakes> maybe some ultra-short-range emergency radio
<+Talvieno> Well, I've never heard of a radio program that could introduce viruses on anything playing it.
<+Talvieno> radio program as in "music and ads and news and such"
<+Cornflakes> your FM radio isnt connected to your pc though
<+Cornflakes> and isnt IP based
<+Talvieno> Nope, hence why I said you could safely leave radio communication on.
<+Talvieno> it [would] be short range, though.
<+Cornflakes> an emergency circuit
<+Cornflakes> you can get some very coarse data
<+Talvieno> Mhm. Just in case everything else fails and you have to go dark.
<+Cornflakes> and give some coarse commands
<+Cornflakes> not more
<+Talvieno> Staticky at best.
<+Cornflakes> "group 4 attack that carrier"
<+Cornflakes> should be the most precise order type
<+Talvieno> the most precise type allowed over short range?
<+Talvieno> Sure.
<+Cornflakes> over the emergency radio
<+Talvieno> That works. I think that's reasonable.
<+Talvieno> You could get a lot more detailed otherwise, giving out weak points and other things.
<+Talvieno> Also, you'd be limited to one command at a time.
<+Talvieno> so, have we worked it out farther?
<+Cornflakes> mhm
<+Cornflakes> i should storage that stuff
<+Talvieno> I [really] like this idea.
<+Talvieno> This would almost be fun to play just by itself.

[unrelated discussion on DF]

<+Cornflakes> soo...
<+Cornflakes> how can software attack each other
<+Cornflakes> and how do you actuall defend?
<+Talvieno> Programs could have slotted functions like "virus defense X"
<+Cornflakes> hm
<+Talvieno> Which would be bulky.
<+Talvieno> hence why it's easier to just put it on the antivirus.
<+Cornflakes> then you'd have explicit defenses everywhere
<+Talvieno> It'd take up a lot of memory.
<+Cornflakes> i'd like to have some passive defences everywhere per default
<+Talvieno> It'd have to be balanced, but.
<+Cornflakes> it cant destroy a virus
<+Cornflakes> but it can survive a while
<+Talvieno> *nods* Something that can delay a virus, for instance.
<+Talvieno> Something like firmware encryption.
<+Cornflakes> regardless how its named
<+Cornflakes> but how could it work gameplay wise
<+Cornflakes> plain HP?
<+Talvieno> No.
<+Cornflakes> and an offensive program "attacks"?
<+Talvieno> I would start it by "roll higher than X to crack encryption"
<+Cornflakes> and basically reroll so long until you get through?
<+Talvieno> better viruses have better rolls, better encryptions require higher rolls.
<+Talvieno> Mhm.
<+Cornflakes> hm
<+Cornflakes> that sounds actually good
<+Talvieno> Then the virus starts actually destroying it, and you get into the HP stuff.
<+Talvieno> Partial HP left means partial damage to the system.
<+Cornflakes> i'd not do multiple stage imo
<+Talvieno> No?
<+Talvieno> I was just going to have it be a percentage.
<+Cornflakes> its already complex enough
<+Talvieno> 75% damage to your thruster controls mean your thrusters behave appropriately 75% of the time...
<+Talvieno> but I agree that might be too complex.
<+Talvieno> It'd work well with your old "systems damage" idea.
<+Talvieno> or was that thymine's...
<+Cornflakes> i dont know
<+Cornflakes> i did it too, though
<+Talvieno> *nods* My memory on it is fuzzy. I just remember someone saying it'd be cool to have partial damage to systems.
<+Talvieno> like you get hit with a torpedo, your turret guidance might start malfunctioning.
<+Talvieno> rather than straight-up HP.
<+Talvieno> everything works until it gets destroyed.
<+Talvieno> i.e. http://tvtropes.org/pmwiki/pmwiki.php/Main/CriticalExistenceFailure
<+Cornflakes> iirc that was some collaboration between gazz, thymine and me
<+Cornflakes> at least
<+Talvieno> *nods* it was a good thread. Maybe too complex, though, yes.
<+Cornflakes> but in this case i'd not make it "behaves x percent of the time" but limit the extent of the influence of the virus
<+Cornflakes> so at 100% it can do nothing
<+Cornflakes> at 75% it can affect the throttle within limits
<+Talvieno> *nods*
<+Cornflakes> at 50% it has control of your throttle
<+Cornflakes> etc
<+Talvieno> Or you could just have critical existence failure at 0% and suddenly the virus is able to hack in.
<+Talvieno> Or you could even have it so that once the virus hacks in, it has control.
<+Cornflakes> which would be more realistic in that case
<+Talvieno> Although with the HP bit I meant it more for the virus to have to take some time destroying the program.
<+Talvieno> So it's not like "We hacked in!" "Hit delete!" "Done!" *high five*
<+Cornflakes> mhm...
<+Talvieno> As to the rest of the stuff, let me outline what I imagine could happen in a hypothetical eBattle.
<+Talvieno> You're within range of the enemy ship, so you set a virus on its computers. This is a roll vs roll thing like before.
<+Cornflakes> (im away for a few minutes, but continue)
<+Talvieno> (okay.)
<+Talvieno> When you finally roll higher than their defenses, taking into account the different functions on each ship, you're able to see their systems, and your virus is inserted at the data port.
<+Talvieno> This is probably the trickiest part of the whole thing, since this would be where a lot of their firewalls/antiviruses would be concentrated.
<+Talvieno> You could: A. Phase through the enemy firewall, B. destroy the enemy firewall, or C. attempt to slip around the enemy firewall. If you have an expansive firewall protecting the entire system, your only options are to either phase or destroy.
<+Talvieno> Destroying means that you have every antivirus sentry out there on you all at once, with all their roll going against your one itty bitty roll.
<+Talvieno> Or you [could] have your virus split into multiple parts, with some acting as decoys. So let's do that.
<+Talvieno> Actually, why upload just one virus? let's do two.
<+Talvieno> Virus one splits into two parts. Virus two splits into three. All parts are mostly invisible, but one part of #2 starts attacking the firewall directly, which starts making noise.
<+Talvieno> The enemy's antivirus moves to respond.
<+Talvieno> Meanwhile, your virus #1 has flanked the firewall and started slipping past it. The enemy's antivirus is now mostly out of the way, and your #1 virus's functions are sophisticated enough to roll past the firewall fairly quickly on both sides.
<+Talvieno> The enemy's antivirus has just finished destroying one part of Virus #2, and would soon find your #1 from the noise it's making slipping past the firewall, if it wasn't for virus #2 sending another part at a place distant from both the antivirus and virus #1.
<+Talvieno> This works as a secondary decoy and gives your virus more time.
<+Talvieno> As soon as the antivirus is pulled over there, your third part of #2 starts attacking the firewall directly. This piece is the largest part of that virus, and the most capable of dealing damage. It would've been discovered quickly if the decoys hadn't been there.
<+Talvieno> Your #1 virus does some stealth hits from the inside, where the firewall is weaker, and the outer firewall falls. There are still firewalls around critical systems like nuclear engines and life support and such, but you're free to send in your nastier viruses now.
<+Talvieno> The ones that were previously too big to get past the firewall without being noticed.
<+Talvieno> The #2 virus bits and the #1 virus bits are mostly just decoys themselves, now, and start attempting to destroy whatever they can find. The antivirus splits up its resources to try to combat all of them at once, since that's what its functions have it programmed to do in case of multiple targets.
<+Talvieno> This makes it easier for your large, nasty #3 virus to try to attack the antivirus itself and shut it down. Big battle there, obviously.
<+Talvieno> Your #4 virus, meanwhile, slips into the system and splits into multiple parts, staying mostly silent and invisible and avoiding the battle completely as they make their way to the thrusters, sensors, and HUD. This virus is huge, and would normally be pounced upon immediately if it wasn't for your #3 virus giving the antivirus a run for its money.
*** Slymodi (~Sly_@ip70-181-47-29.ri.ri.cox.net) has joined #limittheory
*** ChanServ sets mode +v Slymodi
<+Talvieno> From here, you go through the various bits of hacking into the firmware encryption, each of the functions on the virus pieces doing different things.
<+Cornflakes> at first i'd guess inserting shouldnt be a roll per default
<+Cornflakes> when you have a channel open it should depend on the virus if its a roll or an attack move
<+Cornflakes> \destroy
<+Cornflakes> if your initial attack is sneaky/manipulation/phasing its a roll
<+Cornflakes> else its "damage"
<+Talvieno> hmm... Okay, yeah, I guess so.
<+Talvieno> If it's a direct attack you deal damage.
<+Cornflakes> this could also be limited by the comms channel
<+Cornflakes> the more bandwith, the more rolls/attacks it can do
<+Cornflakes> within the limits of the software
<+Talvieno> making it faster or slower to break in, right.
<+Talvieno> so the enemy antivirus would have time to prepare.
<+Cornflakes> mhm
<+Cornflakes> assuming the enemy notices your intrusion
<+Talvieno> Well, if it's a direct attack, I think it probably would, wouldn't it?
<+Cornflakes> yeah
<+Cornflakes> but he shouldnt notice that theres "something" until you make noise
<+Talvieno> Right. *nods*
<+Cornflakes> i guess it also wouldnt be "all rolls against the virus" at the first moment
<+Talvieno> How not?
<+Cornflakes> as the guardians are possibly dispersed through the system
<+Talvieno> Well, actually, yeah, that makes sense.
<+Cornflakes> and have limited moving speed
<+Talvieno> If it's on a 2d system, they'd both have limited moving speed and also, only so many guardians could be adjacent to the virus at a time.
<+Cornflakes> yeah
<+Talvieno> (making larger viruses easier to pigpile against, thus making them more vulnerable)
<+Cornflakes> mhm
<+Talvieno> Nice... I like how that works out. lol
<+Cornflakes> the communications bandwith limitation could also apply if you move between computers on the same object
<+Cornflakes> like a dispersed system
<+Talvieno> whoa, multiple computers on the same ship?
<+Talvieno> huh...
<+Cornflakes> networked computers
<+Cornflakes> you may have one small one running engine firmware mounted in the engine
<+Talvieno> You could use one computer as backup memory and then replace the damaged data when you noticed something was going wrong.
<+Cornflakes> a bigger one in the sensor running sensor firmware etc
<+Talvieno> ahhhh, that's what you mean.
<+Talvieno> I like that idea too.
<+Slymodi> ok so what I pull from a brief reading is that you are givin an on board computer and you have all sorts of other aspects that you have to maintain with it
<+Cornflakes> and all of those are connected using limited bandwith buses
<+Cornflakes> yeah
<+Slymodi> hmm ok
<+Slymodi> so not quite where I was going with fleet formations but I will still join
<+Cornflakes> lol
<+Slymodi> haha totalyl different conversation
<+Talvieno> You may have missed the parts about viruses making the enemies hallucinate, Sly.
<+Talvieno> That was fun. :D
<+Slymodi> haha yeah that adds a cool layer to it all
<+Cornflakes> or flying into asteroids
<+Talvieno> XD Lol, yeah.
<+Slymodi> let me switch computers and I'll start talking
<+Cornflakes> and you can tinker with your computers software, minmaxing your capabilities
<+Cornflakes> i agree with the general notion of the rest of your text talv
<+Cornflakes> though im still not sure how roll vs attack would work out...
<+Talvieno> There's another idea.
<+Talvieno> Two rolls.
<+Cornflakes> hm?
<+Cornflakes> sneak vs attack?
<+Talvieno> Roll 1: roll higher than enemy's roll to determine if there's a breach.
<+Talvieno> Roll 2: if roll one is successful, deal [roll] damage to the HP.
<+Cornflakes> hm
<+Cornflakes> i guess it would do the same with 1 roll + fixed dmg
<+Cornflakes> less complexity
<+Talvieno> hmm... yeah, maybe.
<+Talvieno> remember I'm a huge DF fan. =P
*** SlymodiL (~sahil@ip70-181-47-29.ri.ri.cox.net) has joined #limittheory
*** ChanServ sets mode +v SlymodiL
<+Cornflakes> hehe
<+SlymodiL> here we go
<+Cornflakes> but if it has the same effect, it doesnt matter :P
<+SlymodiL> I thin k the virus thing is interesting
<+Talvieno> Hail, SLY MO DIL
<+Cornflakes> hey sly
<+Talvieno> It doesn't have the same effect, though.
<+SlymodiL> it can add a layer of complexity if the player is allowed to create viruses using their own scripting language
<+Talvieno> With "roll for damage"
<+Cornflakes> i'd not use any scripting sly
<+Cornflakes> besides modding
<+Talvieno> yeah, I think scripting would be too complex.
<+Cornflakes> take the statistic average of the rolls
<+SlymodiL> yeah for the ordinary uaser
<+Talvieno> that goes in the direction of 0x10c.
<+Talvieno> No.
<+SlymodiL> but I want SUPER high level gameplay with insane depth and complexity
<+Talvieno> (to cornflakes)
<+Cornflakes> you have some research generated libaries which you slot together
<+Cornflakes> it would be far too much
<+Cornflakes> and the AI couldnt use it
<+Talvieno> With "roll for damage" you have damage dealt every roll, no matter how weak your virus is compared to the antivirus.
<+Cornflakes> and with roll for breach + damage you have the same
<+Talvieno> With "roll for breach and then damage" you have to breach the system before you can deal damage at all.
<+Talvieno> hmm.
<+Cornflakes> which was what i was saying
<+Talvieno> although I suppose you could achieve the same effect if the damage dealt was "your roll - enemy roll"
<+Cornflakes> roll if breach + damage
<+Cornflakes> hm
<+Cornflakes> yeah
<+Talvieno> no, first roll was y/n, second roll was damage, with the breach+damage scenario.
<+Cornflakes> but with separated systems we could have "sneaky" viruses with high roll which just compromise
<+Cornflakes> and "agressive" ones with lower roll but high damage
<+SlymodiL> I wonder how much depth you could attain from a virus system
<+Talvieno> Much, Sly.
<+Cornflakes> viruses are just a part of it
<+SlymodiL> I wonder what would be the easiest way to script it and allow the user to really screw over the attackee
<+Cornflakes> just the most active and prominent one
<+Talvieno> Sly, start reading at line 67 of part 2.
<+Talvieno> that details advanced hacking ideas. =p
<+SlymodiL> haha I missed that
<+Talvieno> And yeah, viruses are just a part of it.
<+Talvieno> You could also have AIs that control different aspects of your systems for you.
<+SlymodiL> oh that's interesting
<+Talvieno> I mean, if you could program one to do that to the enemy ship malevolently, why not design a benevolent one for your own ship?
<+Talvieno> Upgrade the turret aiming, increase the efficiency here and there, etc.
<+SlymodiL> yeah that could become really interesting and allow for some really cool high level gameplay
<+Talvieno> Pimping out your ship's systems.
<+SlymodiL> and just automating parts of your ship as well
<+SlymodiL> I love anything automation
<+Cornflakes> it would be independent from "automation" though
<+Cornflakes> i guess
<+SlymodiL> yeah
<+SlymodiL> it wold be different
<+SlymodiL> not quite an autopilot, but more of an assist
<+Talvieno> taking control of the enemy's hyperspace jumping would be fun...
<+Talvieno> jump them into a planet... :D
<+SlymodiL> haha
<+Cornflakes> lol
<+Talvieno> might be too overpowered though. :\
<+SlymodiL> I like that
<+SlymodiL> wel
<+Talvieno> No walking away from that. lol
<+SlymodiL> that would have the most security
<+SlymodiL> I would think
<+Talvieno> That and life support. Maybe the engines too so you couldn't remotely detonate them.
<+Talvieno> Also, here's something.
<+Talvieno> What is there keeping a capital ship from hacking every enemy in the system all at once?
<+SlymodiL> would you need something physical to hack them
<+Cornflakes> hm... bandwith?
<+SlymodiL> or is it online
<+SlymodiL> yeah and that
<+Cornflakes> i guess a whole system of antivirs should be able to combat a single ship...
<+Cornflakes> especially if all of them drop their RAM and reboot only with emergency radios on
<+SlymodiL> this is going to make a great mod
<+Talvieno> it's a capital ship. It's going to have a fuckton of bandwidth.
<+SlymodiL> where is abndwidth created from
<+Cornflakes> theres the same question with "what keeps a capital from destroying everything in a system"
<+Talvieno> it's probably a hardpoint-type component.
<+Cornflakes> communications arrays
<+SlymodiL> yeah
<+Talvieno> Hmmm. Idea.
<+Cornflakes> see communications pipelines :P
<+SlymodiL> so that means that it is a constant in a system
<+Cornflakes> more or less
<+Talvieno> If one capital ship could target tons of fighters...
<+Talvieno> couldn't the tons of fighters all target the capital ship at once?
<+Cornflakes> yeah
<+Cornflakes> if theres the bandwith for it
<+Cornflakes> it works both directions
<+SlymodiL> ooh that adds another layer to production
<+Talvieno> mhm. That would make the capital ship significantly more vulnerable from all the bandwidth it has.
<+SlymodiL> creating of communication arrays
<+SlymodiL> well I am assuming that bandwidth is equally split between those using it
<+SlymodiL> is that correct to assume
<+Cornflakes> well, the receiver can only accomodate a certain bandwith
<+Talvieno> don't know... I don't think it should be possible to have output without input.
<+Cornflakes> so you cant use all your petabits per second of your battleship on a mbit/s fighter comm
<+Cornflakes> because it wouldnt get most of it
<+SlymodiL> let's say that in this case there are no limits to sending and recieving
<+SlymodiL> would it be split equally
<+Talvieno> If you have five ships of size 1 against one ship of size 15, then the large ship should probably get 75% of the bandwidth.
<+SlymodiL> that's interesting
<+Cornflakes> thats actually a good question
<+Talvieno> 15 being 75% of (15 + (5 x 1))
<+Cornflakes> if you can allocate where your bandwith's going
<+Cornflakes> cant you prevent connections from forming?
<+Talvieno> If you could, that ruins a... OH IDEA
<+SlymodiL> if you own the communications array I would think so
<+SlymodiL> ooh
<+SlymodiL> hacking those
<+Talvieno> Weapons designed to pierce the enemy hull and search for computer systems to directly hack, bypassing the communication arrays.
<+Cornflakes> that should be [a] way, yes
<+Talvieno> You could load them full of viruses like a bomb.
<+Cornflakes> mhm
<+Talvieno> kind of like spiders or something.
<+SlymodiL> yeah that goes with the physical limitation
<+SlymodiL> ooh another layer of production
<+SlymodiL> creating those things with certain aspects
<+SlymodiL> speed/transfer speed/size
<+Talvieno> you wouldn't get the visual representation, but it'd be cool as heck to imagine.
<+SlymodiL> haha yeah,
<+SlymodiL> unless you make a particle effect
<+SlymodiL> which wouldn't be that hard
<+Cornflakes> nah
<+Cornflakes> you couldnt see the "memory map" of the warzone
<+Talvieno> :\ hmm. Good point.
<+SlymodiL> could you explain that
<+Talvieno> unless.
<+SlymodiL> the memory map
<+Talvieno> Memory map is 2d
<+Cornflakes> every program needs a certain space in your computer
<+Talvieno> Programs take up rectangles.
<+SlymodiL> and it shows the ships
<+SlymodiL> ooh
<+Talvieno> Bigger programs take up bigger rectangles.
<+Cornflakes> so you have a literal memory map of programs
<+Talvieno> Programs touching each other can interact with each other.
<+SlymodiL> ah I see
<+Talvieno> Programs can zigzag like tetris pieces and deform themselves.
<+Talvieno> Some like firewalls can completely encircle large areas.
<+Talvieno> or even just single programs as extra layers of protection.
<+SlymodiL> that's interesting
<+Talvieno> Anyway, you [could] see a memory map of the warzone, I think - graphically.
<+Talvieno> You'd look at it like a nodal map.
<+Cornflakes> well, you dont have a data connection back
<+Talvieno> You'd zoom in to each of the nodes/computers separately.
<+Talvieno> hmm...
<+Cornflakes> except if your breaching device has a comms device
<+SlymodiL> could you not create an offline thing that works its way in
<+SlymodiL> deletes everything
<+SlymodiL> or some predesigned orders
<+Cornflakes> this is what i imagine viruses to be
<+Talvieno> well, for hull breachers, yeah... but otherwise it'd kind of suck if you couldn't tell what you were doing.
<+SlymodiL> and it shows you an estimate of what happens
<+Cornflakes> you "program" them and set them lose
<+Cornflakes> and see if they work
<+Talvieno> Slymodi has a good idea.
<+SlymodiL> :D
<+Talvieno> It gives a report as to how the battle went if successful.
<+SlymodiL> yeah
<+Talvieno> e-battle, rather.
<+SlymodiL> and based on what happens you can work on the virus to try to make it better
<+SlymodiL> I want my tiling wm in LT
<+Cornflakes> yeah
<+Cornflakes> if you have the libaries to do so
<+Talvieno> I don't know, I just wish I could play this thing already. lol
<+Cornflakes> if you only have 1 variant of everything you cant improve/tinker
<+SlymodiL> could you also explain libraries
<+Cornflakes> like RL programming libaries
<+SlymodiL> oh ok
<+Talvieno> libraries are small functions you "plug" into programs.
<+Talvieno> like with slots.
<+SlymodiL> interesting
<+Cornflakes> small pieces of code which dont do anything on their own but constitute a program if brought together
<+Talvieno> You could have "hack 1.0" or "thruster control v2.6"
<+Talvieno> Mhm.
<+Talvieno> Thruster control would probably itself be made of more pieces.
<+SlymodiL> that is an interesting way of simplifying a program
<+SlymodiL> I like it
<+Cornflakes> like burn chamber control and coil control and whatnot
<+Cornflakes> and those pieces need connections to their respective hardware to work
<+Cornflakes> :P
<+Talvieno> Mhm.
<+Talvieno> It's a fun idea. (:
<+SlymodiL> yeah totally
<+Talvieno> And you could upgrade the separate libraries to make them more efficient.
<+Talvieno> Or smaller.
<+Talvieno> Or faster.
<+Talvieno> Or better protected, etc.
<+Cornflakes> im totally not surprised that you like it
<+SlymodiL> I can see some nice visualizations and whatnot
<+SlymodiL> but I wonder how complex could you make it
<+Talvieno> Well, you'd keep it simple and self-automated most of the time.
<+SlymodiL> I really enjoy just absurd amounts of complexity
<+SlymodiL> hmm alrgith
<+Talvieno> That way you don't have to micromanage thrusters while you're mining.
<+Cornflakes> it would be the software level of the modular construction stuff
<+Talvieno> That could get tedious and painful quickly.
<+Cornflakes> the more you are willing to tinker, the bigger are the potential rewards
<+Talvieno> Then you could dock at a station and pimp out your software; fine tune, upgrade, streamline, etc.
<+SlymodiL> I see
<+Talvieno> But even without tinkering, your ship would still run.
<+Cornflakes> yeah
<+Cornflakes> reasonably so
Post

Re: A Reinterpretation of Research

#67
A quick note on the idea of "programs": assuming some language will exist for converting data from one form to another, the one requirement for modular programs is... interface specification.

If I can say that Function B requires two inputs from Function A -- say, one integer between 0-255 that represents energy level, and one string describing the nature of that energy -- then Function B doesn't care what Function A looks like or how it chooses values for the two inputs. Function A is a "black box"; all that matters is that its outputs match Function B's expected inputs.

If you can create a simple way to specify those interfaces, then you have a hope of being able to define programs as modular components that can be swapped out for other programs that match the interface spec.

Of course this could get very detailed, and of course the details make the idea more complicated, etc., etc. But the basic concept is pretty much how modular software gets written, especially when you're working a large project with multiple teams of developers, and it does work about as well as anything does. The principle of minimizing side effects through "decoupling" is sound, even if implementing an interface specification model for "programs" in the world of Limit Theory might prove to be somewhat complex in practice.
Post

Re: A Reinterpretation of Research

#69
BFett wrote:I've read through 75% of the conversation and I have to say I'm liking what you guys came up with. I do have a question though. Is the initial attack on a ship's systems just a chance thing or can the player access the ports directly without dice rolling in the background?
the port access itself is not a roll thing, but the action against the firewall behind the port is a roll.

if theres nothing blocking your entry, you dont have to roll.


flat: there would not be any interface spec or anything approaching "real" programming.

software would be very abstract black box mechanisms like spaceship equipment, you slot them together and they work
the nuts, bolts and USB-to-RS232 converters that are between dont matter gameplay wise.

a program spits out "raw sensor output" and another one takes that in and processes it to "object data".

how the interfaces look between is irrelevant
Post

Re: A Reinterpretation of Research

#70
Cornflakes_91 wrote:
BFett wrote:I've read through 75% of the conversation and I have to say I'm liking what you guys came up with. I do have a question though. Is the initial attack on a ship's systems just a chance thing or can the player access the ports directly without dice rolling in the background?
The port access itself is not a roll thing, but the action against the firewall behind the port is a roll.

if there's nothing blocking your entry, you don't have to roll.
Okay, and the better the virus's code the better chance it has of entering a system? Is a virus basically a series of connected modules which work together? Are viruses, firewalls and anti-virus programs procedurally generated in the same way assembly chips are? I assume the attack or defend actions won't be procedurally generated, but will be defined from the beginning.
Image
Post

Re: A Reinterpretation of Research

#71
BFett wrote: Okay, and the better the virus's code the better chance it has of entering a system? Is a virus basically a series of connected modules which work together? Are viruses, firewalls and anti-virus programs procedurally generated in the same way assembly chips are?
Yeah all software is built from modules just like i described equipment in this thread.

So you can build better software by swapping out or assembling modules.

Those would also be procedurally generated, just like other modules.
I assume the attack or defend actions won't be procedurally generated, but will be defined from the beginning.
Well, as hardcoded as ship to ship damage types would be hardcoded.
I personally was thinking of my spectrum defined "damage" types, would give practically infinite variations
Post

Re: A Reinterpretation of Research

#72
Cornflakes_91 wrote:flat: there would not be any interface spec or anything approaching "real" programming.

software would be very abstract black box mechanisms like spaceship equipment, you slot them together and they work
the nuts, bolts and USB-to-RS232 converters that are between dont matter gameplay wise.

a program spits out "raw sensor output" and another one takes that in and processes it to "object data".

how the interfaces look between is irrelevant
I think anyone attempting to create a "modular programs" feature in in LT will, after spending time repeatedly going back to rewrite code boundaries when they change -- and they will -- will discover that focusing on getting the interfaces mostly nailed down first would have saved them a lot of time and frustration. That's where modularity comes from. That's what lets you just "slot [things] together" and they just work.

Whoever wants to do this is free to do it any way they like, of course.
Post

Re: A Reinterpretation of Research

#73
Flatfingers wrote: I think anyone attempting to create a "modular programs" feature in in LT will, after spending time repeatedly going back to rewrite code boundaries when they change -- and they will -- will discover that focusing on getting the interfaces mostly nailed down first would have saved them a lot of time and frustration. That's where modularity comes from. That's what lets you just "slot [things] together" and they just work.

Whoever wants to do this is free to do it any way they like, of course.
You seem to misunderstand me.

The modular programming im suggesting is in no way related to real world programming or scripting.

The program modules are just gameplay objects that behave in more or less predefined ways.

There is no "sensor filter" program that actually implements any DSP, its a gameplay object that increases sensor sensitivity by 5% or something else.

Nothing to worry about interfaces or similar problems :)
Post

Re: A Reinterpretation of Research

#74
Posting this here because relevant.
Image Cornflakes may (hopefully) have the transcript that went with it.

Yellow = firewalls.
Blue = antivirus "sentries".
Green = programs and their (1x2) components.
dark green = background connections that other programs can deform/pass over while moving through the memory, as viruses and antiviruses tend to do. They're all just programs.
Have a question? Send me a PM! || People talking in IRC over the past two hours: Image
Image
Image
Post

Re: A Reinterpretation of Research

#75
Talvieno wrote: Cornflakes may (hopefully) have the transcript that went with it.
you could have asked me before you logged off :roll:

Code: Select all

+BFett:	So memory and programs might look something like this http://forums.ltheory.com/viewtopic.php?f=5&t=2010&start=15#p80508
+Cornflakes:	yeah
maybe
+BFett:	Where memory space is the big box and programs are the small pieces
+Cornflakes:	im more thinking of some rectangular "memory map" and programs filling that space
yeah
+BFett:	ok
Can programs be placed any where?
+Cornflakes:	yep
they have to have access to that area though
so firewalls can block your way around
+BFett:	and is the same true with ports (besides being on the edge?)
+Cornflakes:	ports work the same way, yes
ports would have a position on the map and can only be accessed from that area
+BFett:	I don't quite follow.  What area are the ports restricted to?  Do you mean the perimeter of the rectangular memory map?
+Cornflakes:	some area on the map
maybe the periphery
but it wouldnt have to be that way
+BFett:	I'm thinking of a computer.... if you are on the internet and you are looking at someones machine, ports are going to be the only way to gain access to the computer
+Cornflakes:	yeah, so?
+BFett:	so are you suggesting that there can be ports within ports?
+Cornflakes:	what
where did i say that
or anything approaching that
+BFett:	some ports are restricted to an area of a map.... how are these accessed if not on the perimeter?
Does an attack not occur from the outside in?
+Cornflakes:	a port doesnt have to be connected to the perimeter of the memory map
+Talvieno:	Heyaa. (:
+BFett:	hi Talvieno
+Cornflakes:	ahoi
+Talvieno:	I'm gonna draw a quick picture of how I imagine programs will look. lol
graphically.
+BFett:	thanks talv
+Talvieno:	We need a computer stuff thread. Does one exist yet?
+BFett:	stuff?  Like Technical chat?
+Cornflakes:	i've dumped it in the "reinterpretation of research" thread talv
+Talvieno:	Like viruses + antivirus + firewall + everything else.
And it doesn't feel like it should go there.
+Cornflakes:	it is part of my modular construction stuff
+Talvieno:	It has [some] research, but it's not focused around that.
+Cornflakes:	it belongs to that
i have an idea to work around the "having to cross programs" problem
for communcation/connections
data bus programs
you can allocate some area as data bus and you can connect programs touching it in any way
so you can have many data streams going on without it becoming a puzzle to get it working
for an overhead on your computing resources
+Talvieno:	ahhh.
I had an idea too.
"layers".
You have a background layer, like a large rectangle in the background.
+Cornflakes:	well, that would be the 3d thing we said which would not be that wise
+Talvieno:	anything on top of that layer is connected to anything else on top of that layer.
+Cornflakes:	heh?
+Talvieno:	It'd be easy enough to represent.
You'd be able to see it in the background between the gaps.
+Cornflakes:	that could also not be enough at times
its PCB design at its best
and thats hard puzzling at times
+Talvieno:	hmm, possibly.
Hmm, I'm not sure you're getting what I'm saying.
I may not be explaining it well enough.
give me a minute.
+Cornflakes:	i know what you mean
you have 2 layers of memory
and on both of them you can place stuff
and what "overlaps" is able to communicate
and that sounds to me like PCB design
+Talvieno:	Not really.
+Cornflakes:	why not
+Talvieno:	I mean, no, that's not really what I'm saying.
+Cornflakes:	ah
+Talvieno:	I'm saying you have areas in the background design designated as "everything touches" zones, where everything in this allocated area is able to communicate with everything else inside it by default.
With this, you could feasibly zone the entire memory as one of these.
+Cornflakes:	hm
seems cheap to me
+Talvieno:	The drawback would probably be, it'd take a lot to research, and viruses can get to anything easily.
Maybe.
Just an idea. I didn't think it through very far. =P
+Cornflakes:	and a bit unelegant
its an idea
better have it than not
i'll probably go ahead and draw some mockup for it
later
like, after i've slept
your idea would also work a bit "outside" the rest of the system
quite literally
+BFett:	I can't wait to see what you guys draw up
+Cornflakes:	im just happy that i've got a bit of drive on that now
i've been procastinating for months on that now
like, since when i've posted the last thing in the "reinterpretation of research" thread
+BFett:	almost 3 months?
+Cornflakes:	yeah
actually i've had that idea a while before that
just say "long"
or to put it in joshs terms "soon"
+Talvieno:	okay, uploading a pic.
it's horribly hacked together, so forgive the quality. XD
+Cornflakes:	np
i've been uploading hacked images for ages now :P
+BFett:	I've made worse :)
+Talvieno:	nah, I made this in a real rush.
it's MS paint.
http://i.imgur.com/flBiaV1.png
the idea is, yellow is firewall, large greens are programs, smaller greens are components.
+BFett:	very impressive for MS paint
+Cornflakes:	yep
+Talvieno:	dark green lines allow programs to connect across gaps so other programs can go through them.
+Cornflakes:	however you made it glow
+Talvieno:	light green lines are the image equivalent of a typo. lol
and that was a quick photoshop once-over. =P
+Cornflakes:	lol
+Talvieno:	The light blue are antivirus "sentries".
+Cornflakes:	looks better than what i'd have made
+Talvieno:	the darker blue are ones that actively "patrol", looking for invisible viruses.
+Cornflakes:	in my mind they'd actually be programs like any else
+Talvieno:	things can expand or move over the darker green lines.
well, they're all programs.
it's just easier to color-code them.
+Cornflakes:	ok
+Talvieno:	then you can know what you're looking at a lot faster.
and the blue background grid is purely for show.
I imagine you could have ones that only take up part of a grid space.
HOWEVR
+Cornflakes:	i'd actually include such a grid
+Talvieno:	*EVER TYPO YAY
+Cornflakes:	lol
+Talvieno:	You can see with the grid that it's actually very easy to see through to the background.
+Cornflakes:	and everything moves in that grid
+Talvieno:	making "linking zones" easier to see.
if you chose to include them, anyway.
+Cornflakes:	then "parcel" the programs themself too, visually
+Talvieno:	How different is that stuff from how you imagined it?
+Cornflakes:	not that far
+Talvieno:	(oh, and the programs probably ought to have labels on them.)
+Cornflakes:	components wouldnt be visible that "independently"
imo
you have a big blob "program A"
+Talvieno:	Maybe...
+Cornflakes:	and subcomponents are a "zoom level"
+Talvieno:	hmmm.
But what if I just want to interact with a single component?
+Cornflakes:	or at least components which belong together have a common border around them
+Talvieno:	hmmm... yeah, I like that idea.
+Cornflakes:	im only talking about visualisation
the functional aspect of your mockup is fine
+Talvieno:	Okay, yeah, I'm with you on that.
It definitely needs some sort of border between the parts.
+BFett:	light green are all programs that the enemy ship is running?
+Cornflakes:	or your ship
+Talvieno:	or your ship.
you beat me to it. =p
But ys.
+BFett:	ok
+Cornflakes:	literal ninja
+Talvieno:	*yes. I hate this keyboard.
The part with a secondary firewall in the center could be a critical component.
I would also think that the outer firewall ought to be thinner unless it actually needs to take up that much memory.
+Cornflakes:	its at minimal thickness
one unit
+Talvieno:	hmm, if we use units.
+Cornflakes:	i'd say so
+Talvieno:	The grid was just there to make it easier for me to draw.
+Cornflakes:	continous stuff gets messy fast
maybe a finer grid
+Talvieno:	:\ True. Good point.
Yeah, finer grid.
Unless...
+Cornflakes:	unless?
+Talvieno:	unless this is an example of a smaller memoryspace than average.
+Cornflakes:	yeah
but im more thinking about the unit sizes of programs
the smallest of the small should maybe take up 9 units or so
+BFett:	The more important the program the larger it is?
+Cornflakes:	as they consist out of multiple parts which have sizes larger than 1
+Talvieno:	No, the more memory it takes up, the larger it is.
+Cornflakes:	yeah
+Talvieno:	so...
+BFett:	well both could be true?
+Talvieno:	don't run games on your thruster computers.
you'll regret it later. =P
+Cornflakes:	correlation doesnt imply causation bfett
maybe bigger programs tend to be more important
but they arent big because they are important
+Talvieno:	Both could technically be true at the same time, yes.
That a bigger program is more important.
but cornflakes explained it better.
+BFett:	Yeah, I know what you are saying :P  Carry of
on*
+Cornflakes:	it also depends on how you define "important"
the most important piece of software could be the guardians
+BFett:	Stock items are important
+Cornflakes:	or the big blob in the secondary firewall
+BFett:	Still... memory usage will have to either be defined or random
+Cornflakes:	defined on the memory requirements of the subcomponents
+Talvieno:	Probably based on how much the program does.
+Cornflakes:	sensor data analysis would be big
because it has to buffer large amounts of data
+BFett:	if programs are procedural as you stated, then they could be random to spice things up
+Cornflakes:	meh
maybe changing depending on their activity state
+Talvieno:	Hmm.
+Cornflakes:	inactive sensor -> small
active sensor -> huge
+Talvieno:	maybe the amount of memory they take up is partly controlled by a component.
+BFett:	Sensor code small vs big?
+Talvieno:	"memory-efficient v3.2" could be a component.
+BFett:	sensor cone*
+Cornflakes:	for example
+Talvieno:	and you just slap it onto whatever you need it for.
+Cornflakes:	but it could also be a slider like energy allocation
so if you want better target data you allocate more CPU to your analysis program
+BFett:	ok, I get it.  This calls for ALL aspects of the ship
+Cornflakes:	yeah
+Talvieno:	yeah, anything that could be effected by numbers is something I would consider it necessary to have a program for.
+Cornflakes:	like, everything
+Talvieno:	even down to how quickly and efficiently you can cool your afterburners.
+Cornflakes:	every subcomponent of your ship has some piece of control software attached to it
+Talvieno:	oh, fun idea.
write virus > upload >
+Cornflakes:	and all those pieces give your "sensor firmware" for example
+Talvieno:	enemy's cockpit opens at random
+Cornflakes:	theorethically, yes
but i guess that would be some independent hardcoded circuit
+Talvieno:	i doubt there will be cockpits like that in LT, though. :(
+Cornflakes:	*hardwired
+Talvieno:	yeah, I guess so. There are some things you really don't want connected to the net.
+BFett:	You'd just make everyone where Imp TIE pilot suits
+Talvieno:	wear? lol XD maybe.
then they wouldn't have to worry about whether their cockpit opened.
+BFett:	still a bit sick.... yes
+Talvieno:	Unless they were in the Star Wars universe, in which case the passing air would probably rip their cockpit door off its hinges.
because wings and sound in space.

Online Now

Users browsing this forum: Baidu [Spider] and 1 guest

cron