I am an accountant working full-time (and some). I'm not here as often as I would like to be. Send a message if you need me. There are a few people in the community who can get in contact with me urgently if you need - don't be afraid to ask. I just don't check here as frequently as I used to. Sorry!

To be honest, who cares about the development anymore? I question why this thread still exists if all it does is bring nonsensical and completely useless information to the table. Just drop it. Every single person here on this forum knows deep inside that YS has been broken since 2012 in some ways. I could care less if 2014 was at least some type of stable or not. Soji's obviously not caring anymore so just give up and use your time on something else. It's what I've said for the past three years. Use crap that's fixed, not "reportedly bugged and needs improvement"/fixing stuff that had no issue in the first place.

Wake up people jc

---EDIT---

Being the realist that I am, the more I look back at this post and the ones before mine, the more I question why we're still here. Why do we continue to play a game where recruitment and word that gets around, compared to other sims, is at a completely bare minimum each and every day that passes by? Seriously? I understand this used to be a great, free game, but to be honest it's so far from great the way it's been headed. Continuing to use one version of the game will very soon become old. We've gone nowhere as to the amount of actual HQ users in more than a few months. Posting rates at this point have been the slowest they've been for probably longer. The game has obviously already taken a turn for the worst and all of the wishing and believing that a better version will be released will never happen. Pay attention to the pattern he runs on, and also think that this is a pet project of his. That's all that this game is in the end. He's not some dedicated dev that sits idly by waiting for people's requests. The game will never get better from this point on and that's that.

I've been an ardent supporter of his but have to agree with the above comments. New features are meaningless if the basics don't work. And judging by his own comments he's not really out to fix the basics.

I will stick to using the 2011 version of YS Flight. I love the game and I don't want to stop playing the working version of it. When it comes to YS, if it ain't broke, don't upgrade it.

Hi! I make average, undesirable, boring grey maps for YS Flight!

Check out my YSFS videos on my Youtube channel!
-----------------------
Avatar: Pratt and Whitney JT8D-219
-----------------------
My two cents:
Most over-used phrase of 2020: "New normal". Can we stop with that already? Pandemics do not last forever, and things will eventually go back to normal, just like they always were. You're welcome!

I've been learning Vulkan API for the last a few weeks. I feel that I have enough knowledge to port YSFLIGHT to Vulkan. When the doomsday comes, when OpenGL is no longer cross platform, I should be able to switch to Vulkan.

That's only if Vulkan gains popularity as advertised. I have a serious doubt if it will be well adapted though. The reason why I am worried about the Vulkan adaption is because it is not taking over OpenGL. It is trying to take over extreme low-level APIs like Direct 3D and Metal. I don't think Microsoft and Apple are happy with Vulkan. Apple is openly unhappy with Vulkan. It also takes over OpenCL, which gives nVidia a reason not to be supportive. If Vulkan takes down OpenCL, and the Vulkan itself fails, nVidia will dominate the GPU processing by CUDA. Those big companies, except Apple, are saying they support Vulkan, but they may just be pretending.

Already I see signs that Vulkan is buckling. Since Apple totally ignored Vulkan, they arranged a deal to get MoltenVK, Vulkan implementation on Metal for Apple platforms, open-sourced. But, it is only a subset of Vulkan. It lacks the Validation layer. Vulkan has too many knobs to control. You cannot tell if you are feeding correct parameters.. The Validation layer will tell you when given parameters are outside of the Vulkan specification. It is virtually impossible to develop without the Validation layer. You may get something working in your environment without the Validation layer, but your program may not work when you take it to another platform.

So what I have been doing is writing code on my Mac mini home, and the next day I test the same code on Windows on my office PC to see a bunch of error messages from Validation layer then only I can correct them. Why can't I debug at home? Because of Intel's reluctance in Vulkan, none of my ThinkPads running Windows 10 can run Vulkan. My ThinkPad X250 is just 3 years old, but it is too old to run Vulkan. In a sense, Vulkan doesn't run on too many integrated GPUs and is nothing cross-platform yet. Since Vulkan runs on those older integrated GPUs on Linux, there is no reason it cannot be done on Windows. I don't know what Intel is holding off.

The shader program of Metal seems to be less capable than SPIR-V. The output from the vertex shader ( varying in the OpenGL term) cannot be an array or a matrix. (Come on, Apple!) That is supposed to be a Metal problem, not a Vulkan problem, but MoltenVK inherits the problem since it is implemented on Metal.

