Jump to content

Recommended Posts

Posted (edited)

Your answer doesn't answer all of my questions, even worst it's the reverse of what you said one post higher.

 

What you highlighted in your first post is the tip of the iceberg, there are a lot of other things to think about : notably AI (both intention AI and event based AI aka scripts), knownlist system (which is atm handled by 11264 L2WorldRegion for IL size map = 22k CHMap, and 1 CHMap per spawn = 45k+ CHMap refreshed every 1,25sec), scripts system. Skill XML engine is the least of your problem (moreover when it actually works exactly as it should).

 

About L2J coding, the whole architecture is pretty much fine, if you do something from scratch, it will look as L2J on the biggest part. You still need a World class, a WorldRegion class, a class which defines Player, etc. 99% of existing variables are needed, few can be cleaned up. 90% of classes are legit (and I would say, based on how L2JFree Genesis and regular Java projects are handled, L2J got like 2x lesser classes that it should - ppl like abstraction so much).

 

Then you got big changes, like... Using a Object oriented database framework, which introduces overhead. Using Netty, which introduces a lot of overhead (from Netty 3 to 4 they divided overhead by 5, just to give you the amount of overhead it creates). Or your reddwarf middleware which is probably also an overhead by itself.

 

More you add external technologies, bigger is the overhead. That's the only point I agree with russians, which developped "commons" package a long time ago.

 

But well, I'm maybe used to L2J. I doubt you can do it easier to understand (in term of organization) with no overhead cost. At least, me, I can't.

 

Moreover, I doubt you will have "time". That's the biggest problem in developpement.

Edited by Tryskell
Posted

So, finally :), AI system and knownlists.

 

I would build a more simplified system for how character AIs and their knownlists are managed.

Also I would definetly not use copy paste retail logic, based on leaked files, I would do what it is expected to be done from a players point of view.

That would help keep it really simplified and optimised.

 

Like a basic character AI that players, npcs and monsters would extend it.

If an NPC or Monster would need something special, I would make a script for it.

Posted (edited)

Go nio-like AIs and tickrate update based servers, that would be a great change

 

LOAD BALANCING ? +++

Edited by xxdem
Posted (edited)

So, finally :), AI system and knownlists.

 

I would build a more simplified system for how character AIs and their knownlists are managed.

Also I would definetly not use copy paste retail logic, based on leaked files, I would do what it is expected to be done from a players point of view.

That would help keep it really simplified and optimised.

 

Politicans speech, "I would make a wonderful world" :D You only speak about theory, reality is different.

 

"NPC AI from player PoV", what does it mean ? You got a NPC who "listens" different types of actions, nothing more.

 

 

Like a basic character AI that players, npcs and monsters would extend it.

If an NPC or Monster would need something special, I would make a script for it.

 

You probably missed entirely the model.ai package, because it's exactly what is it. And next sentence is exactly what L2J is... A specific script for specific case, with the main script being L2AttackableAIScript.

Edited by Tryskell
Posted

You act like you haven't read those scripts.

I took a look at them 2-3 days ago, while I made various code rework on my project.

L2J AIs are "badly" written, following "retail logic" and over-complicating script on many cases.

I would simple choose not to do that on a new project.

 

Take a step further from core AI and see NPC instances.

By todays L2J server scripting potential, they have absolutelly no reason to exist, they may as well have their own script managing them.

From my point of view, its like having two systems doing the same thing.

Posted

Just a pointer on the fact that if we started developing anew things would be more optimised.

Optimization comes with testing. And there is nothing more tested than l2j itself.

Posted

Optimization comes with testing. And there is nothing more tested than l2j itself.

 

You are SO wrong.

Testing equals to things made to work, nothing more.

Run some code coverage plugins on Eclipse and see how much optimised L2J trully is.

 

Also this is not a post on how good L2J is, you get out of the point.

Stick on topic please.

Posted (edited)

You are SO wrong.

Testing equals to things made to work, nothing more.

Run some code coverage plugins on Eclipse and see how much optimised L2J trully is.

 

Also this is not a post on how good L2J is, you get out of the point.

Stick on topic please.

I am sticking on the topic. I am explaining that optimization does come with testing.

If you develop a project using TDD then it will be optimized as you develop it.

If you just start developing it blindfolded you will get nowhere.

 

You NEED to have to in order to optimize. You can't write optimized code because optimization

depends in the wider spectrum of your project. Basic software engineering.

 

EDIT: I never said that l2j is optimized. It is pure shit but it has been tested over the years so you know

what performs better and what not.

Edited by .Elfocrash
Posted

Knownlist and AI are poor motivators.

 

