Issues and bugs

[robocat04]

Hello. I found that while bot is aiming or turning it can't do anything else until it finish aiming/turning and it makes impossible writing of ideal program (for example, in my case) for shooting wasps flying past you because you can't make my bot turn and aim at the same time. And although it can be somehow solved by using motor(); instead of turn(); and adding a little extra values to aim(); it is bad, really uneffective solutions. Thus, I think, it would be better, if the devs will make turn(); and aim(); not delay the whole program. Or maybe make a modes for these instructios which will define: will they delay the program or not. Or you know what? I think it's time to implement threads. Though I don't know, maybe someone is already doing it or I just missed something. But in general there's plenty of things to do.

And yeah, I understand that a whole topic for such little details is too much, but I didn't found a related topic.

UPD: I forgot to tell you about some bugs (and I didn't found them at github and I also currently have no accounts there). These I got under Linux (debian). Maybe it fixed in latest versions, as I have not latest Colobot version from debian testing repos.
1. When the saved game is loaded, some information, such as absolute time and all current variables, lost. It is, of course, more important than issues above.
2. After some time after launch game may hangs and then I have to kill it's process.
And this is one that I found under windows 7 (then didn't even continue) within the latest colobot version (both user and dev).
1. Game can't find screenshots for saved games and after I loaded one, i see that even programs of all objects lost - even insects becomes dumbs. Changing directories in configuration file didn't help.

Also sorry for my english if it's little incorrect.

[tomangelo]

CBOT will be rewriten in the future, we will think about this.

[robocat04]

That's good. I'll see it.

---

Hm, I have a thought about insects. Unlike ants spiders are completely not dangerous if you have at least one shooter. What if make modes of moving for them (walk/run) and make "run" mode very fast? Because IRL spiders, if you count their size, are really very fast, faster than champions-runners. And also decrease time of exploding for them? And it's good idea to make wasps do not slow down while approaching to position by goto(); and do not wait any time after this instructions completed. These two insects should be more dangerous than even ants which we meet on many missions. Although I don't have any ideas about worms - they're quite don't seems like real enemies. Maybe make them fully paralyze bots and buildings?
P.S. As far as I remember, when you moving wasp by motor() instruction, sometimes wasp may stuck at high buildings like defense tower when they're over them, and there's no way to make them free.

---

Well, there's the conclusion of my thoughts about what needs to be changed for a better gameplay.


At first, these moments:
1. The astronaut's suit should fully protect it's carrier, but take damage upon itself (but, of course, slower than bot's shield) and restore only during the spaceship flying from one place/planet to another. Explanation of this - special material of the suit, which was made on the Earth, and repairing of it on the ship while astronaut resting from it. Because how it happens now seems totally implausible (including squirting blood and lack of injuries), especially in case of a fall from height.
2. All the fresh ruins and wrecks after loading saved game drops their original models to the same one - it shouldn't be so.
3. Vault and Houston also should be indestructible. But it solves with magnifyDamage=0.0 parameter in a mission file.

There's also some changes in the instructions needed:
1. Bots and insects should not be slowed down while approaching to the destination point by executing instruction goto().
2. Maybe it's a good idea to make defense tower more precisely? I mean, they will shoot not to the point where they took aim at the beginning but where an enemy is at the current moment of time. Good programmed wasps can easily fool them and the ants which is down a steep slope has a chance to shoot. Thats why here it is even more efficient to use right programmed bots than defense towers. But it is written in satcom, that defense towers is the most efficient protection against any insects regardless of where they attack from, which is not very like the truth in this case.
3. Or maybe it's better idea to give to player capability to program them too? And then give to every new defense tower default program which is going by the old scheme.
4. Instructions aim(), fire() and turn() should not delay the whole program. Either separated threads for engine, gun/grabber and logic should be realized.
5. Capability to exclude already found objects (which will be contained in arrays) from searching should be added to radar() instruction.

And insects also should become more dangerous:
1. Wasps will be able to use any objects like titanium cube or uranium ore as projectiles but they will damage targets much less than orga-matter.
2. Orga-matter should not explode if it dropped by wasp which is on the ground at this time.
3. As I written above, instruction goto() should not slow down bots and insects, but to wasps it relates especially - they at all shouldn't slow down while approaching to their target. Even in satcom it is written that the wasps are very formidable enemies (at least in the translation to my language) - then let's make them such!
4. Also maybe it's good idea to make them little faster in flight? However, flying winged shooters won't be able to chase them, but I'm not sure that it's important. But after all these changes it will be able to organize full avia-raids!
5. The idea about wasp's ability to transport ants and spiders which I've seen at one of the topics - I liked it and I'm really for this.
6. Spiders should run more faster and explode faster and at a greater distance. Perhaps two movement modes - walk and sprint - should be implemented for them. And as some of you may know, IRL spiders, if you count their size, of course, are more faster than even runners-champions.
7. Most likely explosion of a spider should ignite everything around, including another insects. Possibly excluding another spiders (if their incendiary liquid is incendiary by itself, not in contact with air) and partially queen (which will take very low damage from these incendiary particles).
8. It will be better if worms will paralyze not the programs executing of bots, but themselves. Because at this moment they even don't seems like real enemies!

---

I want custom researches. I just want it. And possibility to change reactor range for all winged bots on the map, including those that built in the bot factory during the game process. I hope, it will be possible after code refactoring...

---

I would be glad to have an instruction for worms that will return level of their submersion in the ground - 0.0 would mean that worm is fully on the ground and 1.0 would mean that worm is fully underground.
Maybe it's not so difficult as custom researches...

---

I found now that worm's model done badly:
http://i.imgur.com/gsYYu7j.png
As you can see in this picture on a quite steep slopes and ledges worms stretches wrong and their parts tends to break away from each other.
About spiders, I found this long ago - when you thumping while a spider in the radius and then you getting closer then you discover this situation.
http://i.imgur.com/7V2kj0H.png
Spider upside down but it's program still tries to make it explode despite it's position. And the spider can't nor explode nor not explode. It would be possible to get a spider do not explode in this position but there even isn't any instruction that returns it's position.
As for me, it seems like original colobot devs was really sloppy.

[Bot2Hot]

Hi guys,

I want to help with some things I 've found so far but I don't have enough time to sign up at github and check if these bugs are already known so far.
So please don't flame me

Im using alpha 1.3 Debian-Build on a linux box.

Code:

dpkg -l|grep colobot

ii  colobot                  0.1.3-1 amd64 educational programming strategy game
ii  colobot-common           0.1.3-1 all   educational programming strategy game - data
ii  colobot-common-sounds    0.1.3-1 all   educational programming strategy game - sounds and music
ii  colobot-common-textures  0.1.3-1 all   educational programming strategy game - textures

- nuclear cells can't be found by radar. item.position has undefined values for them.
Workaround so far is taking them out of the nuclear plant by waiting 35 seconds then grab and then using them directly without any dropping in between.

- the file requester box shows files mixed, no sorting possible. I miss the ordinary headlines in order to sort by name/size/date

- sometimes reading/saving gets crumbled filenames. so LongFilename.txt gets sometimes LongFilename. or LongFilename.tx.txt

- programmes with umlauts ÖÄÜöäüß get strange characters and dont work anymore

- Changing the appearance of the Astronout leads to white rendering of him although it works later on but you cant modify things in realtime (in the meaning of youll see nothing).

- The maximum font size just looks acceptible. The min is way to small. Can you add more/bigger size like 3 more steps to maxium font size?

Suggestions for features I would like to have (maybe you too):
1. It is possible to use public functions for all bots. If the bot with the public function in its memory get's distroyed the code gets lost also...
So why not make the spaceship be able to have those public funtions in its memoy (add Programme -registers like for the bots, but code  only with "public" can be used).
Then any robot can access those functions and in case of a bot being destroyed the public function code still exists.
As the SpaceShip is the base station of all so tho speak you could explain this with its communication nature and surely any remote control of any bot is being send from here.

2. A dual-screen solution would be very useful, so having the original Colobot window on screen 1 and on screen 2 you have either SatCom or the CBOT-Editor as own windows. Maybe just seperate windows for each are enough to achieve this. Also a sperate window for the "watch" (=showing variable values of any relevant information) would be a good idea. At the moment the space under the editorfield is very small.

3. Add some more screen resolutions (or free aspect so everybody can finetune to his/her own monitor).

4. I miss breakpoints in the editor for debugging. One button more like "run until breakpoint" and a seperate mark per line would be enough ... like we are used to in Microsoft VBA for example.

5. I'v got all the 58 user-developed programms that used to be on the Epsitec Homepage where they are no more accessible. Where can I send/upload them?

6. There should be a code-exchanging place. Is the wiki or this forum the place for them and especially where precisely ?

Thanks for reviving this excellent game... :love

[krzys_h]

Im using alpha 1.3 Debian-Build on a linux box.

Code:

dpkg -l|grep colobot

ii  colobot                  0.1.3-1 amd64 educational programming strategy game
ii  colobot-common           0.1.3-1 all   educational programming strategy game - data
ii  colobot-common-sounds    0.1.3-1 all   educational programming strategy game - sounds and music
ii  colobot-common-textures  0.1.3-1 all   educational programming strategy game - textures

This is kinda an old version. We've already released 0.1.4 and we're almost ready to release 0.1.5 (once I find some time to prepare release builds for download).
I have no idea how Debian/Ubuntu packages are updated, but I think @OdyX has to do this since he is the package maintainer.
You can get the latest release (0.1.4) and development 0.1.5 builds on our main page - http://colobot.info/download-colobot-gold/

---

- nuclear cells can't be found by radar. item.position has undefined values for them.
Workaround so far is taking them out of the nuclear plant by waiting 35 seconds then grab and then using them directly without any dropping in between.

If you can't detect a NuclearCell inside NuclearPlant, that's because it's not standing on the ground. Use this instead:

Code:

object plant = radar(NuclearPlant);
object cell = plant.energyCell;

If you can't detect it in any other case, that's either a bug we don't know about or the level author blocked scanning of that object on purpose by using proxyActivate=true with proxyDistance=0.

- the file requester box shows files mixed, no sorting possible. I miss the ordinary headlines in order to sort by name/size/date

That would be nice to have. Added to GitHub - https://github.com/colobot/colobot/issues/476

- sometimes reading/saving gets crumbled filenames. so LongFilename.txt gets sometimes LongFilename. or LongFilename.tx.txt

That has been partially fixed in 0.1.4, you still can't use too long filenames, but it won't append .txt if it would get cut off.

- programmes with umlauts ÖÄÜöäüß get strange characters and dont work anymore

I remember that there were some problems with Polish characters like ąćęńśżź too. Keep in mind that you shouldn't be able to use them as a program name because it's like a function name, but the problem still exists in message() function.
A workaround seems to be to copy them from an external text editor.
Added as https://github.com/colobot/colobot/issues/477

- Changing the appearance of the Astronout leads to white rendering of him although it works later on but you cant modify things in realtime (in the meaning of youll see nothing).

That's one of the oldest bugs in Gold Edition that we still didn't find a way to fix properly. Temporary fix is coming in 0.1.5 soon. See https://github.com/colobot/colobot/issues/94

- The maximum font size just looks acceptible. The min is way to small. Can you add more/bigger size like 3 more steps to maxium font size?

I think this was done already since 0.1.3 but I'm not sure. That was a long time ago.

---

1. It is possible to use public functions for all bots. If the bot with the public function in its memory get's distroyed the code gets lost also...
So why not make the spaceship be able to have those public funtions in its memoy (add Programme -registers like for the bots, but code  only with "public" can be used).
Then any robot can access those functions and in case of a bot being destroyed the public function code still exists.
As the SpaceShip is the base station of all so tho speak you could explain this with its communication nature and surely any remote control of any bot is being send from here.

I was also thinking about some way of protecting public functions from being lost by destroing robot that holds them. The main problem with using SpaceShip as memory for public functions is that it's only available in missions mode, you wouldn't be able to use that in free game, exercises and challenges.
Also, any changes to CBot will have to wait until we rewrite the whole compiler. It's really ugly right now, and it's hard to change anything without breaking everything else.
https://github.com/colobot/colobot/issues/478

2. A dual-screen solution would be very useful, so having the original Colobot window on screen 1 and on screen 2 you have either SatCom or the CBOT-Editor as own windows. Maybe just seperate windows for each are enough to achieve this. Also a sperate window for the "watch" (=showing variable values of any relevant information) would be a good idea. At the moment the space under the editorfield is very small.

That's a very good idea. I never throught about that. Added to GitHub: https://github.com/colobot/colobot/issues/479

3. Add some more screen resolutions (or free aspect so everybody can finetune to his/her own monitor).

I throught that 0.1.3 had the ability to resize the window by dragging the corner. This was disabled later due to some issues with reloading textures after changing resolution. We probably have to ask @piotrdz or @tomaszkax86 about that since I don't really know much of OpenGL/SDL.
See old issue https://github.com/colobot/colobot/issues/339

4. I miss breakpoints in the editor for debugging. One button more like "run until breakpoint" and a seperate mark per line would be enough ... like we are used to in Microsoft VBA for example.

That would be awesome, but needs to wait until CBot rewrite.
https://github.com/colobot/colobot/issues/480

5. I'v got all the 58 user-developed programms that used to be on the Epsitec Homepage where they are no more accessible. Where can I send/upload them?

We already have a mirror of them. See http://colobot.info/forum/showthread.php?tid=190 and http://colobot.info/forum/showthread.php?tid=348

6. There should be a code-exchanging place. Is the wiki or this forum the place for them and especially where precisely ?

We used to have a page where we published programs, kinda like the old Epsitec site. It's still available under http://colobot.info/programdb/, but it's going to be moved to our Wordpress-based main page when I find some time. Also, most of the old programs are available only in Polish.
Also, I've noticed that there is really no good place on our forums to put things that work both in original and gold edition. Feel free to use either one of Workshop forums for now.

---

PS. Did you see the awesome dynamic shadows that @tomaszkax86 implemented recently?

[Bot2Hot]

Hello again,

now I've updated to colobot 0.15-2 (debian linux). Thank you for telling the debian guy to update this package.

So far I've found these things:

Translation errors:
In a lot of satellite reports you tell in German about "Platinerz"(=platinum ore) that doesn't make sense. It should be "Uranerz" (=uranium ore).
Also the term "Energiefelder" (=energy fields) sounds wrong. Only related to Oil (Ölfeld) it sounds right. So it should be better translated to "Energiequellen" or "Energievorkommen". If this is a problem because of string length you could use "Energ.quellen" (13 chars) as a abreviation.

Filehandling:
filepath of user programs is /home/username/.local/share/colobot/savegame/Spieler/program/xyz.txt
subdirectories in this directory are listed as if they were files with size 4096, so no subdirectory can be used.
The file sorting in now alphabetically, thanks. As minor hint I detected that filenames are case sensitive (lower case files are displayed way after upper case filenames). Perhaps this is only relevant on linux machines and doesn't occur on Windows machines.

Missions:
freemission 1 Leaving Earth:
- it is only possible to build a robot factory but nothing else. How to play this level then ?
- only wheeled robot can be built in the robot factory
- cheat codes / CTRL-Pause do not work anymore so no workaround possible
- no satellite report tells us information about ores, energy, etc.
- how to start other free missions like going to other planets? Seems not to be possible right now.

mission chapter 3 tropia 5:
- It feels inconsistent that you know already how to build a subber. In the past and in future missions you had to research everything first. So I want to suggest that you should please add the possibility to build a research lab to spaceguy and revert research status.
- I like the wrecks under water very much - there should be more under water wrecks in other missions.

mission chapter 4 cristallia 1:
- in SatCom controllcenter you don't get information on how to end the level. But I'fe read English an French mission text also. Only in the solution texts you get a hint what to do.
- I'm stuck although I could end this level in colobot 0.13-1. I've built the radar at the same spot as in 0.13-1 and defend tower nearby so the red circle showing the defending range is much bigger than the radar position. I also killed all warms (controll center didn't tell you have to kill'em all, got this hint from solution only). Nevertheless I can't start the rocket after getting on board (with wheeled grabber, winged grabber, winged shooter an spaceguy).

Other suggestion:
I had the idea to keep public functions surving destroyed robots by having a program-storage in the rocket. krzys_h told me that freemission doesn't provide a rocket. So why not add a program-storage for public functions in the spaceguy remote control unit/satcom device?

Old bugs:
I can confirm that the rendering issue of the spaceguy appearance now is ok in 0.15-2.
Maximum font size now looks a bit bigger than in 0.13-1 but could be improved nevertheless.

[tomaszkax86]

Thank you for your input.

The "platinum ore" is actually legit version of translation. There are two alternate categories that actually work in Colobot: PlatinumOre and FuelCell. Someone probably didn't like the idea of having nuclear power in game so they implemented "less dangerous" aliases. I think it was used in some CeeBot games as well. As for translations, we'll correct them when we can. Unfortunately, not many people here know German well enough to translate things so we rely on other people.

I don't use Linux so I can't properly test those things. Although I know that Linux does treat files in case-sensitive way unlike Windows. We'll see what we can do about it.

Free missions are currently designed in such a way that you only have access to stuff you unlocked in main missions. So if you didn't unlock flying, you won't be able to fly. We might change that in the future.

Subber was available that way in original game. There are many such inconsistencies. We might correct that in the future when we refactor stuff.

I tested Crystallia mission 1 and can pass it just fine. Are you sure you built a radar in the right place?

We'll still thinking what to do with public functions. I suggested using Exchange Posts for that. They're kinda useless so we could reuse them by adding more functionality.

[Simbax]

You all really need to be punished before you actually obey the rules, eh? Okay, that's the last time that ended without any warning points. I'm closing this thread and each one similar to this one. Read this: http://colobot.info/forum/showthread.php?tid=617.