Therefore, the shader that runs perfectly on Windows may not run on macOS and iOS. Because of this hiccup (plus more hiccups), Khronos is now talking about official Vulkan 'subset'. Aaaagh! What's the point of the standard?

By the way I think GLSL to SPIR-V compiler that comes with the LunarG package has a bug. If I write:

Everything after lightEnable[0] were zero in my shader. Only lightEnabled[0] receives a correct value from my C++ program. I checked every single line in my code, counted bytes to make sure 16-byte alignment, and could not figure why my shader didn't receive any value after lightEnabled[0]. In a desperate attempt, I changed float[4] to vec4, and everything worked. I found no explanation why vec4 worked and float[4] didn't. I hope it is a bug, not a mysterious specification that nobody understands.

Speaking of uniform, to set a uniform value in Vulkan, you need to first copy values to a uniform buffer, which is supposed to be already in the GPU memory, and then uniform buffer "written" to the VkDescriptorSet, which then can finally be bound to a binding point of a VkDescriptorSetLayout and become visible to the shader program (or pipeline in Vulkan term).

My question: Isn't VkDescriptorSet unnecessary?

Although I "write" the content of a uniform buffer to a VkDescriptorSet, a VkDescriptorSet looks to be just a pointer to a uniform buffer or a sampler. I don't see any point to make VkDescriptorSet an allocated resource. It should be possible to bind a uniform buffer or a sampler directly to a VkDescriptorSetLayout.

In the current version of Vulkan, you need two resources, a uniform buffer and a VkDescriptorSet to bind a uniform. (If you count a uniform buffer and a uniform buffer memory separately, three resources.) Since VkDescriptorSet is no more than a pointer, it should be small enough to be carried in a command buffer. Allocation of VkDescriptorSet is a utter waste. I hope the next version of Vulkan includes a function that directly binds a uniform buffer or a sampler to a binding point of a VkDescriptorSetLayout. For the time being, I allocate a uniform buffer and a VkDescriptorSet always as a pair, and my code looks to be working fine.

Anyway, I am hoping one of the two things to happen: (1) Vulkan gains momentum as promised, or (2) someone writes an OpenGL implementation on Metal (actually there is a commercial library called MoltenGL, but I cannot afford.) If Vulkan gets popular, I'm fine. I can continue coding cross-platform with Vulkan. I have already seen some problems, but it also is free from some OpenGL's problems. First of all, I appreciate its type safety. Every object in OpenGL was an unsigned integer. A compiler didn't catch if I was giving a texture name as a vertex-buffer name. It would take several months to a year to port my OpenGL code to Vulkan if I need to, but doable. Or, if OpenGL continues to be available on Apple platforms, it maintains its value and stay alive for longer period.

My worst fear is that Vulkan fails, OpenGL fades, and no cross-platform graphics API. I might look into Unity or Unreal engine, but those are basically for commercial development. I admire Unity's effort to keep backward compatibility, but still there is a license clause saying I need to pay some fraction of earning when the product is commercialized. Some of my research code have been used not as a consumer products, but as a part of the deliverables for industry-sponsored projects. Of course it is a part of an academic research project, but it is somewhat gray area that I don't want to step into. If I code for an industry-sponsored project using Unity or Unreal, I need to talk to an attorney who is specialized in the intellectual property laws to make sure there is no problem, and I don't have money to do so.

I expect Khronos would say something during SIGGRAPH 2018, which will be next month. I keep eye on what they say.

P.S.: As for me, firstly need separate code of simulator kernel from code of GUI client. Then fix simulator kernel (keep it closed source, but with open API) & open sources of old OpenGL GUI client (for community), and only after this think twice about switching to other toolkit, IMHO... :-/

I see where he's coming from - a float of 4 bytes * 4 should be a byte array of 16.

But what the hell does this have to do with maintainability of YSFlight? Sounds more like a new coding hobby project.

"We need YSFlight to be able to use modern api's" No, we don't.

Age of Empires II still works fine on my PC for a 90's game, we can make YSF work too.

It's funny, whenever I see this thread bumped I think to myself "Oh great, this'll be fun".

Oh Soji...