Both can be reworked without trashing the rest, even if you plan going full custom.

 

But yeah you need to see how long it will take you to get there, it's nothing like adding a few skill or quest. We have a design for AI in mind for a while now, but it's risky :D

Posted (edited)

Knownlist and AI are poor motivators.

 

For a "rework from scratch" I fully agree. In fact any scenario is a poor motivator to rework all (even if you sum up all those little reworks). If L2J must be made from scratch it has either to be "insane performance boost" or "really easier design", otherwise I don't see the point.

 

Every single point stated as TODO (either by Mobius, me or UnAfraid/you) can be reworked one after the other, without having to build things from zero.

 

Ppl blames L2J but continue to use it, and when they try to do different and from scratch it ends as "L2JFree Genesis". If it's still used there is a reason, either none is enough brave to make it from zero (and even me, as a big reworker, I see no use to go that path) or there is no reason to do so. Pick your preference.

Edited by Tryskell
Posted

This forum is full of shit, lots of talking, lots of ideas.

 

All abandoned during the week. Please all of you deal with this fact and gtfo.

Posted (edited)

This forum is full of shit, lots of talking, lots of ideas.

 

All abandoned during the week. Please all of you deal with this fact and gtfo.

"Java is not VM language" - xDem 2016

 

E7wcB.gif

Edited by .Elfocrash

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



  • Posts

    • ## SuperPoint Editor   SuperPoint Editor is a practical visual editor for Lineage II PTS 'SuperPoint.bin' files. It is built for people who need to inspect, fix, rebuild, and draw server routes without digging through binary data by hand.   ### What You Can Do   - Open and edit 'SuperPoint.bin' files. - Export BIN data into a readable TXT format. - Save edited data back into a valid BIN file. - Validate routes before saving. - Work with SuperPoint routes, points, directed connections, and path records in tables. - Add, duplicate, delete, and reorder points. - Create direct and reverse connections between route points. - Automatically generate connections between neighboring points. - Edit raw point coordinates: 'X', 'Y', 'Z', 'Index', and 'Delay'. - Keep route names and internal route data organized. - Use either English or Ukrainian interface language.   ### C4 Server Support   Some C4 servers have 'SuperPoint.bin', but do not have 'superpointinfo.txt' in scripts. The editor supports this case directly. When 'superpointinfo.txt' is not found near the BIN file, the editor can open the BIN in C4 mode. In this mode, 'Fstring ID' is disabled because that value belongs to 'superpointinfo.txt', not to the BIN itself. The editor will not generate or modify 'superpointinfo.txt' while working in this mode. This keeps C4 data clean and avoids creating script files that the server does not actually use.   ### superpointinfo.txt Support   For chronicles that do use 'superpointinfo.txt', the editor can load and synchronize it together with the BIN data. When saving, the editor updates route nodes and coordinates while preserving existing metadata such as: - 'npc_name' - 'move_type' - 'fstring_index' - 'social_number' - 'delay' New nodes are generated with safe default values, so existing script metadata is not accidentally wiped.   ### Geodata Tools   The editor can also open converted geodata '.dat' files and display them as a map. This makes route editing much more visual. You can: - Load geodata and inspect the terrain by layer. - Zoom and pan around the map. - Create a new SuperPoint directly from a map cell. - Draw a route by clicking on the geodata. - Drag existing points to new positions. - Automatically snap 'X/Y' to the selected geo cell. - Use the selected geodata layer to fill the point 'Z'. - See all routes on the map or focus only on the selected one. This is especially useful when building new NPC movement paths or correcting bad route coordinates.   ### Connections and Paths   SuperPoint connections are directional. A connection from point '3' to point '2' is not the same as a connection from point '2' to point '3'. The editor makes this explicit by separating: - route points, - directed connections, - and the actual path records used by each connection. For simple cases, it can create direct path records automatically. For more complex movement, you can edit the path points manually. ### Built for Safe Editing The editor includes validation before saving, so common structural problems can be caught before a broken BIN is produced. It also verifies rebuilt BIN files through the converter engine. The goal is simple: edit quickly, but do not silently damage server data.   ### Unknown Field   This small 'Unknown' field is part of the original BIN structure. Most official-looking files keep it as '0', and for regular route editing there is usually no reason to change it. The editor exposes it so nothing from the BIN is hidden or lost. If you do not know exactly what your server uses it for, keep it at '0'. Download
    • NpcGrp não salva no interlúdio e da crítico quando coloca ele no cliente, já testei ele antes.
  • Topics

×
×
  • Create New...

Important Information

This community uses essential cookies to function properly. Non-essential cookies and third-party services are used only with your consent. Read our Privacy Policy and We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue..