Frames.......a matter of utility? Options

[Pendaric]

Another rule oddity for perusal. :)
The creating of frames rules are perfectly fine save for one small problem that defines the theory of relativity subjective time. Apparently a programmer uploading utilities in to a frame accelerates through the space-time continuum the more utilities they are uploading.
It takes more time to upload a single rating six utility than lets say...2 billion rating 5 utilities!
Or the same time as lets say....3 billion rating 6 utilities!
Good news for agent/daemon programmers.

Does someone already have better house rules for this oversight?
Though I admit, I find this very amusing as is. :rotfl:

[Taran]

Make upload time dependent on program size?

[Fix-it]

[Slump]

Yes, upload time is dependant upon transfer speed (which can be limited by what kind of connection you have, as well as your own deck) and program size. Frames (and agents) have the benefit of being run by the system you're decking, rather than your own deck, which is why they seem to upload/run faster -- they don't take up your own deckspace and icon bandwidth.

[Pendaric]

Am sorry Slump what does transfer time have to do with programming?
Its the programming section of the frames that am refereing to for clarification.
Specifically the putting utilities into the frame core and the time to do so.

What is it they say about a joke you have to explain? :twirl:

[Lazarus]

Nothing to say. Wrong posting. Damn I feel stupid.

(There is nothing to see here. <waves hand> This isn't the post you're looking for.)

[Pendaric]

To be honest I never post a topic without already reasoning the problem at least to my own satisfaction. I do leave room for change but I usally have most of the angles covered. After all innovation is hard, comprehension is only a matter of time.
In this case the maths representing the upload time of a utility payload into a frame is more conserned with the utilities rating and presumably their complexity, rather than their size or number. Which would be fine save for a section in the equation concerned with averages.

The option to base it on utility size has merit but the maths gets interesting. My take is to use the actual payload rating (total of utility ratings being uploaded), as its faster to place the utilities into the frame than actually program a utility or frame core and
as it removes a sum (I like simple but realistic rules).
I'll post the equation once I've crunched the equation to its simplist form and cross referenced against current task times. With standing only one utility of course. :P

[Pendaric]

(Utility payload x 1.5)x 2.
The higher utility payloads, 28 upwards are now increase in base time but only agents with cores of 6 up will really notice unless someone has a high (and dumb) smart frame/agent utility only platform.
The low end utility payload packages of course much faster and realistic.:)

[Slump]

Oops, my mistake, I thought you were refering to upload time.

For programming and loading a frame, I always took the rules to mean that you actually had to have the util you're loading to load it, it's not programed then.

So you make the attack deadly, then make the frame, then load the attack program into the frame.