I am an accountant working full-time (and some). I'm not here as often as I would like to be. Send a message if you need me. There are a few people in the community who can get in contact with me urgently if you need - don't be afraid to ask. I just don't check here as frequently as I used to. Sorry!

I don't know if it is useful for someone, but I have uploaded a set of test scripts. It is significant for me because more than half of pre-release test items are covered by this batch. (Such as selecting random menu items or changing configurations and make sure the program does not crash) Also I have automated installing the add-on packages to a test-environment and flip through airplanes and maps. Actually that was fun. I was impressed by the variety and the quality of the models. I used to be randomly selecting a few packages before. This revealed many mistakes in my code, which should be fixed shortly.

By the way, install_addon.py is free on BSD license. Please feel free to customize and bundle with your add-on packages. This might be useful.

One of my students emailed me saying OpenGL stopped functioning when he updated his macOS to 10.14 Mojave. I was caught by surprise because Apple was stating that OpenGL still functions although it is labeled deprecated. Did Apple break promise again? Is it something I was worried about? I also updated my mac mini and confirmed the problem.

It's already almost one month into the semester. I didn't want to tell all my mac-user students to hold off the OS update or use Linux or Windows at this point. After several hours of investigation, I found that all OpenGL drawing outside of drawRect method of NSOpenGLView are ignored in macOS 10.14. (As far as I tested, all OpenGL function calls outside drawRect and prepareOpenGL look to be ignored.)

For example, your program may be calculating one step of the motion and re-drawing at the end of the same function which is outside of drawRect, then your program may stop functioning in 10.14. Or if you are initializing OpenGL states outside of prepareOpenGL, the state may not be initialized at all. The same limitation used to apply only when NSOpenGLView had a sub-view. But, apparently macOS 10.14 applies this limitation regardless of the presence of a sub-view. I am glad at least I knew about the limitation of NSOpenGLWindow with a sub-view. If I didn't know about it, I could have been in the dark now.

I am teaching an introductory programming. I wanted to avoid dealing with call-back functions, but it looks to be unavoidable. I'll explain in class tomorrow.

I hope Apple to support OpenGL longer, but nobody except Apple employees knows how long OpenGL runs on macOS. How can I teach introductory graphics programming with Metal? Metal is useless unless a student is looking to apply for a position in Apple. If I cover up some hard-to-understand part of Vulkan, I think it is possible to go with Vulkan, but Vulkan has its own problem. Vulkan is still not cross-platform yet. I have three computers home, and Vulkan doesn't work on two of them. It is somewhat understandable it doesn't work on 5-year old ThinkPadX230T, but Vulkan doesn't run on my 2.5-year old ThinkPad X250, either. 3-year old computers are still everywhere. If Vulkan doesn't support 3-year old Intel GPUs, it is not yet eligible to be called a cross-platform. Are they going to ignore 3-year old Intel GPUs? Khronos may say it's Intel's problem, not Vulkan's problem. From the user's and developer's point of view, Vulkan is not running on too many computers no matter whose problem it is. I doubt about the seriousness of the people who are working on Vulkan. Vulkan has a good chance of failing. In fact, it is not taking over OpenGL. It may already be failing. Vulkan gave an excuse to Apple for dropping OpenGL. Other operating systems may follow. Then Vulkan itself may disappear. There is a high probability of programmers' dystopia where no cross-platform graphics API exists.

2018/09/28Vulkan the future or failure?

The undocumented changes in OpenGL-handling of macOS 10.14 created some extra work for me. I need to modify sample codes for my teaching. Each change is small, but I have many source files. I also need to update explanation on my course notes.

There is no explanation of the changes. If the program is not calling OpenGL functions outside prepareOpenGL and drawRect, it should work fine. Otherwise, the program won't work on macOS 10.14. I can imagine programs registering textures in arbitrary locations. The current official version and the test version of YSFLIGHT does not run on macOS 10.14,either. The new stable version will be out soon, which runs ok on macOS 10.14. I have already fixed my code. YSFLIGHT is running fine on macOS 10.14 running on my mac mini. I originally was planning to push it out by the end of the summer break but couldn't finish pre-release tests in time, and pre-release test is now slowly moving forward. But, it worked out well for macOS 10.14.

