[TeeUniverse] Devlog (Page 4 of 12)

I forgot I was going to add a weight variable.  The heavier the vehicle the less a hook can move it and vice versa.  I think that Hookable is another good option. I think it would be funny to see Tees being dragged by vehicles.  Secondary weapon where if available left click would be the second weapon?

It would depend on the vehicle. You can choose to allow all passengers to use hooks including the driver or just one or the other. 

I did not think about how you would enter or exit the vehicle.  I think hooking an empty vehicle should bring you toward it and enter it. Initially I thought that you it would be first come first serve Driver, passenger 1, passenger 2 etc.  But there could be situations where I would want to just man the turret if the driver does not do that.  What about using the switch weapon keys to switch positions?  Should there be a new enter exit vehicle button?  Because if you hook it to enter you should hook to get out, and since using hooks is a possibility maybe this should not be the way to enter.

It's better to discuss it before the implementation Please continue!

b.t.w., just keep in mind that a "vehicle" could be a static turret, or an airplane, or a submarine, or a wagon on rails  ... so flexibility is needed. You can control it in a different way.

Mhhh, we need much more abstraction for vehicles. Like you pointed out, the physics and the prediction is the most important and difficult part for vehicles. That said, I think that a vehicle is simply a tee with different graphics and different bounding box. Want a airplan ? Your tee could also be superman. Want a boat ? Your tee could definitely swim. Want a mine-cart ? Your tee should be able to move on ropes. Want a turret ? Your tee can sometime be stuck on ground but still able to shoot. I don't say that vehicle must be replaced by tees, but simple that the physics and prediction part are similar for vehicles and tees. In addition, the physics of the vehicle must be still activated, even if no players are inside. But it's the same for tees because we want NPC.

So ModAPI need to implement a new type of object able to describe the physics and prediction part of anything.

Once again water and acid/lava should work mostly like this.  You should somehow have the ability to change the color, and wave size before you place the tile down.  like the video there is a lighter outline surrounding the liquid and the deeper the body of liquid the darker it becomes.

I have made the image below to show how water works.

1. Liquid at rest should stay at rest

2. when you enter a body of liquid large waves push away from the Tee

3. When you exit a body of liquid you push the water up and out.  Also while in a body of liquid you can double jump as much as you like, this is how you can swim out of water. also the double jump sound should be replaced with rushing water.

4. moving in a body of liquid makes small amounts of waves.

5. If a block of liquid drop one level then a 22.5° slope is made.  The blocks of liquid beside the slope and the slop it self looks as though water is moving down the slope at all times.  When the Tee is in the slope or below the slope you are gently moved right in this image.  Swimming against current is not that difficult.

6. If a body of water is stair stepped then 45° slope is made.  Everything is the same as #5 except the liquid and you move faster in the direction the water is moving. as well little bits of white is added to the slope and the adjacent blocks to look like rushing water. Swimming against current is a little more difficult.

7.  If two or more liquid blocks are placed in a vertical line without some liquid beside it then the liquid falls.  This time the liquid is much more viscous and moves your Tee quite fast.  Once again the adjacent blocks to the fall look as though they are being affected to the fall and white is added to look like plashing water. Swimming against current is difficult but not impossible to reach the top. This is a cartoon video game after all.

Devlog: the new weapon system is one the way. We put all weapons mechanics into classes, so it become super easy to add a new weapons or to replace vanilla ones. You just have to create a new class and change some virtual functions. No more switch and conditions spread in character.cpp

The next step is to show custom weapon graphics for the client, based on the sprite system.

Edit: this is the list of virtual functions that a weopon must implement:

virtual int GetAmmoType() const;
virtual int GetMaxAmmo() const;
virtual int GetAmmo() const;
virtual bool AddAmmo(int Ammo);
virtual bool IsAutomatic() const;
virtual bool IsWeaponSwitchLocked() const;
    
