Outpost Universe Forums

Projects & Development => Projects => OutpostHD => Topic started by: leeor_net on September 27, 2015, 07:22:40 PM

Title: OutpostHD - An Open Source Remake of OUTPOST by Sierra On-Line
Post by: leeor_net on September 27, 2015, 07:22:40 PM
What is OutpostHD?
OutpostHD is a remake of OUTPOST by Sierra On-line from 1994. It's not a clone of OUTPOST -- it's an entirely new game inspired by OUTPOST's core mechanics while providing a more complete and satisfying experience than the original ever could.

YouTube Video


Screen Shots
(https://i.ibb.co/0m6mhbd/image.png) (https://ibb.co/0m6mhbd) (https://i.ibb.co/Nm7Chnh/image.png) (https://ibb.co/Nm7Chnh) (https://i.ibb.co/NLRqjHc/image.png) (https://ibb.co/NLRqjHc) (https://i.ibb.co/z8JTQNs/image.png) (https://ibb.co/z8JTQNs) (https://i.ibb.co/3hG9790/image.png) (https://ibb.co/3hG9790) (https://i.ibb.co/KxyGvmF/image.png) (https://ibb.co/KxyGvmF)

Current Build
You can download the current build here: Current Build (https://github.com/OutpostUniverse/OPHD/releases/tag/v0.8.7)

The Windows release of OutpostHD is developed using Visual Studio 2019. You will need to download the Microsoft Visual C++ 2019 Redistributable (https://support.microsoft.com/en-us/help/2977003/the-latest-supported-visual-c-downloads). Use the x64 version as OutpostHD is now distributed as a 64bit binary.

How to Play
A "How to Play" guide has been started on the OPU Wiki:

OutpostHD Wiki: How to Play (https://wiki.outpost2.net/doku.php?id=outposthd:how_to_play)

Change Log
Change Log for v0.8.7 (https://github.com/OutpostUniverse/OPHD/blob/v0.8.7/CHANGELOG.md)

Change Log for the current development build (https://github.com/ldicker83/OPHD/blob/master/CHANGELOG.md).


Roadmap
OutpostHD is hosted on GitHub -- you can see its current and future progress here: OPHD Milestones (https://github.com/OutpostUniverse/OPHD/milestones)


WIKI Page (http://wiki.outpost2.net/doku.php?id=opu_projects:active_projects:outposthd)
Basically restates what's here but goes into more details on a number of subjects. Also, as the game is beginning to be fleshed out now it's a good resource for understanding how parts of the game work.


Older Versions
Older versions of OutpostHD, if you're interested in seeing the changes over time, can be found in the files directory of the OPU website: http://outpost2.net/files/ophd/



Goals
I want OutpostHD to be freely available to everybody, so it's open source. The code is available on GitHub under the BSD-3-Clause license.

I also want OutpostHD to have its own new art and audio assets so as not to infringe on the original copyrights and to be able to take advantage of modern graphics hardware and 32bit Color Depths.

Finally, I want OutpostHD to be what Outpost should have been. Outpost was a great idea. Its implementation, however, was terrible. OutpostHD is an attempt at making the game that Outpost could have been.


Changes to the Design
OutpostHD isn't a clone of OUTPOST but instead a re-implementation of the core mechanics and ideas in a more refined and finished product. See OutpostHD's Wiki article (http://wiki.outpost2.net/doku.php?id=opu_projects:active_projects:outposthd) for details.





How You Can Help
I'm often asked how one can contribute without being a programmer -- there are lots of ways!


Graphics
One of the goals of OPHD is to replace all of the visuals with unencumbered assets. Most of the structures have been replaced, all of the tilesets, planets and landing maps are new and the GUI Skin is new. There's still plenty left to do though -- check out the Graphics Update subforum (https://forum.outpost2.net/index.php/board,109.0.html) to see where efforts are being focused and where you might be able to help.


User Interface
I've never been very good at UI design and thankfully several community members have been able to step up and help me develop a much better user interface (https://forum.outpost2.net/index.php/topic,6111.0.html). But, it still needs further work. The best way to help with the UI is to offer designs or to just use the interface and report back any issues you find (something is unclear, something doesn't work right, etc.)

See the User Interface subforum (https://forum.outpost2.net/index.php/board,111.0.html) for discussions about improving the UI.


Writing
I know, not exactly a story driven game but writing is becoming a thing that's going to need some TLC. Specifically, the flavor text for the Research Tree (https://forum.outpost2.net/index.php/topic,6142.0.html), product descriptions for the Factory UI Panel (https://forum.outpost2.net/index.php/topic,6111.0.html), the individual structures and the Wiki Page (https://wiki.outpost2.net/doku.php?id=outposthd:how_to_play). If you're up to the challenge, let me know!


Programming
The best way to get involved is to just jump in, clone a copy of the git repository and start poking around in the code. You can get instructions for cloning the git repository from the GitHub project page: https://github.com/OutpostUniverse/OPHD (https://github.com/OutpostUniverse/OPHD)

I started putting together a Building from Source (https://wiki.outpost2.net/doku.php?id=outposthd:building_from_source) wiki page. It should be fairly complete. If you run into trouble you can post here or get ahold of me or Hooman on Discord (see chat link at the top of the page).

The latest commits on github use Visual Studio 2022 project/solution files and vcpkg for dependency management. See https://github.com/microsoft/vcpkg for instructions on installing vcpkg and Building from Source (linked earlier) for vcpkg commands.

Please ask if you have questions. A lot of effort went into making this as painless as possible and questions help me to see where instructions can be improved.

Poke around the code, see what issues/tasks are still open and don't be afraid to ask questions or make suggestions! I'm very open to assistance and without the help and experience of several other developers OPHD would not be nearly as far along as it is. Even if it's just a small patch, go ahead and submit a pull request -- it's a great way to get my attention on GitHub!

Can I help in some other way?
Yes!

As the developer, I have intimate knowledge of how every part of the game works. I know how I intend the game to work so I often don't think of ways that users may try to play the game.

That's where you, the user, come in. Your feedback is extremely helpful in knowing where to focus my development efforts. Is something not clear? Say so! Did the game explode on you? Tell me!

I love getting bug reports especially when the game breaks in weird and unexpected ways. I've already been able to iron out a lot of bugs just from the feedback of users like you. So download the game, play it, explore it, find ways to break it horribly and then let me know about your experience!
Title: Re: OutpostHD - An Outpost Redesign
Post by: Eddy-B on September 28, 2015, 03:48:33 PM
::ThumbsUp::

I never got this far, although i did toy with the idea once...
Title: Re: OutpostHD - An Outpost Redesign
Post by: Leviathan on September 29, 2015, 08:10:12 PM
Fantastic news! The project is coming along nicely, its looking great!

I did play Outpost 1 a bit when I was a kid.. I will have to revisit it and then I can actually comment on your questions and discuss the projects direction properly. Simplifying things is good and getting rid of pre-game stuff makes sense to just get into the game, it could always be added later, I do remember liking it. Most important thing is the main game.

I hope you find the time to work on the project, I know work is hetic for you!

:D
Title: Re: OutpostHD - An Outpost Redesign
Post by: Hooman on October 05, 2015, 11:12:05 PM
Very nice. Will have to take a more detailed look at this.

I love that you posted the repository link. (Although I currently get a security warning when I click the link in the browser because the certificate is not trusted).
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on October 09, 2015, 01:38:09 AM
I was originally going to keep a record of the changelog here on the Forums but I realized it would make much more sense to simply link to the 'CHANGELOG.md' file I just committed to the repository so I'll be linking to it instead. The SVN server does a decent job of rendering the log but Google has a few Markdown Viewer plugins that work better so feel free to install one of those and view it that way.
Title: Re: OutpostHD - An Outpost Redesign
Post by: Leviathan on October 09, 2015, 05:51:44 AM
Yeah changelog is best on the SVN or website/wiki page.

Glad to see you are making progress :)

I just tried out Outpost 1 lately.. OutpostHD already looking better, being able to see so many more tiles on screen is great.

I forgot about the underground view in Outpost 1, I remember loving that, and in other games like SimCity.
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on October 09, 2015, 05:53:08 PM
The game also scales down to 640x480 pretty well. Not that anybody would really want to play it in that resolution but for nostalgia's sake!

I do need to add some sanity checks for screen resolutions and eventually I'll need to have the screen resolution configurable from within the game. I had a proof-of-concept of doing that on the fly with The Legend of Mazzeroth -- we were switching between resolutions and at the time between a software and OpenGL renderer.

Anyway, the fullscreen mode works well I think. I was wondering about the background of the game though... I know it's a small detail but should I have it auto generated like the original game with a blue gradient and green lines? Or should I shy away from that and go with something else entirely?
Title: Re: OutpostHD - An Outpost Redesign
Post by: rmiddle on October 09, 2015, 11:22:14 PM
Is the game actually playable at this point or is it still more a proof of concept.

Thanks
Robert
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on October 10, 2015, 12:32:46 AM
It's less a proof of concept and more a WIP.

It's almost playable. I need to get resource management and factory production working, difficulty selection and save/loading working before I would call it 'playable'. After that it would be a matter of adding in research trees, resource trucking routes and polishing up the UI to make it intuitive to use and look half way decent, then we can call it a truly playable game.
Title: Re: OutpostHD - An Outpost Redesign
Post by: BinaryMan on October 12, 2015, 06:27:01 PM
For both factory production and research, it could be more user-friendly to use a queue approach. So the factory can make several items (possibly in a loop), and several pre-requisite technologies can be done in a row and all labs can work on the same thing without having to open each one.
Title: Re: OutpostHD - An Outpost Redesign
Post by: rmiddle on October 13, 2015, 11:55:58 AM
For both factory production and research, it could be more user-friendly to use a queue approach. So the factory can make several items (possibly in a loop), and several pre-requisite technologies can be done in a row and all labs can work on the same thing without having to open each one.

That would be great.  The interface in OP2 especially tended to leave your research labs idle doing nothing.

Thanks
Robert
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on October 13, 2015, 12:52:27 PM
That's not a bad idea... kind of take a page from Civilization's book in that case. I was actually thinking about how to handle the UI when selecting factories, labs and manufacturing/research parks. Could use a similar approach where it just covers the whole screen.

Research makes a lot more sense to queue up but I'm wondering if I should again take a page from Civ5's book and every time a research topic is completed it lets you know "Hey! Listen! You can do more research!". In this case research labs would be assigned all together. Or again, go with the research parks where several labs are directly connected to an administration building and they are treated together.

Going to have to think about it.
Title: Re: OutpostHD - An Outpost Redesign
Post by: rmiddle on October 13, 2015, 07:06:28 PM
That's not a bad idea... kind of take a page from Civilization's book in that case. I was actually thinking about how to handle the UI when selecting factories, labs and manufacturing/research parks. Could use a similar approach where it just covers the whole screen.

Research makes a lot more sense to queue up but I'm wondering if I should again take a page from Civ5's book and every time a research topic is completed it lets you know "Hey! Listen! You can do more research!". In this case research labs would be assigned all together. Or again, go with the research parks where several labs are directly connected to an administration building and they are treated together.

Going to have to think about it.

In Outpost 1 how do you add additional Command Center to create additional Colonies?
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on October 13, 2015, 10:45:17 PM
You don't. The game was never finished.
Title: Re: OutpostHD - An Outpost Redesign
Post by: Sirbomber on October 14, 2015, 03:15:45 PM
In Outpost 1 how do you add additional Command Center to create additional Colonies?

You don't. The game was never finished.

Wrong.  I forget what tech you need, but you can actually build new Command Centers and start new colonies.  It needs to be placed at least 30 tiles (I think) away from any existing Command Center on terrain that hasn't been cleared by a Robo-Dozer.
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on October 14, 2015, 05:34:00 PM
Okay, great. Let's stick to the topic at hand, questions about how to play Sierra's OP1 can be brought up in the appropriate forum.
Title: Re: OutpostHD - An Outpost Redesign
Post by: vomov on October 16, 2015, 06:50:32 AM
Played around with it, and I must say: it's already quite an accomplishment!

I'd love to help, but I'm not good enough with coding (I'd love to help with testing and balancing, though, as well as most people here). Some thoughts:

UI can definitly benefit from some improvement, but I'd say to leave that for last. Base gameplay might go through several iterations, requiring tedious rewrites. Especially considering the original was quite broken, improvements would be made, changing the gameplay massively.
Question; didn't Outpost 1 under windows simply change the theme to some odd variant of the high-contrast theme?

In Outpost 1, I remember not paying attention to resources at all, unless something was wrong. I vaguely remember I'd just plop down mines, and keep the mining robot busy on new ones. This cannot be intended, so some form of resource management would be required. Separating metals and minerals into common and rare is good enough, I'd say. Could mining sites have differing proportions of these, though?

Mines automatically adding to the pool is odd, and trucks are defintely a solution. Truck routes with waypoints might not be ideal. How about this (example): mines automatically add truck routes from the mine to the command centre. The length of these routes is calculated using for A*, with every tile having a bit of resistance (rough tiles take longer). All trucks are shared between them. If a truck can traverse 100 tiles every turn, and we've got two mines at a distance of 25 tiles to the colony, then one truck can visit each mine twice every turn. Assuming mine production is balanced based on resource usage, then you'd only have to fiddle with the truck size until it feels right. Using mining robots to extend a mine would have it produce more resources, having insufficient trucks would cause resources to stock at the mine until the mine is full. A button showing the results of the search algorithm and a small window showing all truck routes with the used storage room at the mines would be enough for truck routes, then. Connecting a mine directly to the colony with a tube or monorail or whatever means trucks are no longer for that route, and then resources are added instantly (read: it's best to start near a mine).

MPG always reminds me of Soylent Green, so its universal use always felt wrong. I would also vote for the resource 'organic waste'. Food comes from agridomes, raw organic matter is fertilizer. Slag as a resource also feels realistic. Question: what did SPEW stand for (Sewage Processing ...)? It's kinda a nice acronym:)

As I read it, we've got several resources:I'd like to propose the following as proper resources as well:On research, I'm not a huge fan of Civ's system; it feels like an annoyance. Queing might work quite well, but maybe a slider system, like Space Empires uses, would work better. This would be a parallel system, where you set up a couple of 'studies', which are then shared across labs. Making research parcs by coupling research labs would work very well, as long as you can set the task for the whole parc in one go. Multiple parcs, multiple tasks. Same for factories; certain tasks take quite a while, combining factories would reduce the time required. Separate factory parcs with separate tasks would be brilliant. As for the interface-part; show the separate parcs as a single 'factory' in a list, each with their own task/queue.

Modelling individuals would be a nice addition, and easy since it's a turn-based game. Also, this allows you to model birth, aging, and death. Relationships... would be complicated, but a simple marriage and procreation thing might be nice.

Question: didn't the original say something like 'people are frozen, and will be thawed if we've got the capacity'? If not; this might be a good addition, for the sake of realism. A genepool of twenty people is awefully small.

I feel medical issues are generally neglected, while they provide quite a bit of material for gameplay and storytelling. Perhaps medical issues could benefit from something similar, but simpler: everybody has a base chance to get a cold, break a leg, get cancer, andsoforth. However, somebody working in the agridomes might have an increased chance of needing treatment for allergies. A list of diseases/disorders with base chance, and modifiers based on job would do the trick (although this might stretch the idea a bit too far). Medical centres producing medicine would be good enough, so they'd need a bit of resources. Maybe this addition might go a bit too far, though...

I've seen other games use VERY simple formulas to model morale to good effect, so it doesn't have to be too complicated. Let's say morale goes from 0 to 100. The base state would be 20 (the only survivors, stuck on a inhospitable planet; not fun). And then you'd simply give additions per individual.
For example: let's say you've got one residential unit, which holds 16 people, and you've got a production of 10 cheap luxury items per turn. Randomize the colonist list, and start running through then one by one. For the first ten, you've got housing and cheap luxury items: +10 morale for housing, +5 for cheap luxury items. For the next six, you've only got housing: +10. The next four, you don't have anything; they'll sleep in the hallways and brush their teeth with the gravel found outside the airlock. Simple math then tells you you've got 10 colonists with 35, six with 25, and four with 20. Average would then be ((10*35)+(6*25)+(4*20))/20=29, which is not great.

The effect of food should work differently. Let's say 20 people, but only food for 10: nobody starves, but people aren't happy, so -10. Food for 40, and everybodycan pick and choose: +10, and slightly more organic waste (people simply eat more), which drains into the agridomes. Food for eighty, and a lot of food gets wasted, leading to unhappiness: +10 for the food, -5 for the inefficiency.

EDIT: sorry for the wall of text, I got carried away.
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on October 16, 2015, 12:48:14 PM
Quote from: vomov
EDIT: sorry for the wall of text, I got carried away.

By all means, this is the kind of discussion I was hoping to see.

Quote from: vomov
I'd love to help with testing and balancing, though, as well as most people here

This is an area I could certainly use help. For the moment I've just used arbitrary values that help me just to see where things are going and test the resource consumption, etc. but none of it is set up well. Arbitrary values don't usually work well for these kinds of games so balancing will be needed.

Quote from: vomov
UI can definitly benefit from some improvement, but I'd say to leave that for last.

Naturally. This is why I called it a 'functional' UI but that doesn't make it good. Toward the 0.8/0.9 versions of the game I'll be looking at making a pretty UI that's as functional as it is good looking, but for now the basics do the job with simple buttons and pop up menus and the delightfully classic Windows 95 look.

Quote from: vomov
Question; didn't Outpost 1 under windows simply change the theme to some odd variant of the high-contrast theme?

Pretty much. They just changed it to black and green.

Quote from: vomov
Could mining sites have differing proportions of these, though?

They already do, though atm it's as simple as YIELD_HIGH, YIELD_MEDIUM and YIELD_LOW. Again, just threw in some arbitrary values there but it wouldn't be difficult to expand on that such as YIELD_HIGH_RARE_HEAVY, etc. or there could just be a randomized element to what kinds of resources a given mine will yield. I have mines randomly generated up to a set amount but the terrain difficult dictates the likelihood of getting a higher yield mine (e.g., tougher terrains will tend to favor medium and high yields, easy terrain will tend to favor low yields).

Quote from: vomov
these routes is calculated using for A*

There was another user that had PM'd me about exactly this. My thinking was that trucks had a certain range for which they could travel... say 30 tiles. So we could limit the A* search to that. Your other proposals of showing pathed trucks makes sense and is something I had considered as well and only makes too much sense. Highlighting truck routes is a natural progression.

Following that, once a route is established, the user would mostly be looking at assigning x number of trucks to particular routes. The UI for that would show if there are too many trucks, if resources are being left at the mine, etc.

I also thought about how often routes would need to be calculated and it should be fairly straight forward -- whenever a new mine is placed or an existing route becomes obstructed (colony expansion, etc.). The only issue then is whether or not the Smelther that it's being brought to is inaccessible and in a case like that the game can alert the player that there is a mine with no truck access to a Smelter.

Finally, when a mine becomes active, does the user have to initiate the routing? Or does it happen automatically? If it happens automatically, it will need to determine which smelter it needs to go to. Smelters are connected to the colony via tubes, but mines aren't, so a smelter could feasibly be built right next to a mine meaning trucks aren't taking much time to get back and forth and that the resources, once processed, are immediately available to the colony. I don't see this as an issue but it would mean that trucks would need to have a limit to how long they spend at each building. My thinking is once they arrive at a structure, it takes them 1 turn to load/unload.

Quote from: vomov
As I read it, we've got several resources:

These are the resources I'm currently considering:


I don't want to really break it down much farther than this and I may even consider combining the two waste's into just simply 'waste' which when processed produces a small amount of metals and minerals. I don't think making it any more complex than that is necessary or fun.

I am curious though -- if one does not have a recycling center, what happens to all of this waste? What do the colonists do with it? Organic in particular -- does it just get dumped out onto the surface somewhere where it gets to fester before being irradiated or frozen? I would think at the very, very least that all residential units and any structures with toilet facilities would have some sort of a sump well that separates the solids from the liquids with the liquids then being sent off to the CHAP (perhaps it should just be called the Life Support Facility considering it does more than just air) for cleaning and re-circulation. That being stated, the now dry solid waste is the concern... do they just throw it away? With a recycling facility that's my suggestion of where this waste, along with manufacturing waste, etc., would go to be broken down into their components for use where needed.

Quote from: vomov
This would be a parallel system, where you set up a couple of 'studies', which are then shared across labs.

This was the general idea. I liked how Civ5 just laid out their topics, it doesn't mean that we need to be limited to working on only a single research topic at a time. On the contrary, I would want different research projects to happen at the same time. But this is where I think the research parks come in. Unless you have an administration building of some sort directly connected to labs, you'd have to set each lab individually. With the administration set up, now you can set research for  up to four labs at a time, or maybe instead of having labs being required to be directly connected to the Admin building, the Admin building would instead have an area of effect, say any lab within 3 tiles of the admin building are under its control. This does bring up the problem of what about overlapping areas but that can be solved by just restricting administration buildings to having to be at least 6 tiles away from any other administration building.

I like your thoughts on the population and morale models. I haven't looked too deeply into it yet as I've been more focused on getting the basics done first so if you wanted to design the population model and morale model, by all means go right on ahead.
Title: Re: OutpostHD - An Outpost Redesign
Post by: Mordithrahl on October 16, 2015, 08:12:45 PM
This is incredibly exciting, and your project looks great so far! So happy to see this alive.
Title: Re: OutpostHD - An Outpost Redesign
Post by: vomov on October 17, 2015, 04:33:06 AM
Pretty much. They just changed it to black and green.
Ah, yes, now I remember. And after a crash the theme would 'stick'. Ew.

e.g., tougher terrains will tend to favor medium and high yields, easy terrain will tend to favor low yields
I like that; a clear incentive to go to the difficult-to-reach mines, yet at the same time it's possible to make a lot of easy mines.

Following that, once a route is established, the user would mostly be looking at assigning x number of trucks to particular routes. The UI for that would show if there are too many trucks, if resources are being left at the mine, etc.

That's a better idea; I thought about having a general 'truck pool' where all routes get their trucks, but this bit of micromanagement allows the player to fine-tune the influx of materials.

Then the whole stuff about routes and smelters has several possibilities, and is dependent on each other. I think about the steps involved, I end up roughly like this:
New mine is placed --> mine is unconnected --> mine makes automatic connection with the nearest/least busy smelter --> new route requisitions trucks until simple math shows all resources generated in a turn ends up at the smelter, or until the free trucks run out.
This has the advantage of triggers; if a mine expands, a smelter disappears, trucks get destroyed, or something else happens, it can simply run through some or all of these steps again.
Concerning the smelters; I think in Outpost 1 smelters had to be placed outside of the colony, without tube access. If we follow that route, perhaps we can do something like this:
Smelters do not require tube access, and automatically create a link with the colony. As in; they make a sort of 'minitube' (visible or not), or use small trucks that come with the smelter, or whatever. They'd have to be placed within five tiles of a colony-tile for the link to form, which would make the one turn to unload redundant too; the trucks have to travel quite a ways anyway. To make this work perfectly, and add a smidge of realism, perhaps introduce four extra resources: raw common metals, raw rare metals, raw common minerals, raw rare minerals. Mine ships bulky raw stuff to the smelter, smelter gets rid of most of the useless material, and a small transport drone is enough to ship all processed materials to the colony.

These are the resources I'm currently considering:
  • Common Metals
  • Common Minerals
  • Rare Metals
  • Rare Minerals
  • Energy
  • Food
  • Organic Waste
  • Other Waste
Noodles from a tin :o
Although; if we use the term 'bioplastics', then we can use either food or organic waste as a resource required by several industries. For example; while a colonist consumes 1 food per turn, 0.1 of this food is spent in making the packaging. Same for other things; making a truck requires a bit of organic matter for the upholstery, which comes from food or organic waste (organic waste would be the least odd, but you'd still end up with odd smelling tires). On the other hand; realism shouldn't stand in the way of good gameplay, so maybe this goes a bit far. Canned food would work just as well.

... with the liquids then being sent off to the CHAP ...
I think that's where the CHAP and the SPEW can work together; the SPEW eats up (organic, or all) waste, the CHAP gets rid of the smelly liquids, and produces air and potable water. For the CHAP a description should be enough, no extra resources would be needed. Concerning the circulation of matter; I read a Sci-fi book once that detailed (in excruciating detail) the flow of matter through a small colony. Generic 'trash' would be collected, separated into liquids, solid-ish organics, and non-organics. The liquids were used for air and water, same as here, the solid organics were made into fertilizer, and the non-organics were thrown into something that reminds me of the smelter. Perhaps a pseudo-resource could work here; the SPEW and CHAP simply get an amount of input based on the amount of people; more people, more organic waste. An overloaded SPEW or CHAP makes people unhappy. And then assume the CHAP produces as much air as required (until overloaded), and the SPEW has a direct line to the agridomes. In other words; organic waste disappears as a proper resource, and other (inorganic) waste can simply be thrown into the smelter for a small amount of random materials. No need for a big pile of poo outside the colony  ;D

With the administration set up, now you can set research for  up to four labs at a time, or maybe instead of having labs being required to be directly connected to the Admin building, the Admin building would instead have an area of effect, say any lab within 3 tiles of the admin building are under its control. This does bring up the problem of what about overlapping areas but that can be solved by just restricting administration buildings to having to be at least 6 tiles away from any other administration building.
That'd require an additional building, and I expect people will want to put multiple admin buildings to the same task. Why not make labs auto-connect into larger labs? For example:
Two separate labs, with separate tasks:
lab+lab
Two parcs, where the right one has twice the research points:
lab+lablab
Two parcs, with the right one five times the research points:
lab+lablab
       lablablab
It would provide some cosmetic benefits; no more 'grid of tubes' eating up half the space. The same could be done for factories and, now that I think about it; smelters! Also, in late-game; terraformers could also do something similar. Other buildings might also benefit from this; putting four universities together might change the description; "This university has a dedicated astronomy, geology, physics, and medicine faculty". Question; there were no multi-tile graphics in the original, except for some unused graphics of the terraformer and the defective mass driver, right?

Every parc (lab, factory, smelter) would behave as one single entitiy. No admin buildings needed, no additional micromanagment (linking labs to admin buildings), and easy expansion (overloaded smelter? Expand it!). Some form of limit would have to be imposed, like a max of nine combined labs, or four combined factories. If, for example, the CHAP is overloaded, and we build a second one half a colony away, then resources are shared between them. If we put them right next to each other, we end up with a single CHAP, with one window, one set of resources, etc.

Question: in Outpost there was an administrative building, but I don't know what it did. Did it have a use?

I like your thoughts on the population and morale models. I haven't looked too deeply into it yet as I've been more focused on getting the basics done first so if you wanted to design the population model and morale model, by all means go right on ahead.
I'll do some minor brainstorming, and I can set up a preliminary list with some seemingly arbitrary values.
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on October 20, 2015, 11:49:51 PM
@Vomov -- I will reply, I promise. Just haven't had the time to really respond.

Quick update -- not ready for release yet but this is what the current factory production interface is shaping up to look like. This will change in the future when you can update factory production in groups instead of individually but this interface will likely remain if you want to tweak a single factory without looking in the production window.

(http://leeor.outpostuniverse.org/ophd/screenshots/0.5.0/ss_01_thumb.png) (http://leeor.outpostuniverse.org/ophd/screenshots/0.5.0/ss_01.png)
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on November 01, 2015, 10:09:11 PM
Quote from: lordpalandus
Humans don't die from old age. They die from organ failure

Who cares? I'm not trying to simulate true biology here.

Ultimately when I first started putting that class together, I just threw in values that I thought made sense. E.g., structures. They also have a 'maxAge' field. Do actual structures in the real world have a set number of years that they exist and then suddenly fail? No, not at all. All kinds of factors are involved in how long a structure lasts including exposure, maintenance and natural events (like storms and earthquakes). But, a maxAge field makes sense because that's how long a structure is expected to last. And some, for the sake of game play mechanics, will last only so long.

Perhaps a better way to represent both People and Structures is 'state of health' and 'state of repair'. Instead of counting up these values would count down. When either of these values hits '0' the person dies or the building collapses.

Regardless, the idea here is to be able to provide a reasonably good simulation of a population where values are used to approximate actual conditions. A 'maxAge' value for a Person would simply represent an average lifespan which is modified during the simulation based on stress, morale, working conditions, environment conditions (e.g., heavy radiation exposure or high gravity), medical technology and advancement and availability of life support.

I dunno -- this seems like we're beating a dead horse now. I'm going to proceed with what I had originally envisioned. If someone has a better idea, I'm open to a proposal which should include an actual model of how it would work vs. how it could be handled. Not being pissy here, just want to move forward with this. :)
Title: Re: OutpostHD - An Outpost Redesign
Post by: dave_erald on November 08, 2015, 12:19:11 AM
Cool, new content. Awesome.

So my biggest beef with Outpost 2, (sorry never played the first Outpost game ) was replay-ability, as far as tech and research tree was concerned it really kind of requires more micro managing then I think it really needed. Trying to replay quickly in multiplayer would drive one nuts I believe. Also the the levels and separate upgrades for a particular upgrade of an upgrade made me scratch my head.

I seen the original post and was wondering if you had made any head way in this direction yet or still needed input?

I can't program but I can brain, if that makes any sense.
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on November 08, 2015, 12:02:54 PM
With the research trees? Not really. I've been focused more on the basics. Research trees are coming up soon though in terms of development so I will need to figure that out.

There have been a few suggestions as to how to improve the original research tree and research management. So far nothing concrete.
Title: Re: OutpostHD - An Outpost Redesign
Post by: vomov on November 09, 2015, 09:10:30 AM
Concerning research: I still have the outpost research tree from a FAQ, but it doesn't contain all the effects (although quite a few are obvious). A short playthrough should solve most of this, though :)

I had a question about the connector tubes; originally, we had straight tubes in the two directions, and an intersection. Would it be possible to replace this with 'tube', that simply connected to whatever was in the next tile? A tile would be a 'tube'-tile, which would get a different image based on its bordering tiles. I think I could even make some generic T-junctions for artwork (they're just BMP's, so...). This would be partially a aesthetic improvement, but also a UI improvement; a single generic 'tube'-button would be it for the user interface, perhaps with generic 'bulldoze' and 'dig' and 'mine' buttons next to it.
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on November 09, 2015, 10:25:26 AM
This is something I've considered at it makes sense. While the current UI and placement code looks at them as separate objects, the internal code sees it as a single structure with just a specific type of direction.

Adding this in would be fairly simple and would actually reduce the complexity of the connectedness algorithm (instead of checking for tube direction, it just checks to see if a tube is present).
Title: Re: OutpostHD - An Outpost Redesign
Post by: Vagabond on November 11, 2015, 04:54:24 AM
Leeor,

This is a great project!. I really enjoyed Outpost back in the day, despite the difficult user interface. Curious on a couple of graphics related questions since you are planning to move away from the original game's graphics. I gathered 2D graphics, 32bit PNG arranged on sprite sheets.

Are you planning to stick with ISO view?

Are you planning on drawing multiple textures per tile (IE a ground texture with a building texture on top), or only drawing one texture per tile?

Are you planning on having any animated tiles? If so, will the animation just sequence through several PNG tiles from a sprite sheet?

-Brett
Title: Re: OutpostHD - An Outpost Redesign
Post by: Hooman on November 11, 2015, 02:25:02 PM
For simulating the population as a whole, rather than every individual, you can use the model from Outpost 2 as a reference:
Population Model (http://forum.outpost2.net/index.php/topic,2147.msg38753.html#msg38753)

Your population takes 3 values (number of workers, kids, and scientists).
Population growth takes 3 values (growth progress of workers, kids, and scientists).
Population death takes 3 values (death progress of workers, kids, and scientists).

When growth or death progress reaches a certain threshold, you gain or lose a colonist, with the remainder being saved for the next round. The threshold is affected by med centers and morale.

There are a few rules added to the mix, which adds some interesting asymmetry. Kids have double the death rate, you don't get new kids if they outnumber the adults, and scientists contribute half as much to procreation. A single active nursery is required for kids to grow, and also acts like a med center with a capacity of 40 for kids only (same as an unupgraded med center, which helps all population components), a single active university is required for kids to be trained into workers, and workers require manual training to become scientists.
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on November 11, 2015, 03:33:26 PM
@Hooman

That actually breaks things down much more easily for me and I now have the forumlation for a simple mathmatical approach. My math isn't particularly strong so I imagine it would be very easy to figure out a pattern and develop strategies to take advantage of any weaknesses in the math.

I suppose over time it can be improved but it would certainly work better (I think) than my initial thinking.

@Vagabond

Quote from: Vagabond
Are you planning to stick with ISO view?

Yes.

Quote from: Vagabond
Are you planning on drawing multiple textures per tile (IE a ground texture with a building texture on top), or only drawing one texture per tile?

?

It's already being drawn as separate 'textures'. As the engine loops through each tile its' drawing, it first draws the ground 'tile' and then any structures or visible elements on top. Next tile, rinse, repeat.

Doing it any other way seems awfully inefficient.

Quote from: Vagabond
Are you planning on having any animated tiles? If so, will the animation just sequence through several PNG tiles from a sprite sheet?

Already using the animations from the original game. It's kind of a pain to convert from the resource files and placement to a more modern format. My sprite implementation is a little naive and perhaps a bit wasteful (each frame shows the entire sprite vs. having the sprite with any changes drawn on top).

And yes, that's basically what it does. The sprites just grab chunks off a sprite sheet and draw that. The animation is laid out from right to left, top to bottom in the sprite sheets but it's not required to be done that way. Sprites are defined as XML files with tags and sections specifically for working with multiple sheets and frames of animation. Frames can be defined in any order and from any section of a given sprite sheet. Each frame also has a time/delay definition as well so you can have a single frame displayed for several milliseconds of for several minutes.

Following is one of the sprite XML definitions currently in use:

Code: xml [Select]

<sprite version="0.99">
<imagesheet id="construction" src="construction_01.png" />
<imagesheet id="main" src="command_center.png" />

<action name="construction">
<frame sheetid="construction" delay="800" x="0" y="0" width="107" height="64" anchorx="0" anchory="18" />
<frame sheetid="construction" delay="145" x="107" y="0" width="107" height="64" anchorx="0" anchory="18" />
<frame sheetid="construction" delay="145" x="214" y="0" width="107" height="64" anchorx="0" anchory="18" />
<frame sheetid="construction" delay="145" x="321" y="0" width="107" height="64" anchorx="0" anchory="18" />
<frame sheetid="construction" delay="145" x="0" y="64" width="107" height="64" anchorx="0" anchory="18" />
<frame sheetid="construction" delay="145" x="107" y="64" width="107" height="64" anchorx="0" anchory="18" />
<frame sheetid="construction" delay="145" x="214" y="64" width="107" height="64" anchorx="0" anchory="18" />
<frame sheetid="construction" delay="145" x="321" y="64" width="107" height="64" anchorx="0" anchory="18" />
<frame sheetid="construction" delay="145" x="0" y="128" width="107" height="64" anchorx="0" anchory="18" />
<frame sheetid="construction" delay="145" x="107" y="128" width="107" height="64" anchorx="0" anchory="18" />
<frame sheetid="construction" delay="145" x="214" y="128" width="107" height="64" anchorx="0" anchory="18" />
<frame sheetid="construction" delay="145" x="321" y="128" width="107" height="64" anchorx="0" anchory="18" />
<frame sheetid="construction" delay="500" x="0" y="192" width="107" height="64" anchorx="0" anchory="18" />
<frame sheetid="construction" delay="145" x="321" y="128" width="107" height="64" anchorx="0" anchory="18" />
<frame sheetid="construction" delay="145" x="214" y="128" width="107" height="64" anchorx="0" anchory="18" />
<frame sheetid="construction" delay="145" x="107" y="128" width="107" height="64" anchorx="0" anchory="18" />
<frame sheetid="construction" delay="145" x="0" y="128" width="107" height="64" anchorx="0" anchory="18" />

<frame sheetid="construction" delay="145" x="321" y="64" width="107" height="64" anchorx="0" anchory="18" />
<frame sheetid="construction" delay="145" x="214" y="64" width="107" height="64" anchorx="0" anchory="18" />
<frame sheetid="construction" delay="145" x="107" y="64" width="107" height="64" anchorx="0" anchory="18" />
<frame sheetid="construction" delay="145" x="0" y="64" width="107" height="64" anchorx="0" anchory="18" />
<frame sheetid="construction" delay="145" x="321" y="0" width="107" height="64" anchorx="0" anchory="18" />
<frame sheetid="construction" delay="145" x="214" y="0" width="107" height="64" anchorx="0" anchory="18" />
<frame sheetid="construction" delay="145" x="107" y="0" width="107" height="64" anchorx="0" anchory="18" />
</action>

<action name="operational">
<frame sheetid="main" delay="125" x="0" y="0" width="107" height="55" anchorx="0" anchory="9" />
<frame sheetid="main" delay="125" x="107" y="0" width="107" height="55" anchorx="0" anchory="9" />
<frame sheetid="main" delay="125" x="214" y="0" width="107" height="55" anchorx="0" anchory="9" />
<frame sheetid="main" delay="125" x="321" y="0" width="107" height="55" anchorx="0" anchory="9" />
<frame sheetid="main" delay="125" x="0" y="55" width="107" height="55" anchorx="0" anchory="9" />
<frame sheetid="main" delay="125" x="107" y="55" width="107" height="55" anchorx="0" anchory="9" />
<frame sheetid="main" delay="125" x="214" y="55" width="107" height="55" anchorx="0" anchory="9" />
<frame sheetid="main" delay="125" x="321" y="55" width="107" height="55" anchorx="0" anchory="9" />
<frame sheetid="main" delay="125" x="0" y="110" width="107" height="55" anchorx="0" anchory="9" />
<frame sheetid="main" delay="125" x="107" y="110" width="107" height="55" anchorx="0" anchory="9" />
<frame sheetid="main" delay="125" x="214" y="110" width="107" height="55" anchorx="0" anchory="9" />
<frame sheetid="main" delay="125" x="321" y="110" width="107" height="55" anchorx="0" anchory="9" />
<frame sheetid="main" delay="125" x="0" y="165" width="107" height="55" anchorx="0" anchory="9" />
<frame sheetid="main" delay="125" x="107" y="165" width="107" height="55" anchorx="0" anchory="9" />
<frame sheetid="main" delay="125" x="214" y="165" width="107" height="55" anchorx="0" anchory="9" />
</action>
</sprite>
Title: Re: OutpostHD - An Outpost Redesign
Post by: Hooman on November 12, 2015, 06:56:09 AM
Quote
That actually breaks things down much more easily for me and I now have the forumlation for a simple mathmatical approach. My math isn't particularly strong so I imagine it would be very easy to figure out a pattern and develop strategies to take advantage of any weaknesses in the math.

One weakness is the way morale affects the denominator. You only need good morale as the remainder grows to meet the denominator. Having high morale means more progress before a death occurs, and less remainder after it occurs. If your morale suddenly drops while there is a lot of growth, it can trigger a death, and lead to a lot of remainder to contribute towards the next death. Granted, morale is capped to only move 5 units max at a time. On the other hand, if you have low morale, but it's slowly rising to stay ahead of the growth, no death will occur until the growth catches up, and there will be little remainder to contribute towards the next death if the denominator is large.

In a sense, the effects of morale are forgotten between the death points. Morale does affect when those points will happen, but it's a moving target, and doesn't matter until that target is hit. You can potentially game the system by moving resources away from morale structures until the death point is getting close. Same for med centers. Save on workers and scientists until someone is almost ready to die, then gradually activate them to keep the denominator larger than the accumulating progress.

Ideally, I think things like med centers or morale should affect the numerator, so it can properly accumulate over time. That would totally change the math around though. Plus, it is hard to game the current system, particularly since those growth accumulators are hidden. But of course a clever little trainer, or an AI could make use of the way things work.
Title: Re: OutpostHD - An Outpost Redesign
Post by: vomov on November 13, 2015, 05:43:32 AM
Your population takes 3 values (number of workers, kids, and scientists).
Population growth takes 3 values (growth progress of workers, kids, and scientists).
Population death takes 3 values (death progress of workers, kids, and scientists).

Now I understand. I thought primarily from a coding standpoint: individuals in a matrix vs individuals in objects, which is why I didn't get it.

While this does reduce realism and immersion, and potentially introduces odd abstractions in population management, this does reduce the amount of data processed to practically nil.
Furthermore, this is a lot simpler to implement. At the start of a turn:
1) Calculate the changes in the population pool.
2) Loop through the jobs at the start of a turn (based on job priority, I guess), keep 'filling' them until we run out of people.

However, from a coding standpoint, I do have a question: how complicated and abstract will the formulas get (assuming the Outpost 2 method isn't copied to the letter)?
If population death works based on a number, and every turn this number increases: numDeath = numDeath + 0.01 * numPop. Then we add general medical research, which leads to numDeath = numDeath + 0.001 * numPop. An negative event happens, so numDeath instantly increases by 0.05 * numPop. numDeath > 1 means killing floor(numDeath) individual(s), and numDeath = numDeath - floor(numDeath). I'm not sure I understand the effects of morale; does a high morale increase progression towards a death-event? That does not feel proper. It's been a long time since I played Outpost 2, so I might not get it.

Morale itself, however, can become very complex very quickly, since there are a lot of factors that can be taken into account. Furthermore, if the formulas incorporate a lot of other factors, they will potentially reach a level of abstraction that makes bug-hunting difficult. I remember a game with a similar approach for a worker pool, that would roll over zero at some point, leading to an infinite worker pool and a crash. Also, due to the formulas being abstract, it would be quite difficult to get them to approach something believable (although this might be less of an issue here).

On the other hand, this does feel quite similar to what Outpost originally did. Also, the other method (population as object-individuals) does have some drawbacks. On the computational side, it is slower. Of course, the amount of operations per individual should be relatively low (a small 'does it change?' operation should take care of most of it), and steps can be taken to reduce this (infants and children in a pool as a single number would be a VERY good idea, possibly ignore retirees as well), but it'll always require more computing power than the population-as-a-number-approach. Second, all supporting functions would be inherited from the 'person' class, and should be very easy to understand, but would still take up a bit of time to code. Bug-hunting should be easy, though, since the level of abstraction is a lot lower.

Some stuff can certainly be improved from the original, and I do like immersion and storytelling, but it does deviate from the original. I think I'll mount the fence for this issue.
Title: Re: OutpostHD - An Outpost Redesign
Post by: Hooman on November 13, 2015, 06:06:06 AM
From the thread I linked, the death fraction is:
workerDeathRemainder / (totalMedCenterCapacity + M_DIE_RATE)

Note that M_DIE_RATE is actually an inverse rate. A higher number means slower death rate. By increasing the med center capacting, or increasing the die "rate" (having higher morale), you slow the rate at which workers die.

There's a problem with this approach. If you have say 70 workers, so workerDeathRemainder increases by 70 each cycle, and your med center capacity is 70 (upgraded), then as long as you can activate an additional med center each turn, nobody dies. Once a person dies, idle all the med centers and repeat. That should give you extra workers and scientists to play with meanwhile. Granted, idling all the med centers affects morale, which is the other part of that fraction.


There are possibly other formulas that may work better. This was just an example. It's not overly complicated, and doesn't need to be.
Title: Re: OutpostHD - An Outpost Redesign
Post by: vomov on November 13, 2015, 07:07:38 AM
Get it now, thanks. Not sure if morale should actually influence death rate, though. Perhaps only below a certain level?

There are possibly other formulas that may work better. This was just an example. It's not overly complicated, and doesn't need to be.

There are problems with all approaches, but I'm a big fan of the simple ones. What's simple for us (easy to read/implement) is not always simple for the computer, or sometimes comes back to bite us in the tushy with unexpected complexity or weird border-cases (I created a solution for a data-problem four months ago, and I have been regretting it for the past four bug-hunting days). Here, the simplest solution seems to be to define population as a single number, and add modifiers to the 'progression to death' - variable. Morale would be similar, albeit a bit more complicated (i.e.: more modifiers).

Concerning possible exploits, I think not allowing certain buildings to shut down (was that in the original?) would be a good start on that.

On feedback: like in Outpost, there should be a 'master report' showing food, morale, population, and several other things, which should also show the 'percentage busy' for the medical centres and possibly also for the parcs/resevoirs and rec' centres, like the original did for the residential structures. A high 'percentage busy' should give some kind of feedback, like a news message, as well.

I had a question: the original had the news-button, which became active if there was a bit of news present. Perhaps a scrolling news ticker, news box with clickable items, or popup news messages might be better. I did a bit of a playthrough two days ago and only looked at the news around turn 100.
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on November 13, 2015, 11:35:36 PM
Quote from: vomov
I had a question: the original had the news-button, which became active if there was a bit of news present. Perhaps a scrolling news ticker, news box with clickable items, or popup news messages might be better. I did a bit of a playthrough two days ago and only looked at the news around turn 100.

The news items in the original game were... cute. Honestly, the more I analyze the game the more it's apparent that there was a breathtaking amount of hubris when developing the game. They spent more time with witty headlines for a virtual newspaper than they did programming the game. It's really quite amazing how much time the spent on little things.

Anyway, a news ticker is an interesting idea but it reminds me of SimCity 3000. I had thought about a news system similar to the original Outpost but with 'notifications' of some sort. Ultimately I think it's a lower priority and something to start thinking about later on during development.
Title: Re: OutpostHD - An Outpost Redesign
Post by: vomov on November 14, 2015, 01:35:13 AM
The original Outpost news system did give popups, but only sporadically give useful information (somebody dies every two turns in my 500+ colony; who cares?).
The news button tends to be ignored, but a notification might draw attention to it. Perhaps a simple blinking button for low-priority articles, while high-priority stuff uses a popup?

I've been doing a playthrough, and I agree on the news items. 'Funny' news articles about time travel on every load aside, I was mainly thinking about setting up a small system that watches out for certain situations occurring, like food dwindling, or power being insufficient. Of course, it can't do anything if the systems it's supposed to watch are not yet implemented :)

On another note; I've been exploring the research tree on my playthrough, and it feels that about 80% is either not implemented at all, or implemented in some weird hidden fashion, while the actual tree doesn't make sense at all. I'm not the only one thinking a severe revision would be appropriate, right?
Title: Re: OutpostHD - An Outpost Redesign
Post by: dave_erald on November 14, 2015, 09:02:44 AM
I wonder why maybe morale couldn't be used in more aspects of the game? Say for instance that at the extremes of the morale scale it starts to affect production times by a small percentage? And I wonder if there couldn't be a specific point at which morale stops trending to the extreme low, that once you have enough residential and medical centers that morale doesn't go to the lowest level, it could already be programmed that way I'm not sure, but that could be a tip or notification that pops up in your system once you start implementing things.

As far as the tech and research function of the game work, are you looking to reuse all the buildings the way they are and just rework how things work together or maybe start renaming buildings and starting from scratch?
Title: Re: OutpostHD - An Outpost Redesign
Post by: dave_erald on November 14, 2015, 09:04:10 AM
On a side note perhaps today or tomorrow I should download the game and play through to see how good or bad it is.
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on November 15, 2015, 08:09:20 PM
I intend for morale to affect a lot of things including production efficiency, procreation, health levels, research speed,etc.
Title: Re: OutpostHD - An Outpost Redesign
Post by: dave_erald on November 19, 2015, 03:31:12 PM
Sweet, functioning UI means playable?

And you were talking about updated graphics, so does that mean you need someone with graphics design experience?
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on November 20, 2015, 12:06:21 AM
It had a functional UI before, it just couldn't do much. The production UI now works so it adds gameplay to the game in addition to just plopping down buildings you can now also construct robots and use up all your resources in the process!

Work kind of got in the way the last few days so 0.5.0 hasn't been touched since Monday but after my 8 hour car trip tomorrow I'll be relaxing a lot during the weekend far, far away from work and during the evenings will have time to work on development.
Title: Re: OutpostHD - An Outpost Redesign
Post by: vomov on November 20, 2015, 05:19:12 AM
Nice!

Right now all resources are thrown into a single 'pool' right? How will you implement local (mine) vs. colony (storage tanks?) storage?
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on November 23, 2015, 12:05:23 PM
Yes, they're just added/subtracted from a 'pool'.

I've been giving that some thought and I think that it should be simple enough to continue with a 'pool' paradigm only with capacities and locations.

So the short answer is:

Some special case code.

The long answer:

Basically, mines would have their own caps on what they can store. Say a mine can store 500 units of ore, once it reaches 500 units it goes into an Idle state until something comes and takes units of ore out of its 'pool'. If ore is being pulled by a truck, the truck has so much capacity, say 25 units. It then dumps that off at a Smelter which has a fixed rate of processing so the Smelter would have two pools -- the raw ore and the processed ore. Though in reality we can probably just have the refined ore just be automagically added to regular storage.

The number of active storage tank structures would determine the capacity of storage for all of the processed materials. Like mines, I would say that this should just be X number of slots, say 500 units per storage tanks (or maybe in harder difficults 250 units). What's stored in them can be any combination of the common/rare ores. Food storage would probably stay within the Agridome's themselves so they would have enough room for say 100 units of food each.

Energy doesn't accumulate, it's just sum of all energy output from energy producing structures so that should be simple enough.
Title: Re: OutpostHD - An Outpost Redesign
Post by: vomov on November 23, 2015, 02:08:31 PM
Food and energy as colony-wide pools would be best, I agree.

In the original, storage tanks had their own pools, which is odd, now that I think about it.
A generalized pool would be good, but there is a potential issue: if mine yield is randomized per resource, then there is a risk of storage filling with materials of one kind, while there is not enough of another kind. Based on the exact handling and balancing of production and mining, this can get ugly fast. At some point there's going to be 80% filled with common ores, and 20% with common minerals, and no rare anything unless we throw some stuff away... The SPEW took care of that originally, by creating MPG (also known as Torgo's Ground Executive Powder).

Simply 'throwing away' resources above a certain threshold (Rare ore low, common mineral highest, so replace common mineral with rare ore?) is something I've seen before, but I'm not sure if that's a good idea... On the other hand, weird micro-management with the risk of building huge storage parcs is also not desirable.
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on December 19, 2015, 11:59:47 AM
Quote
A generalized pool would be good, but there is a potential issue: if mine yield is randomized per resource, then there is a risk of storage filling with materials of one kind, while there is not enough of another kind.

This is where balancing comes into play. Running the numbers through my head, I don't think this sort of situation would come up. At present, mines are randomly dispersed across the landing area and can have one of three yields: High, Medium and Low. These yields are not randomized (though difficulty ratings should have an effect on actual yields). The yeild determines the amount of resources produced by the mine per turn. I will be taking a page out of Outpost's book on this one and the digging depth determines how long a mine produces good results (after which it continues to produce at a very, very low yield).

In the current code a single medium yield mine produces enough ores of all types to operate a tiny colony. Expand that to two medium yield mines and you will have enough resources produced each turn to develop a colony at a relatively slow pace. It will need more balancing in the future but the numbers at the moment are working out okay.

Quote
Simply 'throwing away' resources above a certain threshold (Rare ore low, common mineral highest, so replace common mineral with rare ore?) is something I've seen before, but I'm not sure if that's a good idea...

It's not a good idea. In fact I'd go so far as to call it a terrible idea. With the way it's working presently and the way I intend to have resources handled at each Mine (which has its own pool), there will never be a need to 'throw away resources'. While a mine can store up to 500 units of whatever ores are produced, if the mine's resources are at say, 498, and in a turn more than this would be produced, the mine simply shuts itself down and stops production. Basically, if a resource pool is too small to handle incoming resources, the resources are outright rejected. In this way there is no loss of resources and a mine simply stops production.

Conversely, if a Smelter has too many raw resources in its resource pool and a truck has more resources than can fit in the Smelter's resource pool, the truck is forced to simply wait for enough room to be made. If storage tanks are at their capacity, then the whole resource production cycle effectively gets halted as the mines fill up and shut down and the Smelter has more resources than it can handle.

It's a somewhat complex process internally that I need to really map out well but I at least have the general idea of how it should work.
Title: Re: OutpostHD - An Outpost Redesign
Post by: vomov on December 21, 2015, 04:39:43 AM
You mean that the yields will be randomized to make people search for a mine with proper ratios, but not too randomized so people won't get stuck building huge storage parcs? Some minor balancing aside, that should work well.

To help people find out which resources they need, perhaps a simple 'balance sheet' showing input, storage, and usage would be very helpful. Perhaps also a small spreadsheet showing all mines and their yield? If something is wrong (mine produces more than trucks can carry, smelter full, etc.), a small exclamation mark to draw attention to it should be enough. I don't remember which game, but there was one that had several buttons related to certain parts of a production flow, and if there was something wrong, the button itself would blink with an exclamation mark.

I like the 'very very low yield', as it prevents a colony from locking up completely.
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on December 24, 2015, 12:05:51 AM
Quote
To help people find out which resources they need, perhaps a simple 'balance sheet' showing input, storage, and usage would be very helpful.

Agreed. I planned on something like this which is pulled up via the GUI. I haven't decided if it's through a 'master report' like interface like the original game had (I don't like this) or via the resource UI which I started to add. One thing I liked in Civ5 is that resources show you exactly what you're getting (+/- each turn). I want to do something like that with the UI so the user can have a general feel for what they're looking at and then they can click on it or right click on it to bring up a UI window with much more detailed results (including what raw resources they're getting, from where, and additional information including the production at individual mines and smelters).

At the moment it's overly simplified and it results in some weird numbers showing up. I need to clean up the resource processing each turn but I haven't yet come up with a good solution. Means I don't have a good grasp of the problem itself so it's time to go back to the drawing board so I can reimplement a cleaner solution.
Title: Re: OutpostHD - An Outpost Redesign
Post by: vomov on January 11, 2016, 05:12:35 AM
I saw you were working on the resource management, and I'm curious on your current plan. The 'Update the way the player's usable resources are handled'-task denotes a problem with complexity, but no preferred solution.

Some questions:
- As I understand it, Agridomes store their own food, which means every Agridome - object has its own counter and behaviour. This is similar to the original, but I'm not sure why this isn't done with a global counter.
- On storage of resources (and later items in warehouses); the original did that per object. That is the plan, I gather, but I wouldn't have the faintest on how an implementation would look like.
- In the original, I would build a tokamak and forget about my energy needs. Energy was implemented, right?

The master report was a bit odd, but it could be made useful. General stuff can be put in a single small window (mini report) that shows the bare basics. Energy, food, and air shouldn't need te be monitored during the game; three dots saying 'enough air', 'enough power', and 'we're producing more food than we need' should be enough. If we're near the limits, those dot could become orange, suggesting a need for something to change.

Clicking on the mini report can open up a bigger version (master report), or bring up separate windows. For example, clicking on the population number can open up a window showing the ages and jobs, and clicking on the energy counter tells us we're getting 10% from solar, and 90% from a Tokamak. The original was heavily limited by the screen resolution of the time, nowadays it's not that much of an issue anymore. Putting all resources somewhere might create quite a bit of clutter, though.
Title: Re: OutpostHD - An Outpost Redesign
Post by: Hooman on January 11, 2016, 08:29:51 AM
Quote
I saw you were working on the resource management, and I'm curious on your current plan. The 'Update the way the player's usable resources are handled'-task denotes a problem with complexity, but no preferred solution.
I really like how you brought that up.

Quote
- As I understand it, Agridomes store their own food, which means every Agridome - object has its own counter and behaviour. This is similar to the original, but I'm not sure why this isn't done with a global counter.
I'm used to the Outpost 2 way of storing food using a global counter. I never even considered it this way. In a way it almost makes more sense to have food stored at agridomes, and potentially losing it if the agridome is destroyed. That may be why it wasn't implemented that way though, since Outpost 2 needed to support land rush games where there is no agridome.
Title: Re: OutpostHD - An Outpost Redesign
Post by: vomov on January 11, 2016, 09:17:38 AM
I really like how you brought that up.
Not good?

... potentially losing it if the agridome is destroyed.
Ah, that's what I was missing! Implementing disasters would mean you'd need to put the hot lab and tokamak away from everything else.
Title: Re: OutpostHD - An Outpost Redesign
Post by: Hooman on January 11, 2016, 12:46:14 PM
Quote
Not good?
It was good. It was basically: hey, you said you were going to work on something vague. What are the specifics?
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on January 11, 2016, 10:34:07 PM
I saw you were working on the resource management, and I'm curious on your current plan. The 'Update the way the player's usable resources are handled'-task denotes a problem with complexity, but no preferred solution.

Note this in the task description:

Quote
TODO:

Finish fleshing out this thought and create tasks revolving around this problem.

Basically, I started defining the task and ran out of time and steam and had to get to bed for work in the morning.

Part of the problem is that I don't have a good grasp of the actual problem. I haven't fully worked it out in my head but it comes down to one thing; my current implementation is far too simple and worked while I was just starting the game development but it's time to provide a more sophisticated approach to it. I'm too tired tonight to finish 'fleshing out my thoughts' so I probably won't be updating it until tomorrow sometime in the afternoon.

Quote
As I understand it, Agridomes store their own food, which means every Agridome - object has its own counter and behaviour. This is similar to the original, but I'm not sure why this isn't done with a global counter.

Because it's easier to use the internally built objects to manage all of this instead of global counters. I never liked global counters and it doesn't fit the simulation model specified by the original game. Hooman touches on one of the reasons I went with this approach:

Quote from: Hooman
In a way it almost makes more sense to have food stored at agridomes, and potentially losing it if the agridome is destroyed.

Bingo. This is why I went with this design. If you don't manage your structures properly and a structure that contains perishable storage goes inactive for one reason or another, you very well could lose all of that resource. You could even consider regular storage tanks to have 'perishable storage' such that if one was disabled the seals on the containers could leak leading to corrosion and deterioration of the stored resources.

Bulldozing a structure would be handled a little differently (this is where a global counter would make sense); Resources stored within the structure would be pushed into other like structures and whatever remains would effectively be lost. Kinda sucks but that's the way it works in real-life too.

*** Quick though while it's on my mind, if a Storage Tanks structure was destroyed during a disaster, bulldozing its remains should probably provide a higher level of resources than an empty Storage Tanks due to whatever remains of its stored resources could be scavenged. ***

Quote
On storage of resources (and later items in warehouses); the original did that per object. That is the plan, I gather, but I wouldn't have the faintest on how an implementation would look like.

This is the plan. Without going into too much detail, suffice it to say that at least for resources, I use an object that defines a number of resource types. This object can act as either a simple container (e.g., to pass along construction, manufacturing and recycling values as well as required input resources) and can act as a storage container with push/pull functions (e.g., pushing resources into the container and pulling resources from it). These storage management function check the given capacity of said container and will only allow so many resource in.

By using these resource objects within certain structures, implementation is fairly trivial. The logic is contained within the structure itself on what resources get pushed/pulled from storage and the resource objects themselves handle push/pull requests.

Quote
In the original, I would build a tokamak and forget about my energy needs. Energy was implemented, right?

Pretty much. At this point the only energy provided is the meager 50 units by the SEED Power Facility. I haven't yet implemented the Tokamak. I'm not sure exactly when I will but probably after I get the storage situation finished and cleaned up.

Quote
The master report was a bit odd, but it could be made useful.

This is true, but simply cloning it and improving it to me is a waste of time. Why fix something that's badly designed when you can redesign something superior? I'm not a great UI designer by any stretch so any thoughts on this front would be helpful especially any mockups. Keeping in mind that I want to kind of stray away from the modified Windows 3.1 GUI approach.

Title: Re: OutpostHD - An Outpost Redesign
Post by: Galactic on January 20, 2016, 01:50:33 PM
Looking good so far, keep up the good work.
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on January 22, 2016, 08:38:47 AM
For those of you who don't want to download the game yet because it's technically not 'playable', here's a short video demonstrating some of the various aspects of the game.

Title: Re: OutpostHD - An Outpost Redesign
Post by: Vagabond on January 22, 2016, 12:43:46 PM
Leeor,

I'm excited about this project. I enjoyed playing through Outpost 1.5 a few times years ago.

Glad to see the progress and nice video.
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on January 22, 2016, 05:01:48 PM
Thank ya!

I'm not sure how to upload in higher resolution... perhaps I just need to set it to full screen and record it that way.

Still pushing a long. The last few weeks have been exhausting at work so I've pushed it to the back burner because of how tired I've been but I have a weekend coming up and then 6 days off from work so I hope to have storage and resource management figured out and probably saving/loading figured out by next the end of next week.

After that it's truck routing and research trees!

Hooman, if you're up for it maybe you could help me figure out some math for the population model? I keep going back to a full-blown population simulation and that seems like total overkill for this game.
Title: Re: OutpostHD - An Outpost Redesign
Post by: Charles_Bronson on December 14, 2016, 01:58:22 PM
thats good progress! Really nice work done!
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on December 14, 2016, 02:45:37 PM
Thanks! Been at it for a year and have a lot to show for myself. Goof has been super helpful too especially with developing a lot of the structures. Would feel very bare without his help.

BTW, I see it's been what, almost 8 years since you posted last? Welcome back!
Title: Re: OutpostHD - An Outpost Redesign
Post by: lhark on June 10, 2017, 11:23:45 PM
Hello everyone, i just discovered this forum and the outpostHD project.
Outpost has a big place in my childhood memories and it warms my heart to see people are still passionate about it :)

Anyways, being a big free software supporter, i tried (and succeeded) building OutpostHD and it's underlying API NAS2D on linux.
It runs reasonably well after a few bugfixes.

I've already submitted a pull-request on github for NAS2D, but i don't know to do the same with the OutpostHD svn repo :/
Do i need to provide a patchfile ? do i get push access to the repo ? to a feature branch ?
I must confess i'm not that familiar with svn.

Once again, thank you for the great work you put into this project :)
Title: Re: OutpostHD - An Outpost Redesign
Post by: Vagabond on June 11, 2017, 12:40:35 AM
Ihark,

The repository is read only until an admin like leeor_net gives you write access. Just keeps people from making a mess of it. It sounds like you already found the repo location to download the source code.

We have some limited, basic info on Subversion in the wiki here: http://wiki.outpost2.net/doku.php?id=opu:repository.

I'm glad to hear the code compiled without too much difficulty on Linux.

-Brett
Title: Re: OutpostHD - An Outpost Redesign
Post by: lhark on June 11, 2017, 11:53:57 PM
Thankks for the answer :)

I guess I'll wait for an answer by leeor_net then.

By the way I also updated OutpostHD to NAS2D v1.4.2 (that had absolutely nothing to do with me not realising
that outposthd was not using the last release when I started ^^).

EDIT : In fact the only part that wasn't already v1.4.2-compatible was ui_builder which is not really part of the game
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on June 13, 2017, 10:22:57 PM
I actually don't have admin access to the SVN -- that's something Leviathan handles (can get a hold of him via IRC).

If you'd like you can submit a patch file for OutpostHD via PM (or send me a message if it won't allow you to attach the file(s) and I'll give you my e-mail address).

Will look at the pull request for NAS2D -- I've been visiting my parents in NJ for the last few days so I've been unable to do a whole lot with it.

And thank you for taking care of the Linux parts! I don't have a linux installation but when I was building The Legend of Mazzeroth (LoM, as in the code base for the file system) the base code worked well.

Once you get write access to the SVN from Leviathan, if you're interested in poking around the OutpostHD code, by all means! I could use a bit of help -- I was starting to work on it again last week but ended up being contracted to build some tooling for a new project so I had to put it down.

Anyway, plan over the next couple of weeks is to implement population requirements check and then move on to the product production and storage implentation. See the Redmine roadmap for the general plan.

Thanks for updating to the latest version of NAS2D! I never got around to it.

I kinda forgot about UI_Builder after I realized I'd have to build a lot more than really cared to do at the time. I should pick that project back up and just build the layout interpreter file and just make my life a lot easier. UI coding can be miserable -_-
Title: Re: OutpostHD - An Outpost Redesign
Post by: Hooman on June 25, 2017, 01:17:49 PM
I just tried compiling the source on Linux and got the following errors:
Code: [Select]
outposthd$ make
/bin/sh: 2: [: src/Map/: unexpected operator
/bin/sh: 2: [: src/Map/: unexpected operator
/bin/sh: 2: [: src/: unexpected operator
/bin/sh: 2: [: src/: unexpected operator
/bin/sh: 2: [: src/: unexpected operator
/bin/sh: 2: [: src/: unexpected operator
/bin/sh: 2: [: src/: unexpected operator
/bin/sh: 2: [: src/Things/Structures/: unexpected operator
/bin/sh: 2: [: src/Things/Structures/: unexpected operator
/bin/sh: 2: [: src/Things/Robots/: unexpected operator
/bin/sh: 2: [: src/: unexpected operator
/bin/sh: 2: [: src/: unexpected operator
/bin/sh: 2: [: src/UI/: unexpected operator
/bin/sh: 2: [: src/UI/Core/: unexpected operator
/bin/sh: 2: [: src/UI/Core/: unexpected operator
/bin/sh: 2: [: src/UI/Core/: unexpected operator
/bin/sh: 2: [: src/UI/Core/: unexpected operator
/bin/sh: 2: [: src/UI/Core/: unexpected operator
/bin/sh: 2: [: src/UI/Core/: unexpected operator
/bin/sh: 2: [: src/UI/Core/: unexpected operator
/bin/sh: 2: [: src/UI/Core/: unexpected operator
/bin/sh: 2: [: src/UI/: unexpected operator
/bin/sh: 2: [: src/UI/: unexpected operator
/bin/sh: 2: [: src/UI/: unexpected operator
/bin/sh: 2: [: src/UI/: unexpected operator
/bin/sh: 2: [: src/UI/: unexpected operator
/bin/sh: 2: [: src/UI/: unexpected operator
/bin/sh: 2: [: src/UI/: unexpected operator
/bin/sh: 2: [: src/UI/: unexpected operator
/bin/sh: 2: [: src/States/: unexpected operator
/bin/sh: 2: [: src/States/: unexpected operator
/bin/sh: 2: [: src/States/: unexpected operator
/bin/sh: 2: [: src/States/: unexpected operator
/bin/sh: 2: [: src/States/: unexpected operator
/bin/sh: 2: [: src/: unexpected operator
/bin/sh: 2: [: src/: unexpected operator
/bin/sh: 2: [: src/: unexpected operator
/bin/sh: 2: [: src/Population/: unexpected operator
/bin/sh: 2: [: src/: unexpected operator
make: *** No rule to make target 'API/NAS2D/lib/libnas2d.a', needed by 'bin/OPHD'.  Stop.
Title: Re: OutpostHD - An Outpost Redesign
Post by: lhark on June 25, 2017, 10:59:25 PM
Ok, that's weird, I can only reproduce half of your problem. On the last line it complains about a missing library and is right about it : leeor_net forgot to include it with the rest of my patch.

If you want, you can compile the missing library yourself leeor_net accepted my pull request for https://github.com/lhark/nas2d-core.

As for the other problems, I can only that my shell scripting wasn't fully POSIX compliant :/

Maybe try the following fix on line 24 of the Makefile

-   if [ "$${dirs#*ui_builder/}" == "$$dirs" ]; \
+   if [ "$${dirs#*ui_builder/}" = "$$dirs" ]; \

Also, leeor_net, you should have a look at line 436 in src/States/GameState.cpp, I think you have a bug : the string sLevel becomes SLevels at one point without any new declaration.
Title: Re: OutpostHD - An Outpost Redesign
Post by: Hooman on June 26, 2017, 03:17:03 AM
Thanks, removing one of the equal signs solved that problem.

I needed to install the SDL2 dependency (using Ubuntu):
Code: [Select]
sudo apt install libsdl2-dev

I also needed to add the "-std=c++11" flag to CFLAGS in the Makefile:
Code: [Select]
-CFLAGS         =       -g -Wall -I./API/NAS2D/include `sdl-config --cflags`
+CFLAGS         =       -std=c++11 -g -Wall -I./API/NAS2D/include `sdl-config --cflags`
That removed a ton of errors and warnings about "nullptr".

I see a few errors about "sLevels", as stated above. I renamed the occurrences to "sLevel" just to see if it would compile. No other compile errors, though lots of warnings about non-void functions having no return statement (they are dummy stubs), and a few typedefs being locally defined but unused.

And of course the error stated above was still present:
Code: [Select]
make: *** No rule to make target 'API/NAS2D/lib/libnas2d.a', needed by 'bin/OPHD'.  Stop.
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on June 26, 2017, 01:23:52 PM
Also, leeor_net, you should have a look at line 436 in src/States/GameState.cpp, I think you have a bug : the string sLevel becomes SLevels at one point without any new declaration.

Seems to be an artifact of merging some changes. Have to admit, I'm finding Git to be far better at merging than SVN.

I'm also seeing that the code itself is wrong, again probably due to changes made between several commits between me and Goof.
Title: Re: OutpostHD - An Outpost Redesign
Post by: lhark on June 28, 2017, 01:14:25 AM
I would also be in favor of a migration from SVN to git, but I don't think my voice is worth anything yet^^

About the makefile, I completly rewrote it in order to have some dependency management: before, if you where to change just one header file,
the whole project would basically need to be rebuilt. I did a single test with GameState.h and got a five fold improvement on the build speed :

Code: [Select]
new makefile: make                  6.31s  user 0.44s system 99% cpu 6.747 total
old makefile: make -f Makefile.old  32.60s user 2.31s system 99% cpu 34.920 total

I also needed to add the "-std=c++11" flag to CFLAGS in the Makefile:
Code: [Select]
-CFLAGS         =       -g -Wall -I./API/NAS2D/include `sdl-config --cflags`
+CFLAGS         =       -std=c++11 -g -Wall -I./API/NAS2D/include `sdl-config --cflags`
That removed a ton of errors and warnings about "nullptr".
Thank you for the tip, I didn't really focus on reducing the volume of warnings ^^

By the way, is there an easier way for me to push this modification now that I have access to the redmine ?
Title: Re: OutpostHD - An Outpost Redesign
Post by: Hooman on June 29, 2017, 01:20:25 PM
Nice job on the compile time improvements. That's a huge win for iterative development.

I think the "nullptr" issue led to actual errors since they were showing up as undefined identifiers before. Though some messages were warnings. Different systems might have different default language standards.


Slightly unrelated, but I use git-svn so I can download the changes into a git repository and work with the code using git. Using git at the source could simplify that slightly.
Title: Re: OutpostHD - An Outpost Redesign
Post by: Goof on July 08, 2017, 07:06:53 AM
Also, leeor_net, you should have a look at line 436 in src/States/GameState.cpp, I think you have a bug : the string sLevel becomes SLevels at one point without any new declaration.

Seems to be an artifact of merging some changes. Have to admit, I'm finding Git to be far better at merging than SVN.

I'm also seeing that the code itself is wrong, again probably due to changes made between several commits between me and Goof.

Yes it seems to be a merge mistake.
R228 was good with the new code and R229 was messy with part of the old code.
It should be right on live SVN version now.

I also add the navigation thru depth levels with First / End / Page Up / Page Down  keys.
Since, for me, it seems to be obvious shortcuts.
Title: Re: OutpostHD - An Outpost Redesign
Post by: Hooman on July 10, 2017, 12:39:27 AM
I made another attempt to compile things on Ubuntu. Seems a few more updates are needed.

I pushed the changes to the Makefile for the = versus == POSIX compliance thing, and added the -std=c++11 flag.

I found additional dependencies needed to be installed outside of just the core SDL2 library. The core SDL library (libsdl2-dev) is needed for the sdl-config utility used in the Makefile. Additionally, other libraries are needed by the compiler. The full install set for OutpostHD is:
Code: [Select]
sudo apt install libsdl2-dev libsdl2-image-dev libsdl2-mixer-dev libsdl2-ttf-dev libphysfs-dev libglew-dev

I'm thinking a rule could be added to the Makefile to install these.

I looked into removing some of the warnings. It looks like there are attempts at compile time errors within templates using the familiar negative array index hack. I'm thinking this should be changed to the new static_assert introduced in c++11. Here's an example:
Code: [Select]
-       typedef int ERROR_CantUseHorrible_cast[sizeof(InputClass) == sizeof(u) && sizeof(InputClass) == sizeof(OutputClass) ? 1 : -1];
+       static_assert(sizeof(InputClass) != sizeof(u) || sizeof(InputClass) != sizeof(OutputClass), "Can't use horrible cast");
Note the negated condition. The code with the negative array index hack gives the condition for passing the check, rather than failing the check. The conditions would need to be rewritten as if the "1 : -1" was reversed to "-1 : 1".

There was one odd example I'm not so sure about:
Code: [Select]
-               typedef char ERROR_Unsupported_member_function_pointer_on_this_compiler[N-100];
+               static_assert(N < 100, "Unsupported member function pointer on this compiler");
What is going on with that check against 100? Seems like a hack. What is it doing, and is there a better way to do that?

I noticed a few sections of code similar to the following:
Code: [Select]
	AiVoiceNotifier() {}; // Explicitely Declared Private
AiVoiceNotifier(const AiVoiceNotifier&) {}; // Explicitely Declared Private
AiVoiceNotifier& operator=(const AiVoiceNotifier&) {}; // Explicitely Declared Private
The operator= caused warnings due to no return value from a non-void function. Removing the "{}" removed the warning. It's not called, so not having a body won't produce an error. But this gets more to the heart of the idiom used here. As the function is explicitly being declared private to prevent its use, it would be more clear to use the "= deleted;" syntax introduced in c++11. This would apply to all 3 methods as well, and would give more clear intent.

Another missing return from a non-void function was:
Code: [Select]
int incrementFuelCellAge() { mFuelCellAge++; }
I'm thinking just change the return type to void. I don't think it needs to return a value. I also noticed it's not called anywhere. Another thought, should the return value actually be desired, it might make more sense to use the pre-increment operator: "return ++mFuelCellAge;". That would return the value after the increment, rather than what the value was before the increment.


It took me a while to realize NAS2D was a separate download. The folder in OutpostHD is really just the development headers. This of course means a new set of challenges.

The Makefile for NAS2D also needed to have the "-std=c++11" flag set.

I needed to install another library:
Code: [Select]
sudo apt install glee-dev

There was one include I needed to update in src/Renderer/OGL_Renderer.cpp:
Code: [Select]
-#include "SDL_image.h"
+#include "SDL2/SDL_image.h"

I still get some errors with NAS2D in src/Renderer/OGL_Renderer.cpp:
Code: [Select]
src/Renderer/OGL_Renderer.cpp: In member function ‘virtual void NAS2D::OGL_Renderer::fullscreen(bool, bool)’:
src/Renderer/OGL_Renderer.cpp:494:44: error: ‘SDL_SetWindowResizable’ was not declared in this scope
   SDL_SetWindowResizable(_WINDOW, SDL_FALSE);
                                            ^
src/Renderer/OGL_Renderer.cpp: In member function ‘virtual void NAS2D::OGL_Renderer::resizeable(bool)’:
src/Renderer/OGL_Renderer.cpp:518:59: error: ‘SDL_SetWindowResizable’ was not declared in this scope
  SDL_SetWindowResizable(_WINDOW, static_cast<SDL_bool>(_r));
                                                           ^
Makefile:22: recipe for target 'obj/Renderer/OGL_Renderer.o' failed

According to the SDL docs:
Quote
This function is available since SDL 2.0.5.

According to the output of apt install:
Code: [Select]
libsdl2-dev is already the newest version (2.0.4+dfsg1-2ubuntu2).

Looks like the packages available for Ubuntu are too old to contain this function.

I'm stopping here for now.
Title: Re: OutpostHD - An Outpost Redesign
Post by: lhark on July 10, 2017, 01:38:43 AM
Wow, very nice and in depth test.

Sorry about the dependency, I didn't write them down anywhere, and it wouldn't have been usefull to you anyway as I'm running archlinux.
However, I don't think that adding the dependency install to the makefile is a good practice or even a good idea. You would need to support
all the different packet managers that are out there (apt, pacman, yum to cite just a few of them).

I reckon a better idea would be mentionning that in the README.

About NAS2D, theorically, if we ship libnas2d.a with the rest of the windows libraries, it should work. But seeing as it's only compiled for
amd64 right now, that wouldn't be really portable.

As for the include in NAS2D/src/Renderer/OGL_Renderer.cpp, I didn't get any issue with it.
It might have something to do with the fact I have both versions of the SDL installed on my machine though.
Title: Re: OutpostHD - An Outpost Redesign
Post by: Hooman on July 10, 2017, 03:31:24 AM
Quote
As for the include in NAS2D/src/Renderer/OGL_Renderer.cpp, I didn't get any issue with it.
It might have something to do with the fact I have both versions of the SDL installed on my machine though.

Ahh, that could be it. Interesting, if there is a mixed version compile happening. I mentioned it precisely because I thought it was odd nobody else had a problem. I figured there must be some configuration where that header file worked, and if I changed it, I might break someone else's setup on another platform.

Well, I suppose one way to find out, is to "fix" it, and see if anybody complains. ;)

Though now that I check, I also have libsdl-dev installed, which is version 1.2.15. Perhaps one of the other packages is involved, or it is a platform difference.

Quote
Sorry about the dependency, I didn't write them down anywhere, and it wouldn't have been usefull to you anyway as I'm running archlinux.
However, I don't think that adding the dependency install to the makefile is a good practice or even a good idea. You would need to support
all the different packet managers that are out there (apt, pacman, yum to cite just a few of them).

I reckon a better idea would be mentionning that in the README.
I was wondering what version of Linux you used.

I was also thinking the package names will differ by platform, as will the package manager. Still, I think dependency installation can still make sense in a Makefile as an independent rule, similar to the .PHONY rule for "clean". Perhaps a rule name "install-deps-ubuntu". Could throw in a rule for Arch Linux too.

The rules might not work for everyone, but I figure it's just as easy to add a Makefile rule as it is to document that in a readme, and for the few people that it helps, it's quite a convenience.

Might even be possible to have a generic "install-deps" rule that detects the distro and passes control to the right place.


Hey leeor_net, how come NAS2D is up on GitHub, while OutpostHD is hosted on the OPU SVN server?
Title: Re: OutpostHD - An Outpost Redesign
Post by: Hooman on July 13, 2017, 10:46:27 PM
Why does NAD2D use both GLee and Glew? From what I understand, they are both OpenGL extension loader libraries. They seem to do the same thing. Indeed, I've read that although you can use both in the same project, you can't include both headers from the same compilation unit.

I've also found a few places that suggest GLee is no longer maintained, and hasn't been in years. Of note is the open bug on the GLee SourceForge project page (https://sourceforge.net/p/glee/bugs/5/), which never got a reply:
Quote
We're going to be restructuring the SDK area of www.opengl.org and, since glee is listed there, wanted to ask what the current state of the project is, and if it should continue to be listed as a current resource. The sourceforge project seems pretty dead by casual inspection.

The use of GLee seems to be restricted to: src/Resources/Shader.cpp
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on July 18, 2017, 10:37:21 AM
It's not supposed to. I originally used GLEE but after that was discontinued I switched to GLEW. Anything from GLEE can be considered legacy and removed.

As a note, Shader.cpp contains... very old code that hasn't been updated in a long time. But, since I've learned a lot more about shaders I'm probably going to start updating that again soon.

Anyway, in the mean time GLEE references can be killed.
Title: Re: OutpostHD - An Outpost Redesign
Post by: Hooman on July 21, 2017, 03:53:19 AM
Question for lhark:
How come you used .PRECIOUS in the makefile? Is there a reason to use this over .SECONDARY?
Code: [Select]
$(DEPDIR)/%.d: ;
.PRECIOUS: $(DEPDIR)/%.d

I read the GNU Make special targets (https://www.gnu.org/software/make/manual/html_node/Special-Targets.html) page:
Quote
.PRECIOUS
The targets which .PRECIOUS depends on are given the following special treatment: if make is killed or interrupted during the execution of their recipes, the target is not deleted. See Interrupting or Killing make. Also, if the target is an intermediate file, it will not be deleted after it is no longer needed, as is normally done. See Chains of Implicit Rules. In this latter respect it overlaps with the .SECONDARY special target.

You can also list the target pattern of an implicit rule (such as ‘%.o’) as a prerequisite file of the special target .PRECIOUS to preserve intermediate files created by rules whose target patterns match that file’s name.

...

.SECONDARY
The targets which .SECONDARY depends on are treated as intermediate files, except that they are never automatically deleted. See Chains of Implicit Rules.

.SECONDARY with no prerequisites causes all targets to be treated as secondary (i.e., no target is removed because it is considered intermediate).


On another topic, I read somewhere that #include lines should omit the "SDL2" directory, and instead add a -I flag to include the SDL2 directory in the include search path. The main reasoning seems to be different install paths and hierarchies on different platforms, or with different setups, such as using a local install rather than a system install. By keeping that out of the source, and in the makefile, it's supposed to make it easier to compile in different environments.

Personally I feel the suggestion to omit directory names is a bit backwards from most other languages. Most other languages have a defined directory layout for packages, and a mapping between package imports and their directory. Having the package/directory in the source makes it very clear what version you're expecting, and makes sure you don't accidentally grab the wrong import.

In this case, specifying "SDL2/SDL.h" rather than just "SDL.h" ensures you're compiling against version 2, and not against version 1. However, there seems to be a lack of a well defined standard in C++ about where package header files go. Indeed, the current source files have a number of platform specific defines to include the right header files. Perhaps the includes should be normalized to not include the directory name, and the build scripts updated to include the necessary include directories? If done correctly, a lot of the platform specific checks could be eliminated.
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on July 21, 2017, 06:47:12 AM
As a side note, I've since updated NAS2D -- fixed a bug in one function that Goof pointed out and I've also commented out all of the shader code.
Title: Re: OutpostHD - An Outpost Redesign
Post by: havkyp on July 29, 2017, 07:14:21 PM
Just wanted to say a huge THANK YOU to you for developing OutpostHD!!! I signed up for this forum specifically to express this. :D

I played the original Outpost 1.5 to death back in the day trying to find all of those missing features thinking they were there somewhere... :p

I'm especially glad that you're making OutpostHD fully open source, this is essential for ensuring its historical heritage and for others to learn from and build on it. BTW what's its license? GPLv3?

Anyway, in addition to the huge thank you, what are some ways to support OutpostHD's development? Unfortunately I'm not a programmer. Do you accept donations or have other ways to help? Let's make this work. Thanks!!
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on July 29, 2017, 08:14:41 PM
Just wanted to say a huge THANK YOU to you for developing OutpostHD!!! I signed up for this forum specifically to express this. :D

Thanks for stopping by! It's good to know people are as excited about this project as I and the other developers are. :)

I'm especially glad that you're making OutpostHD fully open source, this is essential for ensuring its historical heritage and for others to learn from and build on it. BTW what's its license? GPLv3?

No, no no no! I do not like the GPL! I have it under a much more permissive BSD 3-Clause license. See LICENSE.txt in the distributions.

And that's why I made it open source. I could have kept it closed source but the only projects along these lines that seem to survive and progress into anything (OpenTTD, CorsixTH, Caesaria and many others) are all open source. The closed source ones seem to fizzle out and die over time.

Anyway, in addition to the huge thank you, what are some ways to support OutpostHD's development? Unfortunately I'm not a programmer. Do you accept donations or have other ways to help? Let's make this work. Thanks!!

Donations would be nice but I'm not sure I'd feel comfortable accepting them as I'm not the only developer.

Non-programmers can be extremely helpful. On the first post I have this section:

Quote
User Interface
I’m terrible at UI design. I can do the programming but the design itself is not my strong suit. I really need help designing a good UI that’s functional, looks good and is intuitive. Any help here would be much appreciated.

Effectively what I need are UI mockups with details about how the different elements work. The basic UI in the game right now is functional but pretty bare.

If you're up for some wireframing I'd be grateful. I'm just genuinely bad when it comes to UI design -- the few windows you see in game are mostly my doing though Goof and others have helped in developing other parts of the UI (e.g., the bottom ribbon). So any thoughts there are most welcome -- though in a separate thread! :D

Other ways to help:

Play the releases, find issues, spread the word.
Title: Re: OutpostHD - An Outpost Redesign
Post by: Hooman on July 31, 2017, 12:03:05 AM
Quote
Donations would be nice but I'm not sure I'd feel comfortable accepting them as I'm not the only developer.

Leeor, you're too nice.

He could probably use a donation :p
Title: Re: OutpostHD - An Outpost Redesign
Post by: havkyp on July 31, 2017, 01:38:56 PM
No, no no no! I do not like the GPL! I have it under a much more permissive BSD 3-Clause license. See LICENSE.txt in the distributions.

Great!! BSD license is good, too. Sorry I didn't see the LICENSE.txt during my initial short look.

And that's why I made it open source. I could have kept it closed source but the only projects along these lines that seem to survive and progress into anything (OpenTTD, CorsixTH, Caesaria and many others) are all open source. The closed source ones seem to fizzle out and die over time.

I agree. For the sake of history and continuation of culture I strongly believe efforts like this should be free (as in freedom). And even if one wanted to make money, it is still possible with open source anyway.

Donations would be nice but I'm not sure I'd feel comfortable accepting them as I'm not the only developer.

I agree with @Hooman that you should still get some donations. So let me know if and how I can donate, and I'll be happy to donate to other developers, too if that will mean the game getting to 1.0 sooner! :)

Quote
User Interface
I’m terrible at UI design. I can do the programming but the design itself is not my strong suit. I really need help designing a good UI that’s functional, looks good and is intuitive. Any help here would be much appreciated.

Effectively what I need are UI mockups with details about how the different elements work. The basic UI in the game right now is functional but pretty bare.

If you're up for some wireframing I'd be grateful. I'm just genuinely bad when it comes to UI design -- the few windows you see in game are mostly my doing though Goof and others have helped in developing other parts of the UI (e.g., the bottom ribbon). So any thoughts there are most welcome -- though in a separate thread! :D

Good point. I'll download and try to play around a bit more. I already have some thoughts on UI so will make a list and let you know with suggestions! And I'll do my best to mock up some things though I only know Inkscape and not professional wireframing... Is that still useful????

Thanks a lot again for making this game. I'll do my best to give constructive feedback, and please keep up the amazing work!! :D
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on July 31, 2017, 10:07:59 PM
Good point. I'll download and try to play around a bit more. I already have some thoughts on UI so will make a list and let you know with suggestions! And I'll do my best to mock up some things though I only know Inkscape and not professional wireframing... Is that still useful????

Inkscape drawings would be very useful. There are free online tools that can be used as well including Moqups (https://moqups.com/) and draw.io (https://www.draw.io/). Draw.io tends to be more suited toward flowchart design but it can be used for wireframing as well... plus it has excellent integration with Google Docs which means easy sharing of documents.

Moqups is tailored specifically toward UI wireframing but it's technically not free. It has a 'trial' mode but I don't know exactly what the limitations are. Something along the lines of 1 project, 300 layouts and 5mbs of storage or some such. I've used it without signing in, coming up with whatever and then saving an image. With a free account you can save but I don't know where else it goes from there.

There may be other good online wireframing tools as well but these are the two I've actually used and have had good experiences with.

Thanks a lot again for making this game. I'll do my best to give constructive feedback, and please keep up the amazing work!! :D

Thanks for your feedback! Knowing that end users are finding and getting excited about this project helps me to continue development.
Title: Re: OutpostHD - An Outpost Redesign
Post by: Hooman on August 03, 2017, 04:13:43 AM
Quote
Good point. I'll download and try to play around a bit more. I already have some thoughts on UI so will make a list and let you know with suggestions! And I'll do my best to mock up some things though I only know Inkscape and not professional wireframing... Is that still useful?

There are many times where I wished I had some Inkscape skills. Those sorts of tools could be very useful.
Title: Re: OutpostHD - An Outpost Redesign
Post by: Goof on August 03, 2017, 06:55:58 AM
I do use Inkscape a lot for technical stuffs.
I'm not an artist, so i use it basicly at work to re/make clients logos, some layout, sketches, ....
But as SVG is basically XML files I used that to generate raffle tickets with a small program to add the counter on the SVG base file and print them.

Last time it was for the Slider control skin for OPHD.
I figured out how to make Inkscape Slice a picture like in Photoshop.
(one file for each part of the skin, named directly out of Inkscape).
It's a very easy in fact but you have to know the trick.
Title: Re: OutpostHD - An Outpost Redesign
Post by: JetMech1999 on October 15, 2017, 05:45:13 PM
I was looking through the posts for the answers to my questions, but couldn't find anything.  So, if I'm bringing these items up that have already been addressed, my apologies.

1. Multiple colonies on the same planet.  Is this something that will be put into the new rendition?  That would really kind of make the "Trade" idea work.

2. Upon development of a space program, will the launch of a colony ship end the game?  Or will it continue?  Any chance of multiple interplanetary colonies?  As if trying to manage one colony wasn't enough, managing colonies on other planets would make life really interesting.  Since the initial research would have been accomplished on the first colony, research on other colonies would primarily focus on making their new home more habitable.  Or maybe have another "rebel" group make off with some people and equipment and have to start from scratch themselves.

3.  Would research move into theoretical physics, such as Faster-than-light travel (I'm a Star Trek geek, too!)?

4. What about extraterrestrial visitors(invaders)?

I know that some of these are going WAY beyond the original thoughts for Outpost.  It's just that, in addition to the less-than-polished design of the game, it always struck me as an unfinished product. It would be great to see this game done the way it should have been done from the beginning.  I'd also love to see it move forward, be the jumping-off point into a bigger universe!  I know that every game has to have an end-game point.  It just seems to me that this could be carried forward so much further...
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on October 17, 2017, 08:46:11 PM
Hello and welcome!

To answer your questions:

Title: Re: OutpostHD - An Outpost Redesign
Post by: JetMech1999 on October 19, 2017, 07:17:24 PM
That's cool.  That gives me more of an idea where this version of Outpost is headed.  Still sounds like it's going to be a lot of fun.  I knew some of what I put was really out there.
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on October 19, 2017, 09:59:05 PM
It's all about discussion. That's the only way to make a game fun if you ask me. :)

Also, forgive my curtness. I've been dealing with flu this week on top of work and a load of other stuff. I'm usually more articulate.
Title: Re: OutpostHD - An Outpost Redesign
Post by: Hooman on October 20, 2017, 04:37:43 AM
I could see multiple colonies on the same planet working. The other ideas sound fun, though I suspect the implementation would be hard, and the result ... probably not so fun.

Leeor_net, it's good to hear from you. I was wondering how the job was going. Figured you must be pretty busy with it. Hope you get over the flu soon.
Title: Re: OutpostHD - An Outpost Redesign
Post by: singthemuse on October 20, 2017, 10:07:12 AM
I think theoretical physics would be a fun end game research tier. Not necessarily for new technology gains or anything but as a mile marker. My thinking is that if a person's colony has the time/resources to support the study of theoretical sciences, then the colony is likely VERY stable and has enough extra supplies and colonists to support that, rather than something more immediately necessary to survival like housing, mining, morale, etc..

Perhaps "theoretical physics" could be an option that would continuously study thus tying up the facility forever unless it is canceled. It could be a large drain on resources too meaning that if players choose it too soon, they would endanger the colony. It could open the door for creating the new starship maybe (after enough cycles of it being studied)? Or perhaps just gives bonuses to other facilities (universities??) while it is being studied.

Just a thought!
Title: Re: OutpostHD - An Outpost Redesign
Post by: Hooman on October 20, 2017, 11:02:26 AM
Ahh, sounds kind of like the "Future Tech" in the Civilization series of games. Once you've researched the entire tech tree, you just continue researching numbered "future techs", with each one adding to your overall score. There was no actual in game benefit to doing it though. It just affected the high score rankings.
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on October 22, 2017, 05:03:22 PM
I think that's what Basic Research was supposed to do. It sped up current research by a few turns... ultimately not that useful.

I was thinking of something similar which would provide some sort of random buff. Like small efficiency upgrades, cost cutting, etc.
Title: Re: OutpostHD - An Outpost Redesign
Post by: Goof on October 22, 2017, 06:34:24 PM
Moral is a big thing in the game.
So just add moral to balance other issues could be sufficient ?
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on October 25, 2017, 08:02:52 PM
That could work. I still need to fully flesh it out but it currently works with the population model and the birth/death rates of the colonists. Need to get it to work with production and decay rates as well.
Title: Re: OutpostHD - An Outpost Redesign
Post by: JetMech1999 on January 04, 2018, 01:06:08 PM
It's all about discussion. That's the only way to make a game fun if you ask me. :)

Also, forgive my curtness. I've been dealing with flu this week on top of work and a load of other stuff. I'm usually more articulate.
I get it.  No feelings hurt here, it sucks being sick.  Besides, redesigning a game from the ground up is enough of a challenge without trying to incorporate crazy new ideas into the version 1.0 of said rewrite.  Since it's been a while from my last postings, I hope that the new job is going well and that you're feeling better.  Can't wait to see the newest data and graphics. 
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on January 07, 2018, 09:34:38 PM
Glad OPHD is still generating interest even though I've kinda put it on the back burner for awhile.

On that note, I've made a few commits today and am getting the feel to get back into coding. I've settled into my new job, have been offered a permanent position with pay increase and health benefits so I'm far less stressed on that end.

Basically, boils down to I'm starting to pick it back up again.

I don't want to make any promises in terms of time frames... but you can check the SVN/Redmine projects for updates. :D
Title: Re: OutpostHD - An Outpost Redesign
Post by: Hooman on January 08, 2018, 01:29:25 AM
Yeah! And there was much rejoicing.

Checking out the changes now.


Also, congratulations on the job success.
Title: Re: OutpostHD - An Outpost Redesign
Post by: White Claw on January 08, 2018, 07:18:19 PM
Welcome back, Leeor! Looking forward to updates, and congrats on the job. :)
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on January 08, 2018, 08:03:40 PM
Thanks, everybody! :D

Hooman, I saw your change to the initializer -- I didn't realize I had it wrong. Looks like Microsoft added their own non-standard flare once again. Either that or VS2015 doesn't fully implement the standard. Maybe I should just upgrade to 2017?
Title: Re: OutpostHD - An Outpost Redesign
Post by: JetMech1999 on March 25, 2018, 11:32:24 AM
Haven't seen anything new posted for a couple of months.  Just wanted to make sure things are still good.  I know that jobs, family, life, etc. happens and figured that something like that has put the brakes on things for a while.
Title: Re: OutpostHD - An Outpost Redesign
Post by: Hooman on March 26, 2018, 05:25:55 AM
Yes, kind of curious if there are any updates to this. I've sort of let my contributions to this slide as well.
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on March 26, 2018, 12:15:43 PM
Was thinking about posting a status update. I know it's been awhile and things sort fell the wayside. Suffice it to say my own personal brand of insanity has made it difficult to do much of anything. But I'm starting to feel better again and started poking around the code again. I've started by updating the project to allow for PVS-Studio to analyse it (it's a static code analyzer that's pretty good at what it does). With it I've already fixed a few glaring bugs.

Beyond that, I've almost got the warehouse and production systems in place. It's further developed than I remember (shows you how lost I was for awhile) so I hope to start ramping development back up again.
Title: Re: OutpostHD - An Outpost Redesign
Post by: White Claw on March 27, 2018, 11:58:50 PM
I'm still around also, checking the forums periodically. Things were a bit crazy for me the last couple months, but I'm hoping all that will stay settled. I've not made any new buildings in a while, though I did start some 3D modeling again just a couple weeks ago (not Outpost related). Going to try to finish that project over the next couple weeks (if work doesn't stop me), then perhaps back over to remaking the buildings.

Cheers!
Title: Re: OutpostHD - An Outpost Redesign
Post by: Hooman on March 28, 2018, 04:23:52 AM
Cool, great to hear from both of you.

I just checked out the PVS-Studio Analyzer website. Neat little tool. Looks to do the same sort of thing as Coverity Scan.

White Claw, what's your other project? Anything worth starting a new thread about?
Title: Re: OutpostHD - An Outpost Redesign
Post by: White Claw on March 28, 2018, 10:13:09 PM
White Claw, what's your other project? Anything worth starting a new thread about?

Probably nothing worth an entire new thread, but I went ahead and added it to the other 3D modeling thread since it's completely off topic here.

http://forum.outpost2.net/index.php/topic,5951.msg86223.html#msg86223
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on March 28, 2018, 11:24:14 PM
I just checked out the PVS-Studio Analyzer website. Neat little tool. Looks to do the same sort of thing as Coverity Scan.

It basically is but it integrates well with Visual Studio and its code analysis has helped me find many bugs in my other project Rogue Arena (https://github.com/ldicker83/rogue-arena). I didn't realize how useful static code analysis was. It also turns out that Visual Studio has static code analysis built into it even in the free community edition though it missed a lot of what PVS-Studio flagged (and found things PVS-Studio missed).
Title: Re: OutpostHD - An Outpost Redesign
Post by: Hooman on March 29, 2018, 10:03:13 AM
I love static code analysis.  :)

Which is also one of the reasons why I like compiled languages. They generally do at least some basic syntax and semantic checking up front during the compile stage, so you can catch a whole wide range of errors easily and quickly.

Then there are other software packages (I think one culprit was MatLab), where a program can run for an hour before aborting with a syntax error.  >:(

When I first moved to Ruby, I sorely missed the syntax check from a compile phase. Automated tests become a lot more important in a language like that. Which unfortunately have to be manually written.

It is impressive though what some of those C++ static analysis tools can catch, which a compiler typically won't check for. Glad you got that working.  :)
Title: Re: OutpostHD - An Outpost Redesign
Post by: JetMech1999 on March 30, 2018, 07:15:46 PM
Glad to hear everyone is doing well and that none of you fell off the planet.  Looking forward to the status updates (when life gives you a few moments to post them) as well as any new graphics (test or otherwise).
Title: Re: OutpostHD - An Outpost Redesign
Post by: macksting on May 13, 2018, 05:50:24 AM
Every now and then I scratch the itch to play Outpost, or look for something else that will scratch it.
This is probably the first time I've ever seen a post about a remake within the same year it was last spoken of.
I was gonna say "I'll try not to get too optimistic," but then I checked the other topics, and it looks like this is surprisingly far along.

I wonder if there's some way I can help. I doubt it, but if there's simple scripting or bug testing, you might be able to shove some grunt work off on somebody else.
Title: Re: OutpostHD - An Outpost Redesign
Post by: Hooman on May 13, 2018, 07:36:31 AM
In my experience, the most effective way to contribute to a project, any project, is to poke around until you find something you can do, and then just do it. You know your own skills and interests the best. Plus, the majority of projects are generally not organized enough to know where they might need help.

Though I noticed you suggested a few possible ways you could help, which is a better start than most offers to help.
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on May 13, 2018, 10:57:54 AM
Hey, macksting! Welcome to the forums!

Yes, I just recently released the newest versions -- see first post for download link.

I'm going to assume you're not a developer... which is great because it means you're a user! Users are some of the most helpful contributors to a project like this. I could use your feedback on any of the topics in this thread (especially the UI discussions). Play the current build, see if you find any issues, if you do, report them. Finding and squashing bugs is an ongoing process and as the lead developer I may not think to go through a series of actions that a user may follow -- e.g., I know how you're 'supposed' to do things so I tend not to deviate from that but that often leads to logic paths I hadn't considered which is where you, the user, comes in. :D

Anyway, keep checking back! It's been awhile since I posted a major update (last one was july last year) but I want to avoid a long development cycle like that.
Title: Re: OutpostHD - An Outpost Redesign
Post by: macksting on May 26, 2018, 05:29:37 PM
Let's see if I'm wakeful enough to wrestle with this today.

Probably not. I'm not entirely accustomed to the process of compiling from source in Linux, so I'm having a little trouble remembering the process and not seeing anything that looks familiar enough to latch onto other than makefile, which eventually I tried, knowing full well I was jumping the gun. (Sure enough, it didn't yield much of use on its own.) I'll go start a topic for this, I think.
Title: Re: OutpostHD - An Outpost Redesign
Post by: Hooman on May 27, 2018, 02:33:33 PM
Huh, that's much more of an attempt than I expected. Indeed, there is a makefile, though there are 2 projects that need to be compiled together, NAS2D and OutpostHD. I'll have to dig up some of my old notes.
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on May 27, 2018, 07:10:46 PM
I set up an Ubuntu VM and tried building from source but I'm getting hung up compiling SDL 2.0.5 (Apt is still using 2.0.4 annoyingly enough). It's a linker error regarding some functions it can't find, I dunno. I suspect after I compile SDL2.0.5 NAS2D will build which will let me build OutpostHD.

Today's been a super lazy day -- been in bed watching star trek all day. Yeah, one of those. :D

I'll see what I can figure out from there maybe with your assistance. I've got all the instructions required for downloading and installing the dependencies to build all of the projects.
Title: Re: OutpostHD - An Outpost Redesign
Post by: macksting on May 27, 2018, 11:38:58 PM
Huh, that's much more of an attempt than I expected. Indeed, there is a makefile, though there are 2 projects that need to be compiled together, NAS2D and OutpostHD. I'll have to dig up some of my old notes.

If you've been waiting to see a unicorn as long as I have... - Molly Grue

I've helped out with a couple things, very much a layman in such matters but willing to learn something long enough to apply it (and then, due to disuse, promptly forget about it.)
Title: Re: OutpostHD - An Outpost Redesign
Post by: Hooman on May 28, 2018, 07:28:35 AM
Ubuntu 18.04 is now out. I just checked the download page. The new version of Ubuntu should have up-to-date Apt packages, that will be sufficient for building OutpostHD.

You can also try the stuff in that docker thread from a couple months back, which was using a Docker image for Ubuntu 18.04.

I think my SDL2 source install script was not complete, in that it only compiled the modules it needed up to date versions of, not all modules used. I'm not sure mixed Apt and source install versions play well together. With all the things I've done locally on my machine, it's possible I missed the mixed version issue in my earlier attempts.


I've had Star Trek binge days. Awesome.  :)

Though I've never seen The Last Unicorn.
Title: Re: OutpostHD - An Outpost Redesign
Post by: macksting on June 15, 2018, 11:54:41 AM
It's probably one of my top favorite books. In some ways it reminds me of some of the more peculiar new wave science fiction stories I've read; if Beagle wrote a science fiction story, I'd eat it right up. The movie's good, too, great actors, kept most of the important parts of the book, music's nice, etc. But I feel it's a rare case where reading the book first would improve watching the film, since it's close enough to the book to not have the film insult the reader's intelligence, and the book gives the events in the movie more context.

Uh, anyway, I'll consider upgrading soon. It's gonna be a busy summer, though.
Title: Re: OutpostHD - An Outpost Redesign
Post by: chris2222 on September 08, 2018, 05:52:25 PM
Hi!  It's been a long time since I last visited this forum.  Every once and a while I think about digging out OP1 and playing it but short on time and busy family life, you all know how it is.  Didn't really get into Outpost2 wasn't as beautiful a game as the original Outpost.  Anyways, I can't recall ever knowing about this Outpost remake, OutpostHD is looking quite awesome!  Just googled "games like outpost" and happened to be reading a forum that led me to OupostHD, this is awesome!
I don't know that I can help but I certainly appreciate all the work that has been done on this project.  I have the original boxed outpost still in great condition with it's manual and a rather large Outpost strategy guide I had bought after a few weeks of playing OP1.  Just wondering if you all have access to these manuals?  I'm pretty sure you do, but if you don't I could provide information from these that could help? 

I realize OPHD is almost ready to release version 0.7.9.  I'm sure everything has mostly been thought about. 
CRTL F12 was a way to force a choice of a natural disaster on your colony.  Monorails I think was never properly implemented in OP1.  I'll have to do some digging, but this looks fun! 

Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on September 08, 2018, 09:37:06 PM
Very glad you decided to pop in and say something! It helps to know that there's a bit of buzz (even if it's just a tiny amount) for OutpostHD.

I also have the manual and the 'official strategy guide' (which is more of the witty quips of Bruce Balfour in book form more than anything else).

The best way to help is to play the game as it is and let me know if you find any mistakes, any bugs, any usability issues and present any ideas you may have. You might think of something I haven't though of or (as in the case with another user (https://forum.outpost2.net/index.php/topic,6164.0.html)) come across a usability issue that isn't obvious to me as the developer. Feedback from users is extremely important and helps me to know where to focus development efforts.

Thanks for stopping by! Hope to see you around more often!
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on October 06, 2018, 11:27:25 PM
Thought I'd provide a bit of an update for the main OPHD thread. :D

As the various (https://forum.outpost2.net/index.php/topic,6167.0.html) other (https://forum.outpost2.net/index.php/topic,6179.0.html) threads (https://forum.outpost2.net/index.php/topic,5990.0.html) in this subforum suggest, OPHD has seen a huge amount of progress over the last few years. It's really beginning to look and feel like a finished game. To that end, I've been keeping the first post updated to the best of my ability.

That stated, I'm really bad at writing 'flavor text' and the UI panels are beginning to need that. Additionally, the research tree (https://forum.outpost2.net/index.php/topic,6142.0.html) is going to need some help writing the flavor text for the individual research topics. If anybody is up to the challenge, please let me know and we can get something going.

I also wanted to reiterate my appreciation for the support and contributions from everybody here on the forums. Thanks for making this such a great process! I know it's taken a lot of time to become a thing (kind of the nature of a hobby programming project) but I really do appreciate all of the feedback I've gotten!

2018 is drawing to a close and I look forward to pushing development even further in 2019!
Title: Re: OutpostHD - An Outpost Remake
Post by: leeor_net on October 19, 2018, 10:29:54 PM
It's been a couple of weeks and it's time for a quick update!

I've run across a design limitation (read flaw) in the way NAS2D implements its signals/slots paradigm. It leaves open the possibility of a type of race condition caused by asynchronous code modifying a container while it's being iterated over. Simply put, the way I built some event handling code in OutpostHD broke horribly. There were two ways to address this -- rewrite the part of NAS2D that's faulty to harden it against this kind of problem (not easy but ultimately needs to be done) or rewrite parts of OutpostHD's event handling code (band-aid solution but the fastest viable option).

So I chose the latter. I have some great thoughts on how to make it work for NAS2D... but it would have taken awhile to get right and I wanted to get OPHD moving forward again so I changed its internal handling of events. It's ugly. I don't really like it. It works though.

So that's where I'm at. I worked around a show stopping design flaw in the middle ware, fixed a few bugs that were causing crashing in OPHD and now I'm ready to push forward and get 0.7.9 out the door. Not sure exactly how long it'll take but I'm pretty hopeful that the UI changes involved will make the game much more accessible.
Title: Re: OutpostHD - An Outpost Remake
Post by: Hooman on October 22, 2018, 02:16:41 AM
Hmm, that could actually be a pretty interesting side discussion if you were able to clearly explain the problem in a new thread. I'm actually rather curious how the problem came up, and how it was resolved. I bet there are other people that would love to delve into the event handling system of a game, and see where the hidden problems are.
Title: Re: OutpostHD - An Outpost Remake
Post by: leeor_net on October 22, 2018, 11:41:13 PM
See, now you done gone and made me do a thing (https://forum.outpost2.net/index.php/topic,6199.0.html).
Title: Re: OutpostHD - An Outpost Remake
Post by: leeor_net on January 14, 2019, 06:14:43 PM
Figured I should keep the main topic updated as well.

Long story short -- holidays were busy, I got sick like I usually do at the end of the year, I'm recovering and picking back up on development for OutpostHD.

All that stated, I've overcome a lot of difficulties in the underlying architecture of the messaging/event handling system. It's not perfect. It's not even particularly great. But it works. I'm sure at some point in the future I'll make it much more elegant but eh, atm I just want to make this thing freaking work.

The main two full-screen UI's I wanted to have finished for this release are effectively done. Warehouse UI needs some touching up and there are some rules I want to add when handling some actions but otherwise it's feature complete. I hope to have a release out this week. I've addressed a couple of bugs I found since the last release including a crash bug that would occur sometime around 200 turns related to aging robots (https://forum.outpost2.net/index.php/topic,6223.0.html).

So yay! ::thumbsup:: Progress!
Title: Re: OutpostHD - An Open Source Remake of OUTPOST by Sierra On-Line
Post by: leeor_net on March 02, 2019, 02:07:27 PM
Been about six weeks and another release is out (https://forum.outpost2.net/index.php/topic,6242.0.html)! I'm very pleased with the changes in this one -- the bulk of the changes are due to user feedback that I found too important to wait on. There are also a number of bug fixes (many thanks to Sirbomber for fixing one that I was too lazy to look into and finding another that I never would have found on my own).

So yeah, on to v0.8.0! This new version will focus on resource production and in particular truck routing, mine production and fine-tuned resource management.

As always, if you're not a developer or artist and you want to contribute, download the game. Play it. Provide feedback. Break it in unusual and horrible ways! I love getting bug reports. :D
Title: Re: OutpostHD - An Open Source Remake of OUTPOST by Sierra On-Line
Post by: jballou on April 20, 2019, 11:28:43 AM
Hey, first off I wanted to say thanks for undertaking such a huge amount of work, the game is coming along nicely and the thought of playing Outpost in a less broken state is really appealing to me. I've got a bunch of questions and suggestions, but please know that I raise these because I like what you're doing and want to see it get better, it's not a criticism by any means.

On the first page, the "how to play" link should point to https://wiki.outpost2.net/doku.php?id=outposthd:how_to_play

As far as the game itself, I'm a little lost on the interface.

I think it might be a good idea to add a "tips" feature to help give the player some in-game tutorial on the basics, just things like "land the seed factory here" and "build an agridome and CHAP before you bring down colonists" or whatever. The lack of clear direction on getting the basics was a problem for me in the original, putting in a little bit of handholding for new players will go a long way here.

Does the lab have any research options yet? I see no menu to do anything there.

I'm not sure where to find the Master Reports, if it's not implemented no worries but if it is you may want to document how to do access them on the wiki.

For the Morale, it would be nice if the game gave me an indication of why my morale is changing (i.e. +2 from residential, +2 from park, -3 from police).

For population, it would be good to have an indication or tip on how to get more workers or scientists, and a little bit of context as to what the classes of colonist are.

With Factories, I get an indication that it's on "Turn 5/5" for a long time. Is that because I don't have enough materials, or another reason?

For resources, having a dialog showing me where they are being consumed would be great, I'm having resources seemingly disappear and have no idea where to.

I also got "you have failed, your colony is dead" without any clear reason why. I had enough food, energy, housing, and materials, morale was around 300, and game over. Having some sort of alert like "your people are dying fast" or "morale is too low, people are air locking themselves to escape this existence" would be great.

I'm also a developer, usually FPS stuff but I've worked on a number of different mod teams all over. I'm not a C++ guy, but I can give you some time around doing documentation and other non-coding non-artistic stuff.
Title: Re: OutpostHD - An Open Source Remake of OUTPOST by Sierra On-Line
Post by: leeor_net on April 20, 2019, 08:26:03 PM
Hey, first off I wanted to say thanks for undertaking such a huge amount of work, the game is coming along nicely and the thought of playing Outpost in a less broken state is really appealing to me. I've got a bunch of questions and suggestions, but please know that I raise these because I like what you're doing and want to see it get better, it's not a criticism by any means.

Thanks for posting! Constructive criticism is never a bad thing -- in fact I find it to be extremely helpful. I very much appreciate you taking the time to post your thoughts -- without users like you it's hard to know where I need to focus my efforts.

On the first page, the "how to play" link should point to https://wiki.outpost2.net/doku.php?id=outposthd:how_to_play

Good catch! Seems the link broke after we forced HTTPS rewrite rules on the server. This has been fixed.

As far as the game itself, I'm a little lost on the interface.

I think it might be a good idea to add a "tips" feature to help give the player some in-game tutorial on the basics, just things like "land the seed factory here" and "build an agridome and CHAP before you bring down colonists" or whatever. The lack of clear direction on getting the basics was a problem for me in the original, putting in a little bit of handholding for new players will go a long way here.

Understandable. The interface needs work; I suppose that's part of the "work in progress" aspect to this. I very much agree with your suggestion -- it's something I'd like to see in the final product though I wanted to at least get resource management and research going before I spent time on it.

Does the lab have any research options yet? I see no menu to do anything there.

Not yet. See the GitHub Milestones (https://github.com/ldicker83/OPHD/milestones) page for my planned development route. It's slated for v0.9.0 but I think I'm going to switch that to v0.8.5 and move structural integrity decay to v0.9.0 instead -- the game is playable but there's a distinct feeling of lack of progress atm which I think technology improvements will help to alleviate.

I'm not sure where to find the Master Reports, if it's not implemented no worries but if it is you may want to document how to do access them on the wiki.

There isn't really a master report ATM but there are main report windows for Factories. You can access this by double-clicking on a factory. Pressing F1 will also bring this up though for now this is a debug aid, not sure if it'll stay that way or if I'll add a button somewhere to the HUD or just have double-clicking on a Command Center do this.

For the Morale, it would be nice if the game gave me an indication of why my morale is changing (i.e. +2 from residential, +2 from park, -3 from police).

I hadn't considered this but I think it's a really good suggestion. I'll slate this for the current release being worked on (https://github.com/ldicker83/OPHD/issues/104).

For population, it would be good to have an indication or tip on how to get more workers or scientists, and a little bit of context as to what the classes of colonist are.

Good point -- there's a bit of an assumption made that someone playing the game is familiar with the original game. I had opted for the wiki/manual to sort of explain this (at least for now) but in-game explanations are also a good idea. This is something I'll slate for a later release.

With Factories, I get an indication that it's on "Turn 5/5" for a long time. Is that because I don't have enough materials, or another reason?

This happens when the factory is producing a product that doesn't have storage space. Either it's a robot but there is no additional robot command capacity (e.g., you have three robots already and haven't yet built a Robot Command Center) or you're producing a product, say clothing, but you either have no warehouses or the warehouses are full. This isn't well indicated in the current release. I'm sort of scratching my head on how to indicate this well to the user -- it could just be a note in the Factory Inspector Window, the Factory Reports screen or both.

Ultimately I intend this to be a 'beginning of turn' notification type of deal -- e.g., you have an indicator appear on the screen alerting you to issues like this. It's talked about a bit in this thread (https://forum.outpost2.net/index.php/topic,6113.0.html).

For resources, having a dialog showing me where they are being consumed would be great, I'm having resources seemingly disappear and have no idea where to.

Similar to the Morale suggestion you had, this is also something I've been thinking about. There's the current resource breakdown which shows changes over time but nothing that indicates where resources are going. I'm not sure where to put the details though -- I've though about the Mining Master View (naming is inconsistent here, I apologize) -- but basically the full-screen UI.

I'm open to suggestion on this, of course. As I've stated in other threads (and in the first post of this one), I'm really bad at UI and interface design. This is evident in the minimalist approach that most of the interface takes. I use the excuse that "I'm the developer so I don't really need to focus my time on the UI" but the reality is that this thinking does a disservice to the potential users. Sure, the game is a work in progress but it's the users that need to be heeded here. The last two versions of the game that I published were heavily driven by a user on IRC from SimTropolis (I'm unable to access the website for months now which is a crying shame as the user was very helpful) who provided a great deal of feedback. This feedback pushed me to make the UI changes that are now present in the game.

Anyway, long story short, I'm open to suggestions about the overall design of the interface. Having a mockup that I can look at helps me to actually develop the underlying code. The coding isn't really the hard part (even though it's sort of tedious), but knowing what to put on screen is a real challenge.

I also got "you have failed, your colony is dead" without any clear reason why. I had enough food, energy, housing, and materials, morale was around 300, and game over. Having some sort of alert like "your people are dying fast" or "morale is too low, people are air locking themselves to escape this existence" would be great.

Yeah... that's an on-going issue. It's almost always due to a shortage of a critical resource (usually rare minerals) that lead to the CHAP facility shutting down which causes everything to collapse immediately and very suddenly. Part of the notification tasks I linked to earlier will be to warn users very loudly about critical resources getting too low. ATM resources that are reaching limits will start to glow red. It's a start but it's not the really loud "You're about to lose your colony because Resource X is dwindling -- bulldoze a structure or two NOW before this happens" that needs to happen.

Basically, I'm working on it. :D

I'm also a developer, usually FPS stuff but I've worked on a number of different mod teams all over. I'm not a C++ guy, but I can give you some time around doing documentation and other non-coding non-artistic stuff.

By all means! I could really use help with in-game tips and help text and help with the Wiki 'manual' as well. I'm not a great writer and the task is often daunting to me.

If you'd like to help on the Wiki, let me know and I'll PM you temporary login info based on your username here. We had a lot of issues with spam there so I have the wiki locked down.



So... apologies for the wall of text. I hope I answered your questions. If you have more thoughts or questions, please post! I really do love getting bug reports and feedback from users. I've said it many times before and I'll say it again, without user feedback I can't make this game great. So again, thank you!
Title: Re: OutpostHD - An Open Source Remake of OUTPOST by Sierra On-Line
Post by: jballou on April 21, 2019, 11:18:32 AM
First off, thanks for the detailed response, it's gotta be a wall of text since I put up a wall myself.

I actually realized after I posted it that there was a whole subforum here and a lot of this has already been covered. So I'll just go over the remaining points.

For the master reports, a little context for the user on how to open the interface would be helpful. Even if it's a temporary dialog with buttons to connect all the UI pieces, it wouldn't be that much worse than the original. Heck, you wouldn't even make players wait 5 seconds for a smarmy AI WAV file to play before displaying the menu, so you're already ahead of the game :D

I'd be glad to work on some UI connectors to allow localizing out some text and events, that would let you make the code part and people like me could make smaller scripts with the help text and triggers that make them appear. It's not a trivial ask, but I've done something similar in other games and it did end up saving time and being easier to have a simple event thrower/listener than hardcoding the tutorial stuff directly into the game.

For the factory alert, and other stuff, something like an "events scroller" at the bottom would be good. Any event, be it "time travel", "bold new discovery", "factory can't deliver goods" or "no more air" could all show up in a feed. Players click the event to get deeper context and information, and maybe color code and/or flash critical events that need immediate attention. Something that always bugged me about Outpost was that things would happen, from the seed factory imploding to the rebels surrender, and I'd have no idea it happened until I clicked News Briefs. Bringing that to the foreground will go a long way here.

For the materials breakdown, I can see an entire "resource view", that has minerals, metals, air, etc. all on the list. Each has an In/Out column, to show the balance. Clicking any resource shows what buildings are creating, and consuming, these resources. You can get fancy like click an element to move to it on the map, or prioritize/enable/disable buildings that consume resources, but to start with just a list of the things and the balances would solve a lot of problems.

I can mock up a couple of these for you, what's your preferred format?
Title: Re: OutpostHD - An Open Source Remake of OUTPOST by Sierra On-Line
Post by: leeor_net on April 21, 2019, 04:19:53 PM
First off, thanks for the detailed response, it's gotta be a wall of text since I put up a wall myself.

I actually realized after I posted it that there was a whole subforum here and a lot of this has already been covered. So I'll just go over the remaining points.

For the master reports, a little context for the user on how to open the interface would be helpful. Even if it's a temporary dialog with buttons to connect all the UI pieces, it wouldn't be that much worse than the original. Heck, you wouldn't even make players wait 5 seconds for a smarmy AI WAV file to play before displaying the menu, so you're already ahead of the game :D

By master reports, do you mean the full-screen reports UI that was recently developed?

(https://i.ibb.co/Qmz3f36/image.png) (https://ibb.co/3hG9790)

At the moment this can be accessed by double-clicking on a Factory (surface or underground) or a Warehouse. This can also be accessed by pressing F1 though I'd like to reassign this key to something more intuitive in the future.

If this isn't what you mean, I'd like to hear more.

I'd be glad to work on some UI connectors to allow localizing out some text and events, that would let you make the code part and people like me could make smaller scripts with the help text and triggers that make them appear. It's not a trivial ask, but I've done something similar in other games and it did end up saving time and being easier to have a simple event thrower/listener than hardcoding the tutorial stuff directly into the game.

I'm not opposed to this but developing a scriptable GUI would take considerable resources. I wanted to keep things as straight forward as I could in the code -- it's why structures are hard-coded instead of being in some external definition file like an XML, etc. It's also why the UI is hard-coded. Developing a scripting system for this does mean that the UI can be developed without having to recompile the code but it adds additional overhead that I'm not convinced is a good idea, it potentially limits how tightly it can integrate with the core code (there's some really weird stuff I do in there, not as bad as working with wxWidgets but hard-coding the UI does overcome some inter-class comm issues that would be difficult to do with scripting). It also eliminates a lot of the loading times you'd get by having to load up external script files, check them and 'compile' them. Ultmiately it really just kind of shifts the location of the problem without actually solving it.

That stated, I do intend to have a lot of the text moved outside of the code -- currently it's all in a series of constants that are defined in <Constants/Strings.h>. This works but it's hardly ideal for being able to quickly change the text as needed. The plan is to build an XML file with key/value paired string constants that the code can reference with something like StringConstants[nameKey];. Quick, easy and provides and safe. There are a few cases where I use c-like string formatting specifiers (ala printf) that would make assumptions about the nature of the format specifiers... so I'll have to think about how to do this well should the string be changed.

For the factory alert, and other stuff, something like an "events scroller" at the bottom would be good. Any event, be it "time travel", "bold new discovery", "factory can't deliver goods" or "no more air" could all show up in a feed. Players click the event to get deeper context and information, and maybe color code and/or flash critical events that need immediate attention. Something that always bugged me about Outpost was that things would happen, from the seed factory imploding to the rebels surrender, and I'd have no idea it happened until I clicked News Briefs. Bringing that to the foreground will go a long way here.

This is precisely what I had in mind. Similar in style to how Endless Space does it with the notifications building up along the left edge of the screen. When you click on them you get more details, right-click to dismiss.
(https://i.ibb.co/0ZtYM0Z/notifications-1.png) (https://ibb.co/0ZtYM0Z) (https://i.ibb.co/5vNkkpy/notifications-2.png) (https://ibb.co/5vNkkpy)

For the materials breakdown, I can see an entire "resource view", that has minerals, metals, air, etc. all on the list. Each has an In/Out column, to show the balance. Clicking any resource shows what buildings are creating, and consuming, these resources. You can get fancy like click an element to move to it on the map, or prioritize/enable/disable buildings that consume resources, but to start with just a list of the things and the balances would solve a lot of problems.

I can mock up a couple of these for you, what's your preferred format?

Please do!

I don't have a particular preference in format. I would recommend posting in the User Interface (https://forum.outpost2.net/index.php/board,111.0.html) subforum. Another forum user (havkyp I think?) suggested using a program called Pencil -- I still use it and it's pretty effective at quickly developing UI mockups. It's not perfect but it's free and does its job. I mention it in this post (https://forum.outpost2.net/index.php/topic,6112.0.html).
Title: Re: OutpostHD - An Open Source Remake of OUTPOST by Sierra On-Line
Post by: jballou on April 21, 2019, 07:03:12 PM
Yep, I found the interface, but the double-click invocation wasn't clear to me at first. Another wiki/tooltip issue probably.

About the event/scripting interface, having not looked at your code, your reasoning seems pretty good. So, that aside, maybe I could come up with a list of tips, and things that trigger them? I think the initial set of triggers for tips would be a building created/destroyed, turn numbers, mines going dry, and robots dying. That covers a lot of ground, and seems like a reasonable amount of work to parcel out (again, making some big assumptions from my side here).

I'll take a peek at Pencil tomorrow, and pop a couple ideas into the UI subforum, and we can discuss them further in there.
Title: Re: OutpostHD - An Open Source Remake of OUTPOST by Sierra On-Line
Post by: leeor_net on April 21, 2019, 07:08:19 PM
About the event/scripting interface, having not looked at your code, your reasoning seems pretty good. So, that aside, maybe I could come up with a list of tips, and things that trigger them? I think the initial set of triggers for tips would be a building created/destroyed, turn numbers, mines going dry, and robots dying. That covers a lot of ground, and seems like a reasonable amount of work to parcel out (again, making some big assumptions from my side here).

Makes sense to me. :D Should be very do-able in-game. It's a matter of setting a flag to 'show first-time tips' and as you said just have them trigger as the player uses the game.

Looking forward to seeing what you come up with!
Title: Re: OutpostHD - An Open Source Remake of OUTPOST by Sierra On-Line
Post by: ekztal on August 30, 2019, 03:54:19 AM
Hello!

I have Visual Studio 2019 installed, along with vcpkg, GLEW, & PhysFS
I cloned git repo for this, then downloaded and extracted the extra data.zip and api.zip files. I added their path as additional include directories

When I try to Build the project I get the following output

Code: [Select]
1>------ Build started: Project: OPHD, Configuration: Debug Win32 ------
1>GraphWalker.cpp
1>main.cpp
1>TileMap.cpp
1>Population.cpp
1>ProductPool.cpp
1>GameState.cpp
1>MapViewState.cpp
1>MainMenuState.cpp
1>MapViewStateDraw.cpp
1>C:\Users\Tom\source\repos\OPHD\src\main.cpp(7,10): error C1083:  Cannot open include file: 'NAS2D/Mixer/NullMixer.h': No such file or directory
1>C:\Users\Tom\source\repos\OPHD\src\Map\TileMap.h(62,53): error C2039:  'clamp': is not a member of 'NAS2D' (compiling source file ..\..\src\GraphWalker.cpp)
1>F:\Outpost 1\includes\NAS2D\include\NAS2D\Resources\Sprite.h(19): message :  see declaration of 'NAS2D' (compiling source file ..\..\src\GraphWalker.cpp)
1>MapViewStateEvent.cpp
1>C:\Users\Tom\source\repos\OPHD\src\Map\TileMap.h(62,28): error C3861:  'clamp': identifier not found (compiling source file ..\..\src\GraphWalker.cpp)
1>C:\Users\Tom\source\repos\OPHD\src\ProductPool.cpp(134,20): error C3861:  'clamp': identifier not found
1>C:\Users\Tom\source\repos\OPHD\src\Map\TileMap.h(62,53): error C2039:  'clamp': is not a member of 'NAS2D' (compiling source file ..\..\src\Map\TileMap.cpp)
1>F:\Outpost 1\includes\NAS2D\include\NAS2D\Resources\Sprite.h(19): message :  see declaration of 'NAS2D' (compiling source file ..\..\src\Map\TileMap.cpp)
1>MapViewStateHelper.cpp
1>C:\Users\Tom\source\repos\OPHD\src\Map\TileMap.h(62,28): error C3861:  'clamp': identifier not found (compiling source file ..\..\src\Map\TileMap.cpp)
1>C:\Users\Tom\source\repos\OPHD\src\Map\TileMap.h(62,53): error C2039:  'clamp': is not a member of 'NAS2D' (compiling source file ..\..\src\States\MainMenuState.cpp)
1>F:\Outpost 1\includes\NAS2D\include\NAS2D\Resources\Sprite.h(19): message :  see declaration of 'NAS2D' (compiling source file ..\..\src\States\MainMenuState.cpp)
1>C:\Users\Tom\source\repos\OPHD\src\Map\TileMap.h(62,28): error C3861:  'clamp': identifier not found (compiling source file ..\..\src\States\MainMenuState.cpp)
1>C:\Users\Tom\source\repos\OPHD\src\Population\Population.cpp(31,16): error C2039:  'clamp': is not a member of 'NAS2D'
1>F:\Outpost 1\includes\NAS2D\include\NAS2D\Resources\Sprite.h(19): message :  see declaration of 'NAS2D'
1>MapViewStateIO.cpp
1>C:\Users\Tom\source\repos\OPHD\src\Population\Population.cpp(31,21): error C3861:  'clamp': identifier not found
1>C:\Users\Tom\source\repos\OPHD\src\Map\TileMap.h(62,53): error C2039:  'clamp': is not a member of 'NAS2D' (compiling source file ..\..\src\States\GameState.cpp)
1>F:\Outpost 1\includes\NAS2D\include\NAS2D\Resources\Sprite.h(19): message :  see declaration of 'NAS2D' (compiling source file ..\..\src\States\GameState.cpp)
1>C:\Users\Tom\source\repos\OPHD\src\Map\TileMap.h(62,28): error C3861:  'clamp': identifier not found (compiling source file ..\..\src\States\GameState.cpp)
1>C:\Users\Tom\source\repos\OPHD\src\Map\TileMap.h(62,53): error C2039:  'clamp': is not a member of 'NAS2D' (compiling source file ..\..\src\States\MapViewState.cpp)
1>F:\Outpost 1\includes\NAS2D\include\NAS2D\Resources\Sprite.h(19): message :  see declaration of 'NAS2D' (compiling source file ..\..\src\States\MapViewState.cpp)
1>C:\Users\Tom\source\repos\OPHD\src\Map\TileMap.h(62,28): error C3861:  'clamp': identifier not found (compiling source file ..\..\src\States\MapViewState.cpp)
1>C:\Users\Tom\source\repos\OPHD\src\Map\TileMap.cpp(256,18): error C3861:  'clamp': identifier not found
1>C:\Users\Tom\source\repos\OPHD\src\Map\TileMap.cpp(257,6): error C3861:  'clamp': identifier not found
1>MapViewStateTurn.cpp
1>MapViewStateUi.cpp
1>PlanetSelectState.cpp
1>C:\Users\Tom\source\repos\OPHD\src\Map\TileMap.cpp(353,18): error C3861:  'clamp': identifier not found
1>C:\Users\Tom\source\repos\OPHD\src\States\MapViewState.cpp(337,9): error C3861:  'clamp': identifier not found
1>C:\Users\Tom\source\repos\OPHD\src\States\MapViewState.cpp(343,9): error C3861:  'clamp': identifier not found
1>C:\Users\Tom\source\repos\OPHD\src\States\MapViewState.cpp(349,9): error C3861:  'clamp': identifier not found
1>C:\Users\Tom\source\repos\OPHD\src\States\MapViewState.cpp(355,9): error C3861:  'clamp': identifier not found
1>C:\Users\Tom\source\repos\OPHD\src\States\MapViewState.cpp(542,9): error C3861:  'clamp': identifier not found
1>C:\Users\Tom\source\repos\OPHD\src\States\MapViewState.cpp(547,9): error C3861:  'clamp': identifier not found
1>C:\Users\Tom\source\repos\OPHD\src\States\MapViewState.cpp(552,9): error C3861:  'clamp': identifier not found
1>C:\Users\Tom\source\repos\OPHD\src\States\MapViewState.cpp(557,9): error C3861:  'clamp': identifier not found
1>C:\Users\Tom\source\repos\OPHD\src\States\MapViewState.cpp(685,10): error C3861:  'clamp': identifier not found
1>SplashState.cpp
1>C:\Users\Tom\source\repos\OPHD\src\States\MapViewState.cpp(686,10): error C3861:  'clamp': identifier not found
1>C:\Users\Tom\source\repos\OPHD\src\Map\TileMap.h(62,53): error C2039:  'clamp': is not a member of 'NAS2D' (compiling source file ..\..\src\States\MapViewStateDraw.cpp)
1>F:\Outpost 1\includes\NAS2D\include\NAS2D\Resources\Sprite.h(19): message :  see declaration of 'NAS2D' (compiling source file ..\..\src\States\MapViewStateDraw.cpp)
1>C:\Users\Tom\source\repos\OPHD\src\Map\TileMap.h(62,28): error C3861:  'clamp': identifier not found (compiling source file ..\..\src\States\MapViewStateDraw.cpp)
1>C:\Users\Tom\source\repos\OPHD\src\Map\TileMap.h(62,53): error C2039:  'clamp': is not a member of 'NAS2D' (compiling source file ..\..\src\States\MapViewStateEvent.cpp)
1>F:\Outpost 1\includes\NAS2D\include\NAS2D\Resources\Sprite.h(19): message :  see declaration of 'NAS2D' (compiling source file ..\..\src\States\MapViewStateEvent.cpp)
1>C:\Users\Tom\source\repos\OPHD\src\Map\TileMap.h(62,28): error C3861:  'clamp': identifier not found (compiling source file ..\..\src\States\MapViewStateEvent.cpp)
1>C:\Users\Tom\source\repos\OPHD\src\Map\TileMap.h(62,53): error C2039:  'clamp': is not a member of 'NAS2D' (compiling source file ..\..\src\States\MapViewStateTurn.cpp)
1>F:\Outpost 1\includes\NAS2D\include\NAS2D\Resources\Sprite.h(19): message :  see declaration of 'NAS2D' (compiling source file ..\..\src\States\MapViewStateTurn.cpp)
1>C:\Users\Tom\source\repos\OPHD\src\Map\TileMap.h(62,28): error C3861:  'clamp': identifier not found (compiling source file ..\..\src\States\MapViewStateTurn.cpp)
1>C:\Users\Tom\source\repos\OPHD\src\States\MapViewStateDraw.cpp(183,57): error C3861:  'clamp': identifier not found
1>C:\Users\Tom\source\repos\OPHD\src\States\MapViewStateDraw.cpp(183,190): error C2661:  'NAS2D::Renderer::drawSubImage': no overloaded function takes 6 arguments
1>C:\Users\Tom\source\repos\OPHD\src\Map\TileMap.h(62,53): error C2039:  'clamp': is not a member of 'NAS2D' (compiling source file ..\..\src\States\MapViewStateHelper.cpp)
1>F:\Outpost 1\includes\NAS2D\include\NAS2D\Resources\Sprite.h(19): message :  see declaration of 'NAS2D' (compiling source file ..\..\src\States\MapViewStateHelper.cpp)
1>CheckBox.cpp
1>Slider.cpp
1>C:\Users\Tom\source\repos\OPHD\src\Map\TileMap.h(62,28): error C3861:  'clamp': identifier not found (compiling source file ..\..\src\States\MapViewStateHelper.cpp)
1>C:\Users\Tom\source\repos\OPHD\src\Map\TileMap.h(62,53): error C2039:  'clamp': is not a member of 'NAS2D' (compiling source file ..\..\src\States\MapViewStateIO.cpp)
1>F:\Outpost 1\includes\NAS2D\include\NAS2D\Resources\Sprite.h(19): message :  see declaration of 'NAS2D' (compiling source file ..\..\src\States\MapViewStateIO.cpp)
1>C:\Users\Tom\source\repos\OPHD\src\Map\TileMap.h(62,28): error C3861:  'clamp': identifier not found (compiling source file ..\..\src\States\MapViewStateIO.cpp)
1>C:\Users\Tom\source\repos\OPHD\src\Map\TileMap.h(62,53): error C2039:  'clamp': is not a member of 'NAS2D' (compiling source file ..\..\src\States\MapViewStateUi.cpp)
1>F:\Outpost 1\includes\NAS2D\include\NAS2D\Resources\Sprite.h(19): message :  see declaration of 'NAS2D' (compiling source file ..\..\src\States\MapViewStateUi.cpp)
1>C:\Users\Tom\source\repos\OPHD\src\Map\TileMap.h(62,28): error C3861:  'clamp': identifier not found (compiling source file ..\..\src\States\MapViewStateUi.cpp)
1>C:\Users\Tom\source\repos\OPHD\src\States\MapViewStateTurn.cpp(158,19): error C3861:  'clamp': identifier not found
1>C:\Users\Tom\source\repos\OPHD\src\Map\TileMap.h(62,53): error C2039:  'clamp': is not a member of 'NAS2D' (compiling source file ..\..\src\States\PlanetSelectState.cpp)
1>F:\Outpost 1\includes\NAS2D\include\NAS2D\Resources\Sprite.h(19): message :  see declaration of 'NAS2D' (compiling source file ..\..\src\States\PlanetSelectState.cpp)
1>C:\Users\Tom\source\repos\OPHD\src\Map\TileMap.h(62,28): error C3861:  'clamp': identifier not found (compiling source file ..\..\src\States\PlanetSelectState.cpp)
1>C:\Users\Tom\source\repos\OPHD\src\states\SplashState.cpp(130,18): error C3861:  'clamp': identifier not found
1>C:\Users\Tom\source\repos\OPHD\src\UI\Core\CheckBox.cpp(106,17): error C3861:  'clamp': identifier not found
1>C:\Users\Tom\source\repos\OPHD\src\UI\Core\Slider.cpp(170,14): error C3861:  'clamp': identifier not found
1>Done building project "ophd.vcxproj" -- FAILED.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

I'm sure I'd doing something wrong, if you know what it is, that would be fantastic.
Title: Re: OutpostHD - An Open Source Remake of OUTPOST by Sierra On-Line
Post by: Vagabond on August 30, 2019, 07:04:27 PM
Hello ekztal,

Welcome to the forums!

I briefly looked at the build output youposted. My first guess is either you have not downloaded the NAS2D dependency or that you placed the dependency in a location that OutpostHD is not looking for it, esp the file nullmixer.h.

You can find NAS2D here: https://github.com/lairworks/nas2d-core

Hope this helps. Please post how it goes.

Brett
Title: Re: OutpostHD - An Open Source Remake of OUTPOST by Sierra On-Line
Post by: ekztal on August 31, 2019, 03:13:33 AM
Hello ekztal,

Welcome to the forums!

I briefly looked at the build output youposted. My first guess is either you have not downloaded the NAS2D dependency or that you placed the dependency in a location that OutpostHD is not looking for it, esp the file nullmixer.h.

You can find NAS2D here: https://github.com/lairworks/nas2d-core

Hope this helps. Please post how it goes.

Brett

Thanks for the quick reply.   I had previously already downloaded NAS2D.  Before I had downloaded NAS2D the other day I was getting "Cannot open include file:" on every line.  Now I mostly get the 'clamp' error except for the 1st line where I get the error "Cannot open include file: NAS2D/Mixer/NullMixer.h" but that's because there IS NO NullMixer.h in the NAS2D/Mixer/ directory it only contains 3 files:

Code: [Select]
Mixer.h
MixerNull.h
MixerSDL.h
Title: Re: OutpostHD - An Open Source Remake of OUTPOST by Sierra On-Line
Post by: Hooman on September 01, 2019, 10:20:10 AM
Sounds like you may have an out of date copy of NAS2D (or too new of a copy to match with what OPHD expects). Both the Mixer and Clamp areas were changed recently.

If you cloned the OPHD repository from GitHub, you may want to Init and Update submodules. That should download a matching version of NAS2D into a subfolder.

If that doesn't help solve your problem, maybe try posting what version you have of each repository, giving perhaps a commit hash or date/time/message. It's possible we could have messed up the version dependencies during an update and not noticed.



Edit: Oh, and welcome to the forums :)

Edit2: I think your version of NAS2D is too new. Updates are often made to the library using the built in unit tests to verify them. When working on these updates, the focus is mainly on the library. We often don't get around to pushing corresponding changes to the main game until sometime later. A git submodule update from the game should checkout a matching version of NAS2D.
Title: Re: OutpostHD - An Open Source Remake of OUTPOST by Sierra On-Line
Post by: leeor_net on September 05, 2019, 01:41:41 PM
Apologies for the late reply. The last few weeks have been... rough. I'll be posting a separate topic about that and where things lie in terms of development.

You pulled from the main branch of OPHD -- try the v0.8.0-develop branch (https://github.com/ldicker83/OPHD/tree/v0.8.0-develop).

Thanks for your interest! And sorry about the confusion. There were many changes made to NAS2D on the back end (such as removing NAS2D::clamp in favor of std::clamp) that haven't been merged into the main branch yet. You'll see that the main branch is 20 some commits behind the development branch.
Title: Re: OutpostHD - An Open Source Remake of OUTPOST by Sierra On-Line
Post by: ekztal on September 05, 2019, 09:59:58 PM
Thank you for trying to help.  I just tried pulling from the development branch you linked, and re-downloading the api.zip and assets.zip listed in your original post.  I added include directories where NAS2D was downloaded but I still have the same problem.  If I can't even figure this out seemingly single step out I doubt I have any business messing with source code.
Title: Re: OutpostHD - An Open Source Remake of OUTPOST by Sierra On-Line
Post by: leeor_net on September 06, 2019, 09:34:39 AM
Believe it or not, setting up the environment is the hardest part. We call it dependency hell for a reason. It's usually a simple problem but it's not at all an easy one to tackle if you're unfamiliar with what the project expects.

I'll see if I can get something written up a bit better to help get the environment set up the way it's supposed to be. Chances are I haven't put up the most up to date versions of NAS2D -- I have a bad habit of using builds that I haven't actually released yet.

I'll have some time this weekend (I think), I'll see if I'm up for working with code.
Title: Re: OutpostHD - An Open Source Remake of OUTPOST by Sierra On-Line
Post by: Hooman on September 18, 2019, 04:39:24 AM
Sounds like you are downloading NAS2D separately from OPHD. That an obvious thing to do, but can lead to mismatched versions. And we're not very good at tracking release versions.  ::)

I'd recommend using Git to download both repositories together. The OPHD project has a Git submodule reference to the NAS2D project. If you use the submodule update from within the OPHD repository, it should fetch the NAS2D project for you, and checkout a matching version. Unfortunately, Git doesn't tend to fetch submodules by default. I really wish it would.

When you clone the repository, sometimes you can choose to clone recursively, which should also fetch submodules. Failing that, once a repository is cloned, you should be able run a Git submodule init, followed by a Git submodule update. Do that from the OPHD repository, and it should give you a matching NAS2D library in a subfolder to build with.

Don't just copy one repository into a subfolder of the other. I know it can be tempting if the default clone gives you an empty "nas2d-core" folder, but you don't want to just copy stuff in there. It won't work the same. When you use the submodule feature, the hidden ".git" folder of the parent project will be shared between both repositories. The submodule will just have a small ".git" file which gives the relative path to the parent repository's ".git" folder. By using the Git submodule features, you'll enable Git to match up the versions of the two repositories.


Of course I'm assuming you're using a Git client to pull the changes. If you don't have a Git client installed, and are just downloading raw zip files, we'll have to come up with a different plan.
Title: Re: OutpostHD - An Open Source Remake of OUTPOST by Sierra On-Line
Post by: JetMech1999 on November 13, 2019, 06:56:12 PM
So, Leeor,

I recently got Stellaris Console Edition for my Xbox 1.  Looking at the screen, particularly the top of the screen, I see icons and resource amounts that look strikingly similar to OPHD.  Just out of curiosity, did you happen to get some inspiration for the screen design from Stellaris, or is this strictly coincidental?
Title: Re: OutpostHD - An Open Source Remake of OUTPOST by Sierra On-Line
Post by: leeor_net on November 15, 2019, 06:40:32 AM
Coincidental. I've never played Stellaris. Though you're right, it does look similar in a lot of ways. It's always annoying when that happens.

Wouldn't it be interesting if they copied me? Hehe, unlikely, I know, but I did start and release a beta build of OPHD about a year before Stellaris released. :D
Title: Re: OutpostHD - An Open Source Remake of OUTPOST by Sierra On-Line
Post by: JetMech1999 on November 15, 2019, 05:03:36 PM
It's nice to know you're still kicking around.  Hope everything is settling out okay.  Looking forward to seeing some more new stuff.
Title: Re: OutpostHD - An Open Source Remake of OUTPOST by Sierra On-Line
Post by: leeor_net on November 15, 2019, 09:16:14 PM
Most definitely still kicking and feeling better than I have in years. It's been real busy in real life as of late -- I was promoted at work and given a brand new retail store to operate --- so the last few weeks I've been spending a lot of time with that. BUT, I've also started sort of poking around the code and getting myself re-familiarized with it so I can start implementing the v0.8.0 roadmap (truck routing and mine operations). After that I want to push research and start making the game more interesting with the ability to actually progress besides just building outward!
Title: Re: OutpostHD - An Open Source Remake of OUTPOST by Sierra On-Line
Post by: JetMech1999 on November 18, 2019, 05:03:21 PM
Congrats on the promotion and best wishes to you with the store!
Title: Re: OutpostHD - An Open Source Remake of OUTPOST by Sierra On-Line
Post by: Hooman on January 04, 2020, 02:06:38 PM
So for those who were trying to build OPHD and were getting compiler errors (particularly about clamp and Mixer), there have been some recent fixes. It seems about 6 months back, a version of OPHD was checked in on GitHub that had a mismatched version of OPHD and NAS2D, which led to build errors. This went unnoticed for quite some time. I just kind of assumed things were working when I gave earlier advice about using Git with a recursive clone to get both projects together with matching versions. Turns out I was wrong about the versions actually matching, so people following my earlier advice would definitely have seen the errors mentioned earlier.

The error has now been fixed, thanks to Leeor. If you checkout the current version of the code, it should compile.

I'm just testing it out now with the data assets linked from the first post in this thread.
Title: Re: OutpostHD - An Open Source Remake of OUTPOST by Sierra On-Line
Post by: Longjump on July 15, 2021, 09:07:59 PM
I remember Outpost from when I was young! Glad to see people are still interested. I tried the linked version (0.8.3) and enjoyed it greatly! This isn't intended as criticism, as often my own age and limited perceptions are often at fault; I seem unable to establish a running colony. I landed the seed, started mines, dug, placed buildings being frugal with resources; every time, no matter what combination of planet/buildings/timing I attempted, within a few turns of placing the CHAP facility, my colony runs our of common metals, and the CHAP shuts down; more metals come from the mine and it reactivates for a turn or two, then uses the rest of the metals and shuts down. The cycle continues, and I am unable to gather enough resources to build a second robominer. Several attempts, I have built two mines; once I tried building more trucks; both times, the mines ran out of common metals and my colonists died within 70 turns of the game beginning. Am I missing something? I can't seem to find any information in game or online about the details or specifics on game mechanics, and the youtube video which demos the game begins from a previous save. Thanks for your time and effort!
*Also thought I'd mention when I looked at the research tree ( https://drive.google.com/file/d/14Z044zgUGCvQ9_cLovHoaFaoCLY8xYze/view?usp=sharing) linked in another post, it just looks horribly blurry when I zoom in to read the words. Can't seem to save it anywhere either.
Title: Re: OutpostHD - An Open Source Remake of OUTPOST by Sierra On-Line
Post by: leeor_net on July 16, 2021, 09:02:49 PM
Thanks for the feedback!

There are some issues with 0.8.3 that are resolved in the 0.8.5 branch -- I wanted to have a new release last week but that didn't happen... so I'm looking at this weekend! Should make it a bit easier.

There is a balancing issue with the cost of buildings and robots -- they're too expensive. I noticed this while doing some test plays; common metals are always very very scarce even with multiple mines. You can improve throughput by building more trucks and assigning them to mines (side note, the trucks don't save properly in 0.8.3 so when they're assigned if you save and reload you lose the trucks unless you move them into warehouses first).

You can get some much needed resources by bulldozing your landers early on. Don't go too crazy until you have storage tanks built as the Command Center has very limited resource storage capacity.

Unlike the original game, when you bulldoze a building you don't need a recycling center to get the materials back. Instead the materials are sent back to the Smelter for refinement. I think right now I have the return rate at 90% of the cost of the building.

You will need the recycling facility to manage waste produced by residential units. If you let waste build up it'll start to tank your morale which is hard to build back up.
Title: Re: OutpostHD - An Open Source Remake of OUTPOST by Sierra On-Line
Post by: Mordithrahl on March 31, 2023, 08:44:29 PM
Just popping in to say that I am amazed at the progress so far. I sort of miss the epic music at the start, and its a bit odd being turn-based instead of real time. A undo button would be cool. But overall - this is terrific. So much nostalgia shot into my veins. Hope this project is still going!
Title: Re: OutpostHD - An Open Source Remake of OUTPOST by Sierra On-Line
Post by: leeor_net on April 01, 2023, 10:37:16 PM
Thanks for the words of support!

Yes, the project is still very much going on. 2022 was kind of a rough year for me which is why progress kinda ground to a halt. Medical/Health issues that made it difficult to concentrate.

I've mostly recovered at this point and I've started making additional progress. I've resolved a number of issues that have been reported including the Command Center collapsing due to maintenance decay (definitely a bug, self-contained structures aren't supposed to need maintenance as a gameplay mechanic), structure/factory resources costs have been adjusted and a bunch of other under the hood stuff.

I'm preparing a v0.8.7 release here to make the game a bit more stable and easier to use. I'm also going to be able to release a proper macOS app bundle for the first time now that I have a couple of macs around that I can test development on as well.

After that I'm going to finish the push for research and go from there especially with some quality of life UI improvements primarily centered around getting better feedback from the colony and about what's happening from turn to turn.

An undo function isn't a bad idea. I'll have to think about that one a bit as it would almost be a cheat. Could maybe even have it save a few turns to go back... make it a beginner option? I dunno, I'll see how I feel about it and go from there.
Title: Re: OutpostHD - An Open Source Remake of OUTPOST by Sierra On-Line
Post by: ytszazu on April 08, 2023, 08:52:52 AM
As someone who played the original outpost during my school years, (until launched the spaceship), OutpostHD is very good project. Keep up with it.

One thing caught me off balance though, the air generator uses too much one of the resources, but other than that, good work so far.

Can't wait for your next update to OutpostHD.
Title: Re: OutpostHD - An Open Source Remake of OUTPOST by Sierra On-Line
Post by: leeor_net on April 09, 2023, 10:09:23 PM
Thank you!

I just pushed out a new version which balances the cost of structures and robots. The CHAP may need some balancing as well, will look into it going forward.

Give it a try ant let me know!
Title: Re: OutpostHD - An Open Source Remake of OUTPOST by Sierra On-Line
Post by: ytszazu on April 10, 2023, 10:02:28 AM
Played up to turn 150+

1) Around turn 120+ the game starts to crash alot. There was a time it reaches a point where everytime i hit the same turn it crashes, so i loaded a previous save and built differently. Anyway to export crash logs? Or send save files over?

2) Resources in game is much more manageable now, at least for Mars.

3) Which buildings do not serve any function yet? Research lab, hot lab, underground factory and underground commercial centre?

4) I have two nurseries, one university, habitat at < 100% and one red light district, however, the workforce population keeps dropping. Happiness > 600

5) Any function for clothing and medicine?

Anyway, good update so far, need to reduce the crashes through. Playing using the same computer as the previous OutpostHD one. Q6600, 8gb Ram, GTX 460.
Title: Re: OutpostHD - An Open Source Remake of OUTPOST by Sierra On-Line
Post by: leeor_net on April 10, 2023, 11:49:38 AM
You can attach save files here, they would be really helpful in figuring out the crashing. I have a feeling it's something dumb I forgot to address.

Labs are the only ones off the top of my head that serve no purpose yet. The UG factories can build items but they're not really consumed yet at this point. UG Commercial improves morale.

Population model needs to be improved. Working on it :D
Title: Re: OutpostHD - An Open Source Remake of OUTPOST by Sierra On-Line
Post by: ytszazu on April 11, 2023, 02:16:44 AM
May i know where is the location of the save files? Thanks
Title: Re: OutpostHD - An Open Source Remake of OUTPOST by Sierra On-Line
Post by: leeor_net on April 11, 2023, 01:39:43 PM
It's in the AppData folder in your user directory. It's typically hidden by default. If you launch the game and click Continue, the file picker window will come up. There's a button at the top right that should open the folder for you. (see attached image). In my case it breaks because there's a space in my user name... will have to address that in the next patch.

As a note this is not currently working on macOS (will work on figuring that out).

Also if you are getting any error messages, screenshots of those would also be really helpful.

Finally there is a log that OPHD generates in its launch folder, it's called ophd.log, that could be useful too.

--

But yeah, it's weird that it's so unstable for you. I tried playing the game a few times on three different computers (my main development machine, my macbook pro and my mac mini) and haven't had any crashing.
Title: Re: OutpostHD - An Open Source Remake of OUTPOST by Sierra On-Line
Post by: ytszazu on April 12, 2023, 07:47:57 AM
Hello there,

Here are two save files.

1 10 is working
1 11 will crash upon pressing next turn.

Anyway, i reloaded save file 1 10 and played until turn 230, then it crashed again, refer to the crash screen picture.
Title: Re: OutpostHD - An Open Source Remake of OUTPOST by Sierra On-Line
Post by: leeor_net on April 13, 2023, 09:17:05 AM
Ah so it just hangs, no error message? Huh. Will definitely look over this. I played a few games on a few different computers without issue so interested to see what's going on here :D



So in 1 11 game this is in the data:

Code: [Select]
<structure age="8" crime_rate="0" depth="1" direction="1" disabled_reason="0" forced_idle="false" idle_reason="0" integrity="95" pop0="2" pop1="0" state="1" type="18" x="53" y="96">
<waste accumulated="966440236" overflow="-2147471807" />
</structure>

So interesting. This looks like a residence... and the overflow value... overflowed. The accumulated value is also very weird. Suspecting this is where I'm going to take a closer look.
Title: Re: OutpostHD - An Open Source Remake of OUTPOST by Sierra On-Line
Post by: leeor_net on April 13, 2023, 06:41:01 PM
Ran it on my development machine and... ... ew. This is a scary bug. Not sure how this was managed but the savegames you provided are extremely helpful!

If you're able to figure out the steps you used to get the game into the state that they're in (e.g., saving/loading, reloading, etc.), let me know. In the mean time I've got some bug hunting to do!
Title: Re: OutpostHD - An Open Source Remake of OUTPOST by Sierra On-Line
Post by: ytszazu on April 14, 2023, 04:40:25 PM
Hello there,

The attachment contains another of those failed saves.

It might be the saving process, as i did not do much except bulldoze a few tiles.

Another assumption is because i bulldoze the robot command center and have about 5 dozers "deactivated somewhere" after bulldozing the robot command center. (due to not enough workforce)
Title: Re: OutpostHD - An Open Source Remake of OUTPOST by Sierra On-Line
Post by: leeor_net on April 14, 2023, 04:50:12 PM
That's a really good observation. There is no check in the code atm for whether or not there is storage for robots if an RCC is bulldozed. Not sure if that would cause stack/heap thrashing but it's definitely a clue!
Title: Re: OutpostHD - An Open Source Remake of OUTPOST by Sierra On-Line
Post by: ytszazu on April 21, 2023, 09:13:23 AM
Hello there,

May i know what is your plans for the next version? Estimated date release?
Title: Re: OutpostHD - An Open Source Remake of OUTPOST by Sierra On-Line
Post by: leeor_net on April 26, 2023, 06:25:17 PM
A fudge, I thought I replied to this. Probably forgot to hit post.

So I can't say for sure, but the biggest block for me right now is figuring out what the research screen itself should look like. UI/UX design is confounding to me... What I have now is either super kludgy (see Factory Production Window) or someone else designed it and I just made it functional (see factory production full screen UI and mine full screen ui).

That stated, a lot of the research implementation is already complete in the code -- it's why the Fusion Reactor and Solar Receiver Array structures are no longer available to build (until the appropriate research is completed).

So assuming I can figure out a basic idea of the research UI, it shouldn't take more than a few weeks to get it implemented and pushed out for release.
Title: Re: OutpostHD - An Open Source Remake of OUTPOST by Sierra On-Line
Post by: ytszazu on June 05, 2023, 08:26:24 AM
Checks here once a month to see if got any updates :)
Title: Re: OutpostHD - An Open Source Remake of OUTPOST by Sierra On-Line
Post by: leeor_net on June 11, 2023, 11:34:38 PM
So there's actually a lot changed under the hood with the new research interface partially built. I might go ahead and make a v0.8.8 release for ya, see if some of tgst crashing is improved.

Ivve still not been able to reproduce the conditions your save game ended up in. Really really weird. But we have found and squashed some other defects that may be related.
Title: Re: OutpostHD - An Open Source Remake of OUTPOST by Sierra On-Line
Post by: ytszazu on July 15, 2023, 06:57:30 AM
Monthly check in.

Of course i am intrested to test any new releases. :):):)
Title: Re: OutpostHD - An Open Source Remake of OUTPOST by Sierra On-Line
Post by: leeor_net on August 05, 2023, 09:36:21 AM
Haven't made a whole lot of progress in the last month -- work moved me to another store so that's occupied my time and I got a paid gig to help develop some parts of a commercial game so my time has been focused on that the last couple of weeks. So not dead, just on the back burner for a bit :D
Title: Re: OutpostHD - An Open Source Remake of OUTPOST by Sierra On-Line
Post by: ytszazu on August 11, 2023, 08:33:06 AM
"Jumps in"

Monthly check in!!!!

"Jumping out"
Title: Re: OutpostHD - An Open Source Remake of OUTPOST by Sierra On-Line
Post by: Hooman on August 11, 2023, 01:29:03 PM
Ahh yes, subtle hints we should get back to work on this.  ;)
Title: Re: OutpostHD - An Open Source Remake of OUTPOST by Sierra On-Line
Post by: ytszazu on October 20, 2023, 07:24:35 AM
Monthly peek-a-boo!
Title: Re: OutpostHD - An Open Source Remake of OUTPOST by Sierra On-Line
Post by: Sirbomber on October 20, 2023, 01:12:49 PM
You should probably hop on the official OPU Discord channel (https://discord.gg/kDz5Q3t) if you want to stay up to date on things.
Title: discord is a bad piece of software with a dangerous T.o.U.
Post by: VileTerror on October 23, 2023, 07:15:46 PM
But there's a wonderful forum right here!
Title: Re: OutpostHD - An Open Source Remake of OUTPOST by Sierra On-Line
Post by: Arklon on October 28, 2023, 04:59:52 PM
But there's a wonderful forum right here!
To each his own, but really we're all here for a niche cult hit from the 90's RTS, itself a genre that's even more abandoned than Arena FPS is now. Let's not pretend as if QuakeNet IRC was any better though. :P
Title: Re: OutpostHD - An Open Source Remake of OUTPOST by Sierra On-Line
Post by: leeor_net on November 28, 2023, 10:21:48 AM
I know I've been a bit quiet as of late -- mostly I've just needed a break from coding in general.

Definitely haven't forgotten about the project. Holidays are usually a bad time for me so not sure when I'll get back into the swing of it.

Anyway, I've been hyping myself up to push for 0.9.0 -- the biggest bottleneck is the research interface. I'm getting stuck on trying to make it perfect the first time around. So I've been telling myself that I just need to get it working and can make it better later.