But, the removal of OpenGL from macOS is becoming more realistic. To prepare for the transition to Vulkan, I was reviewing my Vulkan test codes that I wrote in July. OK. I was able to do shadow mapping. That refreshed what I studied. I think I can use Vulkan if I choose to.

Yes, I am confident in coding with Vulkan. But, probably only few developers can understand and use this API. Vulkan is an EXTREMELY difficult API. Exponentially more difficult compared to OpenGL. Years ago, we had tough time transition from OpenGL 1.1 regime to OpenGL ES 2.0 regime because ES 2.0 made GLSL mandatory. But, the difficulty of Vulkan is way too much more than that. It requires unreasonably low-level programming and micro-management of GPU. OpenGL somewhat provided the rendering model, but Vulkan gives nothing. Vulkan dumps all the responsibility on the application programmer. Probably less than 1% of the programmers who can write OpenGL ES 2.0 code can develop on Vulkan.

After Vulkan is out, there are so much developers who are worried about the future of OpenGL. Vulkan started as the next-generation OpenGL. It is very much understandable. No matter how loud Khronos shouts that they maintain OpenGL, it is too late to extinguish those anxiety.

I had once used an API called IRIS Performer. I think it was in 1994. IRIS Performer was developed by Silicon Graphics who was the leader in the 3D graphics industry that time. My then advisor wanted to see if IRIS Performer was useful. IRIS Performer was made public when the computer-graphics community came up with an idea of Scenegraph. The idea was that the graphics API can optimize rendering operation if the entire scene structure, rather than a soup of lines and triangles, is registered to the API. But, in IRIS Performer, the registration was difficult like hell. Sure, if I transfer that much rich information to the API, it should be able to fully optimize the rendering operation. But, it was too difficult and impractical. That was our conclusion. Other people soon stopped talking about it, and IRIS Performer was forgotten. Silicon Graphics was wonder-straying off course in developing a scene-graph API, and they then released a new API called Cosmo 3D, which quickly disappeared by itself. Developers lost confidence on Silicon Graphics, and it lost the dominance.

I see so much of similarity between IRIS Performer and Vulkan. Sure, if I go down that low level, I may be able to fully tune the rendering pass for maximum performance. But, virtually nobody will be able to program Vulkan, except handful programmers. People saw IRIS Performer as the next-generation 3D graphics API at first. We thought 3D-graphics then-giant, Silicon Graphics, must have created a very good API. People gave up quickly because it was unreasonably complex and extremely difficult. Because nobody used, people stopped talking about it. It disappeared by itself. My very unscientific survey is indicating that more people are complaining about extreme difficulty of Vulkan than appreciating its performance. If only few people uses it, it would disappear. Just as Silicon Graphics lost trust from developers, people will lose confidence on Khronos. Didn't Khronos learn from the failure of IRIS Performer? .... Maybe young people haven't even heard about IRIS Performer.

As if Khronos totally lost their mind, they started Vulkan Portability Initiative. For many of us, the problem is how we can transition to Vulkan. It is virtually impossible to transition our current code base using OpenGL to Vulkan. It helps nothing about our problem. This portability initiative, for an unknown reason, is done in a programming language called Rust. I've only heard about it. Just skimming the code, I got an impression that it was another lesser copy of C++. New programming languages are irresponsibly created and thrown away. That's a serious problem of computing today. Looks like this portability initiative is not going anywhere. It has been stopping since last year.

The situation, almost 100% re-enactment of IRIS Performer, makes me hesitate to transit my code base to Vulkan. It happened before. I spent quite good amount of time to learn DirectX9, and partially added support in my projects including YSFLIGHT. Then Microsoft dropped the backward compatibility in DirectX10. Learning DirectX9 was made utter waste. I felt so dumb. I'm glad I didn't waste time to learn DirectX10 because Microsoft cut the backward compatibility again in DirectX11. I'm done with DirectX. I don't want to repeat the mistake again. Because at this time I see very good probability of Vulkan to disappear, I cannot invest more time for Vulkan. Well, another reason is it still doesn't run on my ThinkPad X250 and X230T. Is Vulkan cross-platform? No. It's a fake news! There still are very large quantity of Windows PCs that are running on 4th- and 5th-generation Core processors and built-in GPU. Vulkan is failing to reach out to those population.

