Over the Reich - Creation Thread

Well I have an issue. Over the past week or so my laptop has been turning off randomly and now it is turning off almost immediately and consistently. Luckily I have backed up every thing I needed to including the scenario but it'll be at least a week before I get this sorted. I'm weighing my options.

I spent a few hours today trying to fix this and don't think its heat so I'm not sure if it is the motherboard or what. I'll try calling a repair place tomorrow and see what they recommend.

If its unrepairable or uneconomical I'll have to consider other options which might take a bit longer. It's not something to jump into...

 

It turns out I was prevented from doing much work on the events after all. Since I'll probably be prevented for a few more days, I'm giving back the events. (Though, I see now you might not be in a position to make changes anyway.)

 

Yes it is annoying! I believe it is a hardware failure and am waiting on the recommendation. One way or another, I'll be operational within about two weeks.

 

I should be operational this weekend, but I dont think I need the events right away if you still have some stuff you want to work on.

 

I'm back in business

 

I have a few days off to go fishing with my son, who promptly came down with the flu, so now I'm sitting around here while he sleeps quite a bit. Let me know if you're making changes to the events or if they're still available. There's a couple small things I want to fix. Nothing urgent if you're in the middle of things, but I can find some time.

 

I haven't done anything to the events. You can use them. I hope your son recovers quickly.

 

I'm very sorry.

About the only thing we're not doing in this scenario is modelling supply lines and encirclements. If we were, your supply line module would do a perfectly good job out of the box as it is. It is true that I have a preference for modules where the details for the specific scenario are specified in the events.lua file rather than in the module itself, but that preference is relatively small, and, for all I know, others might actually find it easier to use modules the way you write them. However, to make the supply lines module do what I want (check if there is a path between a unit and a particular city), I need to be able to change the definition of "supply depot" every time the function is used. I may also want to be able to make it so that air units can't block the path, and probably make battle groups block the path from a few squares away, so I would probably need to make changes to that part of the code as well.

I wasn't meaning to criticize or demean your work, but I can see how it could be taken that way. Perhaps an analogy would make my thought process clearer: I need to sink a screw, but don't have a screw driver. However, I do have a sledge hammer, and you have a very nice pair of visegrips. Maybe I can weigh the screw down with the sledge hammer and turn it with the visegrips. It might work, but the result will not be elegant and maybe I'd better think of another way to do this that might work better. Or, maybe, if you're going to the hardware store anyway, you might pick up a screwdriver or, better still, a drill. On the other hand, much of my workmanship is pretty ugly as it is, so I shouldn't get fussy now about how it will look when a screw is sunk with a sledge hammer and visegrips. I wasn't thinking in terms of being polite about the visegrips, since they were bought for a different project and aren't meant to sink screws.

I should have kept in mind that while I was thinking of the supply module as an already existing tool that might or might not meet my needs, it was something that you created and, now that I think about it, hasn't been used in a scenario yet (at least to my knowledge). I apologize for my lack of respect.

 

I'll probably get back to this later this week. I've written most of a "text" module (stuff like automatically splitting text into multiple boxes if it is too long, automatically producing a menu from a table, deferring messages until the next after production sequence for the appropriate player, archiving messages to be read later), but I've only tested a little bit of it so far, and I want to post that first.

 

Thanks very much for your response @Prof. Garfield; I appreciate you taking the time to come back to this. I'm relieved to hear that I misinterpreted some of your statements, or took them to have a tone you didn't intend.

I agree -- ease of use (implementation), and being able to organize or segment code by "purpose" as much as possible, are probably the most compelling reasons for writing modules that are designed to be customized for each scenario. That definitely makes my modules different than true libraries, of course -- and I see a lot of value in libraries as well. Ultimately, I'm hoping that we can draw some (more) scenario designers without a programming background into Lua, and start to get their feedback on what approach has the lowest barrier to entry.

Got it. Yeah, I guess your previous comments struck me as either arguing that my visegrips weren't a very effective screwdriver, or -- worse -- saying that I shouldn't have spent my time building visegrips when that isn't what most people need. To use a different analogy, I felt like I built a Model T Ford, and you were plainly unimpressed because you want a Formula One race car. Well, sure, a race car would be great -- and I fully agree that what I've released so far isn't one. But there are also some people out there who are looking for a basic family sedan -- or an 18-wheeled semi truck! My perspective is, hey check this out, I built a vehicle with a working internal combustion engine. Now the door is open to iterate on that and introduce improvements to meet a variety of needs.

I do think that version 2.0 of my module will be going in the direction of making this a more generic tool -- in other words, the trend is towards the broader goal of "pathfinding" and not the narrower one of "supply lines". Since it's still a module that's intended to be edited by the implementer, though, you (or any designer) are welcome to tackle more advanced adaptations as part of that process. Perhaps that's another advantage to this design style -- it lends itself more easily to functionality tweaks that I didn't anticipate or explicitly support.

I think the upcoming version 2.0 of my module intends to support both of these goals, although the code might not be structured exactly the way you envision it.

Correct... "zone of control" is on the list of enhancements I have not tackled yet. I had jotted down at least two different options for how a designer might want this to work in a functional sense, though, and now you've just raised a couple more: support for an extended ZOC with a radius greater than 1 tile, and having different ZOC rules for a customizable set of unit types.

Adoption is always going to proceed pretty slowly in a small community like this, so I'm not discouraged at all. I've actually received several private messages about this module from interested parties, which is pretty cool, so I'm optimistic that a scenario using it will eventually be released. One of those conversations was the impetus for many of the version 2.0 enhancements I've been working on.

 

The events are yours - the only tweak I made was to add the torpedo to the list of units deleted each turn and that's a quick redo later.