|
I'm impressed, Decoy Badger! I'm going to need some time to digest what you just said and turn it into code. One thing, though:Decoy Badger posted:If the binary trigger is activated (and there doesn't seem to be any pattern to why/how this happens, except that it can't be activated less than 4 turns apart): I've previously dismissed market news as useless, but maybe I just didn't know how to read it. If you think you can do something useful with it, I'll get you a fresh set of data with news items. I'm going to figure out how a, b, and c work for different modules, as well as what formula is used to calculate demand for multi-activity modules, as well.
|
#
?
Jul 21, 2021 19:06
|
|
|
|
| # ? May 2, 2024 08:35 |
|
|
I went through and collected the round 1 news. There were 10 predictions about 7 industries, excluding the ambiguous ones. Of these, three predicted future movement opposite to the last turn trend, but only one was accurate. Four successfully predicted that the market trend would continue which is hardly exciting. Five predictions were contradicting other predictions made in the same or previous turn, but three of them were accurate - which is what you'd expect, as both directions were predicted. Overall, 8/10 predictions were accurate. However, predicting that a trend will continue is not particularly useful. Only 1/3 contrarian predictions were accurate which is not a good sign. So the market forecasts are accurate more often than not (80%). However, a simple trend-following prediction would be right 92% of the time (only 8 trend reversals in round 1, of 96 total market changes excluding turn 1), so listening to the news is actually far, far worse than the naive approach.
|
|
#
?
Jul 22, 2021 02:13
|
|
|
Huh. Does that mean assuming the news is wrong is a useful approach? Also, I'm taking a short hiatus from the LP due to RL events. It's nothing serious, but computer access is a little awkward right now.
|
|
#
?
Jul 22, 2021 21:22
|
|
|
FredMSloniker posted:Also, I'm taking a short hiatus from the LP due to RL events. It's nothing serious, but computer access is a little awkward right now. 
|
|
#
?
Jul 23, 2021 04:30
|
|
|
Hope it's a fun reason, like you're kayaking at the Olympics or something. I looked at the module usages and it turns out that: A) There is a hard demand cap on how much total demand (usage * total commerce modules) there is. Using round 3 as a base, for the weather centres, this was around 30 at the start and ended at 24. For pharmaceutics, this started at around 37 and ended at around 38. So it takes a few dedicated stations, but when usage was tanking we were competing with each other for limited demand with too much supply. Lower charges would not have helped much. B) I consistently got higher usage numbers than the other two players and I'm pretty sure the reason is that I had weather and pharmaceutics modules scattered on practically every station. I had 5 stations with pharmaceutics and 3 with weather stations; Fred had 1 and 3; Berryjon had 2 and 1. My pharmaceutics usage was +26 over the others, and weather station was +10 and +20 over Fred and Berryjon respectively. Maybe the algorithm that doles out usage gives a minimum amount to each station offering services, then scales it for the number of modules? So the lesson is that diversity matters in business. Fred's 29-pharma station was a thing of absolute beauty but when the demand cap is hit, it would probably lose in earning potential to two stations with 14 pharma modules each. I'm going to guess that the hidden demand cap probably follows a similar system to the market. No idea if the news can predict it though. This also indicates that there is an upper limit to how much money can be made in the game, and ultimately to growth - and this limit would probably be hit at around 24 total commerce stations which could saturate every single market. Maybe this is where advertising would come in.
|
|
#
?
Jul 24, 2021 03:40
|
|
|
Decoy Badger posted:Hope it's a fun reason, like you're kayaking at the Olympics or something. Sadly, no. I live in a camper, which my parents own, and they wanted to make use of it for a couple of day trip vacations. I've moved my computer into their house, but the lack of privacy and various 'as long as you're here' tasks have made it awkward for me to really dig into the game. That said, you seem to be having fun contributing to the thread. Check your PMs for info on how else you can contribute! Is this your way of saying you'd be interested in being player four once the LP kicks back in, or are you just enjoying an excuse to post Space: 1999 images?
|
|
#
?
Jul 24, 2021 19:15
|
|
|
FredMSloniker posted:Is this your way of saying you'd be interested in being player four once the LP kicks back in, or are you just enjoying an excuse to post Space: 1999 images? I'm sorry, I'm just a Space: 1999 fan. You folks have broken this game over your knee, and while it is very fun to read about, I don't think I could participate on anywhere near that level.
|
|
#
?
Jul 27, 2021 10:09
|
|
|
Rappaport posted:I'm sorry, I'm just a Space: 1999 fan. You folks have broken this game over your knee, and while it is very fun to read about, I don't think I could participate on anywhere near that level. I'm sorry to hear that! I hope you'll at least continue to contribute to the thread, but all three of us would be happy to help you out if you change your mind. We've all learned a lot about how the game works over the course of the LP, and there's more learning to do. Speaking of, I've sent Decoy Badger what he needs to do some digging into the game's memory and/or code himself. I'm itching to get back to the LP, though, so I'm working on some tools that, while they may not model the economy, will at least react to things like being undercut and market saturation. Given my current living situation, though, progress will be slow. I can at least talk a bit about the next mission, Lunar Base. In order to construct a Settlement station on the Moon, our goal for this mission, we have to do some research. One of our top priorities will be Construction research; not only do we have to get to Construction B50 to unlock the Dry Dock module, but by getting to Construction B00 along the way, we unlock the Fabrication Lab module, which is our only source of Fabrication research - and we need to get to Fabrication C00 to unlock the Settlement Life cargo module. We need to get started on that as soon as possible. We also need to get started on Transport research quickly. As we saw in the previous mission, it's difficult to get the ball rolling with only Shuttle Port modules to generate it, so we'll want to be putting them into research mode as soon as it won't cripple growth. Getting to Transport B00 will unlock the much more efficient Space Tug module, but we need to get to Transport B50 to build the Propulsion Unit module. That's not the only research we need, though. The Settlement Power cargo module requires Energy C00, and our only initial source of Energy research is the Solar Collector module, another bulky module. Fortunately, it actually provides resources, and we only need to get to Energy A50 to unlock the Energy Platform module, which also provides Energy research. Once we have all of that, we'll need to build. We'll purchase three stations on top of the ones we have commercing and researching: a Dry Dock station in low earth orbit, a Cargoliner in low earth orbit, and a Settlement on the Moon. We'll then build the Dry Dock and the Cargoliner, which will carry the Settlement Life and Settlement Power modules to the Moon and deliver them to the Settlement to complete it. It's a lot to do, and unlike the Mars Rescue mission, we'll be back to starting with 200 credits. Balancing commerce and research will be key; whoever best times their transitions from commerce to research and back again will have the privilege of forming Moonbase Alpha. aeiou
|
|
#
?
Jul 27, 2021 19:52
|
|
|
Rappaport posted:I'm sorry, I'm just a Space: 1999 fan. You folks have broken this game over your knee, and while it is very fun to read about, I don't think I could participate on anywhere near that level. Hey, Fred is the one that's broken this game like Bane. He's written programs to help him optimize for economic growth. I'm just good at station design and optimization. Speaking of, hey Fred, we haven't actually won Scenario 1 yet. Want to do a quick re-run through that to test your programs, and Rappaport can join us to get a feel for things.
|
|
#
?
Jul 30, 2021 03:39
|
|
|
All the high-level optimization doesn't matter when you can get screwed by the RNG or undiscovered mechanics any time! Like stations randomly exploding! Seriously, my "market prediction" was simply: "Did I get 100% usage? Yes: Increase price by 2-3; No: Decrease price by 2-3." The hardest part is getting a station design up, and there's a tool to do that for you without the need for spreadsheets or even uploading screenshots - just post the code. That being said, I have been doing some exploratory surgery on the game. Earth Orbit Stations from the ground up I'm not a professional programmer, and what little I know about it comes from slapping together dumb programs and hacking dumber games. I never owned a C64 and it was developed before I was even born. That being said, the Commodore 64 is an interesting machine. Coming from a more modern perspective, it's an 8-bit microcontroller with a comically small amount of RAM and memory - the sort of thing that you would find in a cheap children's toy, a musical greeting card or the original Arduino. The era of wacky computer architecture was largely over at this point and a lot of the design principles embodied in the C64 have survived to the modern day. There's a microcontroller running everything, system RAM to run the program, a dedicated video processor with its own optimized RAM, an audio chip, and a way to process button presses. Unlike a bare microcontroller or game console, it was clearly built to be a home/hobbyist computer targeted at beginning programmers. Instead of expecting people to deal with simple uC opcodes, there's a Kernal [sic] ROM giving a layer of abstraction and a BASIC ROM giving a relatively high-level layer of abstraction above that. BASIC is pretty, well, basic, without much built-in memory management that is taken as given in newer languages. As an early personal computer, the C64 did not have any built-in permanent rewritable storage, i.e. what a HDD or SSD would do today - mostly because it was too expensive. Instead, storage was through cassette tape, expansion cartridges, or the 5-1/4" floppy disk (storage capacity: a whopping 360 KB) and associated disk drive. Earth Orbit Stations came on two floppy disks. Floppy disks are magnetic storage, so to avoid people from overwriting the game I'm assuming that EOS punched the read-only notch onto the first disk. This means that all saved games had to be saved onto a second, writable, disk hot-swapped into the C64. The program was further split between the main program on side A that would get loaded into RAM, and resources (like each of the mission scenarios) left on side B/save disk and accessed as needed. While a very familiar arrangement to anyone who played games on CD, the disk drive meant that this was also slow as hell. Fred is a saint for putting up with that clunky interface enough to make the LP. From what Fred's told me, saved games start as a straight copy of the resource disk side which is admirably lazy and should make things easier for us. This also explains why you can't have multiple missions saved, and can't restart missions: the game is modifying its own code as it goes! This self-modifying code can't be re-initialized to the starting settings without a full wipe and reload from the original resource disk. This is the kind of craziness you get up to without a HDD. We're focused on exploring the game engine, so need to delineate that from the tremendous amount of GUI overhead and the AI designer. As I learned from programming my own station designer, the actual part that does the work is pretty small, making it usable takes up 10x the effort. Thinking about how I did my designer, each player's stations must be stored in some sort of array that records the station, location, orientation and status of each module. Each player must also have arrays that record their respective commerce charges and other stats. There should also be an array that records the value of each market and the hidden variables like demand cap. So if I want to figure out how the game engine processes these arrays, I need to find out where the arrays are kept. From there, I can figure out what functions read or manipulate the arrays and how those work. Since we know that the game copies the resource disk to be a save disk, we can browse a save file and see what pops out. Going through it with a hex editor shows that it has a fairly straightforward layout: x00000-x04100: Module data - Easy to tell, every module starts with a name. x04101-x04AFB: Player data - Easy to tell, each player is labeled. x05A1F-x12B6F: Station data - I guessed it's this because there are 32x4 repetitions (4 players x 32 station limit) of a 144-length array, which is just slightly more than the 11x13 grid squares on the designer. x26B00-x2A8E0: Mission data, news data, and GUI/collision detection stuff - Easy to tell because there are oodles of text strings. Apparently your station(?) can just randomly explode?? The large amount of whitespace padding each section of the save file makes me suspect that memory is statically allocated, by hand. This should help with taking apart the engine. At the very end of the save file, this caught my eye:  Doesn't look like much, but there's clearly some kind of spatial pattern to the hex codes if you squint, indicating image data:  If it were a more modern system I'd assume some kind of RGB code, but the C64 had only 16 colours, half a byte of colour space. Let's start by confirming the image dimensions. The C64 had a 320x200 resolution, but only 160x200 with "full" colour images - each pixel was doubled horizontally. But the size is wrong for a splash screen. Looking at the code, everything lines up best at a multiple of 15 bytes. So that would be 30x119 half-byte colour codes. Realigning it to that configuration, a much more coherent pattern appears. But I'm doubting that it is a full-colour image - a lot of the colour codes make no sense next to each other, and the monotonic increases in value we see wouldn't work when greyscale values are scattered all over the colour table. So I'm going to assume it's a 16-colour greyscale palette, though I have no idea how feasible this was on the C64. Let's try to display it. This is a simple bitmap, so I'll try to shove it into the .bmp format. I created a 30x119 bitmap with all 16 C64 colours present to ensure the colour table was properly populated. I extracted the C64 data and ran it through a bunch of regex to convert everything to 24-bit RGB, then inserted it into the bmp file. This is what came out:  Neat!
|
|
#
?
Jul 30, 2021 16:45
|
|
|
Hah! So the L1 Station, and the Jupiter Explorer are both right out of 2001!
|
|
#
?
Jul 30, 2021 16:54
|
|
|
Decoy Badger posted:The program was further split between the main program on side A that would get loaded into RAM, and resources (like each of the mission scenarios) left on side B/save disk and accessed as needed. While a very familiar arrangement to anyone who played games on CD, the disk drive meant that this was also slow as hell. Fred is a saint for putting up with that clunky interface enough to make the LP. Having an emulator with a warp speed toggle makes this significantly more convenient. Decoy Badger posted:From what Fred's told me, saved games start as a straight copy of the resource disk side which is admirably lazy and should make things easier for us. This also explains why you can't have multiple missions saved, and can't restart missions: the game is modifying its own code as it goes! This self-modifying code can't be re-initialized to the starting settings without a full wipe and reload from the original resource disk. This is the kind of craziness you get up to without a HDD. To get more specific and correct an error or two: the game came on two floppy disks, the first of which being what was colloquially called a 'flippy'; by flipping the disk over, you could access a second set of data. (Think of a DVD where one side holds the widescreen version of a movie while the other side holds a pan-and-scan version.) The first disk was double-sided, with the Boot disk on one side and the Archives disk on the other side, while the second disk only had one side, the Missions disk. The Boot disk contains the program. You only use it once, when starting the game. The Archives disk contains mission-specific data for each of the seven missions, while the Missions disk contains data common to all missions, like images of the various station types. To start a new game, you:
This is actually not terrible for multi-disk C64 games. Ultima V had nine disk sides (five physical disks), and disk-swapping was constant, especially if you didn't have a second drive to put the Overworld disk in. And disk drives were expensive; one cost about $1,000 in today's money (the system itself was about $1,500 in today's money) Anyway. Back to Decoy Badger. Decoy Badger posted:x05A1F-x12B6F: Station data - I guessed it's this because there are 32x4 repetitions (4 players x 32 station limit) of a 144-length array, which is just slightly more than the 11x13 grid squares on the designer. Typo here: the grid is 12x11, or 132 tiles. Decoy Badger posted:x26B00-x2A8E0: Mission data, news data, and GUI/collision detection stuff - Easy to tell because there are oodles of text strings. Apparently your station(?) can just randomly explode?? I'm going to guess that's a news item that applies to NPC stations. What's the exact text in the data? The C64 had several graphics options, balancing memory usage and graphics capability. The one used for gameplay is 320x200 with two colors; each 8x8 region can have its own foreground color, but the whole screen shares a background color. This is what that data looks like when rendered: 
FredMSloniker fucked around with this message at 19:31 on Jul 30, 2021 |
|
#
?
Jul 30, 2021 19:17
|
|
|
Ah, you beat me to that last one. I realized that the 15-pixel width was too narrow and checked out what it would be as a black-and-white bitmap instead of greyscale: Re: Explosions: "(x) was destroyed as it passed through a meteor shower. There were no survivors" "(x) has been hit by large meteors and destroyed. Inadequate warning is blamed" "(x) was hit by orbiting space debris. The impact caused a fire that gutted the station" "(x) was destroyed by a fire. The cause of the fire is unknown" "(x) exploded and was destroyed by resulting fire. An investigation is underway" Some news is still relevant today: "sequels to a 1970's space fantasy movie are being released next month"
|
|
#
?
Jul 30, 2021 20:30
|
|
|
This remains the coolest LP on the forums right now. Eagerly awaiting the continued dissections and missions from you three!
|
|
#
?
Aug 3, 2021 15:53
|
|
|
RL continues to be less than conducive to starting up the LP again, but I'm working on it. Your support is appreciated, however! Here's a little something extra for Decoy Badger, or anyone else, to gnaw on. The archive contains:
|
|
#
?
Aug 4, 2021 01:48
|
|
|
We'll be here when you get back man, no problems. Badger, while you're doing Math to the Numbers (and that's the scientific term), do you think so can see if there's some sort of soft upper-limit to the amount of commerce that all stations across all players produce? Because I am still convinced we saturated the Pharmaceuticals market last game, and it tanked all our economies.
|
|
#
?
Aug 4, 2021 05:59
|
|
|
Thread's rad, don't understand game, will continue lurking periodically.
|
|
#
?
Aug 6, 2021 07:51
|
|
|
I'm planning on examining the demand cap, market prediction, news and usage calculations. I'm still teasing things apart, but so far there absolutely is a hard cap on demand - in the scenario I just tested, about 9.72 total usage for Energy. I just can't find (yet) where in the code those values are coming from. Some parts were trivial - e.g. giving yourself a dozen stations, boatloads of money, or even changing module connector layouts. But the market has some pretty deep roots too. It does seems to be somewhat in line with the predicted model with the form T(n)=T(n-1)*a. I'm starting to think that the explosion messages were meant to be in the game but were cut prior to release, because nothing references their addresses. Probably because of, well, you know.
|
|
#
?
Aug 7, 2021 05:53
|
|
|
Earth Orbit Stations from the ground up: Usage Cap part 1 So we've loaded up a mission, built a station, are sitting around and extracted the RAM. What does it have? My focus today is unravelling the mysteries of the market demand/usage cap. We saw in the past round that when you have too many modules all delivering the same product, total usage between all modules is capped to a fixed number, usually in the low double digits. When there are 12+ stations in play this can become a huge limiting factor. So let's start by looking at the market database:  Some things were pretty obvious, but there are some interesting mysteries buried there. I've labeled things with my best guess for the Sciences row, but who knows? I tried looking for some kind of demand cap value, and built a set of Solar Collector stations, since they only deal with Energy. I also don't want to futz around with actually playing too much so I set my loan to 0 and cash to 7000 (at 0xF0B9 and 0xF029 respectively). Oh, and let's set the base market to 200 we won't have to deal with prices changing too much. This will also let us see how the market changes with each turn. Now to build a station with 5+ Solar Collectors. It's at this point I realize I should have gone with building platforms as they are way smaller. But oh well.  I charged the default amount which should in theory give 100% usage. Now let's run a turn and see what happens!  Hm, full usage. And the market went to 201.3! At this point I kind of started smashing everything to see if anything worked at all. Nothing did, and checking the next turn's save state confirmed that a lot of the values were reset to their originals. So we have to go a bit deeper - presumably these are being reset from the mission disk somewhere. Let's start by figuring out what the actual cap is. I hacked in extra stations for myself because I didn't want to advance the turn a bunch - I basically just copied my second station a few times. With 54 solar collectors, I advanced the turn - and got 18% usage or 9.72 units of use. The market went up (and I reset it to 200 each turn) so the price charged probably had no deleterious effect. I couldn't find various interpretations of 9.72 in the RAM, so I set my prices to 0.1 and reran the turn to see how it would change: I got 18% usage again! So the demand cap is definitely independent of price charged. I advance a few more times and get 18% each time. I also tried with multiple players and the demand cap stayed unchanged (usage went to 17% with 55 solar collectors - 9.35 total usage). Then I went and pretty much bashed anything that looked relevant in the RAM to see if I could get any change at all - nothing, though I did manage to break the significant digit code - "it is now year 00001996". It seems important that there's no rounding at all - your revenue equals usage times charge exactly. Combine that with the fact that the cap actually changed with a different number of solar collectors, and it looks like the usage percentage is being calculated from game data, then applied - i.e. the cap isn't retrieved directly from some fixed address and usage made to fit. Which means we have to go deeper. If you think about it, the game should only update market information between turns, since the player charges and station manifests can keep changing until "next turn" is pressed. So the way to find this usage cap is probably to monitor addresses we know will be used. The simplest one I found was 0xD0C4-D0C7, which seems to be the "revenue received" value. Let's set a monitor on that address and advance the turn. Nothing actually happened until the turn processed and I opened up the report screen, where it got loaded a whole bunch, maybe 40 or 50 times, but using only two program counter locations: 0xA9A1 and 0xA9E0. So we have our first clue - what part of the RAM the code handling "received revenue" comes from. Let's disassemble the code in that part and take a look at it:  It grabs a value (LoaD A), shoves it somewhere else (STore A), then moves over one byte (DEcrement Y) and repeats until it's done this 4 times (Branch if PLus back to the start). 0xA9E0 does the same thing but in reverse. So not very helpful - this is likely part of a function that loads an array into a working part of memory to do operations to it. We need to find out what happens after it's moved, so let's tell the emulator to stop after STA (0xD0C4) and step through cycle by cycle after that point. We've learned some valuable stuff: a cap definitely exists, it is independent of the number of players, and it doesn't matter what you charge (advertising seems like it would change this however). We still don't know the underlying source of the cap, but diving farther into the assembly code will hopefully be fruitful next time!
|
|
#
?
Aug 10, 2021 14:06
|
|
|
Assuming this is running on a C64, that's pretty wild. For one thing, the 0xA000-0xBFFF range is normally where the BASIC ROM lives. It's clearly mapping that chip away to use the RAM underneath it, which isn't that strange for a big complex game that isn't written in BASIC itself, but it's a little surprising that it would need to push itself out that far. What's really wacky though is that it's storing important game data at 0xD0C4. That's usually the middle of the graphics chip, with 0xD0C4 through 0xD0C7 being the X and Y coordinates of sprites 2 and 3. (It's also not usually how you'd access them, but by default on a C64 that's what you'd be reading and writing.) That means that the I/O chips and even the BIOS has been traded away for Even More RAM. The C64 has a pretty sophisticated memory-mapping system inside of it, but what we're seeing here is that EOS has configured the system to grab every last byte of memory that it is even theoretically possible for it to access.
|
|
#
?
Aug 11, 2021 02:22
|
|
|
Decoy Badger posted:I'm starting to think that the explosion messages were meant to be in the game but were cut prior to release, because nothing references their addresses. Probably because of, well, you know. I'm embarrassed to admit it took me a moment to realize what 'you know' was, being focused more on the whole 'it'd be kind of a dick move to have that random of an event hit a player' angle of things. But yeah, I can see how certain disasters were taken off the board. ManxomeBromide posted:Assuming this is running on a C64, that's pretty wild.
|
|
#
?
Aug 11, 2021 04:30
|
|
|
FredMSloniker posted:Yeah, this is the C64 version (though there's an Apple ][ version, as I briefly mentioned, and the manual has a certain 'made on a Macintosh' quality to it). I don't think it can be trading away the VIC chip, though; wouldn't that mean the screen would be blank for the duration? It'd be weird for it to use the sprite position registers as miscellaneous storage, but the game doesn't actually use sprites, so you wouldn't have to switch the chip off to do so. So, I haven't actually tested this, but my understanding is that the VIC-II is pretty independent, and in particular it has its own, direct, access to memory with its own independent memory mapper. (This is why it can see the default character set even though you have to go out of your way to map that ROM into where the CPU can see it -- and when you map that in, that ends up replacing the CPU's access to the I/O chips, too. If you try to put a bitmap display at $0000-$1FFF, you'll get a lot of garbage because that memory is usually being used for something else, but you'll also see a perfect copy of the entire font right in the bottom half of it.) So swapping it out of the CPU's memory won't get in its way, and it doubly won't if it's not using sprites -- all the other graphical information will be handled by writing to the (shared) main memory. The part that's exciting is that in addition to switching out the I/O chips, if you switch out BASIC and the I/O chips, you also end up switching out the system BIOS*, so either it's got its own direct keyboard reading routines or it's bankswitching chips in and out of accessibility as needed. Changing the memory configuration is like four bytes worth of instructions (a write to 0x01) so it could easily just be doing this as-needed. * BIOS was specifically an IBM thing back then; the Commodore 8-bits had a "KERNAL", but it's a BIOS.
|
|
#
?
Aug 11, 2021 04:54
|
|
|
Came for the crazy space station building Stayed for the C64 hyjinks discussion
|
|
#
?
Aug 11, 2021 05:09
|
|
|
When they* said that all anyone would need was 64k memory, they meant it. *I have no idea who "they" are. Truth be told, I had a C64 in the days of yore. All I really played on it, or at least the only game I could remember was Phantasy. That, and Archipelagos. And I used GEOS for the word processor on it. Goddamn am I old.
|
|
#
?
Aug 11, 2021 06:04
|
|
|
berryjon posted:Truth be told, I had a C64 in the days of yore. All I really played on it, or at least the only game I could remember was Phantasy. That, and Archipelagos. You talking about Phantasie and Archipelago? Or did you mean Rainbow Islands, which came up a lot when I searched for 'archipelagos C64' for some reason? And I've got you beat for the olds, I think, because for a while my word processor was SpeedScript, out of Compute!'s Gazette. Never had GEOS, though. After my time. In other news, gently caress it, WE'RE DOING IT LIVE  In module news:
As I previously mentioned, we have several research goals in this scenario:
 First, though, we need money. The largesse of the Mars Rescue mission is over, and we start at 200 credits and a 50-credit loan. With this in mind, I start with a Shuttle Port module, because it looks like the best commerce bet currently, and a Solar Collector module, because I need power and Energy research both. The former is set at a 75.5 charge, and the latter is set at 18.7. Berryjon and Decoy Badger only have a couple of options at this point, but their importance is hard to overstate. As we've seen in prior missions, the effects of a mis-step on turn one can cost you the game...
|
|
#
?
Aug 12, 2021 01:09
|
|
|
Canadian Space Arm-and-Leg Agency - "Where you don't pay what we have to! Turn 1 - Spring 1996 The Director woke up from his nap to find the Nameless Intern weeping in the corner. "It can't be done!" he wailed. "It can't be done!" Unbothered by the breakdown of someone who couldn't handle the pressure, the Mighty And Courageous Director looked over the fax that came down from Ottawa. "Hrm," he said, "the development of a Lunar Colony, eh? I can see several things we'll need to do. Alas, it doesn't look like the Market is spiking in terms of a module type that will also work with the end goals. Now, jumping into the R&D sector right off the bat may sound like a good idea, but it can backfire pretty quickly if something goes wrong. No, we'll want finances first and foremost." "I would almost say start with the Construction Module. It's only gone down 4% this past quarter, and once our finances stabilize, they will be useful for R&D. On the other hand, looking at the Transport, they are always a solid financial return on investment. And we'll need a few in the future as well." "On the third hand, if I ignore double-dipping in the future, building Resource Platforms might work out. While the Agri market is crashing, the Resource and Forestry Markets are rising far in excess. The Return on Investment might not be high on the first couple quarters, but I can see good things in the future." "But is it worth it now? Take the safe bet, or go for broke? Going for Transport should get me 95 Credits back total, barely enough to start doubling. However, if I go for the Resource Market... Let's see, 40 Base. Assume 1/3 split, but history shows that there is a slight favor for higher markets... 46 income? That can't be right. I must have done my math wrong. Regardless, that will allow me to purchase two more Modules next quarter, allowing me a 50% increase in income if the markets stay still. But they won't. Yes, this sounds like a good start. Money now, second Station can go for research."  Resource: Charge 12 200 Credits in the Bank. 50 For Loan. Command Module, Logistics Module (40 Credits) Life B Module (18/+8/+0/-10) Solar Collector (60/0/0/+100) Galley and Gym (25/0/+24)/-10) Long Connector *2 (16 Credits) 4 Resource Modules (84/-4/-4/-40) 7 Credits Remain.
|
|
#
?
Aug 12, 2021 03:03
|
|
|
berryjon posted:When they* said that all anyone would need was 64k memory, they meant it. I mean, you're not the only one. THough we inherited a significant number of games with ours. From Elite to Bards Tale 3 to a whole buncha arcade games and whatnot
|
|
#
?
Aug 12, 2021 05:57
|
|
|
New modules code:Given that it's a lunar colony mission, the usage cap on everything needed for research has probably been bumped up a lot. Everything else is probably still pretty low though, so don't spam too many resource platforms! Also, I think you could totally build and run a station with no galley & gym if it's composed entirely of solar collector modules. Charges: Pharmaceutics: 32 Resource platform: 15 Solar collector: 19.5 Eloi Wusk: "You might think I want to launch another road vehicle to the moon, but it is in fact dog money that will get there first."
|
|
#
?
Aug 13, 2021 03:47
|
|
|
Decoy Badger posted:Given that it's a lunar colony mission, the usage cap on everything needed for research has probably been bumped up a lot. Everything else is probably still pretty low though, so don't spam too many resource platforms! The plan is hit 7/8, then diversify into other modules. If we do hit the Commerce Cap somewhere, I would suggest we run a 1 turn experiment were one person spends the minimum credits on Advertising to see how that affects things.
|
|
#
?
Aug 13, 2021 03:55
|
|
|
 I've been meaning to ask: why are the images in your station builder tool slightly stretched horizontally? Decoy Badger posted:Gotta get that money. I'm surprised Fred went so research-focused. My thinking is this: I'm going to need to build so many research-related modules that I can't afford to build modules just to generate commerce. That said, and as I said before, the Shuttle Port module is my top pick for income generation right now, and while I could use Station Power modules to meet its needs, I'm going to need Solar Collector modules anyway, so. Decoy Badger posted:Also, I think you could totally build and run a station with no galley & gym if it's composed entirely of solar collector modules. You wouldn't need Life-providing modules either, I believe; the Command and Logistics modules provide their own needs. I haven't double-checked this in-game, but I have no reason to believe it wouldn't work.  Berryjon, unless I missed it, you forgot to specify a charge for the Solar Collector module. Once I have that, I can process the turn.
|
|
#
?
Aug 13, 2021 17:22
|
|
|
Sorry! Ah... 17, please.
|
|
#
?
Aug 13, 2021 23:22
|
|
|
Berryjon is going for 17 on the Solar Collector module, I'm aiming at 18.7, and Decoy Badger is going to 19.5. Kind of a Price is Right situation going on here; let's see who went over. But first, module news:
 Fortunately, my investments were in Transport and Energy, which did pretty much what I expected them to. In fact, it looks like I could have gotten away with charging more.  Berryjon decided to start with Resource Platform modules instead of Shuttle Port modules. I'm not sure why; hopefully it wasn't because he confused them with Building Platform modules, which are what's needed for the Dry Dock cargo module research. If it was because of the high demand in the Resources market, though, he may have miscalculated; despite getting 100% module usage, he's still in last place for cash available. He either misbuilt or undercharged, and I'm leaning towards the former; Resource Platform modules are terrible commerce options, tied for the lowest base charge in the game with the Weather Center and Forestry Lab modules. Even the soaring Resources market didn't soar enough.  In a very close second place money-wise is Decoy Badger, who decided to focus on cash money even though it meant building Pharmaceutic Lab modules. That may pay off for him if the Pharmaceutics market continues to rise or the Transport market suddenly tanks, and the Medical market abruptly stopping its descent may be good news too. Unfortunately, he got greedy. With only 90% usage on the Solar Collector module, 85% usage on the Resource Platform module, and 86% usage on the Pharmaceutic Lab modules, he couldn't keep me from pipping the post. Some of that is on us for undercutting his prices on the Solar Collector and Resource Platform modules, but the Pharmaceutic Lab module goof is all his. (I would have charged 25.4. I don't know where he got 32 from.) I'm going to keep my strategy to myself for now, mainly because I'm still developing it. Let's see what you come up with!
|
|
#
?
Aug 14, 2021 02:36
|
|
|
Canadian Space Arm-and-Leg Agency - "Where you don't pay what we have to! Turn 2 - Summer 1996 "A slow start, yes. But that was to be expected," the Director said. "But that was to be expected. The Resource Platforms are a means, not an ends. I expected to be able to add two Modules this quarter, and that's what I can do. With a little bit of preemptive expansion to boot." "Also, I need to double check my math before I make submissions. That one's on me."  Solar Collector: Charge 18.7 Resource Platforms: Charge 13 48.4 Credits on hand. 2.7 For Loan. 2 Resource Platforms (42 Credits) 1 Long Connector (8 Credits) Note to Fred: I'm predicting less than 100% usage on my Resource Modules. To whit, I'm expecting 97% this turn. Let's see if I'm right.
|
|
#
?
Aug 14, 2021 06:33
|
|
|
FredMSloniker posted:I've been meaning to ask: why are the images in your station builder tool slightly stretched horizontally? I assumed it was a square grid, which apparently isn't quite correct. I also didn't realize that the module images all had a black outline that doesn't appear in game, and that distorts things a bit. In theory a simple fix, in practice I'm happy enough with the tool to leave everything alone. New modules  Remaining cash goes towards the loan. code:3x pharmaceutics: 32 (last turn: 32) 1x solar collector: 19 (last turn: 19.5) 1x resource platform: 15 (last turn: 15) If I had charged what Fred would have or what berryjon did, I would have made less money even with 100% use! It's always better to overcharge rather than undercharge when price uncertainty is involved here, and I'm using an exceptionally naive market pricing model (i.e. guess-and-check). Eloi Wusk: "It is important to make the module affordable. Like the thing that bugs me the most about where we are right now is that our modules are not affordable enough. We need to fix that."
|
|
#
?
Aug 14, 2021 18:22
|
|
|
I'm working on an update, but I've run into a division by zero issue. I'll let you know when it's sorted out.
|
|
#
?
Aug 14, 2021 18:37
|
|
|
Decoy, did you use your inputs to do something weird to the game after breaking open its code? 
|
|
#
?
Aug 14, 2021 18:49
|
|
|
Going into this turn, I have a narrow lead over Decoy Badger both in terms of cash on hand and research potential. I don't want a narrow lead; I want a huge lead. So it's time once again to re-examine my assumptions, starting with this:Decoy Badger posted:If I had charged what Fred would have or what berryjon did, I would have made less money even with 100% use! It's always better to overcharge rather than undercharge when price uncertainty is involved here, and I'm using an exceptionally naive market pricing model (i.e. guess-and-check). I've been assuming that I want to charge whatever gets me 100% usage, but apparently that's wrong. Fortunately, I have the tools to test that assumption. The gross income of a module is the charge I set times the usage percentage. Unfortunately, I don't have a good model for how the usage percentage changes if you over- or under-charge, but I do have some data from a run where I was deliberately overcharging by 10%. If I take all of the data points where my usage was less than 100% and graph chargedelta (what I charged on a turn divided by what I should have charged given the demand for that turn) against myusage (the usage I got on that turn), I get:  The linear regression function is y = -118.4 * x + 215.4, with an R2 of about 0.27. That's not a very good number (the closer it is to 1, the better the fit), but it's what I have. There is one issue, though, which is that when x == 1, y = 97; it should be 100. If I force an intercept at that point, I get the equation y = -142.9 * x + 242.9. I'm not sure if using this formula is a better approach than just increasing the constant in the previous formula; someone with more knowledge of statistics will have to fill me in. For now, I'll use the first formula and adjust the constant to 218.4. So now I have several formulas: income = charge * usage usage = -118.4 * chargedelta + 218.4 chargedelta = charge / fullusagecharge fullusagecharge = demand / 200 * basecharge Combining them, I get: income = charge * (-118.4 * charge / demand * 200 / basecharge + 218.4) So how do I find where income is at its peak? Well, for that I use a derivative. The derivative of a function gives us the function's slope, and at maximum income, that slope will be 0 (i.e., the curve will be straight horizontal at its peak). demand and basecharge are both constants, so the derivative of income with respect to charge is: slope = 1092 / 5 - (47360 * charge) / (basecharge * demand) And that is 0 at: charge = 1092 / 236800 * basecharge * demand At this point, however, I plug in some sample variables and discover something odd, which brings me back to this formula. Since: chargedelta = charge / fullusagecharge fullusagecharge = demand / 200 * basecharge We have: chargedelta = (1092 / 236800 * basecharge * demand) / (demand / 200 * basecharge) Which simplifies to: chargedelta = 218400 / 236800 In other words, this model always suggests we charge about 92% of the 100% usage charge. Why? Because the formulas don't take into account that usage is capped at 100%. If it wasn't, by charging 92% of the 100% usage charge, we'd get 109.2% usage, and (92 * 109.2 = ) 10046 > (100 * 100 = ) 10000. What if I use the fit function I got by forcing an intercept? Well, when I go through all the math, I come up with a model that suggests charging 85% of the 100% usage charge. So. According to the data I have, it's always best to charge that 100% usage charge. I'm not sure what data Decoy Badger is using that gives him different results. I suppose we'll see who's right!
|
|
#
?
Aug 14, 2021 21:39
|
|
|
Good luck fighting the C64 gremlins! EOS stores important variables all over the zeropage RAM, ignoring everything the Kernal wants to do with it. Like storing integers in the cassette motor flag. Or storing integers in the string linked list header. Because gently caress you Commodore, you're not my real dad. No wonder you run into these issues. My statement is pretty easy to verify: If I charge 25.4*100% usage I get 25.4. I charged 32*86% and got 27.5. From my crude model at the top of page, which probably changes from scenario to scenario and market by market: Usage = (-1.44 (relative charge) + 2.44)*100 (ceiling of 100) So if you charge 80% you get 129%->100% usage, which is 100%*80% = 80% income. If you charge 120% you get 71% usage, which is 120% * 71% = 85% income. So under my assumptions, it's better to be wrong on the high side than on the low side. If you know the exact formula money is maximized at 100% usage = 100% income. But since I don't, I have to guess, and you lose less by guessing high. Presumably one could also find this out from the game data, but I focused on the dry dock mission since I'm pretty I would've spoiled myself horribly!
|
|
#
?
Aug 14, 2021 22:05
|
|
|
Decoy Badger posted:Good luck fighting the C64 gremlins! EOS stores important variables all over the zeropage RAM, ignoring everything the Kernal wants to do with it. Like storing integers in the cassette motor flag. Or storing integers in the string linked list header. Because gently caress you Commodore, you're not my real dad. No wonder you run into these issues. The Apple ][ and the Commodore 64 share a processor, the 6502, which makes it easy to write programs that run on both of them - provided, of course, you completely redo all the stuff that talks to the outside world. I'm not surprised the game's running roughshod on the memory, given that it's probably mapped completely differently on the Apple ][. Decoy Badger posted:My statement is pretty easy to verify: If I charge 25.4*100% usage I get 25.4. I charged 32*86% and got 27.5. Which I thought of approximately five seconds after making that post.  I'm going to poke at my assumptions some more and see what falls out. I'm also going to be doing things other than updating this LP, so don't expect another update today.
|
|
#
?
Aug 14, 2021 23:53
|
|
|
|
| # ? May 2, 2024 08:35 |
|
|
So last update I posted a complicated mathematical analysis that said I should always charge whatever charge would get me 100% module usage. And Decoy Badger offered a single data point that disproved this. This is why I keep testing my assumptions. Maybe I'm going about this the wrong way. My data (a) comes from a variety of modules, which is adding complicating variables; (b) has constrained inputs, as I kept aiming for 10% overcharge instead of experimenting more wildly; and (c) is fairly small, with only 14 data points for each module. I can fix the first point by collecting data on a single module at a time. As for points two and three, I can fix them by gathering more data.  A lot more data. First, I make a save state for each commerce setting of the Shuttle Port module from 74.0 to 74.9. There are several different ways this commerce setting can be stored internally, but I believe that, no matter what the format is, some value in the save state will either go up by one or reset to zero with each increase in the commerce setting. Doing a byte-by-byte comparison of the ten save states gives me two file locations that behave as expected. An eleventh state, where the commerce setting of the Shuttle Port module is still 74.0 but I am on a different screen, eliminates one of those possibilities. So now I know where the lowest significant byte of that setting is stored: byte 62141. Two important caveats here. One, that's the 62141st byte of the file, not the 62142nd; I'm working with Lua, which indexes starting at one, and it's convenient just to roll with that. Two, that doesn't mean the value is stored at or near memory location 62141; the VSF file format has a header and stores information in various modules. The important thing, though, is that knowing where in the file the information is stored, I can create new VSF files with whatever data I want. But I only have the lowest significant byte's location. To get more, I need to look around that location. Putting the emulator into warp speed and holding down the G key for a while tells me that the maximum commerce setting for a module is more than 100,000, which is a stupidly high limit; three bytes could store a commerce value from 0.0 to 1677721.5. Let's look at the seven bytes surrounding the byte we've identified, both at commerce setting 74.0 and at 100383.0 (when I gave up on holding G): 74.0.vsf 000 000 002 228 000 000 000 100383.0.vsf 000 015 081 054 000 000 000 From this, I can tell that the program stores the commerce value with the most significant byte first. 2 * 256 + 228 = 740; (15 * 256 + 81) * 256 + 54 = 1003830. Since a commerce setting over 6553.5 would be nonsensical, I only really have to worry about two bytes, and I can easily crank out a program to generate a lot of save states with different Shuttle Port module charges. The current demand for Transport in the game I made to test all this is 188.3. Based on my simple financial model, I should therefore charge 65.6 for the module, anticipating a demand of 177.3. I'm going to test between 50% and 200% of that charge, so I generate a ton of VSF files, using the second 74.0 VSF as a template. (Since it's not displaying the Shuttle Port module charge, I don't have to worry about weird interactions between the displayed value and the actual value). I'm not planning to look at all 985 of those, but I have the option. I load up the savestate I created for 65.6, switch to the Shuttle Port module's commerce settings, and...  ...hm. I seem to have done something wrong somewhere. 3686.6 would be stored internally as 144 followed by 2. 65.6 would be stored internally as 2 followed by 144. This is what we call messing up endianness. A quick correction to my VSF generating program, and...  That's more like it. So where do I go from here? Well, I advance the turn, that's where. As it turns out, that doesn't write to the save disk, so I can keep reloading different save states and advancing the turn without issue. My first data point is 100% usage at a charge of 65.6 with a market demand of 177.3, which is exactly what I predicted. At a charge of 131.2, the highest charge I generated, I get 0% usage. At this point, I start testing data points halfway between tested data points to establish when, exactly, the usage changes. I discover something interesting along the way, though; although the first several data points have the same market demand as the first, they don't all do. In fact, I can get different market demands by reloading a save state, which means the RNG gets perturbed by what I do between loading the save state and generating the new turn. I suspected this could happen, and it's a good thing, because it means I can get even more data from the data set. 177.3 seems to be the most common result, though, which makes sense if the market behaves the way I'm modeling it; any variations are to it randomly deciding to bump the market. (I also keep getting new news items, which means that the RNG is sensitive enough that me taking a fraction of a second longer to choose a menu item is enough to perturb it.) A mere baker's dozen of data points with 177.3 as the market demand gives me:  Omitting the first and last data points, which are at the upper and lower bounds of usage, gives me the formula u = -2.298h + 250.740, with an R2 of 0.9999. That is a happy little data set. So what should I charge to get the maximum income in this particular case? Well, i = h * u Substitute my formula for u in, and I get: i = h * (-2.298 * h + 250.740) i = -2.298 * h ^ 2 + 250.740 * h I'm looking for a maximum again, so I take the slope of i with respect to h: di/dh = -4.596 * h + 250.740 And when that equals 0, h equals 54.6... which is less than 65.6. I'm running into the usage > 100 problem again. However, that only means that, in these exact circumstances, for a Shuttle Port module with Transport demand of 177.3, 65.6 is the right amount to charge. I need to generalize again. And now that I know how the Shuttle Port module's charge is stored, it'll be much easier to find the stored charges for the other activity modules. But not right now. Right now, I need to take a break from this update, then work out my next move and get a new turn out. See you then! FredMSloniker fucked around with this message at 20:09 on Aug 18, 2021 |
|
#
?
Aug 18, 2021 20:07
|
|