virtual bool TickPaused(bool IsActive);
virtual bool TickPreFire(bool IsActive);
virtual bool OnFire(vec2 Direction);
virtual void OnActivation();
    
virtual void Snap(int SnappingClient, class CNetObj_Character* pChar);

I've implemented a part of it and called it "EntityPoint". The idea is:

In the editor, you can add an EntitiesLayer and associate to it a mod (TW07, Infection, DDRace, ...). Then, you can click to a button to add points inside. Each points contains a type. Based on the type id, an icon is displayed at the position of the point. You can move it and change the type at any moment.
In the server, when the map is loaded, the server reads each entity point and calls the GameServer for each of them. Then the mod can decide what to do with it.
In the client, nothing happens because entities points is only interesting for the server. The server could clean up this part before sending the map, to reduce the size of the map.

The mod part in the editor will be described by two files: an image (icons) and a text file. The text file contains the list of each type of entity, with the type ID, the name, a description and the list of parameters that it can take.

This system allows to place entities in world coordinate, not in tile coordinates. So it's more precise, but you can still align them to the grid if you want (Alt).

In the future, we could add also EntityLines and EntityQuads.

Edit: Screenshot of the editor in the current state. EntityTiles (the ones from vanilla TW) are shown by the usual square sprites. EntityPoints (the new ones) are shown by round sprites. The interface is far from perfect, but it's working

The .mod file is being saved like maps oO
Or did I misunderstand you?

The main problem is that most of players don't care about the editor. So they will have to download more images for nothing. Since download in TW is very slow, in particular in some countries, it's not an option :-/ I think that we could clean up the map from server-only information before send it to the client. We can also clean it from graphics if the client ask for it (for low connexion). A third parameters could be "download the Editor package".

Actually, there is a folder ./data/modapi/editor that contains mymod.png (image) and mymod.entitylist (text file). I will stay with that for now because it's super easy to edit. But we can think about a better solution, using the storage system of TW.

Clearly, the .modinfo file is the minimum that we can do, but sufficient for the first "release".

I return back to the weapon system. I confirm that custom animation (for tees and weapons) will be added. So hand fighting could be implemented with ModAPI Teeworlds has already an animation system but limited. So they hard code some other animation (recoil). It's not at all flexible enough for the custom weapon system of ModAPI, so we have to implement our own animation system.

We can discuss the structure of the new animation system (please don't talk about bones or meshes, TW a sprite-based game). There is two level of discussion, the animation of a sprite (CModAPI_Animation) and the animation of a tee (CModAPI_TeeAnimation) that should use multiple CModAPI_Animation.

For CModAPI_Animation, we can start from what is done in vanilla TW, multiple keyframe on a time line between 0 and 1. Each KeyFrame has a X,Y coordinate and an angle. The CModAPI_Animation must contain an option to change the interpolation system (linear, sin, ...).

For CModAPI_TeeAnimation, each body part could has its own CModAPI_Animation : body, left hand, right hand, left foot, right foot and eyes. Animation of hands can be oriented by default to the aim direction.

Devlog: I've implemented the custom animation system for sprites. When you create a mod, you can define some animations with a list of key frames. These animations will be downloaded by the client thanks to the .mod file system. If you define also an AnimatedSprite (a sprite associated with an animation and some options), then you can send during the game an animated sprite.
Concretely, this allows to create floating effect for flying sprites, but also complicated mini-boss with attack animation if you want since you can send multiple CNetOject_ModAPI_AnimatedSprite with a custom animation for each.

I don't think it matters for ModAPI to what else projects I contribute, right? Also, apart from that: What you mean is not a "spoofing system"!! It is just another useless teeworlds client, which can send messages to an external server! Nothing bad about that!

Second, I don't understand why teeworlds devs should have write access but not the people who contributed actively to ModAPI. They seem to be really not interested in the ModAPI, and to be honest, there are only one or maybe two who would possibly do something for any mod.
But do what you want, it is yours project, so I will not argue about this.