hexagonrecursion

Functions

An external function replaces the runnig public function

• Can crash the game: ❓ unknown
• Bypasses typechecking: ✅ no

1. Program A defines a public function
2. Program B uses the function
3. Program B is in the middle of running the function or in the middle of executing CBotInstrCall before calling the function
4. The game is saved
5. A new version of the game introduces a built-in with the same name

hexagonrecursion

1. UI to see all systems in range that import/export a given commodity
2. Make it more obvious that you can jump to two destinations in a binary system
3. In system jumps in a binary system - because I often forget to choose the correct destination

hexagonrecursion

I have played Pioneer and I woud describe it as a game with potential. Currently Pioneer like a number of other openworld games has an acute content problem. It is relatively easy to simulate a wast empty canvas, but a much bigger challenge is to fill this space with enough stuff for the player to see and do.

The current randomly generated missions fail to fill this void for me. They feel generic, abstract, same. Every cargo mission feels exactly the same as every cargo mission, every taxi mission feels exactly the same as every taxi mission, etc. The fact that in for many builds there is one optimal mission type (in terms of profit) aggrivates this issue. Plus: after a certain point trade becomes more profitable than missions, but again every trade feels exactly the same as every trade before it.

Games that in my opinion are both openworld and don't have a content problem:

1. C:DDA
2. Hyperrogue
3. EndlesSky
4. Thrive

hexagonrecursion

The wanderer campaign drops a lore bombshell: korath exiles know how to make jump drives.

https://github.com/endless-sky/endless-sky/blob/c7a3541850828e2d4015dc31e7bad983e35e784b/data/wanderer/wanderers%20middle.txt#L835C51-L835C149 one thing that the exiles were unwilling to give up was the knowledge of how to create jump drives

Remnant have expressed a great interest in knowing how to make jump drives. They also live near the korath exiles. I propose a mission string where remnant steal the secret from the korath.

I imagine the story would unfold something like this:

1. [Wanderers: Kor Efret 4 & Remnant: Broken Jump Drive 1] The player funds out that korath exiles know how to make jump drives and that remnant are trying to reverse engineer them.
2. [New mission string 1] The player reveals this information to remnant.

hexagonrecursion

extern void object::New()
{
	object m = radar(Me);
	while(m.shieldLevel > 0);
}

-> Illegal object

hexagonrecursion

Many levels in the game require you to find "usable objects" - bots that you did not build. Currently even in a full-auto playthrough I have to manually start programs on those robots. I want to automate that.

New function:
setprogram("<program - just like when calling factory()>", <bot - optional; default - closest>)

1. stop the current running program (if any)
2. start the supplied program
3. can be used on `this` - has effect similar to unix exec()

hexagonrecursion

What should our CBot implementation do when it detects a bug in itself? e.g. can't find a variable by m_nIdent https://github.com/colobot/colobot/issues/1494
1. assert(false) like we currently use in many places is a bit too powerful - it crashes the entire game.
2. A CBot "exception" is not powerful enough - a bunch more CBot code may run in the compromised instance of the interpreter potentially making the problem worse. Also: when I see the code throwing a CBot "exception" I expect this detects a possible user error rather than just being defensive.

It would be great to have a middle ground between a CBot "exception" and assert(false).

I propose we panic(). Here is how I think we should implement panics:
1. Unlike an exception you can not catch() an panic
2. Destructors do not run
3. Finally does not run

hexagonrecursion

try { <try body> } catch(<condition>) { <catch body> } is "magical" in CBot because it behaves very differently when you single step through your code in a debugger compared to how it behaves normally. When executed normally it periodically pauses the execution of <try body>, evaluates <condition>, and jumps to <catch body> if <condition> is true. When you single step through try in a debugger, it just executes <try body>: in single-step mode <condition> is treated as if it was a no-op and always evaluated to false.

The code that causes this can be found here:
https://github.com/colobot/colobot/blob/f07b7a1b60cd5685d7cd5f5677669423281fefa0/CBot/src/CBot/CBotInstr/CBotTry.cpp#L104-L105

This "magic" causes a real problem: it is impossible to write unit tests for try ... catch(<condition>) because we execute all our tests in step mode.

I do not know why this "magic" was created. It appears this was already present in the initial commit.

https://github.com/colobot/colobot/blob/a4c804b49ec872b71bd5a0167c3ad457

hexagonrecursion

http://www.faqs.org/rfcs/rfc1925.html

hexagonrecursion

Cataclysm - Dark Days Ahead is my favorite video game.

1. I like that in C:DDA you live and you die by your strategy and your tactics,
   • but I dislike having to start over from the beginning every time I die.
   • I like that C:DDA is moving away from that and I like the direction they chose: CleverRaven/Cataclysm-DDA#53523.
2. I like that in C:DDA most problems can be approached in many different ways depending on your resources and resourcefulness.
3. I dislike the "waiting game". Examples:
   • Sleeping for 8 hours takes about one real life minute (under ideal circumstances; much longer if you sleep in a "busy" area)

• Many crafting recipes also take on the order ~10 virtual hours (=~ 1 real life minute) to complete even after you have learned all the required skills and proficiencies