The cooling power of air around the reactor is 1/2 per air block? I thought it was 1/4. Every time I move the air slider 2 up, I get 1 extra cooling. Is this correct?
Bug squished, without mercy
The cooling power of air around the reactor is 1/2 per air block? I thought it was 1/4. Every time I move the air slider 2 up, I get 1 extra cooling. Is this correct?
Bug squished, without mercy
- A finer heat bar would be dobable
Thanks!
Display More
- The generation/cooling down times are a ratio, as long as you do the same to both timers you get the same EU/t.
Example: A 120 EU/t reactor running for 60 mins with a 30 mins cooldown (80 effective EU/t) ..
now halve those times: 30 mins on / 15 mins off (still 80 EU/t)
minimal times: 2 secs on / 1 sec off (still 80EU/t)
Although I will see if I can squeeze another slider in, for those who don't want to do the maths.
The heating and cooling happens in granular 1 second intervals. For heat generated as an exact factor of cooling, that works, but when they aren't the shorter the timing the more that granularity is apparent. I'll give an example of what I mean.
http://www.talonfiremage.pwp.b…q=1k101010015015111r11r10 176 heat, 66 cooling 200 active eu/t 3.33 energy efficiency.
Minimum timer 1 sec generating / 2 sec cooling. 66.667 eff eu/t (because 22 cooling is wasted every 3 seconds using this minimum timer)
Maximum timer 33min 15 sec generating / 55min 41 sec cooling 74.8 eff eu/t This should actually be shortened to 55min 40s, waiting that last second for it to finish cooling means the first second it is generating wastes 66 cooling, effective eu/t is 75
8.133 eu/t is gained by going from the minimum complexity timer to the maximum. 80% of that is 6.506. What is the minimum timer that gets 6.506 better then the simplest possible timer, and no more than 1.627 worse than the most complex timer possible?
2sec on / 4 sec off is 66.667, same as minimum.
3sec on / 5sec off gets 75, same as maximum. This is the minimum complex timer that gets at least 80% of the difference. It happens to get 100% of the difference, being perfectly equivalent to the best timer.
With a linearly increasing timer complexity, for people like me who don't use redpower/ computer controller mods, this simplifies the construction of the timer by a factor of 665. Going with the simplest one is a wise choice if not a lot of cooling gets wasted, but in this case a timer less than 3x as complex gets >10% output boost. Being able to contrast simplest, most complex, and most of the way toward best output at a glance lets you make decisions about what kind of timer to construct. That was my thought at least. I don't know how many mad scientists make mark IVs without redpower or other smart controller mods. I may be the only person that uses that feature.
- I'm unsure what you mean with the last idea, the planner already displays the amount of 'top-up' lava needed for pre-heated designs that cooldown over time even when generating. (In the Breeder info panel)
Instead of the user using a slider to create a target starting heat, that slider becomes a target for target heat during operation. With a perfect breeder, starting heat is operational heat, so this is more for positive breeding. So instead of 6k starting heat and seeing how long it can run before meltdown, I put the slider at 9k heat. This would tie in to the timer suggestions to come up with the required starting heat for each suggested timing interval.
The minimum timing interval would likely be heat loss over time, so would likely need to have a starting heat over the target. It may even have heat requirements that would melt parts and thus not be doable, knowing that tells you you either need to aim lower or make the timer more complex/better.
The 80% good timer would probably be closest starting heat to the target 9k heat.
The long timer would probably have a starting heat around 8k, since it would spend half the time under and half the time over.
It lets the user aim for what they really care about, and tells them how to get that result. I like what's there now too, you can plug in a starting heat and see what happens. What I'm suggesting excludes that, as average operational heat dictates starting heat, and vice versa. I suggest a toggle feature, where you can change the slider from target heat to starting heat and back.
Much better planner now.
edited last post with old planner.
I'm really digging this! nice work talonius.
I can see now that my Isotope fueled positive breeder mark II design http://www.talonfiremage.pwp.b…q6e0i34xtybddwet470h6ubk0 has a tighter window than I thought, only from 5k to 5.3k for breeding isotopes in a full cycle without meltdown.
When I was looking I noticed that the cooldown time was not working how I expected, it said no cooldown needed.
I've edited the timing scale slider to directly manipulate the displayed generation time, the planner will attempt to match that with an approprate cooldown time
It will round the cooldown time to the nearest second only if doing so will result in less than 5% reduced cooling, otherwise it'll round the cooldown time UP.
As for the starting heat, here's how the planner works under the hood.. assuming a possitive breeder:
There's a "Heating Phase" prior to the Generation Phase where the planner assumes there are no SUC item nor SUC supply, the reactor is also concidered off. It will try to simulate the amount of lava needed to get to the desired target at a safe pace. In this phase, all components that gain heat due to the introduction of lava are flagged as "connected to hull".
The last part of this phase will total up all the heat in the reactor and it's components.
The Generation Phase starts as normal and will most likely stop due to critical heat levels.
The Cooldown Phase starts and will contine until all components that were previously "connected to hull" are less than the desired starting heat, the remaining components must reach 0 heat.
At the end of the phase the planner again totals up the heat and compares it to the value from the end of the heating phase.. the result is display on the Breeder Info tab.
I did it this way due to the fact the components can cooldown at different speeds and if I end the cooling phase prematurely then any component that lags behind will be at risk of melting after continual use.
You can use this heatloss stat to gauge how often you need to 'top up' the reactor with lava after each complete generating/cooling cycle. An addon to view the actual hull temperature is recomended.
I'm unsure how to calculate the starting heat needed based on an average value, prior to running the simulation.
Edit: Cooldown bug squished, a missing line in the data tracking class ment that data from the heating phase was bleeding over into the generation phase.
The standalone crashes after some time trying to reset the grid.
#
# JRE version: 6.0_29-b11
# Java VM: Java HotSpot(TM) 64-Bit Server VM (20.4-b02 mixed mode windows-amd64 compressed oops)
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
#
--------------- T H R E A D ---------------
Current thread (0x000000000669e800): JavaThread "AWT-EventQueue-0" [_thread_in_Java, id=2884, stack(0x000000000c380000,0x000000000c480000)]
Stack: [0x000000000c380000,0x000000000c480000]
--------------- P R O C E S S ---------------
Java Threads: ( => current thread )
0x000000000d465800 JavaThread "D3D Screen Updater" daemon [_thread_blocked, id=6556, stack(0x0000000010de0000,0x0000000010ee0000)]
0x000000000058b800 JavaThread "DestroyJavaVM" [_thread_blocked, id=4516, stack(0x00000000023c0000,0x00000000024c0000)]
=>0x000000000669e800 JavaThread "AWT-EventQueue-0" [_thread_in_Java, id=2884, stack(0x000000000c380000,0x000000000c480000)]
0x0000000006662800 JavaThread "AWT-Windows" daemon [_thread_in_native, id=2488, stack(0x0000000008100000,0x0000000008200000)]
0x0000000006662000 JavaThread "AWT-Shutdown" [_thread_blocked, id=1448, stack(0x0000000008000000,0x0000000008100000)]
0x0000000006655800 JavaThread "Java2D Disposer" daemon [_thread_blocked, id=1428, stack(0x0000000007f00000,0x0000000008000000)]
0x00000000065d7000 JavaThread "TimerQueue" daemon [_thread_blocked, id=10612, stack(0x0000000007c20000,0x0000000007d20000)]
0x000000000657d000 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=10900, stack(0x0000000007840000,0x0000000007940000)]
0x000000000657c000 JavaThread "C2 CompilerThread1" daemon [_thread_blocked, id=1660, stack(0x0000000007740000,0x0000000007840000)]
0x0000000006563800 JavaThread "C2 CompilerThread0" daemon [_thread_blocked, id=10644, stack(0x0000000007640000,0x0000000007740000)]
0x0000000006560800 JavaThread "Attach Listener" daemon [_thread_blocked, id=8108, stack(0x0000000007540000,0x0000000007640000)]
0x0000000006560000 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=1340, stack(0x0000000007440000,0x0000000007540000)]
0x000000000650e000 JavaThread "Finalizer" daemon [_thread_blocked, id=9484, stack(0x0000000007340000,0x0000000007440000)]
0x0000000006508000 JavaThread "Reference Handler" daemon [_thread_blocked, id=11224, stack(0x0000000007240000,0x0000000007340000)]
Other Threads:
0x00000000064fb000 VMThread [stack: 0x0000000007140000,0x0000000007240000] [id=9788]
0x000000000658e800 WatcherThread [stack: 0x0000000007940000,0x0000000007a40000] [id=11004]
VM state:not at safepoint (normal execution)
VM Mutex/Monitor currently owned by a thread: None
Heap
PSYoungGen total 305856K, used 105643K [0x00000000eaab0000, 0x0000000100000000, 0x0000000100000000)
eden space 262208K, 39% used [0x00000000eaab0000,0x00000000f0faf458,0x00000000faac0000)
from space 43648K, 5% used [0x00000000faac0000,0x00000000faceb9a8,0x00000000fd560000)
to space 43648K, 0% used [0x00000000fd560000,0x00000000fd560000,0x0000000100000000)
PSOldGen total 699072K, used 0K [0x00000000c0000000, 0x00000000eaab0000, 0x00000000eaab0000)
object space 699072K, 0% used [0x00000000c0000000,0x00000000c0000000,0x00000000eaab0000)
PSPermGen total 21248K, used 15401K [0x00000000bae00000, 0x00000000bc2c0000, 0x00000000c0000000)
object space 21248K, 72% used [0x00000000bae00000,0x00000000bbd0a440,0x00000000bc2c0000)
Code Cache [0x00000000024c0000, 0x0000000002730000, 0x00000000054c0000)
total_blobs=1091 nmethods=653 adapters=390 free_code_cache=47949696 largest_free_block=14144
Dynamic libraries:
[error occurred during error reporting (printing dynamic libraries), id 0xe0000000]
VM Arguments:
jvm_args: -Xms1024M -Xmx1024M
java_command: IC2ReactorPlannerV2.jar
Launcher Type: SUN_STANDARD
Environment Variables:
--------------- S Y S T E M ---------------
OS: Windows 7 , 64 bit Build 7601 Service Pack 1
CPU:total 12 (6 cores per cpu, 2 threads per core) family 6 model 44 stepping 2, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, ht
Memory: 4k page, physical 6282332k(2393456k free), swap 12562816k(7009128k free)
vm_info: Java HotSpot(TM) 64-Bit Server VM (20.4-b02) for windows-amd64 JRE (1.6.0_29-b11), built on Oct 3 2011 01:06:42 by "java_re" with MS VC++ 8.0 (VS2005)
time: Wed Feb 29 19:12:20 2012
elapsed time: 609 seconds
The standalone crashes after some time trying to reset the grid.
Hmm, all the time.. or was it just a 'one off'?
maybe an nice feature would be the option to swich designs in the old planner to the new planner in some application (manualy doing them all is an huge task since there are so many)
maybe an nice feature would be the option to swich designs in the old planner to the new planner in some application (manualy doing them all is an huge task since there are so many)
When I believe this new planner is ready, it'll replace the old planner's location. The new planner will decode all designs made by the previous planner, if you need to look up an old design right now, you can copy the url of it and press the Paste URL button on the new planner (or alternately, Ctrl+V it into the design code text box)
no one timer, happens all the time usually after around 10 attempts or so.
I cant get the planner to work it keeps loading forever. Using google chrome and java 6. I will try some other browsers tomorow.
Using google chrome
Problem found, try firefox.
Problem found, try firefox.
I use chrome and java 6 too. No problem for me.
The v2 planner has been released into the wilds! ... I've randomly gone through the nuclear engineering section clicking on reacter link to check if they load up fine and so far everything seems okay.
Now to make the page the applet sits on prettier and more informative.
The v2 planner has been released into the wilds! ... I've randomly gone through the nuclear engineering section clicking on reacter link to check if they load up fine and so far everything seems okay.
Now to make the page the applet sits on prettier and more informative.
nice job, seems your little "project" seems to be getting an epic proporsion
Seems like there is a problem with the links that are on the forum now, but its fixable from the user end if they remove the "www." from the url. Check your mimetypes, or maybe domain forwarding not pushing the www sub. If you have no idea what i'm talking about(You probably do, since JAVA), get at your hosting provider and ask them to look at it.
Strange, if all links were broken for everyone I think I'd of been swamped by the cries of many reactor users... I've altered the page slightly in hopes it'll fix the problem for you.
try this link http://www.talonfiremage.pwp.b…hy7ie6lhynne84szpa50pn4lc
And play with timing. Cooldown never changes.
Hmm.. it appears the cooldown phase was interupted by a 'cell death' event.. the hull has gathered so much heat that the IHDs are suiciding themselves during the cooldown phase.
Im going to have to think about how to catch that.
Edit: Okay.. I think the planner now detects when there's a risk to components melting in the cooldown phase and stops the generation prematurely. In that example design the cooling cell suvives with a little over 1% 'health' left.
Also, resources needed was fixed (the planner was doubling needed alloy) and now has the option to list 'intermediate' resources instead.