In my view, there is only one way out for Khronos from the failed attempt of Vulkan. Implement OpenGL on top of Vulkan, release it as a reference code, and maintain it. OpenGL is not that unreasonably crazy low-level as Vulkan. It makes sense to implement OpenGL on top of lower-level API, and it should be very much doable. Of course, the performance will be sacrificed because the GPU and application gets somewhat farther apart by the OpenGL layer.. But, what I am looking for is maintainability and reasonably easy coding. OpenGL, especially 1.1, is so good for quick prototyping. Vulkan is not. OpenGL 1.1 is so nice to get students started. How can I teach Vulkan to my students? It is impossible. I think implementing OpenGL layer on top of Vulkan is the only way for Khronos to re-gain confidence from developers. No matter how much Khronos insists that they continue OpenGL, we won't trust unless they actually act.

2018/09/29macOS 10.14

Looks like I was stepping on another landmine of macOS 10.14, which destroys cached NSMutableDictionary somewhere. I could look into it deeper to pin-point exactly where it is destroyed, but I don't want to waste no more time. My font-renderer was using a cached NSMutableDistionary, but I changed so that my font-rendering function allocates and releases a NSMutableDictionary every time it is called. It is inefficient, but didn't make any visible loss of performance, and works on macOS 10.14.

But, the error was caught during unit tests. I am glad I spent time to set it up.

.... How can I tell if I addressed all undocumented changes in macOS!? I did run my unit tests, but I cannot think my tests cover everything.

Actually, my iPhone 5S no longer charges from PC USB port after upgrading to iOS 12. I need to use a larger-output (like 2.4A) USB charger. I don't think I had a good luck with OS upgrades from Apple this time.

YSFLIGHT

Actually, the fix for macOS 10.14 actually influenced the other part of the code bigger than initially expected. YSFLIGHT is running on macOS 10.14 somewhat ok, but it broke Windows and Linux versions. I think I fixed mostly, and a few more steps to go. But, I'll make another test version before running the pre-release test all over again. I'm going to upload a new test version soon. I wish the new version of macOS hadn't happened.

2018/09/30My First Logbook Completed!

I have been fixing YSFLIGHT code cursing macOS 10.14. But, today I took a nice break from a frustrating task and flew from Beaver County, completing my first flight logbook! (Read more)

When I saw the blog-hosting services, I didn't like it because of inability to keep a local back up. Some seemed to be offering a capability of taking a local back up copies, but then what about restoration? What if they terminate the service? Is it easy to transfer my blog to a different service? Looked to be hell difficult. I didn't buy them. I am stubbornly using an old-school web site.

When I saw Social Network Services like Facebook, MySpace, and Mixi, I wondered why people do what they can do with a personal web site with less control. I also am bothered by the inability to take a local back up and restoration. The contents of my web site is mine. I sacrificed money, time, youth, social life, and hair to learn programming. Why do I have to give away my contents and let them make money? I do have a FaceBook account. But, I'm using it just as an automatically-updating address book. I will never ever upload anything to FaceBook.

When I saw GitHub, I was frightened by every open-source projects concentrated in one web service. If I were an evil programmer, here's what I would do. I would hack into a source repository and then inject a malicious code into a source code of a very popular software title. Next time the build from that repo is released, the official copy of the title will distribute my code for me. Now everyone uploads code to GitHub, such a hacker knows exactly where to target.

What's common about above my concerns are the centralization. Everyone tries to lock you in to their service and make hard to leave. I was thinking I was only one person who is concerned about the centralization. Surrender of controls over contents, not just private information. The trend was not going to the right direction in my view. People talk about problems of those SNSes, but nobody seemed to be concerned about getting locked in to a specific network.

Apparently, someone else does have concern. A famous guy. I 100% agree with the philosophy of the Solid project.

https://solid.mit.edu/ (Hmmm, I cannot agree more to their philosophy, but they are hosting the sources in GitHub.)

Right now I have problem in how to make my open-source part of my code public. I haven't been able to release them in a timely fashion because I always get higher-priority tasks than making and testing a release package. I rather want to open read-access to my public repository to public. GitHub for sure will host my open-source projects, but I don't want to be a part of the centralization. I'm looking into the Solid project to see if it can solve my problem.

So, I created my POD, but I haven't been able to do anything useful yet. Maybe it does not work with Firefox.

Nowadays if you download a free program online, macOS or Windows refuses to run. You need to manually and explicitly allow a security exception to run the program. But in the process, you need to click Yes to a threatening warning message telling that allowing this exception would be the end of the world.

I seriously want to digitally sign YSFLIGHT and other binaries before releasing so that you don't have to click Yes to such a doomsday messages. However, I need a code-signing certificate to do so, and getting a certificate is hell expensive. $200 is about the average price for a code-signing certificate for Windows. I have been paying $99/year to Apple. I cannot pay $200 per year on top of it for Windows.

Unfortunately this code-signing is a part of the industry-wide attempt to exterminate free programs. While I understand that there should be a way to verify that the code is written and signed by a trustworthy person, $200 per year price tag for such a certificate just kills free software authors. I am getting small income from YSFLIGHT.COM ads and shareware sales, but overall I am paying more for maintaining it.

I really cannot afford $299 per year ($99 for Apple and $200 for Windows). But, I found an ad from COMODO Certificate Authority advertising $179 per year will cover macOS and Windows. Well, then I can stop paying Apple and get a certificate from COMODO. $179 per year is still a pain, but I can live with it. So, I created my account and paid $179.

To my dismay, COMODO then told me they don't issue a certificate to an individual business owner. To issue a certificate, I need a letter from an attorney, notary, or an accountant, which I cannot afford. I saw no explanation from COMODO that they don't issue a certificate to an individual business owner until I paid $179. For sure I don't see any cancel-order button from my account. I am requesting refund, but I am worried that they keep my account unverified and refuse refund.

I write code as a professional programmer, therefore I totally understand how important the security is. At the same time, as a free-software developer, I seriously believe that a programmer should be allowed to publish programs freely, and the programmer should be allowed to choose to publish as a binary or as open-source. It is very unfortunate and outrageous to me that the industry is so hostile to free-software developers.

I am not saying code-signing is bad. I am saying there should be an affordable code-signing certificate for individual developers.

Now my concern is to get my $179 back from COMODO. $179 is worth for 1.1 hour rental of Cessna. Worth 3 retro-games for my FM-7.

By the way, I decided not to pay $99 to Apple this time.

P.S.: Soji, just open source code of YSFlight, take 10-year old PC & install Linux on it — then no need any paid certificates!..

"Nowadays if you download a free program online, macOS or Windows refuses to run. You need to manually and explicitly allow a security exception to run the program. But in the process, you need to click Yes to a threatening warning message telling that allowing this exception would be the end of the world."

Soji, you do realize that the "threatening doomsday message" is simply asking for elevated privileges right?

"Unfortunately this code-signing is a part of the industry-wide attempt to exterminate free programs."

*puts my tinfoil hat on* COLLUSION!

"I write code as a professional programmer"

No, I highly doubt that. You have said it yourself that your code is so sloppy that you can't even fix your own problems. A PROFESSIONAL programmer is someone who keeps his/her code organized and efficient while also understanding what it does (with the help of google of course). But who am I to judge, i'm a normie on a lil forum.

TL;DR Soji if it's such a flipping inconvenience for you to work on YSFlight then just stop. Nobody cares anymore and I doubt you'd get any sympathy for your troubles anymore.

2018/11/12
...
I am very worried about the recent trend of programming. It is incrementally getting more and more difficult for an individual developer to publish a program. The whole industry is hostile to such individuals. If I want to publish a program, the developer feels a pressure to swear allegiance to a big guy.
...

P.S.: Soji, just open sources of YSFlight and... don't worry, be happy! FOSS software live longer than proprietary software. In FOSS software development you would be not alone, FOSS community is worldwide!

CMI Extended with the NCA A320 gets half the frame rate I get in the 2015 version, both using OGL2.

Did you try it in OGL1?

And are you sure this is actually "fine"?

Hi! I make average, undesirable, boring grey maps for YS Flight!

Check out my YSFS videos on my Youtube channel!
-----------------------
Avatar: Pratt and Whitney JT8D-219
-----------------------
My two cents:
Most over-used phrase of 2020: "New normal". Can we stop with that already? Pandemics do not last forever, and things will eventually go back to normal, just like they always were. You're welcome!

"Why are we still here? Just to suffer? Every night, I can feel my leg... and my arm... even my fingers. The body I've lost... the comrades I've lost... won't stop hurting... It's like they're all still there. You feel it, too, don't you? I'm gonna make them give back our past"